if init-bottom/udev fails, system silently fails to boot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
udev (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
This is a follow-up report on Bug #818177. If during the initramfs phase of a boot the init-bottom/udev script fails, the system will not (properly) boot. This report is not about fixing this potential problem, but about the fact that the user is not informed explicitly enough about this critical event. Potential results:
* filesystems not mounted properly (See Bug #870031)
* System does boot, but unknown side-effects happen. Due to lack of (flashy) reporting, identifying the root-cause (init-bottom/udev) might turn out to be hard
* Logs of bug reports filed to the wrong packages
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: udev 173-0ubuntu4
ProcVersionSign
Uname: Linux 3.0.0-12-generic x86_64
ApportVersion: 1.23-0ubuntu2
Architecture: amd64
CustomUdevRuleF
Date: Tue Oct 11 14:09:18 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110705.1)
MachineType: System manufacturer System Product Name
ProcEnviron:
LANGUAGE=de_AT:de
PATH=(custom, user)
LANG=de_AT.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=
SourcePackage: udev
UpgradeStatus: Upgraded to oneiric on 2011-09-13 (27 days ago)
dmi.bios.date: 11/21/2008
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1406
dmi.board.
dmi.board.name: M3A32-MVP DELUXE
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: System Product Name
dmi.product.
dmi.sys.vendor: System manufacturer
According to a pointer from Steve Langasek and the manpage of initramfs-tools(5) one can do:
/sbin/frobnicate "/dev/mapper/frobb" || panic "Frobnication failed"
which translates to
udevadm control --exit || panic "udev exit failed (http:// some-wiki- page)"
for the init-bottom/udevd script. This could be considered to be a fix for this bug.
There is still the question of extending the scope of this bug. IMHO any failure within the initramfs phase is worth a 'panic'. This would even make the point of adding 'panic' to the call_scripts function within scripts/functions for cases when a called script returns with error code.
(N.B. For testing, I tried to unconditionally call 'panic' in init-bottom/udev, but it just said something like "panic: command not found". The system did boot normally!)