qemu cannot load multiple initramfs archives

[Samuel Bronson]

According to Documentation/early-userspace/buffer-format.txt, an initramfs can be populated from multiple cpio archives, which seems like it could be a really useful feature when using QEMU to boot Linux kernels directly, without installing them on the disk image.

Unfortunately, QEMU does not support actually loading multiple files into the initrd space (which is also where initramfs archives go). It would be really nice if it did.

[Anthony Liguori (anthony-codemonkey)]

I'm marking this as wishlist. Technically speaking, our bootload can support multiple initramfs' that are joined together. What we don't do today is generate one of these automagically from multiple -initrd options. This is a completely reasonable thing to do though.

[agraf (agraf)]

Linux initrd catting works by appending multiple cpio archives. Usually you pass gzip'ed cpio archives though.
So in order to support multiple -initrd with Linux kernels, we'd need to unpack all initrds, concatenate them and gzip them again so Linux is happy.

I don't know if that's worth it.

Multiboot supports multiple "modules" which are represented as -initrd in qemu. I'd rather see multiboot support in Linux than implementing cpio concatenating in qemu.

[Samuel Bronson (naesten)]

 Linux initrd catting works by appending multiple cpio
> archives. Usually you pass gzip'ed cpio archives though. So in
> order to support multiple -initrd with Linux kernels, we'd need to
> unpack all initrds, concatenate them and gzip them again so Linux is
> happy.

That isn't what the Linux documentation says. The relevant portion of
Documentation/early-userspace/buffer-format.txt is:

,----
| The full format of the initramfs buffer is defined by the following
| grammar, where:
| * is used to indicate "0 or more occurrences of"
| (|) indicates alternatives
| + indicates concatenation
| GZIP() indicates the gzip(1) of the operand
| ALGN(n) means padding with null bytes to an n-byte boundary
|
| initramfs := ("\0" | cpio_archive | cpio_gzip_archive)*
|
| cpio_gzip_archive := GZIP(cpio_archive)
|
| cpio_archive := cpio_file* + (<nothing> | cpio_trailer)
|
| cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data
|
| cpio_trailer := ALGN(4) + cpio_header + "TRAILER!!!\0" + ALGN(4)
`----

That is, you can concatenate gzipped cpio archives together just fine,
as long as you align each one on a 4-byte boundary by padding the
previous one with NULs.

> Multiboot supports multiple "modules" which are represented as
> -initrd in qemu. I'd rather see multiboot support in Linux than
> implementing cpio concatenating in qemu.

QEMU has code for that? Where? I get all of two results from:

    % git log -Smultiboot

-- both in the binary file named "pc-bios/openbios-sparc32"

Anyway, even if QEMU does have code for that, why should Linux assume
that multiboot modules are necessarily cpio archives for initramfs?
(If that's not what you meant, what *did* you mean?)

[agraf (agraf)]

Now that looks like a really useful feature. I only knew of cpio concatenating so far, not that Linux can handle multiple gzip'ed cpios.

My multiboot patchset is on its way upstream. It should be in soon unless something breaks utterly ;-). After that you could write a patch that basically does a split by "," and reads several initrds.

Or is this bug about a feature request because you won't do it? If so, I could take a look at it next time I'm fiddling with the Linux -kernel code.

[Samuel Bronson (naesten)]

Well, I began an attempt to implement it, but the way I was going about it was touching way too much stuff, and I didn't know if the way I was doing it was even reasonable -- it involved replacing the single initrd name with a list of them, using some stuff from that queue.h reimplementation, and it was getting kind of hairy and touching a lot more code than I liked.

Your way probably would be a bit easier to do, since it would mean that most of the code that passes around what it believes to be the one and only initrd name could continue to do so without change.

[Thomas Huth (th-huth)]

Looking through old bug tickets... If I've got that right, there is multiboot support in QEMU nowadays, and we also have the possibility to load multiple files with the "loader" device ... is that enough, or is still something to be done here?

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]