Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

2023-04-18 Thread Daniel Abrecht
In my image builder, I just mount a tmpfs over /sys/firmware to hide it: 
https://github.com/Daniel-Abrecht/dpa-image-builder/blob/22a18b8108d07ef72595f5217fd196cd01ddb71f/script/chns#L100

An Image builder shouldn't mess with the hosts firmware anyway.



Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

2023-04-17 Thread Johannes Schauer Marin Rodrigues
Hi,

Quoting Isaac True (2023-04-17 10:49:20)
> > Why would you have to run flash-kernel again?
> 
> When it's being initially installed it won't have the additional command line
> flag that forces it to ignore the EFI check, so it won't run and you would
> have to run it manually afterwards with the flag. I agree that an env
> variable/config file would be better here.
> 
> > The name FK_FORCE_EFI=yes seems a bit backwards; it is ignoring 
> 
> the presence of EFI, not forcing it to behave like EFI. FK_FORCE_NO_EFI?
> FK_IGNORE_EFI? Names are hard.
> 
> My intention behind the name was something like "force *despite* EFI", but I
> think FK_IGNORE_EFI does indeed fit a lot better. .
> 
> > I overall like this approach, although the main drawback is having to write
> > to /etc/default/flash-kernel 
> 
> I agree with this - it's a bit more awkward having to create and write a
> file, but I like that it opens the door to allow both methods to work. The
> user can either set the env variable, or it can be set in the file itself.

I've had a private chat with Vagrant yesterday and we agreed that the best way
forward would be to solve this in the same way the environment variable
FK_MACHINE works which can also be set using /etc/flash-kernel/machine and is
essentially and override for /proc/device-tree/model.

So in the same fashion we could have FK_IGNORE_EFI as an environment variable
which can also be set by having /etc/flash-kernel/ignore-efi which is an
override for the existence of /sys/firmware/efi.

Would you like to amend your patch to add support for
/etc/flash-kernel/ignore-efi in addition to FK_IGNORE_EFI? I'd be willing to
test the result in our CI environment. :)

> I'm not sure if it makes sense to add the "! ischroot" check like in that
> merge request though, as I feel like that's a different topic. What do you
> think?

The "! ischroot" is not strictly required for my use-case. I added it because
with it, we get the nice property, that outside of a chroot (i.e. when not
creating a bootable image for another machine) the presence of efi will not get
ignored. This would mean that after creating the bootable image, one would not
have to remove /etc/flash-kernel/ignore-efi to get back to a system that
potentially could support efi in the future. But I do not require this extra
complexity. I think there is value in making FK_IGNORE_EFI behave the same as
FK_MACHINE without any hidden surprises like the "! ischroot" check.

Thanks!

cheers, josch

signature.asc
Description: signature


Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

2023-04-17 Thread Isaac True
> Why would you have to run flash-kernel again?

When it's being initially installed it won't have the additional command line 
flag that forces it to ignore the EFI check, so it won't run and you would have 
to run it manually afterwards with the flag. I agree that an env 
variable/config file would be better here.

> The name FK_FORCE_EFI=yes seems a bit backwards; it is ignoring 
the presence of EFI, not forcing it to behave like EFI. FK_FORCE_NO_EFI? 
FK_IGNORE_EFI? Names are hard.

My intention behind the name was something like "force *despite* EFI", but I 
think FK_IGNORE_EFI does indeed fit a lot better.  

> I overall like this approach, although the main drawback is having to write 
> to /etc/default/flash-kernel 

I agree with this - it's a bit more awkward having to create and write a file, 
but I like that it opens the door to allow both methods to work. The user can 
either set the env variable, or it can be set in the file itself. I'm not sure 
if it makes sense to add the "! ischroot" check like in that merge request 
though, as I feel like that's a different topic. What do you think?

Cheers,
Isaac



Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

2023-04-16 Thread Vagrant Cascadian
On 2023-04-16, Johannes Schauer Marin Rodrigues wrote:
> On Fri, 31 Mar 2023 13:52:45 + Isaac True  wrote:
>> As part of our CI/CD system, we are building images for target devices.  The
>> images are set up in virtual machines which boot using EFI, but flash-kernel
>> installation always fails as it detects that the system is running in EFI by
>> checking for the existence of /sys/firmware/efi.
>
> we have the same problem when building bootable images for the MNT Reform
> laptop:
>
> https://source.mnt.re/reform/reform-system-image/
>
> The CI system is a machine that boots with EFI but the final system uses uboot
> to boot and not EFI.
>
>> Being able to setup the image on these VMs is an important part of our
>> testing and validation workflow, so it would be very helpful to have an
>> option to skip this check and proceed regardless of whether the system is
>> currently running in EFI mode or not.
>
> This used to work in the past but was broken by this commit:
>
> https://salsa.debian.org/installer-team/flash-kernel/-/commit/8a81a537995a2b98386aea883729ce9960a825bf
>
>> I've added a debdiff for a proposal for a new parameter --force-efi which can
>> be set to skip this check.
>
> The problem with implementing this using a command line flag or an environment
> variable is, that then you will have to run flash-kernel again manually after
> initially installing it.

