Package: initramfs-tools
Version: 0.120
Severity: normal
A recent upgrade of my stretch system via
apt-get upgrade
failed with
mkinitramfs: failed to determine device for /
I run with MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy. My system
uses an i2o hardware RAID device, device major number 80 (decimal) and device
minor number 0, with user-space name /dev/i2o/hda. The root partition is
/dev/i2o/hda6 (device minor number 6).
The main culprit seems to be the new udev at release 220-7. I have tried the
sid version also at 221-1 with no better luck. However, initramfs-tools
may be partially at fault.
udev has 2 major deficiencies, from my perspective:
(1) The symbolic links in /dev/disk/by-uuid and /dev/disk/by-label are no
longer being created at boot time. I don't know why they aren't being created,
but they should be.
(2) The new udev does not contain a command called udevd.
I was able to work around the first problem by changing /etc/fstab,
/etc/initramfs-tools/conf.d/resume, and /etc/lilo.conf to use traditional
block special file names (/dev/i2o/hda6, etc.) instead of uuids (UUID=...).
(I use lilo as my boot loader.) This is a regression from recommended practice,
but I must have a functioning system.
The second problem causes a problem for initramfs-tools. The parse_numeric
function in /usr/share/initramfs-tools/scripts/functions has code in it which
looks like this:
if command -v udevd >/dev/null 2>&1; then
ROOT=/dev/block/${major}:${minor}
else
mknod -m 600 /dev/root b ${major} ${minor}
ROOT=/dev/root
fi
Obviously, initramfs-tools is testing for the existence of udev by checking
to see if there is a command available called udevd. If not, then it assumes
that there is no udev. Older releases of udev contained this command. udev
220-7 (and above) does not. As a temporary kludge, I have changed the first
line
of the above to
if command -v udevd >/dev/null 2>&1; :; then
which causes the "if" test to always test true, resulting in the correct code
path. I had to change MODULES=dep to MODULES=most temporarily, but after
building the initramfs, shutting down, and rebooting, I was able to change back
to MODULES=dep and successfully build an initial RAM file system with
MODULES=dep.
The system then boots correctly using the smaller initial RAM file system image.
Either it is a bug for udev to be missing the udevd command, or initramfs-tools
needs to find another way to determine if udev is present. I plan to eventually
report a bug in udev, but I need to do more research first, and my first goal
was to get my system running again. Thus this bug report came first.
By the way, I am still hoping to get my parse_numeric patch, available at
http://users.wowway.com/~zlinuxman/kernel/parse_numeric.patch, included in
initramfs-tools. The current code cannot handle a kernel composite device
number
greater than 0xfffff. With the patch, it should be able to handle any valid
kernel composite device number.
Respectfully submitted,
--
.''`. Stephen Powell <zlinux...@wowway.com>
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1993869501.4988405.1435736347189.javamail.zim...@wowway.com
