FS#6498 - umount / fails after package update

Attached to Project: Arch Linux
Opened by Pierre Schmitz (Pierre) - Tuesday, 27 February 2007, 20:49 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 27 February 2007, 21:24 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To Jan de Groot (JGC)
Architecture not specified
Severity Critical
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

After updating the glibc package (not sure if this problem is related to glibc) the "umount -a" statement in rc.shutdown fails to umount /. The script ignores this and powers the computer off. At the next boot a lot of transaction have to be replayed due to the unclean shutdown.

I think this is quite a critical problem because it might result in some data loss.

You can reproduce this by:
1) downgrade glibc to a version from pacman-cache
2) type "poweroff" and see the failing umount before the pc turns off
3) restart and you`ll see that some transactions have to be replayed

Even if this is a problem of the glibc package: rc.shutdown should never just turn the computer off when umounting a filesystem fails!
This task depends upon

Closed by  Jan de Groot (JGC)
Sunday, 04 March 2007, 14:04 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 2.5-6
Comment by Tobias Powalowski (tpowa) - Tuesday, 27 February 2007, 21:24 GMT
this happens ever if you upgrade glibc.
Comment by Jan de Groot (JGC) - Tuesday, 27 February 2007, 22:17 GMT
"Even if this is a problem of the glibc package: rc.shutdown should never just turn the computer off when umounting a filesystem fails!"

Ah, so it should just exit without shutting your system down, having killed all processes and umounted all filesystems that did umount? How would you recover from that? The only option is to reboot, having the same effect.

Comment by Pierre Schmitz (Pierre) - Tuesday, 27 February 2007, 22:25 GMT
Well you don`t have to reboot in this case. Prompting an error and changing to "init 1" should be enough. But anyway: we have to find out whih process blocks / after an glibc-update. I tried to check with lsof but did not find anything usefull. (probably init itself is the problem here)
Comment by Jan de Groot (JGC) - Tuesday, 27 February 2007, 22:54 GMT
Thinking about init, what happens when you do "init u" ? I've seen debian restarting init this way after glibc upgrades.
Comment by Pierre Schmitz (Pierre) - Tuesday, 27 February 2007, 23:39 GMT
that`s it! when restarting init with "init -u" I am able to unount /. So this should be added to the install script of glibc. I think rc.shutdown should be made more robust against such problems but i have noe idea how.
Comment by Andreas Radke (AndyRTR) - Friday, 02 March 2007, 13:07 GMT
hell no. an "init -u" in glibc.install would immediatly make the system reboot. a simple message "it's recommended to 'init -u' instead of rebooting/power off" should be enough.

but what at all should happen if umount fails? isn't it enough to force "sync" before umount fails?
Comment by Pierre Schmitz (Pierre) - Friday, 02 March 2007, 13:13 GMT
"init u" does not reboot; it only reloads init. See manpage: "U or u tell init to re-execute itself (preserving the state). No re-examining of /etc/inittab file happens. Run level should be one of Ss12345, otherwise request would be silently ignored."
"

Loading...