Why would you have to run flash-kernel again?
In the EFI VM environment, you are overriding the detected default, as
the image is created for another system type. Once you have booted into
that image, it should pick the correct defaults (e.g. EFI or not EFI).

For better or worse, something similar is already done with the
FK_MACHINE environment variable, so at least another environment
variable would not be inconsistent.

The name FK_FORCE_EFI=yes seems a bit backwards; it is ignoring the
presence of EFI, not forcing it to behave like EFI. FK_FORCE_NO_EFI?
FK_IGNORE_EFI? Names are hard.

I definitely like the simiplicity of the environment variable approach,
although it feels a bit wrong to have the package postinst affected by
it (although there is already precedent with FK_MACHINE).

Not sure about a commandline flag, though I can't quite place my finger
on why...

 
> What do you think about instead using an option in /etc/default/flash-kernel
> which allows ignoring /sys/firmware/efi if inside a chroot as I implemented
> here:
>
> https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/33

I overall like this approach, although the main drawback is having to
write to /etc/default/flash-kernel and then potentially having to handle
changes merged into it on flash-kernel upgrades...


I very much appreciate new energy on this issue; it seemed stuck on two
somewhat incompatible needs and also broke previous working
configurations.

It seems like there are a few options forwards now, at least! Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

2023-04-15 Thread Johannes Schauer Marin Rodrigues
Control: tag -1 + patch

Hi,

On Fri, 31 Mar 2023 13:52:45 + Isaac True  wrote:
> As part of our CI/CD system, we are building images for target devices.  The
> images are set up in virtual machines which boot using EFI, but flash-kernel
> installation always fails as it detects that the system is running in EFI by
> checking for the existence of /sys/firmware/efi.

we have the same problem when building bootable images for the MNT Reform
laptop:

https://source.mnt.re/reform/reform-system-image/

The CI system is a machine that boots with EFI but the final system uses uboot
to boot and not EFI.

> Being able to setup the image on these VMs is an important part of our
> testing and validation workflow, so it would be very helpful to have an
> option to skip this check and proceed regardless of whether the system is
> currently running in EFI mode or not.

This used to work in the past but was broken by this commit:

https://salsa.debian.org/installer-team/flash-kernel/-/commit/8a81a537995a2b98386aea883729ce9960a825bf

> I've added a debdiff for a proposal for a new parameter --force-efi which can
> be set to skip this check.

The problem with implementing this using a command line flag or an environment
variable is, that then you will have to run flash-kernel again manually after
initially installing it.

What do you think about instead using an option in /etc/default/flash-kernel
which allows ignoring /sys/firmware/efi if inside a chroot as I implemented
here:

https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/33

Thanks!

cheers, josch

signature.asc
Description: signature


Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

2023-03-31 Thread Isaac True
Alternatively, this could be an environment variable to allow flash-kernel to 
run non-interactively on an EFI system (such as when installing/updating with 
apt, or after updating the initrd).

---

diff -Nru flash-kernel-3.106/debian/changelog 
flash-kernel-3.106+nmu1/debian/changelog
--- flash-kernel-3.106/debian/changelog 2022-04-22 23:55:41.0 +
+++ flash-kernel-3.106+nmu1/debian/changelog2023-03-31 14:28:23.0 
+
@@ -1,3 +1,10 @@
+flash-kernel (3.106+nmu1) UNRELEASED; urgency=medium
+
+  * Skip EFI detection mechanism when the FK_FORCE_EFI environment
+variable is set to "yes".
+
+ -- Isaac True   Fri, 31 Mar 2023 14:28:23 +
+
 flash-kernel (3.106) unstable; urgency=medium

   * db/all.db: Move MNT Reform 2 boards later to fix sort order.
diff -Nru flash-kernel-3.106/flash-kernel.8 
flash-kernel-3.106+nmu1/flash-kernel.8
--- flash-kernel-3.106/flash-kernel.8   2022-03-23 14:22:28.0 +
+++ flash-kernel-3.106+nmu1/flash-kernel.8  2023-03-31 14:28:11.0 
+
@@ -40,6 +40,10 @@
 .B choice of machine may cause host filesystem partitions to be mounted and
 .B modified.

