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

[Ben Hutchings]

On Wed, 2015-12-09 at 22:09 +, Ben Hutchings wrote:
[...]
> > 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.
> 
> It's not there any more...
> 
> > The current code cannot handle a kernel composite device number
> > greater than 0xf.  With the patch, it should be able to handle any valid
> > kernel composite device number.
> 
> ...but I sent you my patch for this.  It's also on that git branch.
> 
> Please can you test initramfs-tools built from that branch?  Note that
> this has the binary package split into initramfs-tools and initramfs-
> tools-core, and you'll need to install both.

These changes are now in unstable; please can you confirm whether the
bug is fixed?  If I don't hear from you I'll eventually just close
this.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.

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

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

[Ben Hutchings]

Control: tag -1 patch moreinfo

On Wed, 1 Jul 2015 03:39:07 -0400 (EDT) Stephen Powell  
wrote:
[...]
> 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.

It does but now it's called systemd-udevd and isn't on the path.

This should be fixed on my branch benh/parse-numeric-fixes at
https://anonscm.debian.org/cgit/kernel/initramfs-tools.git

[...]
> 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.

It's not there any more...

> The current code cannot handle a kernel composite device number
> greater than 0xf.  With the patch, it should be able to handle any valid
> kernel composite device number.

...but I sent you my patch for this.  It's also on that git branch.

Please can you test initramfs-tools built from that branch?  Note that
this has the binary package split into initramfs-tools and initramfs-
tools-core, and you'll need to install both.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

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

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

[Stephen Powell]

Incidentally, I have now filed a bug report against udev also.
The udev bug is what caused me to switch back, temporarily, to specifying
partitions via a traditional block special file name instead of by uuid.
Doing so exposed this bug in initramfs-tools.  The bug number for
udev is 790823, in case you're interested.

-- 
  .''`. Stephen Powellzlinux...@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/1982051385.5796616.1435833751763.javamail.zim...@wowway.com

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

[Ben Hutchings]

On Wed, 2015-07-01 at 03:39 -0400, Stephen Powell wrote:
 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).
[...]

Please note that i2o will be going away entirely (disabled in 4.0,
removed upstream in 4.2).

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.



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

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

[Stephen Powell]

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 21; 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 21; :; 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 0xf.  With the patch, it should be able to handle any valid
kernel composite device number.

Respectfully submitted,

-- 
  .''`. Stephen Powellzlinux...@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

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

[Stephen Powell]

On Wed, 01 Jul 2015 14:05:57 -0400 (EDT), Ben Hutchings wrote:
 
 Please note that i2o will be going away entirely (disabled in 4.0,
 removed upstream in 4.2).

Thanks, Ben, I hadn't heard that; but it really doesn't have anything
to do with this bug, per se.  I happened to discover it using an i2o RAID device
on i386 using lilo.  But this bug can happen with any disk device, on any 
hardware
platform, and with any boot loader.  All one need do to expose it is to supply
the root parameter on the kernel command line, specifying the root file system
as a kernel composite device number, such as

   root=801

If you do this, and if you use MODULES=dep, and if udev is at version 220-7,
then mkinitramfs (and update-initramfs), performed during this boot session,
will fail.  I've done a little more research, and I suggest using udevadm, 
instead
of udevd, as the command to look for.  You already make use of this command 
elsewhere
in initramfs-tools.  The fix for this problem is a canonical (pardon the pun)
one-line change.  Simply change

   if command -v udevd /dev/null 21; then

to

   if command -v udevadm /dev/null 21; then

in the parse_numeric function.  Problem solved.  And yes, I realize that using
disk labels or uuids is the recommended way to specify the root file system 
these
days.  But that's another story, as I mentioned earlier.

Respectfully yours,

-- 
  .''`. Stephen Powellzlinux...@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/1967416753.5648099.1435795665776.javamail.zim...@wowway.com