Bug#403846: update-initramfs: mount/losetup are broken in initrd
reassign 403846 mdadm retitle 403846 support partionable arrays with offset boot arg severity 403846 wishlist stop On Wed, 20 Dec 2006, root wrote: > > I dont use crypt; I have made my RAID.1 over disk, then partitioning; > that is perfectly OK with RAID.1 (and only this one). Partitions are > relative to md0; since mount works in system, it should work in busybox; > it does in busy box if I put back the systems binary, not with default > one. In fact, I wonder why mkinitrd does not take systems losetup to put > in image ... ok that is not supposed to be supported yet, so i reassign. anyway that is postetch material. best regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403846: update-initramfs: mount/losetup are broken in initrd
tags 403846 moreinfo stop On Wed, 20 Dec 2006, root wrote: > my / is on sdb; sda+sdc are set up as RAID=>/dev/md0 > > At the moment, I boot my system on sdb; file systems of sdb have been copied > to md0. > > After booting sdb, I can run successfully: > mount -o offset=2564014080 /dev/md0 /mnt/whatever > > So, to boot and use md0 as root, I changed the boor arguments from > /vmlinuz ro initrd=/initrd.img root=/dev/sdb3 > to > /vmlinuz ro initrd=/initrd.img root=/dev/md0 rootflags=offset=2564014080 > > In short, at bot time I am said that md0 is not mountable; then, I fallback > to some > prompt. if you report wants to be helpfull we need as much written down from your boot process, without any error message from your side, we have no idea what's happening on your box. > Ther, I try to mount md0 manually, running exactly the same command: > mount -o offset=2564014080 /dev/md0 /mnt/ > and I am said from memory "invalid argument". the busybox mount has not the offset arg for losetup presumbably. i have zero idea what you are trying to do, if you want an encrypted root use luks. cryptsetup has the relevant initramfs-tools boot scripts. > After 2 weeks trying EVERY THING I could think of, I have embedded losetup > from the main system in the ramdisk; once in the prompt, the procedure > became: > - losetup -o 2564014080 /dev/loop4 /dev/md0 > - /scripts/dhp/losetup -o 2564014080 /dev/loop6 /dev/md0 > - mount -o ro /dev/loop4 /root > - mount -o ro /dev/loop6 /root > > First call is using losetup from the ramdisk made by update-initramfs; the > second one is using losetup I put in the ramdisk. 3rd call fails, 4th works. > > This means losetup actually embedded in initramdisk does not support > properly the offset option. The result is that loop device can not be set > up, and everything fails. > > I do not know if other scripts also have this failure (to assume that the > offset option is never passed), but please, check so. > > I will do more testing within days, to see if rebuilding the ramdisk > manually and swicthing the losetup binary solves the problem; if yes, then > other scripts are OK. again it might be helpfull to explain what you are trying to do. losetup is known to be flacky. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403846: update-initramfs: mount/losetup are broken in initrd
Package: update-initramfs Version: update-initramfs Severity: normal my / is on sdb; sda+sdc are set up as RAID=>/dev/md0 At the moment, I boot my system on sdb; file systems of sdb have been copied to md0. After booting sdb, I can run successfully: mount -o offset=2564014080 /dev/md0 /mnt/whatever So, to boot and use md0 as root, I changed the boor arguments from /vmlinuz ro initrd=/initrd.img root=/dev/sdb3 to /vmlinuz ro initrd=/initrd.img root=/dev/md0 rootflags=offset=2564014080 In short, at bot time I am said that md0 is not mountable; then, I fallback to some prompt. Ther, I try to mount md0 manually, running exactly the same command: mount -o offset=2564014080 /dev/md0 /mnt/ and I am said from memory "invalid argument". After 2 weeks trying EVERY THING I could think of, I have embedded losetup from the main system in the ramdisk; once in the prompt, the procedure became: - losetup -o 2564014080 /dev/loop4 /dev/md0 - /scripts/dhp/losetup -o 2564014080 /dev/loop6 /dev/md0 - mount -o ro /dev/loop4 /root - mount -o ro /dev/loop6 /root First call is using losetup from the ramdisk made by update-initramfs; the second one is using losetup I put in the ramdisk. 3rd call fails, 4th works. This means losetup actually embedded in initramdisk does not support properly the offset option. The result is that loop device can not be set up, and everything fails. I do not know if other scripts also have this failure (to assume that the offset option is never passed), but please, check so. I will do more testing within days, to see if rebuilding the ramdisk manually and swicthing the losetup binary solves the problem; if yes, then other scripts are OK. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-alpha-smp Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
