search

Biosias / uefi-mkconfig

grub-mkconfig inspired script for automatically managing uefi entries for booting linux kernel directly without bootloader
Apache License 2.0
7 stars 2 forks source link

uefi-mkconfig doesn't know where EFI partition is #4

Open alecStewart1 opened 2 months ago

alecStewart1 commented 2 months ago

Hello!

I'm on gentoo and have been trying to use this with the installkernel efistub USE flag. It appears on running emerge --config gentoo-kernel, uefi-mkconfig doesn't seem to understand that my EFI partition is at /efi and not /boot. 

 * Updating UEFI configuration...
 * Running uefi-mkconfig...
 * No mounted efi partitions!
 * uefi-mkconfig failed                                                                                                                                                                                                                                                                                                [ !! ]
 * Installing the kernel failed

If I look at my /etc/fstab:

UUID=XXXX-XXXX                      /efi          vfat      defaults,noatime    0 2

If we try and see if /dev/nvme0n1p1, the actual NVMe device, is mounted with /efi:

# mount /dev/nvme0n1p1 /efi
mount: /efi: /dev/nvme0n1p1 already mounted on /efi.
       dmesg(1) may have more information after failed mount system call.

But even with uefi-mkconfig failing, it pulls all the files in /boot and I have to manually move them into the correct places and make a EFI boot entry myself with them, which makes the use of this script with Gentoo's installkernel kind of pointless.

AndrewAmmerlaan commented 2 months ago

Please check the following:

Biosias commented 2 months ago

Hello,

as @AndrewAmmerlaan already mentioned. uefi-mkconfig identifies ESP partition by checking its PARTTYPE so make sure it is c12a7328-f81f-11d2-ba4b-00a0c93ec93b.

You can use:

 lsblk -o +PARTTYPE

If the partition is of a correct type, please let me know, I'll investigate further.

leandrolnh commented 2 months ago

I'm also having the same error. It seems like lsblk -o +PARTTYPE is blank:

(chroot) livecd / # lsblk -o +PARTTYPE
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
                                             PARTTYPE
loop0         7:0    0   3,2G  1 loop        
sda           8:0    1  57,8G  0 disk        
└─sda1        8:1    1  57,7G  0 part        
nvme0n1     259:0    0 953,9G  0 disk        
├─nvme0n1p1 259:9    0     1G  0 part /efi   
├─nvme0n1p2 259:10   0    16M  0 part        
├─nvme0n1p3 259:11   0   476G  0 part        
├─nvme0n1p4 259:12   0    16G  0 part [SWAP] 
└─nvme0n1p5 259:13   0 460,9G  0 part /

blkid shows correctly the PARTUUID:

(chroot) livecd / # blkid
/dev/nvme0n1p5: UUID="<redacted>" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="4f68bce3-e8cd-4db1-96e7-fbcaf984b709"
/dev/nvme0n1p3: BLOCK_SIZE="512" UUID="<redacted>" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="4b885397-13d6-4b55-b360-27c902558c0d"
/dev/nvme0n1p1: UUID="<redacted>" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
/dev/nvme0n1p4: UUID="<redacted>" TYPE="swap" PARTUUID="0657fd6d-a4ab-43c4-84e5-0933c84b4f4f"
/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="7ef72b0e-b2a4-4313-a216-c7f049b6c78b"
/dev/loop0: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/sda1: LABEL="GENTOO-AMD6" UUID="<redacted>" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="001e4fe3-01"
AndrewAmmerlaan commented 2 months ago

blkid shows correctly the PARTUUID

PARTUUID is the identifier for fstab, uefi-mkconfig uses the PARTTYPE to find if a partition is an ESP. Please check the PARTTYPE.

leandrolnh commented 2 months ago

blkid shows correctly the PARTUUID

PARTUUID is the identifier for fstab, uefi-mkconfig uses the PARTTYPE to find if a partition is an ESP. Please check the PARTTYPE.

As I posted above, lsblk -o +PARTTYPE returns a blank column, so there is no PARTTYPE to read.

Edit: to complement the answer:

(chroot) livecd / # lsblk -lo NAME,PARTTYPE
NAME      PARTTYPE
loop0     
sda       
sda1      
nvme0n1   
nvme0n1p1 
nvme0n1p2 
nvme0n1p3 
nvme0n1p4 
nvme0n1p5
Biosias commented 2 months ago

That is very weird indeed. @leandrolnh Could you please send me the output of fdisk -l ?

Edit:

