Support to re-dracut a live image?

[Gavin Lambert]

Given a kiwi-ng live image (built using image="iso", and thus using a squashfs) installed onto a USB stick with automatically created persistent partition, I've noticed that making changes to boot scripts or installing new kernels or kernel modules and then running sudo dracut -f appears successful but then on reboot it still uses the original image's boot and initrd.

It's probably unsurprising that this doesn't work directly due to the overlays.

Is there some additional step required to "bake in" the new boot content (from the target system, i.e. without fully rebuilding the image)?

Is there some other image format that might work better (perhaps just image="ext4" -- can that make a bootable usb)?

[Gavin Lambert]

On Monday, May 5, 2025 at 3:24:05 PM UTC+12 Gavin Lambert wrote:

Is there some additional step required to "bake in" the new boot content (from the target system, i.e. without fully rebuilding the image)?

Still curious about this. 

Is there some other image format that might work better (perhaps just image="ext4" -- can that make a bootable usb)?

But at least on this front, it looks like the .raw file from type="oem" is what I want.  What initially threw me about this is that this file doesn't appear to be published by kiwi-ng result bundle (I also have format="vmdk" so it was perhaps publishing that instead?).  Is there a way to make it publish both -- or even better, preserve the xz-compressed version that it prepares for the installer iso, rather than re-compressing it?

[Marcus Schäfer]

Hi,

> Given a kiwi-ng live image (built using image="iso", and thus using a
> squashfs) installed onto a USB stick with automatically created
> persistent partition, I've noticed that making changes to boot scripts
> or installing new kernels or kernel modules and then running sudo
> dracut -f appears successful but then on reboot it still uses the
> original image's boot and initrd.
> It's probably unsurprising that this doesn't work directly due to the
> overlays.

Yeah this is a known problem for read-only systems with an overlay.
The bootloader setup reads the initrd and the kernel from the read-only
storage and that makes this data immutable. If the overlay is a tmpfs
a copy of the initrd/kernel due to a dracut call or a package update that
issues it would only exist temporary. If the overlay is a persistent write
space created on first boot and re-used for any subsequent boot processes
it would be in theory possible to point the bootloader to this space.
We could write a more smart early-boot script for grub which checks
on a by-label search if there is a storage space to read the initrd
and the kernel from. At the moment we don't do this. Maybe I find
the time for some experiments.

> Is there some other image format that might work better (perhaps just
> image="ext4" -- can that make a bootable usb)?

As you wrote in your other e-mail using a real disk image (image="oem")
is an option to solve this problem. You can consider to use a filesystem
that supports compression like btrfs to achieve a similar size as you
get with a squashfs/erofs based live system. Such an image is then
mutable like a standard OS.

Hope this helps

Regards,
Marcus
--
Public Key available via: https://keybase.io/marcus_schaefer/key.asc
keybase search marcus_schaefer

[Marcus Schäfer]

Hi,

> But at least on this front, it looks like the .raw file from type="oem"
> is what I want.

yes

> What initially threw me about this is that this file
> doesn't appear to be published by kiwi-ng result bundle (I also have
> format="vmdk" so it was perhaps publishing that instead?).

This is correct. If you specify a format="..." in your oem type the
bundler takes precedence over your format request. Meaning we assume
if the user specifies an image format, that is what the bundled
result should contain. If you are interested in the .raw only, then
simply drop the format attribute from the image type setup. You can
convert the .raw into any format you like via

qemu-img convert -f file.raw -O vmdk file.vmdk

If you wish the .raw to be bundled uncompressed you can configure
that as follows:

edit /etc/kiwi.yml and specify

bundle:
- compress: false

or

use the new "--no-compress" option when calling "kiwi-ng result bundle ..."

[Gavin Lambert]

On Monday, May 5, 2025 at 10:33:43 PM UTC+12 Marcus wrote:

If you wish the .raw to be bundled uncompressed you can configure
that as follows:

Actually it was kind of the reverse; I was under the (mistaken) impression that the disk image embedded inside the oem installer iso had been xz compressed, so I was thinking that it could just put that in the bundle directly rather than deleting it and re-compressing it later.  But I see now that it uses squashfs internally, so it's different anyway.

My disk image is ~20GB uncompressed (blame CUDA) so every little bit of saving build time helps... though I think it's still worthwhile to keep the xz compression since it packs that down to ~6GB.

I've removed the virtual format tags from the kiwi script and using qemu-img after the fact to convert the raw file; works well, thanks!  (It would work even better if qemu-img could take the raw.xz as input, but sadly not.)