While I've been offline, I again had a 'scary' boot. Scary as in
"it's said its going to run fsck, but it appears to have died, with
nothing reported on the screen".
[ To my surprise, I'm back online again (very mixed feelings about
virgin media's phone processes - I got different options every time
I phoned them - but much outweighed by my joy at getting the current
kit replaced (so, not waiting for another 4+ weeks for the upgrade
I asked for after losing service, and double joy at not having to
re-register after the set-top box was replaced). ]
First noticed this a few weeks ago, but left the box and it was
ready for login when I came back to it. Put it down as "one of
those things". This time, I left it and after a few minutes it
continued to boot - I think it was probably fscking /home which is
ext3 on that machine (so I could run an old system if I wanted to),
so prone to taking longer to fsck than ext4.
Experimentation shows that the checkfs script now writes to
/dev/null during fsck (line 82):
fsck ${options} -a -A -C -T >/dev/null
The old pre-lfs-7.0 script didn't have that redirection. If I
remove that and then force an fsck with tune2fs -C, it gives me
a nice progress report like it always used to.
So, the big question: was that change intended ? Perhaps I notice
this more than other people - I normally boot whichever desktop I'm
using at least once a day, and sometimes several times (upgrading
packages on several still-usable systems, or just comparing
results), so I get fscks during boot fairly often. Of course, if
it's /boot that I'm fscking then it's done before I notice, and '/'
is usually quick.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
