pull binaries required for nested initramfs from debirf build, instead of build host

[jrollins]

busybox and klibc-utils are installed in debirf when install-kernel plugin is run, so they can be pulled from there, instead of having them as package depends.

[dkg]

OTOH, the only reason that they're present in the debirf image is because of the Depends: from the linux-image package.

If we just unpacked the linux-image .deb into the debirf chroot instead of dpkg --installing it, then dpkg wouldn't think it needed to install those packages into the chroot.

Would this break anything? what are the extra packages pulled in as dependencies by the linux-image package? the ​package itself depends on ​initramfs-tools and ​module-init-tools. While i suspect module-init-tools is going to be relevant for most debirf instances, initramfs-tools probably is not -- you don't need to make an initramfs if you're running from debirf. busybox, klibc-utils, and udev are all pulled in by initramfs-tools, not by anything else. So we could avoid forcing udev into the debirf if we managed to avoid the initramfs-tools package itself.

Alternately, we could find another way to satisfy the ​linux-initramfs-tool dependency of the linux-image package besides initramfs-tools, since debirf doesn't really need that environment. Maybe a dummy package?

[jrollins]

I agree that it would be nice to not have debirf make an initrd. It wastes time during the build, and is useless. Do we not want udev, though? Is it not necessary with 2.6 kernels? Even if it's not, do we not want to handle hotplug-type events?

I definitely agree that it would be nice to not have the initramfs-tools and module-init-tools in the debirf build. We should try the dpkg unpack instead of install.

[dkg]

udev isn't a dependency of the 2.6 kernels. it's a dependency of initramfs-tools, which is one of two choices (the other being yaird, which doesn't depend on udev) which satisfy the linux-initramfs-tool dependency of the 2.6 kernels.

I think it would be a bad idea to not install module-init-tools, though. Without that, you'd be unable to load kernel modules from a running debirf.

If we want udev for debirf (i think a good argument could be made for its inclusion), why not specify that explicitly for installation?

[jrollins]

so last night i played around a bit with the debirf /etc/kernel-img.conf. For some reason there is no man page for that file currently in debian, but i did find one on-line that specifies what the various parameters do:

​man /etc/kernel-img.conf

I was trying to experiment with that to see if I could tell it to not make an initrd, but haven't had any success, yet.

ultimately, though, like you say, we would like to not have to install initramfs-tools at all.

[jrollins]

the things that get pulled in when the kernel is installed in the install-kernel plugin (at least with lenny) are:

busybox initramfs-tools klibc-utils libklibc libvolume-id0 udev

klibc-utils (+libklibc), busybox, and udev (+libvolume-id0) are all required by the initramfs-tools. i guess the idea would be to make a dummy package that provides linux-initramfs-tool, and depends at least on udev. it we wanted to pull busybox and and klibc-utils from the debirf image, instead of the host, then we could depend on those things as well.

[dkg]

Alternately, we could just explicitly pull in the packages we need, and then just dpkg --extract the linux-image-* package desired, without explicitly installing it within the chroot.

[jrollins]

so i recently changed things to allow for specifying a kernel package, instead of a kernel deb, that would be installed directly with apt in the debirf chroot. i thought this would be a nice feature cause then you could install kernel straight from apt without having to download the deb to the host first. i would like to keep this functionality since i'm using it almost exclusively now. so to work with a kernel package from apt, we could either just download the kernel package in the debirf chroot and unpack it, or provide a dummy package that provides it's requirements, and then just apt-get install the kernel package. i'm not sure way is better.

[dkg]

If we were using aptitude instead of apt-get, we could do

aptitude download $KERNEL_PACKAGE
dpkg --extract $KERNEL_PACKAGE

providing our own dummy package doesn't make a lot of sense to me, simply because we've worked so hard to avoid requiring debirf users to build anything. It doesn't sound like a package that should really be in debian proper, so now you'd all of a sudden either be supplying it within debirf (which is odd) or asking end users to build it themselves (which requires them to have a full set of build-deps available, etc).

[jrollins]

I think we've decided that it's actually just fine to pull the components needed to make the nest from the host build system. This keeps make-debirf simpler, without really adding any extra extraneous requirements on the build system (at least that i can think of now). I'm going to close this ticket and open a new one to address the issue of kernel installation.

[dkg]

Looks good. and the fact that debirf depends on busybox and klibc-utils is enough to make that OK. most modern debian systems are going to have those packages available anyway, and there shouldn't be any conflict between a nest and different versions of the same packages in the real debirf fs.