create_disk.sh: using the target system's grub2-install to install BIOS/PReP bootloader

[HuijingHei]

Fix #3156

[HuijingHei]

/hold
Should wait until OCP 4.12 release

[cgwalters]

Should wait until OCP 4.12 release

Hmm, does it need to? We've branched off 4.12 so I think we can safely land things in main here right?

[HuijingHei]

Should wait until OCP 4.12 release

Hmm, does it need to? We've branched off 4.12 so I think we can safely land things in main here right?

Not sure, is it necessary to wait art build using coreos-assembler:rhcos-4.12 for ocp 4.12 (refer to https://gitlab.cee.redhat.com/openshift-art/rhcos-upshift/-/blob/rhcos-4.12/jobspec.yaml#L141)?

[dustymabe]

Now that this merged.. Is there a way to verify that the installed bootloader was installed using the grub from the target system? Could we make a exttest out of it and we'll know if it ever gets out of sync again?

[HuijingHei]

Now that this merged.. Is there a way to verify that the installed bootloader was installed using the grub from the target system? Could we make a exttest out of it and we'll know if it ever gets out of sync again?

That would be better, I will try to add. Do you have any suggestions?

[HuijingHei]

Can I record the grub2-install package version when running, and compare it with rhcos after booted?

# rpm -qf /sbin/grub2-install
grub2-tools-2.02-123.el8_6.8.x86_64

[cgwalters]

That's the thing...what we see in the RPM database previously was not the same as what got installed to the disk! But note this is actually the same problem as what happens on a traditional e.g. Anaconda+yum/dnf system - typing dnf update does not rerun grub2-install on the MBR.

This is something that adding support into bootupd was aiming to fix.

There might be some version data embedded into the binary data installed into the partition but if there is it's not obvious to me.

I think such a test for now would have to do something basically like simulating create_disk.sh on a temporary loopback device, then compare the raw data in the partitions.

[HuijingHei]

Thanks @cgwalters for the pointer.

Find that when running grub2-install, this will generate core.img

[root@cosa-devsh ~]# grub2-install --target i386-pc --boot-directory /boot/ --modules mdraid1x /dev/vda
...
grub2-install: info: grub-mkimage --directory '/usr/lib/grub/i386-pc' --prefix '(,gpt3)/grub2' --output '/boot/grub2/i386-pc/core.img'  --dtb '' --format 'i386-pc' --compression 'auto' --appended-signature-size 0  'mdraid1x' 'ext2' 'part_gpt' 'biosdisk'

Test with old version 412.86.202211082314-0, compare the size is different before (bootloader is installed by cosa container) and after running grub2-install(bootloader is installed by target os). Maybe can reinstall bootloader and check core.img size.

[root@cosa-devsh ~]# rpm-ostree status
State: idle
Deployments:
● 1e6a74981d2379c11ecec924f59a799efe07b257add5ce34fc4e89198978291e
                  Version: 412.86.202211082314-0 (2022-11-08T23:17:18Z)
[root@cosa-devsh ~]# ll /boot/grub2/i386-pc/core.img
-rw-r--r--. 1 root root 38318 Nov  8 23:21 /boot/grub2/i386-pc/core.img
[root@cosa-devsh ~]# mount -o remount,rw /boot
[root@cosa-devsh ~]# grub2-install --target i386-pc --boot-directory /boot/ --modules mdraid1x /dev/vda
Installing for i386-pc platform.
Installation finished. No error reported.
[root@cosa-devsh ~]# ll /boot/grub2/i386-pc/core.img
-rw-r--r--. 1 root root 37729 Nov 22 09:13 /boot/grub2/i386-pc/core.img