[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#449036: marked as done (initramfs-tools: mkinitramfs - insufficient inclusion of busybox for)



Your message dated Mon, 24 Dec 2007 13:59:18 +0100
with message-id <20071224125918.GA28432@stro.at>
and subject line Bug#449036: initramfs-tools: mkinitramfs - insufficient inclusion of busybox for
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: initramfs-tools
Version: 0.85h
Severity: critical
Justification: breaks the whole system


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.

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!"


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.

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.

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).

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.

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,
joey

-- Package-specific info:
-- /proc/cmdline
root=/dev/hda1 ro root=/dev/hda1 ro root=/dev/hda1 ro

-- /proc/filesystems
       ext3
       ext2
       cramfs
       xfs

-- lsmod
Module                  Size  Used by
nfs                   251320  0
ipv6                  294400  18
nfsd                  260392  17
exportfs               10624  1 nfsd
lockd                  71088  3 nfs,nfsd
nfs_acl                 8320  2 nfs,nfsd
sunrpc                175304  13 nfs,nfsd,lockd,nfs_acl
ppdev                  13960  0
parport_pc             41256  0
lp                     17608  0
parport                44684  3 ppdev,parport_pc,lp
8021q                  25616  0
evdev                  15488  0
pcspkr                  7936  0
8250                   40008  0
serial_core            27008  1 8250


-- System Information:
Debian Release: 4.0
 APT prefers stable
 APT policy: (1001, 'stable'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20-llnw.ops.xen
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages initramfs-tools depends on:
ii busybox 1:1.1.3-4 Tiny utilities for small and embed ii cpio 2.6-17 GNU cpio -- a program to manage ar ii klibc-utils 1.4.34-1 small statically-linked utilities ii module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo ii udev 0.105-4 /dev/ and hotplug management daemo

initramfs-tools recommends no packages.

-- no debconf information

--
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



--- End Message ---
--- Begin Message ---
On Fri, 02 Nov 2007, Joey Korkames wrote:

> 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.
>

as apt with by default installing of recommends is in unstable
and due to migrate soon to testing i'll close that report.
installers like d-i that do *not* install recommends by default
have to take care on there own to add busybox, the goal is
to make initramfs-tools much ligher for embedded box without
loosing the debugging comfort. cryptsetup and lvm2 both need
busybox so if an installer needs that he needs to take little
extra care.

initramfs-tools in stable depends on busybox.

regards

-- 
maks


--- End Message ---

Reply to: