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 system
woow 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
> 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.
> 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?
> 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
> 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
thanks for your report.
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
