User:0xdc/substrate/20200701

From Gentoo Wiki
Jump to:navigation Jump to:search

Big news! I've started experimenting with making live media. Currently, it's under the bindist branch so I can't distribute it. But it has some really cool features.

As a reminder, sources can be found at:

Changes

roflmaOS livecd

In the bindist branch, I turned my hand at building a Gentoo-based systemd livecd, similar to the Gentoo install/admincds.

I came up with the name roflmaOS for the effort.

The reason it is under the bindist branch is that genkernel which does the kernel build requires linux-firmware and doesn't fall under ACCEPT_LICENSES="@FREE" (I will not include non-free software in the distributed releases).

In future I hope to target x86_64 EFI, bare metal (systemd-boot) as well as virtualised (OVMF or xen-pvgrub). virt-install from app-emulation/virt-manager makes it rather easy to boot livecd kernels in virtual machines. I took the decision not to support BIOS x86_64 via GRUB2 out-of-the-box.

It may be possible to target the armv7a platforms that I support too, but that's for another month...

Notes

amd64

upstream seed stage3: stage3-amd64-systemd-20200630T104027Z.tar.xz

armv7a

upstream seed stage3: stage3-armv7a_hardfp-20200509T210605Z.tar.xz


Catalyst LiveCD creation process

As part of my work to create livecds, I had to take a look at the current livecd process.

  • stage1: built from stage3 in a chroot, bare minimum to bootstrap a compiler (in systemd profiles, this is enough to boot in a container)
  • stage2: a bootstrapped system with a complete compile environment
  • stage3: fully configured @system, ready for customisations (no optional packages)
  • stage4: stage3 plus additional packages and optional kernel provided
  • embedded: similar to stage1, but does not have to contain a fully self-hosting system (e.g. no compiler). can have a kernel like a stage4
  • livecd-stage1: similar to a stage4/embedded, the output is used as both (!!!) the compile environment for the livecd-stage2 and the contents of the internal CD image
  • livecd-stage2: this builds a kernel for the livecd and packages everything for the livecd including squashfs-ing the image and building the ISO. Note, that packages are removed from the seed environment before the image is squashed to reduce size.


Substrate Stage Paths.svg

Because I already have stages 1 to 4, I just needed to create the livecd-stages.

I see livecd-stage1 as partially redundant to stage4/embedded stages, and I'd rather use a separate build environment for the livecd-stage2, and even split up the stages a little too...

Here's what I think is needed:

  • livecd-stage1: customises an embedded stage for livecd booting and outputs a squashfs image
  • livecd-stage2: seeded from a stage3, builds a kernel and the isolinux/grub2 bootable payloads
  • livecd-stage3: takes the livecd payloads and the squashfs image and outputs an ISO


This kinda breaks the convention that the source_subpath is the only basis for a stage from which it is built, because now there is a stage with 2 inputs. However, the livecd-stage2 already breaks convention by defining the output_name via the livecd/iso: option, and ignoring the already defined compression_mode.

Some of the bootable payloads (sys/isolinux and memtest86+) don't even need to be installed on the host, as we can install the binaries into the livecd-stage2 environment and pull them into the CD from there. GRUB2 will need to be installed in the host system; this is a optional dependency of roflmaOS.

Future plans

  • Replacing the GRUB2 EFI bootloader with systemd-boot
  • Replacing the genkernel initrd with a dracut built one
  • armv7a support
    • my armv7a devices don't have the same standardised way of booting, so this could get complex
    • maybe I should find devices with UEFI?

libvirt ovmf support

Despite qemu pulling two copies of the EDK2 OMVF binaries, neither of them work out-of-the-box.

  • edk2-ovmf: /usr/share/edk2-ovmf/OVMF_CODE.fd,/usr/share/edk2-ovmf/OVMF_VARS.fd
  • qemu: /usr/share/qemu/edk2-x86_64-code.fd,/usr/share/qemu/edk2-i386-vars.fd


root #sed 's:/usr/share/qemu/edk2-x86_64-code.fd:/usr/share/edk2-ovmf/OVMF_CODE.fd:;s:/usr/share/qemu/edk2-i386-vars.fd:/usr/share/edk2-ovmf/OVMF_VARS.fd:' /usr/share/qemu/firmware/60-edk2-x86_64.json > /etc/qemu/firmware/60-edk2-x86_64.json
FILE /etc/libvirt/qemu.conf
nvram = [
        "/usr/share/qemu/edk2-x86_64-secure-code.fd:/usr/share/qemu/edk2-i386-vars.fd",
        "/usr/share/qemu/edk2-x86_64-code.fd:/usr/share/qemu/edk2-i386-vars.fd",
        "/usr/share/edk2-ovmf/OVMF_CODE.fd:/usr/share/edk2-ovmf/OVMF_VARS.fd",
        "/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2-ovmf/OVMF_VARS.fd",
]

Unprivileged user

A user running in qemu:///session can also run guests with OVMF:

FILE ~/.config/libvirt/qemu.config
nvram = [
        "/usr/share/qemu/edk2-x86_64-secure-code.fd:/usr/share/qemu/edk2-i386-vars.fd",
        "/usr/share/qemu/edk2-x86_64-code.fd:/usr/share/qemu/edk2-i386-vars.fd",
        "/usr/share/edk2-ovmf/OVMF_CODE.fd:/usr/share/edk2-ovmf/OVMF_VARS.fd",
        "/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2-ovmf/OVMF_VARS.fd",
]

Also needed is the /etc/qemu/firmware file from above.

user $virt-install --graphics none --console pty --os-variant gentoo -l roflmaOS-20200701.iso,kernel=boot/gentoo,initrd=boot/gentoo.igz --extra-args "docache console=ttyS0 setkmap=uk cdroot quiet overlayfs" --boot uefi