Bug#582858: initramfs-tools: MODULES=dep fails when / is ubifs
Daniel Kahn Gillmor
Version: 0.94.4
Severity: normal
When / is on ubifs, if i set MODULES=dep in
/etc/initramfs-tools/initramfs.conf, i get the following error:
0 root@moo:~# update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-2.6.32-5-kirkwood
readlink: missing operand
Try `readlink --help' for more information.
stdin: Illegal seek
mkinitramfs: for root missing /sys/block/ entry
mkinitramfs: workaround is MODULES=most
mkinitramfs: Error please report the bug
update-initramfs: failed for /boot/initrd.img-2.6.32-5-kirkwood
0 root@moo:~#
here's more information about this machine (it's a guruplug, running
directly from nand flash:
0 root@moo:~# cat /proc/cmdline
console=ttyS0,115200n8 root=ubi0:root ubi.mtd=2 rootfstype=ubifs
0 root@moo:~# cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /dev devtmpfs rw,relatime,size=254824k,nr_inodes=63706,mode=755 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
ubi0:root / ubifs rw,relatime 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
tmpfs /var/cache/apt/archives tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
tmpfs /tmp tmpfs rw,relatime 0 0
/dev/md0 /home ext3 rw,relatime,errors=continue,data=ordered 0 0
0 root@moo:~#
I can provide more info if you want it; please let me know.
Thanks for keeping initramfs-tools up-to-date!
--dkg
-- Package-specific info:
-- /proc/cmdline
console=ttyS0,115200n8 root=ubi0:root ubi.mtd=2 rootfstype=ubifs
-- /proc/filesystems
ext3
-- lsmod
Module Size Used by
ext3 110692 1
jbd 37274 1 ext3
mbcache 4860 1 ext3
sd_mod 31168 2
crc_t10dif 1106 1 sd_mod
ipv6 252757 10
btmrvl_sdio 8140 0
btmrvl 10622 1 btmrvl_sdio
libertas_sdio 6387 0
bluetooth 47558 1 btmrvl
libertas 79561 1 libertas_sdio
mv_cesa 4620 0
rfkill 14240 1 bluetooth
lib80211 3680 1 libertas
usb_storage 34775 2
aes_generic 32820 1 mv_cesa
raid0 5835 1
md_mod 80194 2 raid0
mmc_block 7634 0
sata_mv 24181 0
ehci_hcd 35267 0
libata 137558 1 sata_mv
mvsdio 5294 0
mv643xx_eth 22510 0
usbcore 122040 3 usb_storage,ehci_hcd
scsi_mod 119084 3 sd_mod,usb_storage,libata
mmc_core 49668 4 btmrvl_sdio,libertas_sdio,mmc_block,mvsdio
nls_base 5367 1 usbcore
libphy 14808 1 mv643xx_eth
-- /etc/initramfs-tools/initramfs.conf
MODULES=dep
BUSYBOX=y
KEYMAP=n
COMPRESS=gzip
BOOT=local
DEVICE=eth0
NFSROOT=auto
-- /sys/block
md0
mtdblock0
mtdblock1
mtdblock2
sda
sdb
sdc
sdd
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: armel (armv5tel)
Kernel: Linux 2.6.32-5-kirkwood
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages initramfs-tools depends on:
ii cpio 2.11-4 GNU cpio -- a program to manage ar
ii findutils 4.4.2-1 utilities for finding files--find,
ii klibc-utils 1.5.18-1 small utilities built with klibc f
ii module-init-tools 3.12~pre2-3 tools for managing Linux kernel mo
ii udev 154-1 /dev/ and hotplug management daemo
Versions of packages initramfs-tools recommends:
ii busybox 1:1.14.2-2 Tiny utilities for small and embed
initramfs-tools suggests no packages.
-- Configuration Files:
/etc/initramfs-tools/initramfs.conf changed:
MODULES=dep
BUSYBOX=y
KEYMAP=n
COMPRESS=gzip
BOOT=local
DEVICE=eth0
NFSROOT=auto
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Martin Michlmayr
thanks
* Daniel Kahn Gillmor <d...@fifthhorseman.net> [2010-05-24 09:00]:
> 0 root@moo:~# update-initramfs -k all -u
> update-initramfs: Generating /boot/initrd.img-2.6.32-5-kirkwood
> readlink: missing operand
> Try `readlink --help' for more information.
> stdin: Illegal seek
> mkinitramfs: for root missing /sys/block/ entry
The patch below works for me. Can you try it?
--- a/hook-functions 2010-06-07 15:03:22.000000000 +0100
+++ b/hook-functions 2010-06-07 15:06:06.000000000 +0100
@@ -226,6 +226,14 @@
# findout root block device + fstype
eval "$(mount | awk '/\/dev\// {if ($3 == "/") {print "root=" $1 "\nFSTYPE=" $5; exit}}')"
+
+ # handle ubifs and return since ubifs root is a char device but
+ # most of the commands below only work with block devices.
+ if [ "${FSTYPE}" = "ubifs" ]; then
+ manual_add_modules "${FSTYPE}"
+ return
+ fi
+
if [ "${root}" = "/dev/root" ] ; then
root="/dev/disk/by-uuid/"$(blkid -o value -s UUID ${root}) 2>/dev/null
fi
--
Martin Michlmayr
http://www.cyrius.com/
Martin Michlmayr
> The patch below works for me. Can you try it?
I should mention that "works for me" means that the initramfs will be
generated without error.
I'm not claiming that you'll actually be able to boot from ubifs with
that ramdisk though. For that, i-t needs to be taught to know what to
do about something like root=ubi0:rootfs.
Michael Prokop
> * Martin Michlmayr <t...@cyrius.com> [2010-06-07 15:07]:
> > The patch below works for me. Can you try it?
> I should mention that "works for me" means that the initramfs will be
> generated without error.
Thanks for the patch, Martin.
Can I apply it already to i-t?
> I'm not claiming that you'll actually be able to boot from ubifs with
> that ramdisk though. For that, i-t needs to be taught to know what to
> do about something like root=ubi0:rootfs.
I see "root=ubi0:root ubi.mtd=2 rootfstype=ubifs" in the additional
information section of the original bugreport. Who does evaluate
this stuff in the guruplug device that's supposed to work?
And what's behind ubi0:root?
regards,
-mika-
Martin Michlmayr
> Thanks for the patch, Martin.
> Can I apply it already to i-t?
Sure.
> > I'm not claiming that you'll actually be able to boot from ubifs with
> > that ramdisk though. For that, i-t needs to be taught to know what to
> > do about something like root=ubi0:rootfs.
>
> I see "root=ubi0:root ubi.mtd=2 rootfstype=ubifs" in the additional
> information section of the original bugreport. Who does evaluate
> this stuff in the guruplug device that's supposed to work?
> And what's behind ubi0:root?
ubi.mtd=2 says that /dev/mtd2 should be used for ubi; this is then
ubi0. ubi0:root is the root volume.
I'm away this week but I'll try to look into this next week.
Michael Prokop
> * Michael Prokop <mi...@debian.org> [2010-06-08 01:21]:
> > Thanks for the patch, Martin.
> > Can I apply it already to i-t?
> Sure.
Thanks, done.
> > > I'm not claiming that you'll actually be able to boot from ubifs with
> > > that ramdisk though. For that, i-t needs to be taught to know what to
> > > do about something like root=ubi0:rootfs.
> > I see "root=ubi0:root ubi.mtd=2 rootfstype=ubifs" in the additional
> > information section of the original bugreport. Who does evaluate
> > this stuff in the guruplug device that's supposed to work?
> > And what's behind ubi0:root?
> ubi.mtd=2 says that /dev/mtd2 should be used for ubi; this is then
> ubi0. ubi0:root is the root volume.
> I'm away this week but I'll try to look into this next week.
This would be great, thanks.
regards,
-mika-
Daniel Kahn Gillmor
hrm, doesn't seem to work for me. Am i applying it in the wrong place?
Here's a transcript of a failure, patch application, and a repeated
failure:
>> 0 root@moo:/usr/share/initramfs-tools# grep ^MODULES /etc/initramfs-tools/initramfs.conf
>> MODULES=dep
>> 0 root@moo:/usr/share/initramfs-tools# update-initramfs -v -k $(uname -r) -u
>> Keeping /boot/initrd.img-2.6.32-5-kirkwood.dpkg-bak
>> update-initramfs: Generating /boot/initrd.img-2.6.32-5-kirkwood
>> readlink: missing operand
>> Try `readlink --help' for more information.
>> stdin: Illegal seek
>> mkinitramfs: for root missing /sys/block/ entry
>> mkinitramfs: workaround is MODULES=most
>> mkinitramfs: Error please report the bug
>> Removing /boot/initrd.img-2.6.32-5-kirkwood.dpkg-bak
>> update-initramfs: failed for /boot/initrd.img-2.6.32-5-kirkwood
>> 1 root@moo:/usr/share/initramfs-tools# patch -p1 < /root/582858.diff
>> patching file hook-functions
>> Hunk #1 succeeded at 258 (offset 32 lines).
>> 0 root@moo:/usr/share/initramfs-tools# update-initramfs -v -k $(uname -r) -u
>> Keeping /boot/initrd.img-2.6.32-5-kirkwood.dpkg-bak
>> update-initramfs: Generating /boot/initrd.img-2.6.32-5-kirkwood
>> readlink: missing operand
>> Try `readlink --help' for more information.
>> stdin: Illegal seek
>> mkinitramfs: for root missing /sys/block/ entry
>> mkinitramfs: workaround is MODULES=most
>> mkinitramfs: Error please report the bug
>> Removing /boot/initrd.img-2.6.32-5-kirkwood.dpkg-bak
>> update-initramfs: failed for /boot/initrd.img-2.6.32-5-kirkwood
>> 1 root@moo:/usr/share/initramfs-tools#
It still works fine with MODULES=list, of course.
--dkg
Martin Michlmayr
> hrm, doesn't seem to work for me. Am i applying it in the wrong place?
> Here's a transcript of a failure, patch application, and a repeated
> failure:
With the patch applied, can you do:
sh -x mkinitramfs -k $(uname -r) -o /tmp/foo > debug 2>&1
bzip2 -9 debug
and then send me debug.bz2.
Martin Michlmayr
> >> rootfs on / type rootfs (rw)
> >> ubi0:root on / type ubifs (rw,relatime)
^^^^^^^^^
This is the output from 'mount', and here's what i-t does:
eval "$(mount | awk '/\/dev\// {if ($3 == "/") {print "root=" $1 "\nFSTYPE=" $5; exit}}')"
it looks for something with /dev/ in it. In your case, this does't
match so root= and FSTYPE= are empty. I think we should simply add a
check to i-t at this point to produce an error when $root is empty.
Daniel, do you know if ubi0:root in /etc/fstab is valid? Is that what
the ubi people recommend to use? Shouldn't this be a device like
/dev/ubiX_Y? (This would make i-t happy)
Martin Michlmayr
> This is the output from 'mount', and here's what i-t does:
>
> eval "$(mount | awk '/\/dev\// {if ($3 == "/") {print "root=" $1 "\nFSTYPE=" $5; exit}}')"
>
> it looks for something with /dev/ in it. In your case, this does't
> match so root= and FSTYPE= are empty. I think we should simply add a
> check to i-t at this point to produce an error when $root is empty.
[PATCH] Produce an error when root cannot be determined with MODULES=dep
A lot of code in dep_add_modules() uses $root. Therefore, produce an
error message if we cannot determine the root device.
Signed-off-by: Martin Michlmayr <t...@cyrius.com>
diff --git a/hook-functions b/hook-functions
index 6a6e233..154ae3e 100644
--- a/hook-functions
+++ b/hook-functions
@@ -226,6 +226,11 @@ dep_add_modules()
# findout root block device + fstype
eval "$(mount | awk '/\/dev\// {if ($3 == "/") {print "root=" $1 "\nFSTYPE=" $5; exit}}')"
+ if [ -z "$root" ]; then
+ echo "mkinitramfs: failed to determine root device"
+ echo "mkinitramfs: workaround is MODULES=most"
+ echo "Error please report bug on initramfs-tools and include the output of 'mount'"
+ fi
# handle ubifs and return since ubifs root is a char device but
# most of the commands below only work with block devices.
--
Daniel Kahn Gillmor
> * Daniel Kahn Gillmor <d...@fifthhorseman.net> [2010-06-08 15:22]:
>>>> rootfs on / type rootfs (rw)
>>>> ubi0:root on / type ubifs (rw,relatime)
> ^^^^^^^^^
> This is the output from 'mount', and here's what i-t does:
>
> eval "$(mount | awk '/\/dev\// {if ($3 == "/") {print "root=" $1 "\nFSTYPE=" $5; exit}}')"
>
> it looks for something with /dev/ in it. In your case, this does't
> match so root= and FSTYPE= are empty. I think we should simply add a
> check to i-t at this point to produce an error when $root is empty.
>
> Daniel, do you know if ubi0:root in /etc/fstab is valid? Is that what
> the ubi people recommend to use? Shouldn't this be a device like
> /dev/ubiX_Y? (This would make i-t happy)
according to:
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mount_ubifs
the /dev/ubiX_Y method is the recommended method for newer kernels.
however, i was unable to get that to work when i tried with
2.6.32-5-kirkwood (unfortunately, i don't have a log of that interaction
-- would one be useful?).
The old-style "device-less" method worked for me, though (and appears to
be reflected in /proc/mounts).
--dkg
Martin Michlmayr
> http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mount_ubifs
Ok, so it sounds like ubiX:name might be quite common.
Maybe the "awk '/\/dev\//" in i-t should be changed to something like
"awk '/\/dev\/|ubi/" or "awk '/\/dev\/|ubi[0-9]/" but I'll leave that
to the i-t maintainer(s).
Martin Michlmayr
> > http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mount_ubifs
>
> Ok, so it sounds like ubiX:name might be quite common.
>
> Maybe the "awk '/\/dev\//" in i-t should be changed to something like
> "awk '/\/dev\/|ubi/" or "awk '/\/dev\/|ubi[0-9]/" but I'll leave that
> to the i-t maintainer(s).
Note: it should probably be |ubi rather than |ubi[0-9] since
something like ubi:rootfs is valid too.
Martin Michlmayr
cases since it makes the error explicit.
* Martin Michlmayr <t...@cyrius.com> [2010-06-08 21:43]:
Martin Michlmayr
> I'm not claiming that you'll actually be able to boot from ubifs with
> that ramdisk though. For that, i-t needs to be taught to know what to
> do about something like root=ubi0:rootfs.
Ok, here's a patch with which you can boot from ubi with i-t when ubi is
modular.
It essentially does three things:
- adds the correct modules to the ramdisk (for MODULES=dep and MODULES=most)
- reads ubi.mtd= from the command line
- loads ubi with the ubi.mtd info and ignores the "Waiting for root" check
I've successfully tested this with a kernel with modular ubi and with
the following boot variants:
console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs
console=ttyS0,115200 ubi.mtd=2 root=ubi0_0 rootfstype=ubifs
With
console=ttyS0,115200 ubi.mtd=2 root=/dev/ubi0_0 rootfstype=ubifs
I get an error that it cannot mount root but I suspect this is an
ubifs error and has nothing to do with i-t (since at this point I can
manually mount it with -t ubifs ubi0_0 whereas the /dev/ variant
doesn't work).
Tested with MODULES=dep and MODULES=most as well as with a kernel that
has ubifs built in.
Signed-off-by: Martin Michlmayr <t...@cyrius.com>
diff --git a/hook-functions b/hook-functions
index 6a6e233..895eca0 100644
--- a/hook-functions
+++ b/hook-functions
@@ -231,6 +231,10 @@ dep_add_modules()
# most of the commands below only work with block devices.
if [ "${FSTYPE}" = "ubifs" ]; then
manual_add_modules "${FSTYPE}"
+ # add some modules required by ubifs on which it doesn's depend
+ manual_add_modules deflate
+ manual_add_modules zlib
+ manual_add_modules lzo
return
fi
@@ -424,6 +428,11 @@ auto_add_modules()
block)
copy_modules_dir kernel/drivers/block
;;
+ ubi)
+ for x in deflate zlib lzo ubi ubifs; do
+ manual_add_modules "${x}"
+ done
+ ;;
ieee1394)
for x in ohci1394 sbp2; do
manual_add_modules "${x}"
@@ -456,6 +465,7 @@ auto_add_modules()
auto_add_modules ata
auto_add_modules i2o
auto_add_modules dasd
+ auto_add_modules ubi
auto_add_modules ieee1394
auto_add_modules firewire
auto_add_modules mmc
diff --git a/init b/init
index 142eb14..798717c 100755
--- a/init
+++ b/init
@@ -42,6 +42,7 @@ export ROOTFSTYPE=
export IP=
export BOOT=
export BOOTIF=
+export UBIMTD=
export break=
export init=/sbin/init
export quiet=n
@@ -126,6 +127,9 @@ for x in $(cat /proc/cmdline); do
boot=*)
BOOT=${x#boot=}
;;
+ ubi.mtd=*)
+ UBIMTD=${x#ubi.mtd=}
+ ;;
resume=*)
RESUME="${x#resume=}"
;;
@@ -257,6 +261,7 @@ unset ROOT
unset IP
unset BOOT
unset BOOTIF
+unset UBIMTD
unset blacklist
unset break
unset noresume
diff --git a/scripts/local b/scripts/local
index cca5e8d..46ab0f3 100644
--- a/scripts/local
+++ b/scripts/local
@@ -8,6 +8,13 @@ pre_mountroot()
wait_for_udev 10
+ # Load ubi with the correct MTD partition and return since fstype
+ # doesn't work with a char device like ubi.
+ if [ -n "$UBIMTD" ]; then
+ modprobe ubi mtd=$UBIMTD
+ return
+ fi
+
# Don't wait for a root device that doesn't have a corresponding
# device in /dev (ie, mtd0)
if [ "${ROOT#/dev}" = "${ROOT}" ]; then
maximilian attems
> mika, the patch below is still required and is imho a good idea in all
> cases since it makes the error explicit.
>
thanks applied. :)
added error out in that case as it makes no sense to continue
beyond that point.
Michael Prokop
thanks
* Martin Michlmayr <t...@cyrius.com> [Sun Jun 13, 2010 at 05:23:14PM +0100]:
> * Martin Michlmayr <t...@cyrius.com> [2010-06-07 18:10]:
> > I'm not claiming that you'll actually be able to boot from ubifs with
> > that ramdisk though. For that, i-t needs to be taught to know what to
> > do about something like root=ubi0:rootfs.
> Ok, here's a patch with which you can boot from ubi with i-t when ubi is
> modular.
[...]
Thanks, Martin!
Applied in branch mika/ubifs:
http://git.debian.org/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/mika/ubifs
Will be merged +_uploaded after final review together with maks.
regards,
-mika-
maximilian attems
> tags 582858 + pending
> thanks
>
> * Martin Michlmayr <t...@cyrius.com> [Sun Jun 13, 2010 at 05:23:14PM +0100]:
> > * Martin Michlmayr <t...@cyrius.com> [2010-06-07 18:10]:
> > > I'm not claiming that you'll actually be able to boot from ubifs with
> > > that ramdisk though. For that, i-t needs to be taught to know what to
> > > do about something like root=ubi0:rootfs.
>
> > Ok, here's a patch with which you can boot from ubi with i-t when ubi is
> > modular.
> [...]
>
> Thanks, Martin!
>
> Applied in branch mika/ubifs:
>
> http://git.debian.org/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/mika/ubifs
>
sorry to jump in so late and due to my complete ignorance of ubi,
please enlighten me on the importance of it?
i'm a bit hesitant of adding it to every initramfs out there:
/lib/modules/2.6.32-5-amd64/kernel/drivers/mtd/ubi/ubi.ko
could d-i add it to the relevant installation as hook?
who does need or may want to use ubi?
thanks
Martin Michlmayr
> i'm a bit hesitant of adding it to every initramfs out there:
> /lib/modules/2.6.32-5-amd64/kernel/drivers/mtd/ubi/ubi.ko
> could d-i add it to the relevant installation as hook?
> who does need or may want to use ubi?
Yeah, I think this is a fair point. UBI/UBIFS is a filesystem for MTD
flash devices, so very few devices will need this. And d-i doesn't
even have support for UBI/UBIFS at the moment.
So how about you remove the line that adds ubi when MODULES=most is
used. Everything else in my patch should be ok, though, or did you
see any other issues?
--
Martin Michlmayr
http://www.cyrius.com/
--
Michael Prokop
> * maximilian attems <m...@stro.at> [2010-06-15 18:14]:
> > i'm a bit hesitant of adding it to every initramfs out there:
> > /lib/modules/2.6.32-5-amd64/kernel/drivers/mtd/ubi/ubi.ko
> > could d-i add it to the relevant installation as hook?
> > who does need or may want to use ubi?
> Yeah, I think this is a fair point. UBI/UBIFS is a filesystem for MTD
> flash devices, so very few devices will need this. And d-i doesn't
> even have support for UBI/UBIFS at the moment.
Ok, thanks.
> So how about you remove the line that adds ubi when MODULES=most is
> used. Everything else in my patch should be ok, though, or did you
> see any other issues?
ACK. Done in:
http://git.debian.org/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/mika/ubifs
Keeping the "ubi)" within hook-functions should be fine AFAICS so a
hook script could call "auto_add_modules ubi".
Maks, please let me know whether merging mika/ubifs into master
would be fine for you.
regards,
-mika-