[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#790722: marked as done (mkinitramfs fails with latest udev (>= 220-7) on some systems)

Your message dated Sat, 16 Apr 2016 23:42:32 +0100
with message-id <1460846552.3814.23.camel@decadent.org.uk>
and subject line Re: mkinitramfs fails with latest udev (>= 220-7) on some systems
has caused the Debian Bug report #790722,
regarding mkinitramfs fails with latest udev (>= 220-7) on some systems
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
790722: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790722
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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    <zlinuxman@wowway.com>
 : :'  :
 `. `'`
   `-

--- End Message ---
--- Begin Message --- 
Version: 0.121~rc1

Based on what you wrote in #820156, I'm assuming this is fixed.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: