Skipping the bootloader installation when creating rootfs or installation media

[Loïc Minier]

Binary package hint: initramfs-tools

Hi

update-initramfs will unconditionally:
a) generate an initrd.gz
b) do bootloader specific logic to use the new boot files on the current system

I would like update-initramfs to support some tunable to disable the b) step, here are the use cases for this:
a) I'm on an ARM machine, I want to create a rootfs natively, including an installed kernel (with modules) and a prebuilt initrd, but I don't want flash-kernel to write the kernel from the chroot into the NAND flash of the build system
b) I'm on a x86 machine, I want to create a rootfs using qemu / qemu-debootstrap, including an installed kernel 9with modules) and a prebuilt initrd, but flash-kernel --supported would be confused by my x86 cpuinfo and would fail out, breaking the initramfs generation
c) I'm on a x86 system, and I'm writing a boot media (e.g. SD card) starting from a generic rootfs I downloaded, but installing the target kernel onto the SD card; same issue as b) occurs

Linaro is currently doing a) because we use live-helper to generate images with the kernel and initrd in the downloadable tarball.

Debian/Ubuntu currently don't install a kernel or flash-kernel at image creation time, but rather at the time the system gets installed (d-i / ubiquity installs flash-kernel in /target and the target kernel as well, and the kernel gets installed and the system is made bootable using these).

I'm personally doing b) and recommending more people to do so as a quick way to create their rootfs locally, without access to ARM hardware; I'd also like Linaro's a) method with live-helper to work with qemu-arm as well in the future.

Eventually, Linaro will be moving to c), where we build a generic rootfs with live-helper, and combine it with hardware specific packages like the kernel and flash-kernel on the system where the boot media is created, which would be an end-user's x86 box writing a SD card or something like that.

So the proposed change is to either add some tunable like an env var or a do_bootloader = no option to initramfs-tools to skip run_bootloader() entirely, but I'm told this should be done by hooks nowadays. This bug is to discuss how this is best handled.

Cheers,

[Loïc Minier (lool)]

BTW a) might also fail because the host image buildd isn't supported by flash-kernel.

[Colin Watson (cjwatson)]

run_bootloader looks like this:

# Invoke bootloader
run_bootloader()
{
        # invoke policy conformant bootloader hooks
        if [ -d /etc/initramfs/post-update.d/ ]; then
                run-parts --arg=${version} --arg=${initramfs} \
                        /etc/initramfs/post-update.d/
                return 0
        fi

        # FIXME: to be removed postsqueeze release
[...]
        if flash-kernel --supported >/dev/null 2>&1; then
                flash-kernel ${version}
                return 0
        fi
}

Thus, I think that if you simply have flash-kernel create a /etc/initramfs/post-update.d/flash-kernel script (this could be done in Debian - see http://lists.debian.org/debian-kernel/2010/07/msg00078.html for the policy draft), then you could have that script honour some environment variable and that would be all you need.

[Oliver Grawert (ogra)]

just as a sidenote, ubuntu installs kernels in it's live images and generates an initrd but does that in a completely controlled environment by diverting update-initramfs to suppress the execution for triggers and explicitly calling the diverted binary at some point in livecd-rootfs. kernel and initramfs installation surely happen in all live or preinstalled images on ubuntu.

currently ubuntu is just in the lucky situation that our imx51 based builders dont have a generic fallback [1] implemented at all and thus simply dont execute flash-kernel.

if you run it on an architecture that has the defined generic fallback implemented (dove and omap3 based systems) flash-kernel will simply try to run that generic method on the hardware it runs on (the build machine)

it seems to be an accidential omission in the spec that there is no way to prevent the generic bootloader installation.

[1] https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-maverick-arm-improved-subarch-detection

[Tobin Davis (gruemaster)]

This is now affecting kernel updates for maverick on beagle/beagleXM (omap3). After updating the kernel through update manager or manually with apt-get/dpkg, the user is left with the impression that a reboot will load the new kernel, when in fact the boot partition is not updated.

[Oliver Grawert (ogra)]

@tobin: this bug here is not related to our problem, i filed bug #701698 for it.

@loic: i will implement the /etc/initramfs/post-update.d script in the flash-kernel package, can you please make a suggestion for a variable name ?

[Oliver Grawert (ogra)]

apparently the needed variable exists in flash-kernel already as FLASH_KERNEL_SKIP which will return false for flash-kernel --supported if it is set.

[Jani Monoses (jani)]

a tangent: In the latest livecd-rootfs (1.155) FLASH_KERNEL_SKIP is set on armel so it does not try to update the boot partition of the host.

[Oliver Grawert (ogra)]

this was fixed long ago