the problem (as I experience it, years from its first report), is that I set
"Paper size" in Firefox "Page Settings"
and this setting is lost every time Firefox is updated (as far as I can tell).
I think it should retain the settings made by the user after each update. Those
are the settings th
On 1 May 2010 07:32, Tero Karvinen wrote:
> Dave Martin, it's much worse than that. In not-uncommon printer
> configuration, sending a US-letter job to printer requires physically
> going to the printer and pressing buttons. Until that, the printer is in
> error state and the whole print queue is
** Changed in: linux (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/992424
Title:
ext4 filesystem errors on SSD disk
To manage notifications about thi
Sorry. I accidentally changed the status from Triaged, thinking I was
clicking through to more details, and it won't let me change it back.
Perhaps someone can revert that change.
I was intending just to add a note that this bug has been affecting
several different Ubuntu systems I maintain for my
@Thomas See my last message. I used the web page interface incorrectly
and then could not undo my mistake.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/992424
Title:
ext4 filesystem errors on SSD d
It might be worth noting that the bug is fairly nasty. I had to recover my
system yesterday afternoon. Today, after the overnight locatedb build (which
might be disk intensive), but relatively little use of the disk during a few
hours of normal work, the bug was triggered again by my downloading
And this just in:
Linux ... 3.6.2-030602-generic #201210121823 SMP Fri Oct 12 22:31:22 UTC 2012
i686 i686 i386 GNU/Linux
[88861.206938] EXT4-fs error (device sda1): __ext4_ext_check_block:472: inode
#1080426: comm Chrome_CacheThr: bad header/extent: invalid magic - magic 81a4,
entries 1000, max
I turned off the "discard" option last week after the first bout of
trouble, based on a suggestion in a google'd bug tracker that there was
an off-by-one in scsi_debug in the part that implemented trim. (Not that
I thought I was running scsi_debug, but since I was having similar
problems I suspecte
Since I get problems anyway, I've enabled "discard" again.
I might be willing to believe my SSD has hardware problems or is wearing out,
but I've seen trouble on two different systems so far.
Also, int February, when I had corruption with ext2/3, I thought it might be
memory or SSD, but memory t
Since I seem to be able to reproduce it, not at will, but at least with the
passage of a day or two,
is there something constructive I could do to help track this down? It looks
useful to run with a USB
stick attached and mounted, so I can copy logs etc onto it when things go wrong.
--
You rece
@André
By being able to reproduce it, I meant only that it happens so regularly from
day to day that I can try to capture more information: it isn't "once in a blue
moon". It does seem to be a function of the amount of file IO (which makes
sense), so I thought I might risk generating a load synt
Today's contribution, after hardly any work (allowing for overnight
locatedb updates and anything else the cron might do.
[70391.556798] EXT4-fs error (device sda1): __ext4_ext_check_block:472: inode
#560844: comm Chrome_CacheThr: bad header/extent: invalid magic - magic 3262,
entries 13113, max
I think I know what it is, in my case. If my revised system gets through
the next few days, let alone a week, without trouble, I'll think it is
reasonably certain.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.
I was wrong about that. fsck -c -c -k ... had found 3 bad blocks, so I thought
"ah! it was device error after all".
Having moved the bad blocks out of the way, I expected all to return to normal,
and would have changed to moaning
about the complete lack of visible diagnostics (including in dmesg)
I wondered whether ext4_mb_generate_buddy might be related to
http://help.lockergnome.com/linux/ext4fs-error-ext4_mb_generate_buddy-741-group-16-8160-cluste--ftopict559576.html
so for a final experiment, I've switched off "discard" once more. That bug
seemed confined to scsi_debug, but who knows?
If I get through the next day or two without the problems that plagued
me last week, that might suggest trying again with "discard" to see if
problems reappear.
On the other hand, if I have further trouble, I've got a new replacement
SSD to try.
Since my usage doesn't seem to be that unusual, and
At 2am, after working away happily for 1.5 days (I copied the work out
regularly), some time after a 45Mbyte Software Update, it
began to go wrong. A reboot prompted the following repair, and I left it:
[6.314129] EXT4-fs (sda1): orphan cleanup on readonly fs
[6.314137] EXT4-fs (sda1): ex
Since I've been running days longer than previously (since the trouble
started at the star of October) with no errors at all, it seems to have
been a hardware problem. (One can imagine software problems that
depended on an odd structure in the original file system, and I didn't
copy the file system
18 matches
Mail list logo
