Add support for UEFI installations

[pmenzel]

Now, on a UEFI system, the output looks like below.

$ sudo ./mxgrub mariux-4.14.67-217
/boot/grub/grub.cfg: updated
mount -L ESP /boot/efi
grub-install --target=x86_64-efi /dev/nvme0n1
Installing for x86_64-efi platform.
Installation finished. No error reported.
umount /boot/efi
GRUB is already installed in MBR.
grub-editenv - set chosen=all-other-kernel>mariux-4.14.67-217

[wwwutz]

Just for my innocent mind... Are we going to install standard MarIuX systems so it will boot from UEFI ? So we have System disks with UEFI and others with Legacy ?

Sounds like a boy group to me... "Wrong Direction".

[donald]

• Is /boot/efi supposed to be the mounted FAT32 EFI system partition? And therefore not disted?
• Does sys 'grub-install','--target=x86_64-efi',$root_disk write a GRUB MBR? Although an UEFI boot doesn't read it?
• Does /boot/grub differ depending on whether the --target=x86_64-efi is being given to grub-install? Currently /boot/grub is disted, so this would be a problem.
• Can we make mxgrub install always install /boot/efi and MBR (and - although disted - /boot/grub) . To my (wrong?) understanding the switch, how we boot, is in the firmware. Can we have a system disk which can take any kind of boot? .

[donald]

Do we need to depend sys 'grub-install','--target=x86_64-efi',$root_disk and exit 1; on is_efi ? Maybe we should use "if there is a UEFI partition" instead. Maybe we should mount it (if not already mounted) and dismount if (if we mounted it).

[pmenzel]

On 09/03/18 11:43, Donald Buczek wrote: Do we need to depend `sys 'grub-install','--target=x86_64-efi',$root_disk and exit 1;` on `is_efi` ? Maybe we should use "if there is a UEFI partition" instead. Maybe we should mount it (if not already mounted) and dismount if (if we mounted it).

If we do not depend on it `grub-install` is going to fail. No idea, if that is acceptable. I’d prefer to be explicit. The ESP is now mounted in case a UEFI installation is detected.

[pmenzel]

[Note, updates were uploaded in the mean-time, some of the changes already addressing some comments.]

On 08/30/18 12:28, Donald Buczek wrote: * Is `/boot/efi` supposed to be the mounted FAT32 EFI system partition? And therefore not disted?

Yes, it is. The EFI System Partition should be mounted there. After discussing this, it is now only mounted, when checking and installing GRUB.

* Does `sys 'grub-install','--target=x86_64-efi',$root_disk` write a GRUB MBR? Although an UEFI boot doesn't read it?

No, it does not. `grub-install` also aborts, when the ESP is not mounted.

* Does `/boot/grub` differ depending on whether the `--target=x86_64-efi` is being given to grub-install? Currently `/boot/grub` is disted, so this would be a problem.

Yes, the subdirectories `i386-pc` is used for legacy boot, and `x86_64-efi` for UEFI. We checked `/root/Distfile`, and `i386-pc` is not disted, so we will go that route for UEFI too. # problems with mod-file /boot/grub/i386-pc between grub-2.00 and grub-2.02 /boot/grub/i386-pc

* Can we make `mxgrub install` always install `/boot/efi` and MBR (and - although disted - `/boot/grub`) . To my (wrong?) understanding the switch, how we boot, is in the firmware. Can we have a system disk which can take any kind of boot?

Good idea. Currently, GRUB is *also* installed in the MBR of a UEFI mounted system. I haven’t found an easy way to trick `grub-install` into installing `/boot/grub/x86_64-efi` also on legacy systems. The switch `--force` doesn’t help. deinemuddah:~> sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --force /dev/sda Installing for x86_64-efi platform. grub-install: error: /boot/efi doesn't look like an EFI partition.

[donald]

Suggestion: Instead of is_efi ( = -d '/sys/firmware/efi') use have_ESP ( = !system "blkid -L ESP>/dev/null" ) ?

[pmenzel]

On 09/04/18 13:25, Donald Buczek wrote: Suggestion: Instead of `is_efi` ( = ` -d '/sys/firmware/efi' `) use `have_ESP` ( = ` !system "blkid -L ESP>/dev/null" ` ) ?

Could you document the advantage? Your suggestion has the disadvantage that it doesn’t work with *mxonastick* where the ESP is named ESPUSB. Getting too depend on labels is not a good idea in my opinion, as it causes problems once you put two devices on the same system (for example for debugging).

[donald]

The intended advantage is, that I'd install the bootcode into the ESP partition (if available on the target disk) and into the MBR and between the partitions (if available on the target disk) no matter how my system booted.

blkid --probe --match-token PART_ENTRY_TYPE="0xef"  $device

might be correct.

[pmenzel]

On 09/04/18 14:01, Donald Buczek wrote: The intended advantage is, that I'd install the bootcode into the ESP partition (if available on the target disk) and into the MBR and between the partitions (if available on the target disk) no matter how my system booted. blkid --probe --match-token PART_ENTRY_TYPE="0xef" $device might be correct.

But didn’t we test, that `grub-install` will fail anyway, if the system is not booted using UEFI?

[donald]

works for me (not UEFI bootet) :

