Ship live PXE artifacts inside live ISO

[bgilbert]

Update bootloaders and 20live for coreos/coreos-assembler#1643.

This adds bsdtar to the package list; it's a wrapper around libarchive (and can handle cpio files). We use it instead of cpio to unpack the rootfs image, because in ISO boots we need to extract the osmet files, and cpio can't do that without reading the entire rootfs image (including the root squashfs) from the boot medium.

This is interlocked with coreos/coreos-assembler#1643 and there is no ratchet.

[dustymabe]

commit 0a3571ab6c8d73ab02d9bce6c3f758330079182c                                                                                                                                                                                              
Author:     Benjamin Gilbert <bgilbert@redhat.com>                                                                                                                                                                                           
AuthorDate: Thu Aug 6 06:20:35 2020 -0400                                                                                                                                                                                                    
Commit:     Dusty Mabe <dusty@dustymabe.com>                                                                                                                                                                                                 
CommitDate: Thu Aug 6 16:23:36 2020 -0400                                                                                                                                                                                                    

    live: move kernel/initramfs and rename initramfs

    It seems to be conventional in Fedora/RHEL to put the kernel in
    /images/pxeboot/vmlinuz and the initramfs in /images/pxeboot/initrd.img.

    Requires matching coreos-assembler buildextend-installer changes.

It feels a bit weird to me to change from images/vmlinuz to images/pxeboot/vmlinuz here for the ISO boot case. I don't disagree that we should do it, but wondering if we can use that iso9660 hardlink trick to have them both be a hardlink. So

• images/vmlinuz hardlink with images/pxeboot/vmlinuz
• images/initramfs.img hardlink with images/pxeboot/initrd.img

[bgilbert]

It feels a bit weird to me to change from images/vmlinuz to images/pxeboot/vmlinuz here for the ISO boot case.

How so? Is anything likely to depend on the old paths? Up until now, everything in the ISO image was supposed to be an implementation detail. 🙂 And if we add the hardlink, new things may acquire a dependency on the old path.

[dustymabe]

It feels a bit weird to me to change from images/vmlinuz to images/pxeboot/vmlinuz here for the ISO boot case.

How so? Is anything likely to depend on the old paths? Up until now, everything in the ISO image was supposed to be an implementation detail. slightly_smiling_face And if we add the hardlink, new things may acquire a dependency on the old path.

Mostly that it just feels wrong. Naming is hard, but it feels awkard that we would move to a less appropriate name for compat even if it is just an internal implementation detail. Also our live PXE initramfs we put on the website is initramfs.img and making it initrd.img could be confusing too. It would feel more ergonomic if we just supported the old "expected" (i.e. people have hardcoded it for other Red Hat distributions) location as a hardlink or symlink (are symlinks supported?), but didn't make it the preferred location.

Something similar seems to be done for the Fedora 32 server DVD where the same initramfs is in two different locations:

$ find /mnt/ | grep initrd.img | xargs md5sum
90b9ce13217024c456c27c78034f4bab  /mnt/images/pxeboot/initrd.img
90b9ce13217024c456c27c78034f4bab  /mnt/isolinux/initrd.img
$
$ cat /mnt/isolinux/isolinux.cfg | grep initrd.img | head -n 1
  append initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-32 quiet

If I were investigating a problem it might throw me down the wrong path because in the ISO case we clearly aren't PXE booting and I would say "wait a minute, why are we using the pxeboot initrd!", but it would be the intended image to use.

I know it doesn't really matter and I don't really know why I'm defending this so hard.

[dustymabe]

oh wow, but if I look at the grub.cfg (for EFI) on that F32 ISO I see:

### BEGIN /etc/grub.d/10_linux ###                                                                                                                                                                                                           
menuentry 'Install Fedora 32' --class fedora --class gnu-linux --class gnu --class os {                                                                                                                                                      
    linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-32 quiet                                                                                                                                                       
    initrdefi /images/pxeboot/initrd.img                                                                                                                                                                                                     
}

So I guess there is a case where it's set up counter to what I would have expected. That certainly weakens my argument.

[bgilbert]

it feels awkard that we would move to a less appropriate name for compat even if it is just an internal implementation detail.

I agree that it's weird. I'd argue the alias is actually worse for two reasons: 1) if there's only one name for a thing, it's obvious which name is being used at any given time, and 2) if there are two names for the thing, people might think there's a difference between them.

[dustymabe]

it feels awkard that we would move to a less appropriate name for compat even if it is just an internal implementation detail.

I agree that it's weird. I'd argue the alias is actually worse for two reasons: 1) if there's only one name for a thing, it's obvious which name is being used at any given time, and 2) if there are two names for the thing, people might think there's a difference between them.

Yeah, I'll concede. I think the only point that still really sticks is the difference between initrd.img and fedora-coreos-32.20200804.dev.1-live-initramfs.x86_64.img, but I think it doesn't matter much either.

[dustymabe]

LGTM, only few optional comments left. Nice work @bgilbert

[jlebon]

One optional comment, but LGTM as is! Needs rebase on top of #545.