mkinitramfs supports compression that neither encodes size, nor is
guaranteed to signal the end of compressed archive. Linux refuses to
parse additional archives beyond the first compressed one - unless they
start at 4-byte boundary like uncompressed ones do.

I request
A) to modify mkninitramfs to append such padding and
B) to add tests to ensure concatenation keeps working (even after, say,
compression algo/lvl changes)

Rationale:
1. Documentation: After the requested change, inserting custom
configuration or installation prerequisites to provided installation
media will just work again. Append your changes, done.
2. It worked before: Without compression, still just works(tm). Should
never have been broken.
3. Debugging: With compression and before the requested change, raw cpio
and xz-compressed (len modulo 4 == 0) can be concatenated just fine. But
compressed-after-lz4 or raw-after-compressed makes the kernel ignore the
second half - and if that was not surprising enough, it *sometimes*
works, by chance.
4. Least surprise: With or without this change, alignment and/or EOF
signal might be added by the bootloader [10]. Since this can surprise
the person working on the image, it would be beneficial to preempt it in
ways visible in the filesystem.

Considerations:
5. Breaks reproducible builds: Post-change files are up to 0-3 bytes
bigger. See also #855357
6. Boot bugs: Unlikely, padding was always allowed; since the
introduction of lz4 even necessary.
7. Breakage in non-kernel Debian software: Unlikely; unmkinitramfs had
already been documented to not support multiple compressed archives.
Scripts would not depend on its behavior when parsing such anyway.
8. Breakage in bootloaders/firmware: Unlikely; all compression
algorithms (save xz) already sometimes produce the post-change
alignment, by (~25%) chance.

The attached sample code copies the desired bytes from /dev/zero. Also
attached is an autopkgtest script that calls qemu-system on the
concatenation of all currently supported compression algorithms in an
attempt to confirm that the kernel has not errorred out before parsing
the last one. It worked on my system, but even if it also works on
yours: beware that it is an amd64-only, non-EFI-only test.

dmesg samples, just to aid in detecting duplicates of this report
Initramfs unpacking failed: invalid magic at start of compressed archive
Initramfs unpacking failed: Decoding failed
Initramfs unpacking failed: broken padding

[10] see grub.git/grub-core/loader/linux.c@a8c473
[11] see linux.git/Documentation/filesystems/ramfs-rootfs-initramfs.rst

Control: tag -1 - patch
[...]

Currently unmkinitramfs is not able to unpack an initramfs image that
has multiple compressed parts.  Since you want mkinitramfs to support
this option, I would expect to see a patch that also makes unmkinitramfs
support it.

(There is an open merge request to make unmkinitramfs use 3cpio where
available:
<https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/172>.
I haven't tested whether 3cpio supports multiple compressed parts; if it
does then only the tests need to be updated to cover this case.)

Ben.

I would caution against that and rather only add the quick and easy bit:

1) Fixing the regression and adding autopkgtest is adds little code yet
solves the hassle for any *manual* workflow that once worked.

2) Actually parsing such archives is way more complicated - and for
what? Unless
unmkinitramfs was aiming for perfect bug-compatibility with kernel code
it would
always harbor potential for dangerously misleading output.

No. Looks like it shuts down even if current decompression stopped short
of EOF:
https://github.com/bdrung/3cpio/blob/2ffd9dc9ce46f5d885fb066eef73b127889918e2/src/examine.rs#L85
https://github.com/bdrung/3cpio/blob/2ffd9dc9ce46f5d885fb066eef73b127889918e2/src/extract.rs#L181
(Still good, insofar it means my suggested unconditional padding does
not make it crash.)