I've noticed that you are in a chroot. This might cause some weird behavior of lsblk which uefi-mkconfig uses. I'll test this hypothesis further. In the mean time fdisk -l output would be very helpful.

leandrolnh commented 2 months ago

Here it is: 

(chroot) livecd / # LC_ALL=C fdisk -l
Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: ADATA SX8200PNP                         
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: <redacted>

Device              Start        End   Sectors   Size Type
/dev/nvme0n1p1       2048    2099199   2097152     1G EFI System
/dev/nvme0n1p2    2099200    2131967     32768    16M Microsoft reserved
/dev/nvme0n1p3    2131968 1000343551 998211584   476G Microsoft basic data
/dev/nvme0n1p4 1000343552 1033897983  33554432    16G Linux swap
/dev/nvme0n1p5 1033897984 2000408575 966510592 460.9G Linux root (x86-64)

Disk /dev/sda: 57.75 GiB, 62008590336 bytes, 121110528 sectors
Disk model: DataTraveler 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: <redacted>

Device     Boot Start       End   Sectors  Size Id Type
/dev/sda1  *     2048 121110463 121108416 57.7G  c W95 FAT32 (LBA)

Disk /dev/loop0: 3.18 GiB, 3417858048 bytes, 6675504 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
Biosias commented 2 months ago

Ok, so the partition is of a correct type. Sooo, something is up with lsblk while in a chroot.

Could you please test lsblk -o +PARTTYPE while booted in that livecd but outside of chroot ?

AndrewAmmerlaan commented 2 months ago

Fdisk shows "EFI System" which is correct, I don't really understand why lsblk shows nothing, but this is probably why uefi-mkconfig is not working.

leandrolnh commented 2 months ago

Yes, here it is:

gentoo@livecd ~ $ lsblk -o +PARTTYPE
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS         PARTTYPE
loop0         7:0    0   3.2G  1 loop /run/rootfsbase     
sda           8:0    1  57.8G  0 disk                     
└─sda1        8:1    1  57.7G  0 part /run/initramfs/live 0xc
nvme0n1     259:0    0 953.9G  0 disk                     
├─nvme0n1p1 259:9    0     1G  0 part /mnt/gentoo/efi     c12a7328-f81f-11d2-ba4b-00a0c93ec93b
├─nvme0n1p2 259:10   0    16M  0 part                     e3c9e316-0b5c-4db8-817d-f92df00215ae
├─nvme0n1p3 259:11   0   476G  0 part                     ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
├─nvme0n1p4 259:12   0    16G  0 part [SWAP]              0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
└─nvme0n1p5 259:13   0 460.9G  0 part /mnt/gentoo         4f68bce3-e8cd-4db1-96e7-fbcaf984b709

Now it works, definitely it's something with chroot.

Biosias commented 2 months ago

Nice, this is for 100% the cause of the problem.

Workaround for now:

While in livecd outside of chroot

Mount rootfs to /mnt/gentoo Mount EFI partition to /mnt/efi Copy uefi-mkconfig configuration from /mnt/gentoo/etc/default/uefi-mkconfig > /etc/default/uefi-mkconfig Run /mnt/gentoo/sbin/uefi-mkconfig

This should work. Let me know if it worked. I'm currently on the train so can't test it myself.

Edit: Before running the script don't forget to copy the uefi-mkconfig configuration.

leandrolnh commented 2 months ago

Now it worked: 

gentoo@livecd ~ $ sudo /mnt/gentoo/sbin/uefi-mkconfig 
 * Running uefi-mkconfig...
 * Using kernel commands from "/etc/default/uefi-mkconfig"
 * Creating UEFI entry "0100" for "/mnt/efi/EFI/Gentoo/vmlinuz-6.6.32-gentoo-dist.efi" found on "nvme0n1p1"...
gentoo@livecd ~ $ efibootmgr -u
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0100,0004,0003,0001,0002
Boot0001* IPV4 Network - Realtek PCIe GBE Family Controller     PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/MAC(<redacted>,0)/IPv4(0.0.0.00.0.0.0,0,0)걎脈鼑䵙຅᫢ⱒ뉙
Boot0002* IPV6 Network - Realtek PCIe GBE Family Controller     PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/MAC(<redacted>,0)/IPv6([::]:<->[::]:,0,0)걎脈鼑䵙຅᫢ⱒ뉙
Boot0003* Kingston DataTraveler 3.0 408D5C15AFCFE7B129041600    PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x3)/USB(5,0)걎脈鼑䵙຅᫢ⱒ뉙᠉
Boot0004* Windows Boot Manager  HD(1,GPT,c12a7328-f81f-11d2-ba4b-00a0c93ec93b,0x800,0x200000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)䥗䑎坏S
Boot0100* 6.6.32-gentoo-dist    HD(1,GPT,c12a7328-f81f-11d2-ba4b-00a0c93ec93b,0x800,0x200000)/File(\EFI\Gentoo\vmlinuz-6.6.32-gentoo-dist.efi) root=PARTUUID=4f68bce3-e8cd-4db1-96e7-fbcaf984b709 rootfstype=xfs initrd=\EFI\Gentoo\initramfs-6.6.32-gentoo-dist.img

