Description of Problem:
An attempt to reboot by picking up "Reboot" on gdm screen ended up with the
Unmounting file systems: umount2: Device or resources busy
umount: /dev/sdb2: not mounted
umount: /usr: Illegal seek
INIT: no more processes left in this runlevel
... and in this moment came "a power switch time". I waited around five
minutes waiting if something will happen. Nada.
A test system was using /dev/sdb1 as / and /dev/sdb2 mounted on /usr.
No file systems were mounted from other disks although swap was using these.
Incidents of that sort do not happen where running RH 7.3 (and earlier
installations) on the same machine.
have you tried more than once with gdm with the same result? have you tried with
'reboot' from console?
Reboot from a console did work. Not on that occasion, clearly enough, and
I forgot to turn on "magic sysrq" immediately after an installation so,
unfortunately, I could not even try to check what was happening there.
I will do more reboots from gdm (later, this is the same system as my
"normal" one only a different disk) but this may depend what was happening
before that on a desktop. Sigh!
You are actually right. This is not gdm problem. I can stuck my box
on a reboot also using a console regardless if I am using 2.4.18-11 or
2.4.18-12.4. SysRq seems to indicate that kjournald blocks in
'interruptible_sleep_on'. Unfortunately nothing in log files as this
happens so late that no user-space processes are around (this includes
If really required I guess that I may rig some kind of a serial console
but that only later.
Should I resubmit that for another component (kernel?) or this can be changed
"interruptible_sleep_on" (ie. "S" state) is the normal state of a sleeping
kjournald process. It would be in "D" state if it were blocked on anything; the
"S" state is normal for a kjournal which is idle. So, whatever the problem is
here, it doesn't look like ext3 is the root cause.
The serial console would probably be helpful here.
Ok, attached are serial console captures of "sysrq-T" and "sysrq-P".
Also what was stored in /var/log/dmesg before we hanged on reboot. :-)
Created attachment 73228 [details]
Serial console capture of "tasks" and "processor" after reboot stopped
Created attachment 73229 [details]
Output of dmesg for a machine in question
The illegal seek hang on reboot is a glibc issue.
Seeing as there are no remarks to which versions of glibc are
the culprits, here my experience (confirmed by update and then
going back to old version):
I had exactly the same umount2 phenomenon.
glibc-2.2.90-23 works (no problem)
glibc-2.2.90-26 does not work (umount/umount2 complains, leads to journal
recovery at next mount/boot)
Does that close you in on the problem? :-)
This appears to be fixed in 2.2.92-2 which is available via rhn/up2date
Apparently fixed now. Closing the bug. If there is a problem reopen.