This is a hard bug for me to classify so I've gone for Core System. Please reassign as necessary. I'm running gentoo-sources-2.6.12 and udev on x86 architecture but noticed the problem on earlier 2.6 kernel releases. During reboot/shutdown, initiated with "shutdown -r/-h now", the system sometimes loses track of its state. The following happens: 1) The tar operation during Saving device nodes fails Errors that -l is deprecated and --one-file-system should be used and can't stat /dev/vcsa7 and /dev/vcs7 are output by tar 2) An "Enter Control-D to continue (root password for maintenance): prompt is displayed Pressing any key produces an unrecognised command error and pressing Enter then presents a command prompt. 3) Entering characters then presents a message that startup can't continue The only way out of this, assuming you have acpid running, is to press the Power Button after which the system enters runlevel 0, the device nodes are saved correctly and shutdown completes correctly. I've noticed this problem occur after emerge updates certain system packages e.g. udev and acpid. It seems to be totally random as to when it happens. Let me know what specific system information you require to assist with this one. I don't expect emerge info will help that much. Regards, Neil Darlow Reproducible: Sometimes Steps to Reproduce: 1. 2. 3.
You're using parellel init scripts setting in /etc/conf.d/rc right? Please verify you have the following.. # Set to "yes" if you want the rc system to try and start services # in parallel for a slight speed improvement. RC_PARALLEL_STARTUP="no"
(In reply to comment #1) > You're using parellel init scripts setting in /etc/conf.d/rc right? No, I'm not. Regards, Neil Darlow
I had the same problem yesterday, and I don't use parallel init scripts neither. I did have a separate runlevel "later", though (I removed that one now). The text was: * Stopping S.M.A.R.T. monitoring daemon ... [ ok ] * Stopping gdm ... [ ok ] * Saving devices nodes ... gdm(pam_unix)[12022] : session closed for user elmicha [ oops ] * The "tar" command failed with error: Semantucs of -l option will change in the future releases. tar: Please use --one-file-system option instead. tar: vcsa7: Cannot stat: No such file or directory tar: vcs7: Cannot stat: No such file or directory tar: Error exit delayed from previous errors * Since this is a critical task, startup cannot continue. Give root password for maintenance (or type Control-D to continue): At that point my login shell was still running - it printed the prompt sometimes when I pressed a key, and sometimes the "Give root password" was re-printed. Alt+SysRq+s,u,b worked.
Some more thoughts: it looks like gdm is still "being killed" while halt.sh runs (this is an old 700 MHz machine): vcsa7 and vcs7 are still there when fgrep creates the ${devices_totar}, but shortly afterwards tar can't find these files anymore. tar did build /lib/udev-state/devices.tar.bz2, though. According to "info tar", tar's exit code is not too well defined (0 for ok, anything else for something else). Therefore I will remove that "try" before the tar. If tar does not succeed to build the device tar ball some day, the system will be somewhat unhappy at the next boot. But anyways I wouldn't be able to repair the system with sulogin while the normal tty1 agetty still runs. And I will be going to use RC_DEVICE_TARBALL="no" in the near future (as soon as I dare to). Regards... Michael
This problem appears repeatable for me after an update of udev. I have just updated to udev-068 this morning and, sure enough, the device tarball creation during reboot failed. Perhaps GKH should be copied on this bug as he might have something to say on the situation. In the meantime, I'm going to try running without the device tarball. Regards, Neil Darlow
the -l option has been fixed in latest releases
