Using the function 'try' will cause system to become un-bootable if extraction fails or the archive does not exist. Udev handles populating /dev by itself so booting is possible even without the archive. For instance, replacing try with [ -f /lib/udev-state/devices.tar.bz2 ] && tar -jxpf \ /lib/udev-state/devices.tar.bz2 -C /dev ..and deletingthe device.tar.bz2 works just fine. I have experienced this problem when my computer has crashed during "saving device nodes" which has resulted in a invalid archive. So, we need a function that tries to extract the archive, but one that will just give a warning, and continue even if it fails. As a side note, it seems to me rather problematic to save the device nodes in this manner in general, because for instance, I have had several different lvm drives on this computer as guest hard drives, and now my /dev is full of non-existent volumegroups, aswell as non-existent /dev/hdx# devices (because the drives in the computer had different amount of partitions). So we'd need something a little bit more intelligent system that only saves nodes that udev/kernel modules do not create themselves. However, for the time being, this is a non-issue, just annoying. Reproducible: Always Steps to Reproduce: 1. delete /lib/udev-state/devices.tar.bz2 2. disable saving of device nodes from /etc/init.d/halt.sh 3. reboot Actual Results: A fatal error message appears and claims system startup is unable to continue. (Admin password for maintennance or ctrl-d to reboot) Expected Results: Give a warning that the extraction of the device nodes failed, and continue. Tested on a x86 system, with baselayout version 1.9.4-r6. There is some problem with lvm that ocurred when I tested this behaviour: The startup script wasn't able to create the device nodes on boot (failed on inappropriate ioctl for device), if the archive file did not exists. (Is vgscan and vgchange run before udev populates the /dev? I haven't looked into it.) However, there seemed to be other similar bug reports about it, but I thought this might be helpful aswell. This might however be kernel related too, because I don't remember seeing this before. The computer is running on 2.6.10-ac9 and udev 045.
already been fixed in baselayout-1.11.8 if [[ ${RC_DEVICE_TARBALL} = "yes" ]] && [[ -s /lib/udev-state/devices.tar.bz2 ]]