root@theinternet:~/git/mariuxinstaller (add-uefi-support)# rm -r /scratch/local2/test.dat
rm: cannot remove ‘/scratch/local2/test.dat’: No such file or directory
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# truncate -s500G /scratch/local2/test.dat
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# loop=$(losetup -f --show -- /scratch/local2/test.dat)
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# ./mxpartit ${loop#/dev/}           # from add-uefi-support branch
[mxpartit INFO] Device: loop0
[mxpartit INFO]  size=1048576000 512 byte blocks / 500GiB
[mxpartit INFO]  hwsectorsize=512 bytes (using: 512 bytes )
[mxpartit INFO]  root: size=274877906944 bytes (256 GiB) (536870912 sectors)
[mxpartit INFO]  data: size=261858787328 bytes (243 GiB) (511442944 sectors)
[mxpartit INFO]  ESP: size=134217728 bytes ( GiB) (262144 sectors)
[mxpartit INFO] partitioning disk loop0 using sfdisk ..
Creating new GPT entries.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Disk /dev/loop0: 500 GiB, 536870912000 bytes, 1048576000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

>>> Created a new DOS disklabel with disk identifier 0xfa86a495.
/dev/loop0p1: Created a new partition 1 of type 'Linux' and of size 256 GiB.
/dev/loop0p2: Created a new partition 2 of type 'Linux' and of size 243.9 GiB.
/dev/loop0p3: Created a new partition 3 of type 'EFI (FAT-12/16/32)' and of size 127 MiB.
/dev/loop0p4: Done.

New situation:
Disklabel type: dos
Disk identifier: 0xfa86a495

Device       Boot      Start        End   Sectors   Size Id Type
/dev/loop0p1 *          2048  536872959 536870912   256G 83 Linux
/dev/loop0p2       536872960 1048313855 511440896 243.9G 83 Linux
/dev/loop0p3      1048313856 1048573951    260096   127M ef EFI (FAT-12/16/32)

The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Invalid argument
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
Syncing disks.
[mxpartit INFO] reloading partition table of loop0 using partprobe ..
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# mkfs.vfat -F32 -n ESP ${loop}p3
mkfs.fat 3.0.26 (2014-03-07)
unable to get drive geometry, using default 255/63
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# mkfs.xfs -f -L root ${loop}p1
meta-data=/dev/loop0p1           isize=512    agcount=4, agsize=16777216 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=67108864, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# mkdir -p /mnt/x/
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# mount ${loop}p1 /mnt/x
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# mkdir -p /mnt/x/boot/efi
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# mount ${loop}p3 /mnt/x/boot/efi
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# grub-install --target=x86_64-efi --boot-directory=/mnt/x/boot $loop
Installing for x86_64-efi platform.
Installation finished. No error reported.
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# umount /mnt/x/boot/efi /mnt/x
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# losetup -d $loop
root@theinternet:~/git/mariuxinstaller (add-uefi-support)# rm -r /scratch/local2/test.dat

[pmenzel]

I guess, the is_efi() check can be removed, and we just handle sys 'mount','-L','ESP','/boot/efi' and exit 1; and the umount gracefully.

[donald]

Yes. Another idea might be to not immediately exit 1if MBR or EFI install failes, but attempt both in any case (and then exit 1 if either failed). So if MBR or EFI install is prevented by bad partiton layout, we'd ar least have the other boot option available.

If you want, I can take over and code this. I mean its perl. For people from the vaults.

[pmenzel]

On 09/04/18 14:01, Donald Buczek wrote: The intended advantage is, that I'd install the bootcode into the ESP partition (if available on the target disk) and into the MBR and between the partitions (if available on the target disk) no matter how my system booted. blkid --probe --match-token PART_ENTRY_TYPE="0xef" $device might be correct.

This seems to only work with root rights. $ blkid --probe --match-token PART_ENTRY_TYPE="0xef" /dev/sda blkid: error: /dev/sda: Permission denied

[pmenzel]

Thank you for the review. I’ll introduced has_esp(), and use that to hopefully avoid error messages on the console.

There is one drawback with efibootmgr, which is called by grub-install, and fails if the system is not booted with UEFI. @donald wants to not have it run by grub-install, and I’ll try to add a switch there. But, it’s not a showstopper in my opinion.

[pmenzel]

Looks like the switch no-nvram will skip executing efibootmgr.

[…]
    case OPTION_NO_NVRAM:
      update_nvram = 0;
      return 0;
[…]
      if (!removable && update_nvram)
        {
          char * efifile_path;
          char * part;
          int ret;

          /* Try to make this image bootable using the EFI Boot Manager, if available.  */
          if (!efi_distributor || efi_distributor[0] == '\0')
            grub_util_error ("%s", _("EFI bootloader id isn't specified."));
          efifile_path = xasprintf ("\\EFI\\%s\\%s",
                                    efi_distributor,
                                    efi_file);
          part = (efidir_grub_dev->disk->partition
                  ? grub_partition_get_name (efidir_grub_dev->disk->partition)
                  : 0);
          grub_util_info ("Registering with EFI: distributor = `%s',"
                          " path = `%s', ESP at %s%s%s",
                          efi_distributor, efifile_path,
                          efidir_grub_dev->disk->name,
                          (part ? ",": ""), (part ? : ""));
          grub_free (part);
          ret = grub_install_register_efi (efidir_grub_dev,
                                           efifile_path, efi_distributor);
          if (ret)
            grub_util_error (_("efibootmgr failed to register the boot entry: %s"),
                             strerror (ret));
        }
[…]

[pmenzel]

I added the switch. (Just for your interest, there is also --no-bootsector for the legacy case.)