Hi,
I just tried the 2.6.22-r1 candidate to test whether some bug I have
hit in the past still exists. I did use 2.6.20.6 so far. So, I have
cleanly rebooted to use the new kernel, after the machine came up I
tried to mess with the bug, and had to reboot again to play with kernel
commandline parameters. Unfortunately, on the next reboot fsck was
schedules on my filesystem after 38 clean mounts. :( And the problem
started. The fsck found some unused inodes, but probably did not know
where do they belong to, but it deleted them automagically. Finally, the
fsck died because it cannot fine some '..' entry.
Here is retyped what happened as recorded by my camera. ;)
/dev/hda3 has been mounted 38 times without being checked, check forced
HTREE directory inode 1163319 has an invalid root node.
HTREE INDEX CLEARED
Entry '..' in .../??? (5570587) has deleted/unused inode 5570561.
CLEARED.
/dev/hda3: Entry '..' in .../??? (5570620) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5570625) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5570567) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5570614) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5570603) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5586948) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5586957) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5701636) has deleted/unused inode
5570561. CLEARED.
Unconnected directory inode 5570567 (...)
/dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Turning off the power and booting back with 2.6.20.6 and obviously
running same fsck gives me:
/dev/hda3 contains a file system with errors, check forced.
Missing '..' in direcotry inode 5570587.
/dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
What do you recommend me now?
I cannot say what is the fsck version, but I can tell you this is a
Gentoo linux box in the ~x86 tree, so whatever is in the "unstable"
branch. :(
I do use ext2/ext3 windows driver from http://www.fs-driver.org/ to
access the filesystem. Even now, when the filesystem should be marked as
dirty I can access it from windows and see the files. Does the extfs.sys
ignore the mark? ;) Anyway, since that time there is a directory
'Recycled' at the top level of the filesystem. ;-)
I do remember recently that possibly one of the system packages in
Gentoo installed some kind of a hash into the filesystem, or hashing
support, something like that. Sorry, I do not remember the details.
Am just think what could have made the fsck think there is something
wrong.
I think IO would like to restore the filesystem to the previous stage
before running the fsck. How can I do it? No, I do not have a backup of
the filesystem. :(
I subscribed to the email lists but please send me Cc: anyway. Many thanks.
Martin
On Fri, 18 May 2007 11:06:04 +0200
Martin Mokrejs <[email protected]> bubbled:
> I cannot say what is the fsck version, but I can tell you this is a
> Gentoo linux box in the ~x86 tree, so whatever is in the "unstable"
> branch. :(
FYI:
# eix e2fs
[I] sys-fs/e2fsprogs
Available versions: 1.39 ~1.39-r1 1.39-r2 ~1.40_pre20070411
So probably 1.40_pre20070411.
Regards,
Martin
--
MyExcuse:
/pub/lunch
Martin Zwickel <[email protected]>
Research & Development
On Fri, 2007-05-18 at 11:06 +0200, Martin Mokrejs wrote:
> Hi,
> I just tried the 2.6.22-r1 candidate to test whether some bug I have
> hit in the past still exists. I did use 2.6.20.6 so far. So, I have
> cleanly rebooted to use the new kernel, after the machine came up I
> tried to mess with the bug, and had to reboot again to play with kernel
> commandline parameters. Unfortunately, on the next reboot fsck was
> schedules on my filesystem after 38 clean mounts. :( And the problem
> started. The fsck found some unused inodes, but probably did not know
> where do they belong to, but it deleted them automagically. Finally, the
> fsck died because it cannot fine some '..' entry.
>
> /dev/hda3: Entry '..' in .../??? (5701636) has deleted/unused inode
> 5570561. CLEARED.
> Unconnected directory inode 5570567 (...)
>
> /dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> (i.e., without -a or -p options)
>
This means that e2fsck has reached a point where it needs user
intervention. So you should not run e2fsck with -p, -a or -y options.
Look up the e2fsck man page for more on this.
Thanks,
Kalpak.
<< snip >>
> I do remember recently that possibly one of the system packages in
> Gentoo installed some kind of a hash into the filesystem, or hashing
> support, something like that. Sorry, I do not remember the details.
> Am just think what could have made the fsck think there is something
> wrong.
>
> I think IO would like to restore the filesystem to the previous stage
> before running the fsck. How can I do it? No, I do not have a backup of
> the filesystem. :(
>
> I subscribed to the email lists but please send me Cc: anyway. Many thanks.
> Martin
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Fri, May 18, 2007 at 05:17:06PM +0530, Kalpak Shah wrote:
> On Fri, 2007-05-18 at 11:06 +0200, Martin Mokrejs wrote:
> > Hi,
> > I just tried the 2.6.22-r1 candidate to test whether some bug I have
> > hit in the past still exists. I did use 2.6.20.6 so far. So, I have
> > cleanly rebooted to use the new kernel, after the machine came up I
> > tried to mess with the bug, and had to reboot again to play with kernel
> > commandline parameters. Unfortunately, on the next reboot fsck was
> > schedules on my filesystem after 38 clean mounts. :( And the problem
> > started. The fsck found some unused inodes, but probably did not know
> > where do they belong to, but it deleted them automagically. Finally, the
> > fsck died because it cannot fine some '..' entry.
> >
> > /dev/hda3: Entry '..' in .../??? (5701636) has deleted/unused inode
> > 5570561. CLEARED.
> > Unconnected directory inode 5570567 (...)
> >
> > /dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> > (i.e., without -a or -p options)
> >
>
> This means that e2fsck has reached a point where it needs user
> intervention. So you should not run e2fsck with -p, -a or -y options.
> Look up the e2fsck man page for more on this.
Yeah, stupid init.d script in Gentoo. I will report at Gentoo as well but
how can I revert the changes? Can you say which directories were affected?
Thanks,
Martin
On Fri, 2007-05-18 at 15:51 +0200, Martin Mokrejs wrote:
> On Fri, May 18, 2007 at 05:17:06PM +0530, Kalpak Shah wrote:
> > On Fri, 2007-05-18 at 11:06 +0200, Martin Mokrejs wrote:
> > > Hi,
> > > I just tried the 2.6.22-r1 candidate to test whether some bug I have
> > > hit in the past still exists. I did use 2.6.20.6 so far. So, I have
> > > cleanly rebooted to use the new kernel, after the machine came up I
> > > tried to mess with the bug, and had to reboot again to play with kernel
> > > commandline parameters. Unfortunately, on the next reboot fsck was
> > > schedules on my filesystem after 38 clean mounts. :( And the problem
> > > started. The fsck found some unused inodes, but probably did not know
> > > where do they belong to, but it deleted them automagically. Finally, the
> > > fsck died because it cannot fine some '..' entry.
> > >
> > > /dev/hda3: Entry '..' in .../??? (5701636) has deleted/unused inode
> > > 5570561. CLEARED.
> > > Unconnected directory inode 5570567 (...)
> > >
> > > /dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> > > (i.e., without -a or -p options)
> > >
> >
> > This means that e2fsck has reached a point where it needs user
> > intervention. So you should not run e2fsck with -p, -a or -y options.
> > Look up the e2fsck man page for more on this.
>
> Yeah, stupid init.d script in Gentoo. I will report at Gentoo as well but
> how can I revert the changes? Can you say which directories were affected?
No there is nothing wrong with your script, most problems get solved by
-a or -p and hence your init.d script is correct in using these options.
I don't understand what you mean by reverting your changes.
An unconnected directory inode means that this directory (inode 5570567)
does not have a valid ".." entry (which is the backpointer to its
parent). So this directory will be moved to lost+found.
Thanks,
Kalpak.
> Thanks,
> Martin
On 18/05/07, Martin Mokrejs <[email protected]> wrote:
> Hi,
> I just tried the 2.6.22-r1 candidate to test whether some bug I have
> hit in the past still exists. I did use 2.6.20.6 so far. So, I have
> cleanly rebooted to use the new kernel, after the machine came up I
> tried to mess with the bug, and had to reboot again to play with kernel
> commandline parameters. Unfortunately, on the next reboot fsck was
> schedules on my filesystem after 38 clean mounts. :( And the problem
> started. The fsck found some unused inodes, but probably did not know
> where do they belong to, but it deleted them automagically. Finally, the
> fsck died because it cannot fine some '..' entry.
>
How do you know that the corruption was caused by 2.6.21-rc1 ?
Isn't it possible that the corruption was created by an earlier
kernel, but only detected when a forced fsck was run - which just
happened to be while you were running 2.6.21-rc1 ...
My point is that, as far as I can see, there's nothing tying
2.6.21-rc1 specifically to this corruption... or?
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Fri, May 18, 2007 at 07:38:18PM +0530, Kalpak Shah wrote:
> On Fri, 2007-05-18 at 15:51 +0200, Martin Mokrejs wrote:
> > On Fri, May 18, 2007 at 05:17:06PM +0530, Kalpak Shah wrote:
> > > On Fri, 2007-05-18 at 11:06 +0200, Martin Mokrejs wrote:
> > > > Hi,
> > > > I just tried the 2.6.22-r1 candidate to test whether some bug I have
> > > > hit in the past still exists. I did use 2.6.20.6 so far. So, I have
> > > > cleanly rebooted to use the new kernel, after the machine came up I
> > > > tried to mess with the bug, and had to reboot again to play with kernel
> > > > commandline parameters. Unfortunately, on the next reboot fsck was
> > > > schedules on my filesystem after 38 clean mounts. :( And the problem
> > > > started. The fsck found some unused inodes, but probably did not know
> > > > where do they belong to, but it deleted them automagically. Finally, the
> > > > fsck died because it cannot fine some '..' entry.
> > > >
> > > > /dev/hda3: Entry '..' in .../??? (5701636) has deleted/unused inode
> > > > 5570561. CLEARED.
> > > > Unconnected directory inode 5570567 (...)
> > > >
> > > > /dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> > > > (i.e., without -a or -p options)
> > > >
> > >
> > > This means that e2fsck has reached a point where it needs user
> > > intervention. So you should not run e2fsck with -p, -a or -y options.
> > > Look up the e2fsck man page for more on this.
> >
> > Yeah, stupid init.d script in Gentoo. I will report at Gentoo as well but
> > how can I revert the changes? Can you say which directories were affected?
>
> No there is nothing wrong with your script, most problems get solved by
> -a or -p and hence your init.d script is correct in using these options.
>
> I don't understand what you mean by reverting your changes.
I would like to boot with another/previous/tested kernel and run another,
stable fsck version. Yes, I cannot say how it happened that ext3 had broken
directory, but for sure before making changes to the filesystem I would
boot with a tested kernel and tools.
>
> An unconnected directory inode means that this directory (inode 5570567)
> does not have a valid ".." entry (which is the backpointer to its
> parent). So this directory will be moved to lost+found.
And those original "errors"? Did not those modifications cause this in turn?
/dev/hda3 has been mounted 38 times without being checked, check forced
HTREE directory inode 1163319 has an invalid root node.
HTREE INDEX CLEARED
Entry '..' in .../??? (5570587) has deleted/unused inode 5570561.
CLEARED.
/dev/hda3: Entry '..' in .../??? (5570620) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5570625) has deleted/unused inode
5570561. CLEARED.
/dev/hda3: Entry '..' in .../??? (5570567) has deleted/unused inode
5570561. CLEARED.
[cut]
Martin
On Fri, May 18, 2007 at 04:20:39PM +0200, Jesper Juhl wrote:
> On 18/05/07, Martin Mokrejs <[email protected]> wrote:
> > Hi,
> > I just tried the 2.6.22-r1 candidate to test whether some bug I have
> > hit in the past still exists. I did use 2.6.20.6 so far. So, I have
> > cleanly rebooted to use the new kernel, after the machine came up I
> > tried to mess with the bug, and had to reboot again to play with kernel
> > commandline parameters. Unfortunately, on the next reboot fsck was
> > schedules on my filesystem after 38 clean mounts. :( And the problem
> > started. The fsck found some unused inodes, but probably did not know
> > where do they belong to, but it deleted them automagically. Finally, the
> > fsck died because it cannot fine some '..' entry.
> >
>
> How do you know that the corruption was caused by 2.6.21-rc1 ?
> Isn't it possible that the corruption was created by an earlier
> kernel, but only detected when a forced fsck was run - which just
> happened to be while you were running 2.6.21-rc1 ...
>
> My point is that, as far as I can see, there's nothing tying
> 2.6.21-rc1 specifically to this corruption... or?
You might be right, but I thought maybe more probably is the cause in kernel
as that is what I have changed recently. ;) Or maybe someone can at leats say
"No, no changes to be considered between 2.6.20.6 and 2.6.22-rc1.". ;)
Martin
On Fri, May 18, 2007 at 04:35:29PM +0200, Martin Mokrejs wrote:
> > How do you know that the corruption was caused by 2.6.21-rc1 ?
> > Isn't it possible that the corruption was created by an earlier
> > kernel, but only detected when a forced fsck was run - which just
> > happened to be while you were running 2.6.21-rc1 ...
> >
> > My point is that, as far as I can see, there's nothing tying
> > 2.6.21-rc1 specifically to this corruption... or?
>
> You might be right, but I thought maybe more probably is the cause in kernel
> as that is what I have changed recently. ;) Or maybe someone can at leats say
> "No, no changes to be considered between 2.6.20.6 and 2.6.22-rc1.". ;)
Well, given that your e2fsck transcript started with this:
> /dev/hda3 has been mounted 38 times without being checked, check forced
#1, This is why periodic checks are a good thing; it catches problems
that could stay hidden and result in data loss sooner rather later.
#2, It seems unlikely tha tthe problem is tied to 2.6.21-rc1. The
filesystme corruption could have happened at any time in the last 38
mounts. It could be caused by hardware problems, or software
problems; there really is no telling.
#3, With respect to your use of gentoo's unstable e2fsprogs, it seems
unlikely that the corruptions were caused by gentoo's e2fsprogs. The
being said, Gentoo includes a number of development patches that I
wouldn't necessarily feel comfortable putting into production, and
indeed haven't been checked into SCM yet. So it makes me nervous, but
I doubt it's related to your specific problem.
Regards,
- Ted
Hi!
> > > How do you know that the corruption was caused by 2.6.21-rc1 ?
> > > Isn't it possible that the corruption was created by an earlier
> > > kernel, but only detected when a forced fsck was run - which just
> > > happened to be while you were running 2.6.21-rc1 ...
> > >
> > > My point is that, as far as I can see, there's nothing tying
> > > 2.6.21-rc1 specifically to this corruption... or?
> >
> > You might be right, but I thought maybe more probably is the cause in kernel
> > as that is what I have changed recently. ;) Or maybe someone can at leats say
> > "No, no changes to be considered between 2.6.20.6 and 2.6.22-rc1.". ;)
>
> Well, given that your e2fsck transcript started with this:
>
> > /dev/hda3 has been mounted 38 times without being checked, check forced
>
> #1, This is why periodic checks are a good thing; it catches problems
> that could stay hidden and result in data loss sooner rather later.
Actually, I see something funny with periodic checks here. It claims
'filesystem check on next boot' for >10 boots now.
It is sharp zaurus machine, and the filesystem tends to _never_ be
unmounted correctly (broken scripts), so I get journal replay each
time.
Anyone else sees that?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, May 20, 2007 at 07:55:26PM +0000, Pavel Machek wrote:
> > #1, This is why periodic checks are a good thing; it catches problems
> > that could stay hidden and result in data loss sooner rather later.
>
> Actually, I see something funny with periodic checks here. It claims
> 'filesystem check on next boot' for >10 boots now.
>
> It is sharp zaurus machine, and the filesystem tends to _never_ be
> unmounted correctly (broken scripts), so I get journal replay each
> time.
The Sharp Zaurus is a PDA which is almost always running on battery,
right? You need to add to /etc/e2fsck.conf:
[options]
defer_check_on_battery = false
See the e2fsck.conf man page for more details, but basically, e2fsck
was optimized for x86 laptops that have such lousy batttery life that
people generally try to run AC adapters to avoid killing the laptop
battery --- and for which running a spinning hard drive platters for
an extended time to fsck a 100GB drive might not be such a hot idea.
So we try to defer the periodic fsck until the laptop is back on AC
power. But for a PDA running a flash drive which is almost always
running on battery you'll want to change the default using
e2fsck.conf.
- Ted
Hi!
> > > #1, This is why periodic checks are a good thing; it catches problems
> > > that could stay hidden and result in data loss sooner rather later.
> >
> > Actually, I see something funny with periodic checks here. It claims
> > 'filesystem check on next boot' for >10 boots now.
> >
> > It is sharp zaurus machine, and the filesystem tends to _never_ be
> > unmounted correctly (broken scripts), so I get journal replay each
> > time.
>
> The Sharp Zaurus is a PDA which is almost always running on battery,
> right? You need to add to /etc/e2fsck.conf:
Right. Could we get more helpful message here? 'Filesystem check on
next boot on AC power'? Or maybe keep counting, and when we reach 2x
mount-count-limit, force a fsck, battery power or not?
> [options]
> defer_check_on_battery = false
I guess openembedded people should make this default on zauruses...
> power. But for a PDA running a flash drive which is almost always
> running on battery you'll want to change the default using
> e2fsck.conf.
I'll just remember to do it manually, I guess.
But here's what I've got:
oot@spitz:/home/pavel# fsck.ext2 -f /dev/hda3
e2fsck 1.38 (30-Jun-2005)
Pass 1: Checking inodes, blocks, and sizes
Inode 371989 has illegal block(s). Clear<y>? yes
Illegal block #2 (134217728) in inode 371989. CLEARED.
Pass 2: Checking directory structure
i_file_acl for inode 371988 (/home/root/misc/zaurus/smail) is 131072,
should be zero.
Clear<y>? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -339972 +471044
Fix<y>? yes
Free blocks count wrong for group #10 (13882, counted=13883).
Fix<y>? yes
...kernel 2.6.16-preempt (on zaurus). Filesystem should have been clean -- I was
using it till crash for half a year, but that's what journal is for,
right? ...But I guess this is almost impossible to debug?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hello,
> But here's what I've got:
>
> oot@spitz:/home/pavel# fsck.ext2 -f /dev/hda3
> e2fsck 1.38 (30-Jun-2005)
> Pass 1: Checking inodes, blocks, and sizes
> Inode 371989 has illegal block(s). Clear<y>? yes
>
> Illegal block #2 (134217728) in inode 371989. CLEARED.
> Pass 2: Checking directory structure
>
> i_file_acl for inode 371988 (/home/root/misc/zaurus/smail) is 131072,
> should be zero.
> Clear<y>? yes
>
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> Block bitmap differences: -339972 +471044
> Fix<y>? yes
>
> Free blocks count wrong for group #10 (13882, counted=13883).
> Fix<y>? yes
>
> ...kernel 2.6.16-preempt (on zaurus). Filesystem should have been clean -- I was
> using it till crash for half a year, but that's what journal is for,
> right? ...But I guess this is almost impossible to debug?
Actually, your case doesn't seem to be hard. The first block number
is 0x8000000 and the second one 0x20000. So something is flipping your
bits...
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
Hi!
> > But here's what I've got:
> >
> > oot@spitz:/home/pavel# fsck.ext2 -f /dev/hda3
> > e2fsck 1.38 (30-Jun-2005)
> > Pass 1: Checking inodes, blocks, and sizes
> > Inode 371989 has illegal block(s). Clear<y>? yes
> >
> > Illegal block #2 (134217728) in inode 371989. CLEARED.
> > Pass 2: Checking directory structure
> >
> > i_file_acl for inode 371988 (/home/root/misc/zaurus/smail) is 131072,
> > should be zero.
> > Clear<y>? yes
> >
> > Pass 3: Checking directory connectivity
> > Pass 4: Checking reference counts
> > Pass 5: Checking group summary information
> > Block bitmap differences: -339972 +471044
> > Fix<y>? yes
> >
> > Free blocks count wrong for group #10 (13882, counted=13883).
> > Fix<y>? yes
> >
> > ...kernel 2.6.16-preempt (on zaurus). Filesystem should have been clean -- I was
> > using it till crash for half a year, but that's what journal is for,
> > right? ...But I guess this is almost impossible to debug?
> Actually, your case doesn't seem to be hard. The first block number
> is 0x8000000 and the second one 0x20000. So something is flipping your
> bits...
Hmm, ouch. Yes, that machine was pretty unstable after repeated
suspend-to-RAMs, so I guess this is a symptom of same problem. Sorry
about noise.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, May 24, 2007 at 05:39:11PM +0000, Pavel Machek wrote:
> Right. Could we get more helpful message here? 'Filesystem check on
> next boot on AC power'?
So "(check deferred; on battery)" wasn't explicit enough? I guess I
assumed that users would understand that the opposite of "on battery"
was "on AC power". I guess I could say "(check defferred 'til on AC
power)" if people think it would be clearer.
> Or maybe keep counting, and when we reach 2x mount-count-limit,
> force a fsck, battery power or not?
We do that already. It's just tough to make that all fit on an 80
status message. :-)
- Ted
On Monday May 28, [email protected] wrote:
> On Thu, May 24, 2007 at 05:39:11PM +0000, Pavel Machek wrote:
> > Right. Could we get more helpful message here? 'Filesystem check on
> > next boot on AC power'?
>
> So "(check deferred; on battery)" wasn't explicit enough? I guess I
> assumed that users would understand that the opposite of "on battery"
> was "on AC power". I guess I could say "(check defferred 'til on AC
> power)" if people think it would be clearer.
>
So when I use my travelling power adapter which I plug into the 12V-DC
power in my car, and it delivers DC power to my notebook.....
My note book tells me that I am using AC power....
I really think "AC" as the opposite of "battery" is wrong and should
be stamped out everywhere, certainly not introduced here.
"external power" maybe?
Check deferred until system is externally powered.
NeilBrown
Hi!
> > Right. Could we get more helpful message here? 'Filesystem check on
> > next boot on AC power'?
>
> So "(check deferred; on battery)" wasn't explicit enough? I guess I
> assumed that users would understand that the opposite of "on battery"
> was "on AC power". I guess I could say "(check defferred 'til on AC
> power)" if people think it would be clearer.
I did not see the "check deffered; on battery" message. Either I'm
blind, or am using too old fsck. Sorry for noise.
> > Or maybe keep counting, and when we reach 2x mount-count-limit,
> > force a fsck, battery power or not?
>
> We do that already. It's just tough to make that all fit on an 80
> status message. :-)
Great, sorry for more noise.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue 2007-05-29 13:05:29, Neil Brown wrote:
> On Monday May 28, [email protected] wrote:
> > On Thu, May 24, 2007 at 05:39:11PM +0000, Pavel Machek wrote:
> > > Right. Could we get more helpful message here? 'Filesystem check on
> > > next boot on AC power'?
> >
> > So "(check deferred; on battery)" wasn't explicit enough? I guess I
> > assumed that users would understand that the opposite of "on battery"
> > was "on AC power". I guess I could say "(check defferred 'til on AC
> > power)" if people think it would be clearer.
> >
>
> So when I use my travelling power adapter which I plug into the 12V-DC
> power in my car, and it delivers DC power to my notebook.....
> My note book tells me that I am using AC power....
>
> I really think "AC" as the opposite of "battery" is wrong and should
> be stamped out everywhere, certainly not introduced here.
> "external power" maybe?
Well, on one sunny day, we'll want to tell the difference between
"cheap" power and "expensive" power.
zaurus running on AC or car adapter is "cheap".
zaurus running from external notebook's battery is something in
between -- given that notebook battery should keep zaurus powered for
few weeks.
zaurus running on external 4xAA batteries or on internal li-ion is
"expensive".
...but I'm afraid it will take long time before we can worry about that.
> Check deferred until system is externally powered.
Check deferred; on battery is completely fine; I just did not see that
message for some reason.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html