Thanks a lot!

Biosias commented 2 months ago

No problem at all. I'll take a look at the root cause and will mention this case in the readme. @alecStewart1 could you please test the workaround as well? Most probably you are suffering with the same issue.

AndrewAmmerlaan commented 1 month ago

Is this a systemd system? If so, could you check if bootctl -p can find the ESP when lsblk is affected by this problem. Could you please also share the exact commands you're using to chroot.

leandrolnh commented 1 month ago

Both LiveGUI and stage 3 were OpenRC.

The command used to enter chroot: $ sudo arch-chroot /mnt/gentoo

The LiveCD used was livegui-amd64-20240526T163557Z.iso

The stage 3 used was desktop profile and openrc, I think the date was from 2024-06-23.

Edit: now that the installation is complete I have no more errors with uefi-mkconfig.

alecStewart1 commented 1 month ago

My system was OpenRC. I was on a LiveCD of Artix Linux, not the Gentoo LiveCD.

I chrooted like so

mkdir -p /mnt/gentoo/tmp
mount /dev/nvme0n1p3 /mnt/gentoo
mount --types proc /proc /mnt/gentoo/proc
mount --rbind /sys /mnt/gentoo/sys
mount --rbind /dev /mnt/gentoo/dev
mount --bind /run /mnt/gentoo/run 
mount --make-rslave /mnt/gentoo/sys
mount --make-rslave /mnt/gentoo/dev
mount --make-slave /mnt/gentoo/run 
chroot /mnt/gentoo /bin/bash
source /etc/profile
mount -a
# did all the stuff I needed for recovery.

I temporarily switched to genkernel just to go with something I know works, and I'm back in my Gentoo system. I'll have to try switching back to the dist-kernel configuration and see if uefi-mkconfig gives me any issues.

Last I recall, even when I was on my Gentoo system before I broke it (I borked my /var/db/pkg somehow, then rebooted and had issues) that uefi-mkconfig will still put initramfs and EFI images in /boot/ not /efi/.

AndrewAmmerlaan commented 1 month ago

Last I recall, even when I was on my Gentoo system before I broke it (I borked my /var/db/pkg somehow, then rebooted and had issues) that uefi-mkconfig will still put initramfs and EFI images in /boot/ not /efi/.

For EFI stub booting to work, the kernel and initramfs must be on the EFI System Partition, the firmware is not capable of reading any other partition. That is why sys-kernel/installkernel moves the kernel and initramfs to the ESP if the efistub USE flag is enabled.

I do not understand why the chroot is not able to read the PARTTYPEs. If you use any other partition editing tool inside the chroot can it identify and maybe even set the PARTTYPE of your ESP?

alecStewart1 commented 1 month ago

I do not understand why the chroot is not able to read the PARTTYPEs, if you use any other partition editing tool inside the chroot can it identify and maybe even set the PARTTYPE of your ESP?

When I was fixing loads of stuff in the chrooted environment, I believe I could see the UUID and PARTUUID when using something like blkid or lsblk. I didn't check for stuff like if I could see the PARTTYPE.

AndrewAmmerlaan commented 1 month ago

I asked around on IRC, and folks could reproduce this behaviour with arch-chroot but not with the old fashioned manual method of chrooting, it could be a bug in arch-chroot.

Biosias commented 1 month ago

I would swear I also experienced this with lsblk and manual chroot when deploying new gentoo machines. Way before uefi-mkconfig was a thing.

That is why I was able to quickly make a workaround.

AndrewAmmerlaan commented 1 month ago

I would swear I also experienced this with lsblk and manual chroot when deploying new gentoo machines. Way before uefi-mkconfig was a thing.

When manually chrooting I think it happens if you miss one of the mounting steps, but I don't yet know which step is responsible for making the PARTTYPEs work in the chroot.