I am using 2.6.9-rc2.
I had a hard hung (only Alt-SysReq-b helped me in recovering.).
Anyway, during the rebooting and expecting fsck run,
I had this very uncomfortable experience of
fsck message not displayed at all.
That is, under previous 2.4.xx kernel, I would have gotten
"The disk was not unmounted cleanly. Running fsck." or
some such message and fsck printed its
progress bar using ASCII characters.
But this message was not shown at all and
fsck seemed to have run without any message at all.
This is very disturbing to a home user.
I wish that this fsck message is restored
and visible during booting.
Since I was testing the release candidate version,
when I didn't see the fsck message and yet hear
the disk head moving around, I was afraid that something
amiss was happening and RESET the pc box and
rebooted in 2.4.2x kernel and made sure fsck run
to completeion with its visible message lines.
(Maybe somebody decided to hide the fsck messages
for users with thousands of disks attached?
I am not sure if this is a good idea to disable the
message by default.)
Please cc: me if you need a response from me.
I am not subscribed to LKML.
--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
In article <[email protected]> you wrote:
> That is, under previous 2.4.xx kernel, I would have gotten
> "The disk was not unmounted cleanly. Running fsck." or
> some such message and fsck printed its
> progress bar using ASCII characters.
Well, this is not a kernel function, your Distribution is calling fsck in
the bootup scripts, and fsck is calling the filesystem specific
implementation and this is checking if fsck is needed.
If you do not get this messages anymore contact your linux distribution
provider.
Do you habe maybe a journalling filesystem? Or do you have set some flags to
force the skip of fsck (/fastboot)
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
>
>>That is, under previous 2.4.xx kernel, I would have gotten
>>"The disk was not unmounted cleanly. Running fsck." or
>>some such message and fsck printed its
>>progress bar using ASCII characters.
>
>
> Well, this is not a kernel function, your Distribution is calling fsck in
> the bootup scripts, and fsck is calling the filesystem specific
> implementation and this is checking if fsck is needed.
>
> If you do not get this messages anymore contact your linux distribution
> provider.
>
>
Thank you for the comment.
Well, I have installed 2.6.9-rc2 on my own after having used
Debian with my own updated kernel 2.4.2x series for a few years now.
I certainly upgraded moduleutil and other packages to run
2.6.9-rc2, but have not specifically updated fsck.
(I DID ran apt-get -u update and apt-get -u upgrade to pick up
the latest packages a week ago or so.).
Agreed that the starting fsck under stock Debian scheme
may depend on 2.4.xx features which may not be available
on 2.6.yy series kernel. I will get in contact with fsck
package (or boot script) maintainer to see
if we can improve this.
>Do you habe maybe a journalling filesystem? Or do you have set some
flags to
> force the skip of fsck (/fastboot)
>
Well, I am running 2.6.9-rc2 from loadlin as follows.
loadlin 269rc2 root=/dev/sda6 ro vga=3 scsihosts=sym53c8xx:tmscsim
I noticed the fsck message lines were missing on the reboot after
a hard-hung forced me to hit reset button in the end.
The message lines were missing, but it seems that fsck
certainly was running invisibly. Thus the
boot sequence halted as if the computer got hung again
until fsck finished and bootting continued. This was very
annoying.
--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
Chiaki wrote:
> Bernd Eckenfels wrote:
>
>> In article <[email protected]> you wrote:
>>
>>> That is, under previous 2.4.xx kernel, I would have gotten
>>> "The disk was not unmounted cleanly. Running fsck." or
>>> some such message and fsck printed its
>>> progress bar using ASCII characters.
>>
>>
>>
>> Well, this is not a kernel function, your Distribution is calling fsck in
>> the bootup scripts, and fsck is calling the filesystem specific
>> implementation and this is checking if fsck is needed.
>>
>> If you do not get this messages anymore contact your linux distribution
>> provider.
>>
>>
>
> Thank you for the comment.
>
> Well, I have installed 2.6.9-rc2 on my own after having used
> Debian with my own updated kernel 2.4.2x series for a few years now.
> I certainly upgraded moduleutil and other packages to run
> 2.6.9-rc2, but have not specifically updated fsck.
> (I DID ran apt-get -u update and apt-get -u upgrade to pick up
> the latest packages a week ago or so.).
>
> Agreed that the starting fsck under stock Debian scheme
> may depend on 2.4.xx features which may not be available
> on 2.6.yy series kernel. I will get in contact with fsck
> package (or boot script) maintainer to see
> if we can improve this.
>
> >Do you habe maybe a journalling filesystem? Or do you have set some
> flags to
> > force the skip of fsck (/fastboot)
> >
>
> Well, I am running 2.6.9-rc2 from loadlin as follows.
>
> loadlin 269rc2 root=/dev/sda6 ro vga=3 scsihosts=sym53c8xx:tmscsim
>
> I noticed the fsck message lines were missing on the reboot after
> a hard-hung forced me to hit reset button in the end.
> The message lines were missing, but it seems that fsck
> certainly was running invisibly. Thus the
> boot sequence halted as if the computer got hung again
> until fsck finished and bootting continued. This was very
> annoying.
>
OK, maybe I was not clear enough in the first post.
Fsck seemed to run during the reboot
after a reset button was hit to recover from a hard hung.
However, NO OUTPUT message from fsck is shown on the console.
It progressed silently : I could hear the disk access
(head movement) and this made me very uncomfortable.
With a test kernel accessing disk furiously without
telling me what it does during otherwise smooth booting
process after a hard reset, I may need to consider
the chance of kernel running wild and trashing the file system.
So that is why I rebooted the system using 2.4.xx which I have
used for quite a long time to make sure that the file system(s)
are fsck'ed and then cleanly remounted.
Anyway, before contacting the Debian package maintainer, I found
the following.
IF during the booting the environment variable TERM
is set to "dumb", "network", "unknown" or not set at all
the progressive horizontal bar display (-C option to fsck)
is disabled in the Debian startup script.
Maybe the TERM setup for console during booting has changed between
kernel 2.4.2x and 2.6.9-rc2?
A little more detail:
I checked the Debian startup script myself.
Now I notice that if the fsck is invoked in a startup script and $TERM is
set to "dumb" or "network" or "unknown" or not set at all, this
progress bar display (-C option to fsck)
is not done by the Debian start up script.
Maybe between 2.4.2x and 2.6.9-rc2,
the boot console $TERM setting changed?
--- begin Excerpt from /etc/init.d/checkroot.sh
if [ "$doswap" = yes ]
then
[ "$VERBOSE" != no ] && echo "Activating swap."
swapon -a 2> /dev/null
fi
... omission...
#
# The actual checking is done here.
#
if [ "$rootcheck" = yes ]
then
if [ -f /forcefsck ]
then
force="-f"
else
force=""
fi
if [ "$FSCKFIX" = yes ]
then
fix="-y"
else
fix="-a"
fi
spinner="-C"
case "$TERM" in
dumb|network|unknown|"")
spinner="" ;;
esac
# This Linux/s390 special case should go away.
if [ "${KERNEL}:${MACHINE}" = Linux:s390 ]
then
spinner=""
fi
echo "Checking root file system..."
fsck $spinner $force $fix -t $roottype $rootdev
FSCKCODE=$?
--- end Excerpt
I think I saw Activating Swap message. But I am not sure if I saw
"Checking root file system..." message during a reboot after the RESET
button was hit due to a hung. I was not paying attention to that.
But definitely, I didn't see at all the
growing ASCII character-base horizontal bar with a spinning char on
the right (/ - \ |). This is a way to show progress bar. This is
shown with the -C option to fsck. I usually see this progressive
bar for fsck during reboot under 2.4.2x kernel.
So obviously "-C" is reset to "". I am NOT using s390 :-)
(OR the output from this shell is eaten by some other mechanism.
I need to understand the stdio/stdout setting of the shell
invoking this script further.)
I will check with the maintainer of Debian package further.
--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
Chiaki wrote:
> Chiaki wrote:
>
>> Bernd Eckenfels wrote:
>>
>>> In article <[email protected]> you wrote:
>>>
>>>> That is, under previous 2.4.xx kernel, I would have gotten
>>>> "The disk was not unmounted cleanly. Running fsck." or
>>>> some such message and fsck printed its
>>>> progress bar using ASCII characters.
>>>
>>>
>>>
>>>
>>> Well, this is not a kernel function, your Distribution is calling
>>> fsck in
>>> the bootup scripts, and fsck is calling the filesystem specific
>>> implementation and this is checking if fsck is needed.
>>>
>>> If you do not get this messages anymore contact your linux distribution
>>> provider.
>>>
>>>
>>
>> Thank you for the comment.
>>
>> Well, I have installed 2.6.9-rc2 on my own after having used
>> Debian with my own updated kernel 2.4.2x series for a few years now.
>> I certainly upgraded moduleutil and other packages to run
>> 2.6.9-rc2, but have not specifically updated fsck.
>> (I DID ran apt-get -u update and apt-get -u upgrade to pick up
>> the latest packages a week ago or so.).
>>
>> Agreed that the starting fsck under stock Debian scheme
>> may depend on 2.4.xx features which may not be available
>> on 2.6.yy series kernel. I will get in contact with fsck
>> package (or boot script) maintainer to see
>> if we can improve this.
>>
>> >Do you habe maybe a journalling filesystem? Or do you have set some
>> flags to
>> > force the skip of fsck (/fastboot)
>> >
>>
>> Well, I am running 2.6.9-rc2 from loadlin as follows.
>>
>> loadlin 269rc2 root=/dev/sda6 ro vga=3 scsihosts=sym53c8xx:tmscsim
>>
>> I noticed the fsck message lines were missing on the reboot after
>> a hard-hung forced me to hit reset button in the end.
>> The message lines were missing, but it seems that fsck
>> certainly was running invisibly. Thus the
>> boot sequence halted as if the computer got hung again
>> until fsck finished and bootting continued. This was very
>> annoying.
>>
>
>
> OK, maybe I was not clear enough in the first post.
>
> Fsck seemed to run during the reboot
> after a reset button was hit to recover from a hard hung.
>
> However, NO OUTPUT message from fsck is shown on the console.
> It progressed silently : I could hear the disk access
> (head movement) and this made me very uncomfortable.
> With a test kernel accessing disk furiously without
> telling me what it does during otherwise smooth booting
> process after a hard reset, I may need to consider
> the chance of kernel running wild and trashing the file system.
> So that is why I rebooted the system using 2.4.xx which I have
> used for quite a long time to make sure that the file system(s)
> are fsck'ed and then cleanly remounted.
>
> Anyway, before contacting the Debian package maintainer, I found
> the following.
> IF during the booting the environment variable TERM
> is set to "dumb", "network", "unknown" or not set at all
> the progressive horizontal bar display (-C option to fsck)
> is disabled in the Debian startup script.
>
> Maybe the TERM setup for console during booting has changed between
> kernel 2.4.2x and 2.6.9-rc2?
>
>
> A little more detail:
>
> I checked the Debian startup script myself.
> Now I notice that if the fsck is invoked in a startup script and $TERM is
> set to "dumb" or "network" or "unknown" or not set at all, this
> progress bar display (-C option to fsck)
> is not done by the Debian start up script.
>
> Maybe between 2.4.2x and 2.6.9-rc2,
> the boot console $TERM setting changed?
>
> --- begin Excerpt from /etc/init.d/checkroot.sh
>
> if [ "$doswap" = yes ]
> then
> [ "$VERBOSE" != no ] && echo "Activating swap."
> swapon -a 2> /dev/null
> fi
>
> ... omission...
>
> #
> # The actual checking is done here.
> #
> if [ "$rootcheck" = yes ]
> then
> if [ -f /forcefsck ]
> then
> force="-f"
> else
> force=""
> fi
>
> if [ "$FSCKFIX" = yes ]
> then
> fix="-y"
> else
> fix="-a"
> fi
>
> spinner="-C"
> case "$TERM" in
> dumb|network|unknown|"")
> spinner="" ;;
> esac
> # This Linux/s390 special case should go away.
> if [ "${KERNEL}:${MACHINE}" = Linux:s390 ]
> then
> spinner=""
> fi
>
> echo "Checking root file system..."
> fsck $spinner $force $fix -t $roottype $rootdev
> FSCKCODE=$?
>
> --- end Excerpt
>
>
> I think I saw Activating Swap message. But I am not sure if I saw
> "Checking root file system..." message during a reboot after the RESET
> button was hit due to a hung. I was not paying attention to that.
> But definitely, I didn't see at all the
> growing ASCII character-base horizontal bar with a spinning char on
> the right (/ - \ |). This is a way to show progress bar. This is
> shown with the -C option to fsck. I usually see this progressive
> bar for fsck during reboot under 2.4.2x kernel.
> So obviously "-C" is reset to "". I am NOT using s390 :-)
>
> (OR the output from this shell is eaten by some other mechanism.
> I need to understand the stdio/stdout setting of the shell
> invoking this script further.)
>
> I will check with the maintainer of Debian package further.
>
I submited a bug report to Debian package bug tracking system.
But here is another data point to clarify the above comment.
I rebooted the system after "touch /forcefsck"
to see the exact message shown just before fsck is run silently.
The output from shows that output using "echo" inside
checkroot.sh is not shown. Strange...
The last few lines just before the fsck run.
NET: Registered Protocol Family 17.
VFS: Mounted root (ext 2 file system readonly)
Freeing unused kernel memory: 152k freed.
Adding 2000052k swap on /dev/hda12: Pirority -1. extents: 1
(Then long pause for running fsck on my root partition.)
...various module insertion messages.
(Then another long pause for checking other mounted
partitions.)
So, a simple output from
echo "Checking root filesystem ..." is not shown.
I inserted an "echo TERM=$TERM" to see what is
the TERM variable setting and this was not output at all, too.
Very strange.
Obviously, Adding 2000052k swap on /dev/hda12 came
from "swapon -a" command.
Something weired is going on here.
I will wait the response from Debian package
maintainer.
--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
>
> I will wait the response from Debian package
> maintainer.
Dear all,
Thanks to the investigative work of
Debian sysvinit package maintainer, Miquel van Smoorenburg,
we have found that I had an incorrect major and minor
number for /dev/console on my PC under 2.6.9-rc2!
When I re-created /dev/console with correct major and minor number,
fsck message appears without a problem during booting
together with other formerly invisible kernel messages.
Why did my PC work *FLAWLESSLY* under 2.4.2x series?
I have been using this setup at least for a few years now.
(I can't remember the exact history. CPU, motherboard have
changed during the life time of my computer now.)
So I investigated a little.
Under 2.6.9-rc2 : Incorrect major, minor number for console on my PC.
Under 2.6.9-rc2, I had the following major, minor for /dev/console.
ls -l /dev/console
crw------- 2 root root 4, 64 2004-10-02 01:46 /dev/console
This turned out to be the culprit for my problem.
Then WHY ON EARTH did my PC log fsck messages to
the console under 2.4.2x?
Rebooting into 2.4.2x: correct major and minor number!
To check this, I rebooted into 2.4.25 *with devfsd running* and
found the correct /dev/console (major/minor) number under it.
ls -l /dev/console
crw------- 1 root tty 5, 1 2004-10-03 04:15 /dev/console
Aha, correct /dev/console major and minor number!
It seems that devfsd saved me from the underlying incorrect setting.
I usually boot 2.4.25 with devfsd from the boot command line. The
devfsd function in the kernel presumably re-created /dev/console
with the correct major and minor number at boot time(?).
Thus fsck output was visible.
My boot command line for booting 2.4.xx was like this.
Kernel command line: mem=nopentium devfs=mount drm=debug
root=/dev/sda6 ro scsihosts=sym53c8xx:tmscsim BOOT_IMAGE=2425
Under 2.4.25, I get these devfs messages in dmesg output.
"dmesg | egrep devfs" output.
devfs: v1.12c (20020818) Richard Gooch ([email protected])
devfs: devfs_debug: 0x0
devfs: boot_options: 0x1
Mounted devfs on /dev
usb.c: registered new driver usbdevfs
Rebooted into 2.6.9-rc2: Recreated /dev/console manually.
I rebooted into 2.6.9-rc2 to manually re-create /dev/console with
correct major and minor number. I had installed udev for a day,
but it doesn't seem to try to re-create /dev/console and,
for that matter, invocation of udev would be too late
for me to see fsck output during booting
even if it re-created /dev/console with correct major and minor numbers.
duron:/home/ishikawa# rm /dev/console
duron:/home/ishikawa# cd /dev
duron:/dev# ./MAKEDEV console
duron:/dev# ls -l /dev/console
crw------- 1 root tty 5, 1 2004-10-03 04:27 /dev/console
duron:/dev#
After I recreated and "touch /forcefsck; reboot", I saw
the fsck message now without a problem!
Morale of the story:
Commercial distribution makers and maybe udev package
maintainers (since udev is only meant for 2.6.y kernels
and later,) might want to include a simple checker for
the correct permissions, major and number settings
of a few key devices to save time for support calls
from those who have been saved by devfsd under previous
2.4.x kernel up until that time.
(Once the cause is known, the fix is easy. But knowing
the cause takes time.)
I have no idea how many percentage of linux users have strange
permissions and/or major/minor numbers for a few important
devices, but when majority of them would move into 2.6.y series
kernel in the next year or so, some users who have been saved
by devfsd will see certain things no longer work.
Majority of installed linux users are 2.4.x series kernels
but they certainly would tinker with 2.6.2y kernels when
they become available :-)
cf.
I have no idea why I had incorrect major and minor number for console
*in the first place*. Current MAKEDEV has correct (major, minor) for
"console".
# cd /dev
# egrep console MAKEDEV
$0 $opts console
$0 $opts console
$0 $opts console
$0 $opts console
$0 $opts console
$0 $opts console
$0 $opts console
$0 $opts console
$0 $opts console
$0 $opts consoleonly
$0 $opts console
$0 $opts console
consoleonly)
makedev console c 5 1 $cons
makedev console c 5 1 $cons
symlink console tty0
console)
$0 $opts consoleonly
Hmm... Was there a transition of major/minor numbers
somewhere between 2.2.y -> 2.4.z ?
--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\[email protected]\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */