Boot grub poo? having a fat partition defo is! lol

OK I suppose this was a ‘self inflicted problem’ cos I messed up grub when I was trying to install arch on a ‘3rd SSD’…then I decided grub was a PITA, tried to install bootctl, messed that up :face_with_raised_eyebrow: then fixed it with rEFInd, then fixed bootctl and finally got things working
THEN this morning, yay tells me that there is a new kernel…ooh, lets update, reboot…fail…drops to shell…journalctl tells me that plymouth has failed to load - it’s nothing to do with plymouth!!!
reboot, error is staring right at me - can’t mount /boot/efi cos ‘vfat is invalid’! REALLY? sounds like another lie to me :stuck_out_tongue_winking_eye:
Anyway I fixed the problem by booting into my ‘2nd SSD backup Endeavouros’, manually mounting the /boot/efi from the 1st SSD, and copying across the 3 *.img and vmlinuz-linux files to /boot/efi
I couldn’t do this from the ‘recovery shell’ of the 1st SSD cos it wouldn’t let me mount /boot/efi !!!
Soooo this raises a few questions:
1 could I have avoided this by running ‘bootctl update’ after the updates and before I rebooted?
2 why do we insist on complicating things by having a ‘dodgy FAT32’ partition? I raised this question quite a while ago…makes me want to go back to having ‘legacy boot’ and a single ext4 partition…KISS anyone :stuck_out_tongue_closed_eyes:
edit I nearly forgot question 3 lol
on my 1st endeavouros ssd install I can browse to /boot/efi using thunar, see files, copy files, no probs
booting the 2nd endeavouros ssd install… /boot/efi is inaccessible through thunar, why the difference?
Thanks for reading, good weekend to all!

OK back from testing…2nd SSD now borked :grimacing:
‘bootctl update’ only does this:
Copied “/usr/lib/systemd/boot/efi/systemd-bootx64.efi” to “/boot/efi/EFI/systemd/systemd-bootx64.efi”.
Copied “/usr/lib/systemd/boot/efi/systemd-bootx64.efi” to “/boot/efi/EFI/BOOT/BOOTX64.EFI”.
could this be fixed using mkinitcpio -P ?
I don’t know what this does, just came across it doing searches :stuck_out_tongue:

Chances are that the ESP (EFI system Partition) is mounted in fstab with a mask specified. This might be a umask (all) or fmask (files) or dmask (directories). I am too tired right now to go into it all :grin: but it forces permissions that can be quite restrictive. Running Thunar in ‘root’ mode allows entry for looking, or changing the mask values can also do the job (following a reboot).

Not sure where to tell you to look, but a little google will do it - or I’ll check back if you haven’t got it figured when I get back up!

@freebird54 thanks for the wiki article on rEFInd that came in useful earlier in the week :+1:
ok now changed my fstab from ‘umask=0077 0 2’ to ‘defaults,noatime 0 2’…dunno why there is a difference between the 2 installs, I defo wouldn’t have changed that…

Maybe there’s a difference in online vs offline installs? The umask is a good idea - but I found it too restrictive :grin: Should solve the ‘no can look’ anyway…

ok something weird going on…
‘new files’ are in /boot BUT not in /boot/efi which is where they should be…
so if I manually copy them again (overwrite old versions) I’ll fix the ‘backup SSD’ just like I did with this ‘working 5.8.13’ that I’m typing from now but how to avoid this issue next time I get a kernel update?

:question: Are you sure you’ve mounted to /boot/efi?

Check with
sudo blkid | grep vfat && findmnt -D -t vfat && cat /etc/fstab | grep boot

hi @2000
thanks for your input…
I’ve fixed it now but concerned I’ll get the problem again with the next kernel update…let’s see…
I’ve been having a tidy up of my ‘boot configuration’
I’m now tempted to delete /boot/efi/EFI/EndeavourOS/grubx64.efi cos I’m on a ‘grub killer’ mission at the moment :stuck_out_tongue_winking_eye:
BUT next time I get a ‘boot issue’ I’ll probably cry into my coffee cup, yelling ‘come back grub all is forgiven’ :crazy_face:

