Description of Problem: An attempt to reboot by picking up "Reboot" on gdm screen ended up with the following messages: 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 syslogd). 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 on bugzilla?
Moving, thanks.
"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? :-) Greetings, Moritz
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.