Bug#532049: readlink error in mkinitramfs-kpkg

[Sebastian Fontius <sebastian.fontius@gmx.net>]

Hi again,

This bug should possibly be reassigned to initramfs-tools
or udev.  See below for the rationale.

Also, sprach Sebastian Fontius am Sonntag, den 28. Juni 2009 um 10:38:
> hits me too.

and I probably know why:

This is what "mount" shows regarding to /:

  rootfs on / type rootfs (rw)

This is what
/usr/share/initramfs-tools/hook-functions:dep_add_modules() does at the
beginning:

  local block minor root FSTYPE root_dev_path x

  # findout root block device + fstype
  eval "$(mount | awk '/\/dev\// {if ($3 == "/") {print "root=" $1 "\nFSTYPE=" $5; exit}}')"

Running this against the output of mount does nothing, hence $root and
$FSTYPE remain empty.

A few lines later
/usr/share/initramfs-tools/hook-functions:dep_add_modules() does this:

  root="$(readlink -f ${root})"

As $root is empty this results in the error message

  readlink: missing operand
  Try `readlink --help' for more information.

After fiddeling around with the postinst of the kernel 2.6.26-2-ixp4xx
I found out that it is calling mkinitramfs-kpkg like this:

  # mkinitramfs-kpkg -o /boot/initrd.img-2.6.26-2-ixp4xx.new /lib/modules/2.6.26-2-ixp4xx
  readlink: missing operand
  Try `readlink --help' for more information.
  mkinitramfs: missing  root  /sys entry
  mkinitramfs: workaround is MODULES=most
  mkinitramfs: Error please report the bug

The mkinitramfs error is not shown during install.  The mentioned
workaround is probably not a good idea as the initrd will possibly be
too big to fit in the 8 minus something MiB of an NSLU2 (but may work
on a machine not having those constraints).

Now as to _why_ mount says rootfs is mounted on / I have no idea.  I
think (but I am not sure) that the output of mount always looked like
this.  I always thought it curious, but I never really did anything
about it, as everything worked just fine.

My /etc/fstab looks like this regarding to /:

  LABEL=oberon-root  /  ext3  nodiratime,noatime,acl,user_xattr,errors=remount-ro  0  1

And running vol_id from udev on /dev/corsair2048p1 (my / partition
renamed by an udev rule) yields this:

  $ /sbin/vol_id /dev/corsair2048p1
  ID_FS_USAGE=filesystem
  ID_FS_TYPE=ext3
  ID_FS_VERSION=1.0
  ID_FS_UUID=72869be7-ab5d-46bd-87cf-33b2cde134a4
  ID_FS_UUID_ENC=72869be7-ab5d-46bd-87cf-33b2cde134a4
  ID_FS_LABEL=oberon-root
  ID_FS_LABEL_ENC=oberon-root
  ID_FS_LABEL_SAFE=oberon-root

This is the relevant part of the udev rule used for renaming:

  # Corsair Flash Voyager
  SUBSYSTEMS=="scsi", KERNEL=="*[0-9]", ATTRS{model}=="Flash Voyager", ATTRS{vendor}=="Corsair", ATTRS{rev}=="1100", ATTRS{max_sectors}=="240", NAME+="corsair2048p%n"
  SUBSYSTEMS=="scsi", KERNEL=="*", ATTRS{model}=="Flash Voyager", ATTRS{vendor}=="Corsair", ATTRS{rev}=="1100", ATTRS{max_sectors}=="240", NAME+="corsair2048%n"

I guess my combination of renaming the / device via udev and using the
label for mounting / is the culprit.  Seeing this I think this bug
should be reassigned to initramfs-tools ir udev. But then again,
previous kernel updates _never_ failed to install, so this bug should
probably stay where it is.


Greetings,


-- 
: Sebastian Fontius : http://www.fsfe.org : http://blogs.fsfe.org/smc
`--------+----------+---------------------+----------------------------.
    []   | "They that can give up essential liberty to obtain a little |
  [][][] |  temporary safety deserve neither liberty nor safety."      |
    ||   :                       Attributed to Benjamin Franklin, 1759 :