1 Like

Getting it to come back is always possible (even fairly easy) - but removal isn’t needed too badly (you can just ignore its presence). Of course, you CAN remove all traces too :grin:

For the sake of simplicity, I have all my sytems with EFI mounted to /boot/efi - much less messy it seems to me…

it’s done it again!! 5.8.14 update and the file updates are in /boot not in /boot/efi

with refind you do not need grub, you can boot without it, and sure you can remove grub and the grub folder from boot

1 Like

Are you really sure you have set up the mountpoint right?

Please post the output of …
sudo blkid | grep vfat && findmnt -D -t vfat && cat /etc/fstab | grep boot


Oh, the initramfs-linux.img and vmlinuz-linux are supposed to reside in /boot.
If that’s your issue, then I may have misunderstood, but you don’t actually have a problem! :wink:

well it doesn’t boot, it drops out to emergency shell!
OK recap…I have 2 independent SSDs, this way I have a Disaster Recovery setup
I have deleted all grub
lsblk -f

├─sda1 vfat   FAT32       BCD2-AC5C                                           
└─sda2 ext4   1.0         4f415d63-c9d4-4a50-850a-fb6834f5be0e                
├─sdb1 vfat   FAT32       CB5E-9E17                             248,5M    17% /boot/efi
└─sdb2 ext4   1.0         8080d019-ef7a-4d0e-b0ce-827979107f74      2G    93% /

bootctl status
Firmware: UEFI 2.60 (American Megatrends 5.13)
Secure Boot: disabled
Setup Mode: user
Boot into FW: supported

Current Boot Loader:
Product: systemd-boot 246.6-1-arch
Features: ✓ Boot counting
✓ Menu timeout control
✓ One-shot menu timeout control
✓ Default entry control
✓ One-shot entry control
✓ Support for XBOOTLDR partition
✓ Support for passing random seed to OS
✓ Boot loader sets ESP partition information
ESP: /dev/disk/by-partuuid/ff193b74-9f37-8748-b68d-bbc63c9f52c7

Random Seed:
Passed to OS: yes
System Token: set
Exists: yes

Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/ff193b74-9f37-8748-b68d-bbc63c9f52c7)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 246.6-1-arch)
File: └─/EFI/BOOT/bootx64.efi (systemd-boot 246.6-1-arch)

Boot Loaders Listed in EFI Variables:
Title: UEFI OS
ID: 0x0004
Status: active, boot-order
Partition: /dev/disk/by-partuuid/ff193b74-9f37-8748-b68d-bbc63c9f52c7
Title: UEFI OS
ID: 0x0005
Status: active, boot-order
Partition: /dev/disk/by-partuuid/bbbdfa05-4f85-6046-a7f3-0f5bbb5292da

Boot Loader Entries:
$BOOT: /boot/efi (/dev/disk/by-partuuid/ff193b74-9f37-8748-b68d-bbc63c9f52c7)

Default Boot Loader Entry:
title: Archlinux
id: arch.conf
source: /boot/efi/loader/entries/arch.conf
linux: /vmlinuz-linux
initrd: /amd-ucode.img
options: root=PARTUUID=de24374d-01ef-ed4c-899e-9839b7be7579 rw

OK, mountpoint is /boot/efi.

Never having tried systemd-boot myself, I always wrongly assumed this would also be the default mountpoint when using systemd-boot but according to the following ArchWiki articles …

  1. EFI system partition - Typical mount points and
  2. Systemd-boot (in german)

you should mount ESP to /boot.

Quote from 1.:

mount ESP to /boot. This is the preferred method when directly booting an EFISTUB kernel from UEFI.

Quote from 2.:

Es empfielt sich, die EFI-Partition nach /boot zu mounten.

Translated: “It is advisable to mount the EFI partition in / boot.”

So I would change the mountpoint from /boot/efi to /boot, remount with mount -a, then run a sudo mkinitcpio -p linux and try a reboot. Future updates should then also build the initramfs-linux.img and vmlinuz-linux in the right place.


@2000 absolutely marvellous that did the trick!
Vielen danke, merci beaucoup and great weekend to you!

1 Like