bug#47889: [installer image] grub-install efi fails getting canonical path to /boot/efi on dos-formatted disk

[Bengt Richter]

Hi Ludo, Florian,

On +2021-04-23 12:39:13 +0200, Ludovic Courtès wrote:
> Hi Florian,
> 
> (Cc: Mathieu.)
> 
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> 
> > On Thu, Apr 22, 2021 at 03:28:39PM +0200, Ludovic Courtès wrote:
> >> There’s no EFI (vfat) partition here.  Is it an EFI machine?
> >> 
> >> Is /boot/efi mounted when you boot the installation image?
> >
> > No because there is no EFI partition.  If I create one and restart the
> > installer, then it is *not* mounted either, only /mnt/boot/efi later
> > during the install.  (I believe since the installer is installed as on
> > an external medium, it does not need an EFI partition.)
> >
> > I had booted the install image via UEFI boot and had expected auto
> > partitioning and the default configuration to do the right thing.
> 
> The installer determines whether it’s doing a UEFI installation like so:
> 
>   (define (efi-installation?)
>     "Return #t if an EFI installation should be performed, #f otherwise."
>     (file-exists? "/sys/firmware/efi"))
> 
> It uses that to determine whether to create an EFI System Partition
> (ESP) and whether to use ‘grub-efi-bootloader’.
>

How does that work if you want to mount an external USB disk as the target
of your installation partitioning and formatting etc, but which may be intended
for another laptop with a different BIOS booting in a different mode than your
installer was booted into? (Maybe plug the finished USB disk into another 
laptop?
USB C3.1 is fast enough if connected to a good SSD cassette).

I.e., suppose your installer machine was booted UEFI but you want the target 
disk
to be legacy MBR booted on a laptop that can only do that, loading grub2 as 
embedded
in the target disk? Or vice versa?

I'd like an interactive install, maybe selecting a target disk something like
--8<---------------cut here---------------start------------->8---
$ select choice in $(lsblk -o kname,model,serial|tr -s ' ' _); do break;done
1) KNAME_MODEL_SERIAL                                      6) dm-0_
2) sdb_Ultra_Fit_XXXXXXXXXXXXXXXXXXXX                      7) 
nvme0n1_Samsung_SSD_970_EVO_Plus_500GB_XXXXXXXXXXXXXXX
3) sdb1_                                                   8) nvme0n1p1_
4) sdb2_                                                   9) nvme0n1p2_
5) sr0_USB_SCSI_CD-ROM_XXXXXXXXXXXXXXXX
#? 2
$ echo "$choice"
sdb_Ultra_Fit_XXXXXXXXXXXXXXXXXXXX
--8<---------------cut here---------------end--------------->8---

so then the installation script can continue and mount the associated disk 
device
--8<---------------cut here---------------start------------->8---
$ echo "$choice"|cut -d _ -f1 
sdb 
--8<---------------cut here---------------end--------------->8---

It seems like the /sys/... file system that would show whether the disk is 
EFI-bootable
will be determined by booting the very disk image we are trying to create -- 
both by its
content (MBR and/or GPT, and what bootloader + .cfg, etc) and the BIOS trying 
to boot it.

Sorry for the noise if I am missing some context.

> Did it create an ESP in your case?
> 
> I’m not entirely sure how it decides between GPT and DOS, though;
> Mathieu?
> 
> We should add UEFI installation tests using OVMF.
> 
> Thanks,
> Ludo’.
> 
> 
> 

-- 
Regards,
Bengt Richter