+.IP FK_FORCE_EFI
+Skip EFI detection when this variable is set to `yes'. Normally, flash-kernel
+will abort if it detects that the system is running in EFI mode.
+
 .SH FILES
 .TP
 .B /usr/share/flash-kernel/db/all.db
diff -Nru flash-kernel-3.106/functions flash-kernel-3.106+nmu1/functions
--- flash-kernel-3.106/functions2022-04-12 19:43:15.0 +
+++ flash-kernel-3.106+nmu1/functions   2023-03-31 14:28:23.0 +
@@ -789,7 +789,7 @@
kfile=$(readlink -e "$kfile")
 fi

-if [ -d /sys/firmware/efi ]; then
+if [ -d /sys/firmware/efi ] && [ "x$FK_FORCE_EFI" != "xyes" ]; then
# skipping when detect EFI
echo "System running in EFI mode, skipping."
exit 0



Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

2023-03-31 Thread Isaac True
Package: flash-kernel
Version: 3.106
Severity: normal
File: flash-kernel
X-Debbugs-Cc: isaac@is.having.coffee

Dear Maintainer,

As part of our CI/CD system, we are building images for target devices.
The images are set up in virtual machines which boot using EFI, but
flash-kernel installation always fails as it detects that the system is
running in EFI by checking for the existence of /sys/firmware/efi. 

Being able to setup the image on these VMs is an important part of our
testing and validation workflow, so it would be very helpful to have an
option to skip this check and proceed regardless of whether the system
is currently running in EFI mode or not. 

I've added a debdiff for a proposal for a new parameter --force-efi
which can be set to skip this check.

---

diff -Nru flash-kernel-3.106/debian/changelog 
flash-kernel-3.106+nmu1/debian/changelog
--- flash-kernel-3.106/debian/changelog 2022-04-22 23:55:41.0 +
+++ flash-kernel-3.106+nmu1/debian/changelog2023-03-31 13:04:23.0 
+
@@ -1,3 +1,10 @@
+flash-kernel (3.106+nmu1) UNRELEASED; urgency=medium
+
+  * Skip EFI detection mechanism when the --force-efi option
+has been set.
+
+ -- Isaac True   Fri, 31 Mar 2023 13:04:23 +
+
 flash-kernel (3.106) unstable; urgency=medium

   * db/all.db: Move MNT Reform 2 boards later to fix sort order.
diff -Nru flash-kernel-3.106/flash-kernel.8 
flash-kernel-3.106+nmu1/flash-kernel.8
--- flash-kernel-3.106/flash-kernel.8   2022-03-23 14:22:28.0 +
+++ flash-kernel-3.106+nmu1/flash-kernel.8  2023-03-31 13:04:23.0 
+
@@ -3,7 +3,7 @@
 .SH NAME
 flash-kernel \- put kernel and initramfs in boot location
 .SH SYNOPSIS
-.B flash-kernel [--supported] [--force] [kvers]
+.B flash-kernel [--supported] [--force] [--force-efi] [kvers]
 .SH DESCRIPTION
 flash-kernel is a script which will put the kernel and initramfs in
 the boot location of embedded devices that don't load the kernel and
@@ -25,6 +25,11 @@
 match. Valid filenames for images to flash are suffixed with the
 subarchitecture.
 .P
+Normally, flash\-\-kernel will abort the installation if it detects that
+it is running in an EFI-based environment. If the \-\-force\-efi option
+is used, flash\-kernel will skip this check and continue with the
+installation.
+.P
 If the \-\-supported option is used, flash\-kernel will test to see if
 the hardware is supported, and return a true or false value.
 .SH ENVIRONMENT VARIABLES
diff -Nru flash-kernel-3.106/functions flash-kernel-3.106+nmu1/functions
--- flash-kernel-3.106/functions2022-04-12 19:43:15.0 +
+++ flash-kernel-3.106+nmu1/functions   2023-03-31 13:04:23.0 +
@@ -679,6 +679,11 @@
force="yes"
shift
 fi
+force_efi="no"
+if [ "x$1" = "x--force-efi" ]; then
+   force_efi="yes"
+   shift
+fi
 if [ "x$1" = "x--machine" ]; then
machine="$2"
shift 2
@@ -789,9 +794,10 @@
kfile=$(readlink -e "$kfile")
 fi

-if [ -d /sys/firmware/efi ]; then
+if [ -d /sys/firmware/efi ] && [ "x$force_efi" != "xyes" ]; then
# skipping when detect EFI
echo "System running in EFI mode, skipping."
+   echo "Use --force-efi if you want to skip this check."
exit 0
 fi