Bug#535513: daily fails to generate ramdisk because / not mounted
* Frans Pop elen...@planet.nl [2009-07-21 17:53]: Which of the three I mentioned is the actual problem? Did they all change or just one or two? Which is used in the relevant code? No idea. All of my machines are already packed in boxes. I won't be able to do any real d-i work before the middle of September. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535513: daily fails to generate ramdisk because / not mounted
* Martin Michlmayr t...@cyrius.com [2009-07-02 22:39]: I just tried a daily image on ARM and it failed because the ramdisk cannot be generated. Apparently this is because / is not mounted in the chroot. The reason this only shows up on ARM is because it uses MODULES=dep for initramfs-tools to generate the ramdisk and in this case initramfs-tools looks for the root device; for MODULES=most (the default) it just puts everything in the ramdisk. I made a successful installation with base-installer/initramfs-tools/driver-policy=most and I guess you can reproduce this problem with =dep on x86. I don't know why root is no longer mounted in the chroot (it was in lenny and until recently in the daily images). Would busybox be responsible for this or where should this bug be reassigned to? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535513: daily fails to generate ramdisk because / not mounted
On Tuesday 21 July 2009, Martin Michlmayr wrote: * Martin Michlmayr t...@cyrius.com [2009-07-02 22:39]: I just tried a daily image on ARM and it failed because the ramdisk cannot be generated. Apparently this is because / is not mounted in the chroot. I don't know why root is no longer mounted in the chroot (it was in lenny and until recently in the daily images). Would busybox be responsible for this or where should this bug be reassigned to? What *exactly* do you mean by / is no longer mounted? It seems to me that it is kind of a silly statement because without a / I would say you can't have a chroot. I guess what you mean is that /etc/mtab or /proc/mounts or the mount command no longer *lists* /. Is that it? If it is, then somebody very simply will have to trace the cause of that change. My suggestion: spend some actual time on tracing it instead of waiting for other people to solve the mystery. If you suspect busybox, then try building an image with the Lenny version of busybox. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535513: daily fails to generate ramdisk because / not mounted
* Frans Pop elen...@planet.nl [2009-07-21 16:23]: What *exactly* do you mean by / is no longer mounted? It seems to me that it is kind of a silly statement because without a / I would say you can't have a chroot. I guess what you mean is that /etc/mtab or /proc/mounts or the mount command no longer *lists* /. Is that it? Yes, that's what I meant. It shows up fine in the d-i system but not in the target. If it is, then somebody very simply will have to trace the cause of that change. My suggestion: spend some actual time on tracing it instead of waiting for other people to solve the mystery. If you suspect busybox, then try building an image with the Lenny version of busybox. That's a fine suggestion but I don't have time for this at the moment since I'm moving to another country, so a bug report will have to do for now. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535513: daily fails to generate ramdisk because / not mounted
On Tuesday 21 July 2009, Martin Michlmayr wrote: * Frans Pop elen...@planet.nl [2009-07-21 16:23]: What *exactly* do you mean by / is no longer mounted? It seems to me that it is kind of a silly statement because without a / I would say you can't have a chroot. I guess what you mean is that /etc/mtab or /proc/mounts or the mount command no longer *lists* /. Is that it? Yes, that's what I meant. It shows up fine in the d-i system but not in the target. Which of the three I mentioned is the actual problem? Did they all change or just one or two? Which is used in the relevant code? Wasn't /etc/mtab for installed systems changed after Lenny to be a symlink to /proc/mounts? I seem to remember a discussion on d-devel about that. I also seem to remember that D-I had some special handling for /target/etc/mtab, but I'm not sure. Guess a grep in the lenny branch of D-I SVN (and trunk for comparison) should tell. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535513: daily fails to generate ramdisk because / not mounted
Package: installation-reports
Severity: serious
I just tried a daily image on ARM and it failed because the ramdisk
cannot be generated. Apparently this is because / is not mounted in
the chroot.
Jul 2 17:57:58 in-target: Setting up linux-image-2.6.26-2-orion5x (2.6.26-17)
...
Jul 2 17:58:02 debconf: Obsolete command TITLE Configuring
linux-image-2.6.26-2-orion5x called
Jul 2 17:58:04 in-target:
Jul 2 17:58:04 in-target: Hmm. The package shipped with a symbolic link
/lib/modules/2.6.26-2-orion5x/source
Jul 2 17:58:04 in-target: However, I can not read the target: No such file or
directory
Jul 2 17:58:04 in-target: Therefore, I am deleting
/lib/modules/2.6.26-2-orion5x/source
Jul 2 17:58:04 in-target:
Jul 2 17:58:04 in-target: Running depmod.
Jul 2 17:58:08 in-target: Finding valid ramdisk creators.
Jul 2 17:58:08 in-target: Using mkinitramfs-kpkg to build the ramdisk.
Jul 2 17:58:08 in-target: Deprecation WARNING: use update-initramfs(8)
Jul 2 17:58:09 in-target: readlink:
Jul 2 17:58:09 in-target: missing operand
Jul 2 17:58:09 in-target:
Jul 2 17:58:09 in-target: Try `readlink --help' for more information.
Jul 2 17:58:09 in-target: mkinitramfs-kpkg failed to create initrd image.
Jul 2 17:58:09 in-target: Failed to create initrd image.
Jul 2 17:58:10 in-target: dpkg: error processing linux-image-2.6.26-2-orion5x
(--configure):
Jul 2 17:58:10 in-target: subprocess installed post-installation script
returned error exit status 9
It fails because $root is empty
++ awk '/\/dev\// {if ($3 == /) {print root= $1 \nFSTYPE= $5; exit}}'
++ mount
+ eval ''
+ '[' '' = /dev/root ']'
++ readlink -f
readlink: missing operand
Try `readlink --help' for more information.
+ root=
which is because / is not mounted in the chroot:
~ # mount
rootfs on / type rootfs (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
tmpfs on /dev type tmpfs (rw,mode=755)
none on /dev/pts type devpts (rw,gid=5,mode=620,ptmxmode=000)
/dev/sda2 on /target type ext3 (rw,errors=remount-ro,data=ordered)
/dev/sda1 on /target/boot type ext2 (rw,errors=continue)
/dev/sda6 on /target/home type ext3 (rw,errors=continue,data=ordered)
/dev/sda2 on /dev/.static/dev type ext3 (rw,errors=remount-ro,data=ordered)
tmpfs on /target/dev type tmpfs (rw,mode=755)
~ # chroot /target
sh-3.2# mount
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
sh-3.2#
sh-3.2# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# file system mount point type options dump pass
proc/proc procdefaults0 0
# / was on /dev/sda2 during installation
UUID=d5f957fc-6c81-4a88-891c-d1f542de0fa3 / ext3
errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=0471103b-39b3-4ed0-9eda-7b85ce0199c9 /boot ext2defaults
0 2
# /home was on /dev/sda6 during installation
UUID=e44f917b-64a3-4d65-a25a-10dfd33f8b15 /home ext3defaults
0 2
/dev/sda5 noneswapsw 0 0
sh-3.2#
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
