--On Friday, November 02, 2007 5:18 PM +0100 maximilian attems <max@stro.at> wrote:
severity 449036 normal stop On Fri, Nov 02, 2007 at 07:51:26AM -0700, Joey Korkames wrote:Package: initramfs-tools Version: 0.85h Severity: critical Justification: breaks the whole systemwoow huge over inflated severity. please next time check for duplicate bugs aka #402931 or for example or discussion on debian-kernel http://lists.debian.org/debian-kernel/2007/08/msg00583.html
My apoligies. I used "bugreport" and flicked through a couple of pages of established bugs, but nothing caught my fancy - maybe I missed that.
By the definition given by bugreport, critical severity was justified because the problem resulted in an inability to boot. However, the edge case I had to come from to get to that was most definetely not standard, so at most I am saving _1_ more end user from not booting at a cost to 3 other initramfs-tools maintainers to fix the issue ;-)
It doesn't need to get worked on like a critical bug - but there's no other weasel code to give it that is still correct.
Hello initramfs-tools team: I routinely use debootstrap and chroot to create stock debian images for mass deployment. A recent hair-pulling session occurred for me when I chose to create and mount the target root LVM volumes of the new images using the /dev/<volume-group-name>/<volume-name> taxonomy instead of /dev/mapper/<volume-group-name>-<volume-name>. This difference is critical as the mkinitramfs script relies on the user having mounted their "root" in the 2nd form in order to notify said user that they must install busybox to satisfy the needed lvm utilitiy library dependencies in their new ramdisk so that they can boot from their lvm volume. It also relies on that mount being for root ('/' in the output of 'mount') in the first place, which in my usage as described, would also fail that test.busybox is a required dep on the version you are reporting against it only got moved to recommends in sid/testing.
Observe in the code: # Busybox if [ "${BUSYBOX}" = "n" ] || [ ! -e ${BUSYBOXDIR}/busybox ]; then mv ${DESTDIR}/bin/sh.shared ${DESTDIR}/bin/sh # those root need busybox eval "$(mount | awk '/ \/ / {print "r_dev=" $1; exit}')" if [ "${r_dev#/dev/mapper/}" != "${r_dev}" ] \ || [ "${r_dev#/dev/md}" != "${r_dev}" ]; then echo "Warning: Busybox is required for successful boot!"the code you are quoting is not in the version you are reporting against. also BUSYBOX=n is only for experienced user. plus newer apt will automaticaly install recommends.
Yes, "apt-cache policy initramfs-tools" tells me as much.... the stable one says...Depends: klibc-utils (>= 1.4.19-2), busybox (>= 1:1.01-3) | busybox-cvs-static (>= 20040623-1), cpio, module-init-tools, udev (>= 0.086-1)
strange - I'm not sure why my (apt-get powered) stable/etch installs aren't grabbing busybox then. I need to check some log files - I had been installing busybox explicitly to fix this, before installing initramfs-tools.
My apologies on filing before I had checked Depends: out. I was incensed, I guess.
I think a much better means of testing would be to parse the intended kernel version's /boot/*.config file to check for LVM=Y|M status in the compiled kernel. But honestly, what I _really_ think is needed is that busybox should be made a required dependency of initramfs-tools.no the target for embedded space doesn't want a klibc on it and yes this is used in production boxes.There is no point in beating around the bush of the many problems with linked-in dependencies of these ramdisks' utilities because of a lack of busybox, much less the uselessness of a broken ramdisk with no working shell. The ramdisks' utilities/libs are also heavily stripped which means I had near-zero inituitive diagnostic information displayed upon failure of the lvm mounts. I don't think the embedded device users' edge case (furtively scrimping bytes) is worth catering to at such a high cost to basic system usability, much less the potential debugging burden that is shifted by such decisions from highly skilled embedded device engineers/tinkerers to hapless end users running off-the-shelf hardware and (more or less) common software setups.you seem to speak of current testing and unstable, well that is not yet a polished distribution and yes knownledge is expected when working on those. as i told you apt will in furture take care of your case.Another problem I've observed because of this scrimping is that while the ramdisk supports IP, it doesn't support DNS and will be happy to _not_ tell you why (unsatisfied dependencies on /lib/libnss_dns* /lib/libnss_files* /lib/libresolv* libs not caught by the initramfs-tools hook functions). This is not critical to system operation however, and is most certainly outside a normal use case of the ramdisk's made by initramfs-tools (which should _NOT_ be a toolchain for embedded device use).could you please explain what you tried to do?
I had installed a new live-initramfs pkg from the Debian-Live repository to a stable system and used the new "fetch=" boot cmdline argument to have it mount root from a wgetted .squashfs file. It wouldn't work with dns hostnames however, only straight IP addresses. I traced it to the ramdisk simply missing these libraries.
As you implied, it could be due to my version mix-n-matching. I will try with an unstable base and report problems on this specific issue to the debian-live team - I do not know how widely "fetch=" has been tried (but I like it lots)
This bug escaped dev firstly because it is built around assumptions in the the ways that d-i would configure a root-volume-on-lvm - which is totally understandable - but MOSTLY because of ridiculous bit-pinching.d-i installs busybox _before_ initramfs-tools you seem to be backporting initramfs-tools to an ancient d-i
As I stated earlier, this is a very specific edge case where d-i isn't ever used to install the root system. Don't know why apt didn't install busybox though - will need to check logs.
Dependencies in ramdisks should be noted, but shedding them at ANY COST (like losing the ability to BOOT) is insane. Let bleeding-edge people bleed (and by their own hand, for trying to run hardware that is too limited for the newest software) and fix - normal systems should just boot. Thanks, joeythanks for your report.
Thanks for reading! -- Joey Korkames Operations Engineer joey@limelightnetworks.com Voice: (602) 850-5344 Fax: (602) 850-5444 Limelight Networks 2220 W 14th St Tempe, AZ 85281 Voice: (866) 200-LIME Fax: (602) 850-5001