--On Friday, November 02, 2007 5:18 PM +0100 maximilian attems
<[EMAIL PROTECTED]> 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 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
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,
joey
thanks for your report.
Thanks for reading!
--
Joey Korkames
Operations Engineer
[EMAIL PROTECTED]
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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
