[SRU] Add FK_FORCE_EFI environment variable to skip EFI check

[Isaac True]

[ Impact ]

Flash-kernel currently checks to see if the machine is running in an EFI environment by checking the existence of /sys/firmware/efi, and exits if this is the case. This is undesirable in some cases, such as in virtual, container, or chroot environments where the host is running in an EFI environment, but the target device that the system will actually run on is not and needs flash-kernel to be run.

This debdiff adds the ability to skip this check by setting the FK_FORCE_EFI environment variable to "yes" (which follows the usage of the FK_FORCE environment variable). This way, flash-kernel can be run even though the host system is running in an EFI environment.

[ Test Plan ]

As this change should not impact the current usage of the tool, a test should be carried out that the normal default usage (i.e. on target platforms) is not affected and retains the current behaviour.

We should also test that the current behaviour of exiting when the /sys/firmware/efi directory is detected is retained when FK_FORCE_EFI is not set to "yes".

Finally, the new ability to skip the EFI detection check when FK_FORCE_EFI is set to "yes" must be tested.

[ Where problems could occur ]

Some users may be relying on the current behaviour of flash-kernel to exit when the EFI environment is detected. The current default behaviour is being retained so as to avoid this issue, meaning a user should only see the effect of this change when setting FK_FORCE_EFI to "yes".

[ Other Info ]

N/A

[Isaac True (itrue)]

Test results on Ubuntu 22.04:

# Normal flash-kernel process.

ubuntu@ubuntu:~$ sudo flash-kernel
Using DTB: s32g274a-rdb2.dtb
Installing /lib/firmware/5.15.0-1007-s32/device-tree/freescale/s32g274a-rdb2.dtb into /boot/dtbs/5.15.0-1007-s32/./s32g274a-rdb2.dtb
Taking backup of s32g274a-rdb2.dtb.
Installing new s32g274a-rdb2.dtb.
flash-kernel: installing version 5.15.0-1007-s32
Generating u-boot image... done.
Taking backup of fitImage.
Installing new fitImage.

# Mount a tmpfs over /sys/firmware so that we can add an efi directory.

ubuntu@ubuntu:~$ sudo mount -t tmpfs test /sys/firmware
ubuntu@ubuntu:~$ sudo mkdir /sys/firmware/efi

# Test the existing EFI detection is still working.
# flash-kernel should exit without doing anything.

ubuntu@ubuntu:~$ sudo flash-kernel
System running in EFI mode, skipping.

# Set the environment variable FK_FORCE_EFI="yes" to skip the EFI check
# Note we have to set the FK_MACHINE variable here as it can no longer
# read the device tree due to the tmpfs mount.
# This should succeed.

ubuntu@ubuntu:~$ sudo FK_FORCE_EFI="yes" FK_MACHINE="NXP S32G274A-RDB2" flash-kernel
Using DTB: s32g274a-rdb2.dtb
Installing /lib/firmware/5.15.0-1007-s32/device-tree/freescale/s32g274a-rdb2.dtb into /boot/dtbs/5.15.0-1007-s32/./s32g274a-rdb2.dtb
Taking backup of s32g274a-rdb2.dtb.
Installing new s32g274a-rdb2.dtb.
flash-kernel: installing version 5.15.0-1007-s32
Generating u-boot image... done.
Taking backup of fitImage.
Installing new fitImage.

[Loïc Minier (lool)]

I'm a bit challenged with time in reviewing less obvious flash-kernel features as I need to wrap my head around the feature and a possible path to Debian (I can more easily review + sponsor hardware additions to the db)

For this particular feature: my memory is that f-k is mainly supposed to run on hardware as it might flash a mtd device, or write to a raw offset of a block device. It has environment variables to disable itself fully while e.g. generating pre-installed rootfs/images; an installer would then chroot into the newly installed / preinstalled rootfs and then run flash-kernel on the target hardware

While f-k mostly generate files, I don't think flash-kernel is particularly good in the mode of "please ignore the current environment and generate artifacts for the following hardware target without flashing them to non-OS managed locations", perhaps it grew such support recently though. I would expect this to be done with something like FK_FORCE_TARGET_MACHINE or something, and then EFI/chroot/device-tree checks should be ignored and the machine db would be used, except for flashing to real hardware

I'd recommend hashing this out in the devel/tip version of f-k in Ubuntu first, with some thoughts on how it would look in Debian, and then SRU-ing this

[Isaac True (itrue)]

> While f-k mostly generate files, I don't think flash-kernel is particularly good in the mode of "please ignore the current environment and generate artifacts for the following hardware target without flashing them to non-OS managed locations", perhaps it grew such support recently though. I would expect this to be done with something like FK_FORCE_TARGET_MACHINE or something, and then EFI/chroot/device-tree checks should be ignored and the machine db would be used, except for flashing to real hardware

I would say there is precedence for forcing installation/environments in flash-kernel with the use of FK_FORCE and FK_MACHINE, where you can override the VM/container and target machine detection.

I also wanted to add a new flag (FK_FORCE_EFI) rather than utilise the existing FK_FORCE flag so that the current behaviour doesn't change unexpectedly for users, in case someone is relying on this EFI detection.

[Isaac True (itrue)]

This changeset also cleanly applies against the current ubuntu/devel tip (flash-kernel-3.106ubuntu13)

[Isaac True (itrue)]

Conversation is progressing on the Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033737

[Łukasz Zemczak (sil2100)]

I see that this has been fixed in debian with 3.107. Before we proceed with backporting, I think someone will have to deal with merging flash-kernel to mantic, and then also preparing the same upload for lunar (before we push it to jammy).

[Benjamin Drung (bdrung)]

I unsubscribed ~ubuntu-sponsors. Please resubscribe ~ubuntu-sponsors once you addressed Łukasz's comment.

[Michał Fita (michal.fita)]

I'd be glad to see this fix in Jammy. ATM I sed `flash-kernel` in chroot to overcome blockade coming from EFI detection. It's ugly hack.

Thank you.