Check firstboot flag in initramfs (helps s390x zipl)

[cgwalters]

The s390x bootloader zipl doesn't have a full interpreted programming language like GRUB that would allow an equivalent of our grub fragment.

Why again can't we mount /boot in the initramfs? We need to do that for FIPS handling anyways too

That said I also do think it makes sense to have the bootloaders support passing other data; they have code sufficient to read the kernel/initramfs so reading other files shouldn't be hard.

[sharkcz]

I think the same helps with the bare metal on Power with petitboot as the bootloader. AFAIK it only parses the other bootloaders configs (grub, syslinux, BootLoaderSpec, ...).

[laenion]

/boot is temporarily mounted in the initramfs already to read the user configuration:

ignition-dracut/dracut/30ignition/ignition-setup.sh

Line 27 in df88988

mount /dev/disk/by-label/boot $bootmnt

.
When using the initrd to read the flag file all of the dependencies (e.g. network) would have to go into the generator. Apart from that I guess it should work and would also help to solve #39.

[dustymabe]

cc @bgilbert @ajeddeloh @jlebon for thoughts

[ajeddeloh]

Grub not supporting s390x is problematic. We want to have one unified grub config that does the boot selection based on successes and failures. If we don't have the ability to do scripting we lose that.

Does zipl support bls?

[hbrueckner]

Grub not supporting s390x is problematic. We want to have one unified grub config that does the boot selection based on successes and failures. If we don't have the ability to do scripting we lose that.

I would suggest to have a generic way to deal with boot configuration instead of basing it on a particular implementation, i.e. grub.

Does zipl support bls?

Yes. Support has been added with ibm-s390-linux/s390-tools@b8a9f0d#diff-f957eeda4ae1e6a34e9b0c581afe6b9e

[ajeddeloh]

I would suggest to have a generic way to deal with boot configuration instead of basing it on a particular implementation, i.e. grub.

The bootloader needs smarts in order to support automatic rollback. It needs a way of tracking if it's tried and failed to boot a kernel/initramfs so if an update has a bad kernel it can automatically roll back.

[ajeddeloh]

After talking with @sharkcz and javier__ on freenode, one possible path forward is to use zipl to load petitboot which can then interpret the grub script. Haven't tested this (haven't even tested just petitboot) but it seems like it could work in theory and would mean everything could use the same unified grub config.

[martinezjavier]

I think the same helps with the bare metal on Power with petitboot as the bootloader. AFAIK it only parses the other bootloaders configs (grub, syslinux, BootLoaderSpec, ...).

Petitboot already has support for grub's built-in scripting language. The only missing piece that's used by the 02_ignition_firstboot fragment will be the source command, that AFAIK isn't supported by Petitboot yet.

[martinezjavier]

After talking with @sharkcz and javier__ on freenode, one possible path forward is to use zipl to load petitboot

Instead of Petitboot, I think that will make more sense to use grub2-emu (the grub user-space emulator) to reduce the differences between architectures where grub is used and architectures where the bootloader chain-loads a Linux kernel that has a built-in initramfs with a user-space bootloader. We have a grub2-emu package now in Fedora Rawhide that contains this tool.

For ppc64le probably makes sense to keep using Petitboot and just add support for the source command. This will mean though that it won't work with older versions of the firmware since it will require a Petitboot that has support for this command.

[tuan-hoang1]

With martinezjavier's suggestion on grub2-emu, I think by the time auto rollback lands on x86 + arm, we could also make it work for s390x.

So in the mean time, I suggest we move the firstboot check into initramfs. We need it for coreos-assembler/create_disk.sh, when we remove anaconda on s390x.

[tuan-hoang1]

17:27 <ajeddeloh> hmm only potential issue I see is that ignition.firstboot is actually a grub config snippet that gets sourced
17:27 <ajeddeloh> we use that for carrying over networking options used by the installer when doing bare metal installs
17:29 <ajeddeloh> and those are kcmdline options
17:30 <ajeddeloh> but I think that would be ok for s390x for the time being
17:32 <tmhoang> I think it's the best we do a check for s390x, that we inject firstboot check into initramfs. For other arch, just do grub source thing.
17:32 <tmhoang> yes right. that should work.
17:33 <ajeddeloh> yeah my thought right now is to do an arch check in the initramfs and only check there on s390x

So to summarize, we do the firstboot check in initramfs for s390x. For others, we keep doing in grub.

[ajeddeloh]

Hrm there's a wrinkle in this: The first boot detection happens in a systemd generator. This means that we don't have udev available and devices are still being enumerated. We can't use /dev/disk/by-* symlinks since those are generated by udev and even if we inspected /sys ourselves we wouldn't be sure if the device has appeared yet. Basically there's not a good way to find/wait for /boot.

[ajeddeloh]

Alternative idea for the short term (since this is only a stopgap until we get proper 2 stage bootloading on s390x): Install with a zipl config that sets the ignition.firstboot karg, then on ignition-complete recreate the zipl config without it. It's hacky, but it's confined to s390x and we should be able to rip it out soon.

[martinezjavier]

Alternative idea for the short term (since this is only a stopgap until we get proper 2 stage bootloading on s390x): Install with a zipl config that sets the ignition.firstboot karg, then on ignition-complete recreate the zipl config without it. It's hacky, but it's confined to s390x and we should be able to rip it out soon.

I agree that could be a way to workaround this.

[tuan-hoang1]

@hbrueckner: mentioned that grub2-emu might be a problem: how do we update the never-fail grub2-emu's kernel (and initramfs).

[ajeddeloh]

grub2-emu might be a problem: how do we update the never-fail grub2-emu's kernel (and initramfs).

We don't unless we really have to. Or make it a manual process.

[dustymabe]

@tuan-hoang1
So to summarize, we do the firstboot check in initramfs for s390x. For others, we keep doing in grub.

I have a possible suggestion that might work for all architectures: coreos/fedora-coreos-tracker#191 (comment)

[darkmuggle]

Based on the discussion and the commits, I'm going to call this closed. If that assessment is incorrect @cgwalters please feel free to re-open against Ignition.