[SRU] Add FK_FORCE_EFI environment variable to skip EFI check

Bug #2011536 reported by Isaac True
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
flash-kernel
Fix Released
Unknown
flash-kernel (Ubuntu)
Fix Released
Undecided
Unassigned
Jammy
Fix Released
Undecided
Unassigned

Bug Description

[ 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

Revision history for this message
Isaac True (itrue) wrote :
Revision history for this message
Isaac True (itrue) wrote :

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.

Revision history for this message
Loïc Minier (lool) wrote :

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

Revision history for this message
Isaac True (itrue) wrote :

> 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.

Revision history for this message
Isaac True (itrue) wrote :

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

Revision history for this message
Isaac True (itrue) wrote :

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

Changed in flash-kernel:
status: Unknown → New
Changed in flash-kernel:
status: New → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

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).

Changed in flash-kernel (Ubuntu Jammy):
status: New → Incomplete
Revision history for this message
Benjamin Drung (bdrung) wrote (last edit ):

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

Revision history for this message
Michał Fita (michal.fita) wrote :

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.

Revision history for this message
Aristo Chen (aristochen) wrote :

Hi

Since Mantic is EOL now, I guess we could backport to Jammy directly. I noticed that there is a new version of flash-kernel in proposed pocket, but not in the updates pocket yet, so I made a debdiff based on the proposed version, please let me know if you have any concern, thanks!

Revision history for this message
Dave Jones (waveform) wrote :

This looks reasonable (patch matches the change that was made for 3.107), and the SRU template is well filled out. I'll sponsor this shortly.

Changed in flash-kernel (Ubuntu):
status: New → Fix Released
Changed in flash-kernel (Ubuntu Jammy):
status: Incomplete → Confirmed
Revision history for this message
Dave Jones (waveform) wrote :

Setting devel to fix released as 3.107 was merged; made one minor change for sponsorship to add the bug number to d/changelog

Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello Isaac, or anyone else affected,

Accepted flash-kernel into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/flash-kernel/3.104ubuntu22 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in flash-kernel (Ubuntu Jammy):
status: Confirmed → Fix Committed
tags: added: verification-needed verification-needed-jammy
Revision history for this message
Aristo Chen (aristochen) wrote :

Hi,

I have verified the version 3.104ubuntu22 on my i.MX8MP platform, and it fixes the issue

here are the steps that I performed for testing
1. create the file /etc/flash-kernel/ignore-efi with content "yes"
2. install new version of flash-kernel
3. check if files are installed correctly under /boot/efi/

tags: added: verification-done-jammy
removed: verification-needed-jammy
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Hello Aristo,

thanks for your verification.

The test plan, however, has more steps:

> 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.

As this is what was agreed on when the SRU was accepted, we need those tests to be carried out. I'm therefore setting the verification tag back to "needed".

tags: added: verification-needed-jammy
removed: verification-done-jammy
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Also, there seems to be an FTBFS on riscv64[1] which wasn't there in the previous update, so this is a regression. Since there are no logs for that failure, I have just retried the build, as that is commonly an indication of an infrastructure problem not related to the package itself.

1. https://launchpad.net/ubuntu/+source/flash-kernel/3.104ubuntu22/+build/29162596

Revision history for this message
Aristo Chen (aristochen) wrote :

Hi Andreas,

I have followed your instructions in comment#16, and the behavior looks good, here are the outputs

# Scenaro 1(while FK_FORCE_EFI is NOT set to "yes")
```
ubuntu@ubuntu:~$ sudo flash-kernel
Using DTB: freescale/imx8mp-evk.dtb
Installing /lib/firmware/5.15.0-1036-ein/device-tree/freescale/imx8mp-evk.dtb into /boot/dtbs/5.15.0-1036-ein/freescale/imx8mp-evk.dtb
Taking backup of imx8mp-evk.dtb.
Installing new imx8mp-evk.dtb.
System running in EFI mode, skipping.
```

# Scenario 2(While FK_FORCE_EFI is set to "yes")
```
ubuntu@ubuntu:~$ sudo flash-kernel
Using DTB: freescale/imx8mp-evk.dtb
Installing /lib/firmware/5.15.0-1036-ein/device-tree/freescale/imx8mp-evk.dtb into /boot/dtbs/5.15.0-1036-ein/freescale/imx8mp-evk.dtb
Taking backup of imx8mp-evk.dtb.
Installing new imx8mp-evk.dtb.
flash-kernel: installing version 5.15.0-1036-ein
Taking backup of imx8mp-evk.dtb.
Installing new imx8mp-evk.dtb.
```

Regarding to the comment#17, is there anything I need to do to fix it?

Revision history for this message
Dave Jones (waveform) wrote :

@aristochen -- no, the retry of the riscv64 build succeeded. Provided the SRU test plan has been carried out successfully, in full (which appears to be the case from a quick skim?), all that's now required is to set the jammy verification tag again.

Aristo Chen (aristochen)
tags: added: verification-done-jammy
removed: verification-needed-jammy
tags: added: verification-needed-jammy
removed: verification-done-jammy
Revision history for this message
Chris Halse Rogers (raof) wrote :

Sorry, but I think the test plan here had *3* components:
1. Test that this doesn't affect behaviour on a normal target machine (ie: on a device)

2. 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".

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

As far as I can see we've verified 2 & 3 here (that flash-kernel skips as normal on an EFI system, and that it does not skip with FORCE_EFI set to yes). I don't see a verification that flash-kernel works as normal on a device that is *not* an EFI device.

Revision history for this message
Dave Jones (waveform) wrote :

@raof Good catch -- thankfully I can test that quite quickly on a Pi here!

$ sudo apt install -t jammy-proposed flash-kernel
.. usual apt output ...
Unpacking flash-kernel (3.104ubuntu22) over (3.104ubuntu21) ...
Setting up flash-kernel (3.104ubuntu22) ...
Using DTB: bcm2710-rpi-3-b-plus.dtb
flash-kernel: deferring update (trigger activated)
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for initramfs-tools (0.140ubuntu13.4) ...
update-initramfs: Generating /boot/initrd.img-5.15.0-1065-raspi
Using DTB: bcm2710-rpi-3-b-plus.dtb
Installing /lib/firmware/5.15.0-1065-raspi/device-tree/bcm2710-rpi-3-b-plus.dtb into /boot/dtbs/5.15.0-1065-raspi/./bcm2710-rpi-3-b-plus.dtb
Taking backup of bcm2710-rpi-3-b-plus.dtb.
Installing new bcm2710-rpi-3-b-plus.dtb.
flash-kernel: installing version 5.15.0-1065-raspi
Taking backup of vmlinuz.
Installing new vmlinuz.
Taking backup of initrd.img.
Installing new initrd.img.
Taking backup of uboot_rpi_2.bin.
Installing new uboot_rpi_2.bin.
Taking backup of uboot_rpi_4_32b.bin.
... all the usual flash-kernel output on a Pi ...

tags: added: verification-done-jammy
removed: verification-needed-jammy
Revision history for this message
Timo Aaltonen (tjaalton) wrote : Update Released

The verification of the Stable Release Update for flash-kernel has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package flash-kernel - 3.104ubuntu22

---------------
flash-kernel (3.104ubuntu22) jammy; urgency=medium

  * Add FK_FORCE_EFI environment variable to skip EFI check (LP: #2011536)
    - cherry pick from commit b58a33cc and 373a0a46

 -- Aristo Chen <email address hidden> Tue, 01 Oct 2024 06:27:04 +0000

Changed in flash-kernel (Ubuntu Jammy):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.