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 
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 
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 
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 
‘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 
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 
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 
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 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?
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 
BUT next time I get a ‘boot issue’ I’ll probably cry into my coffee cup, yelling ‘come back grub all is forgiven’ 
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
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
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
[Edit]
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! 
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
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 vfat FAT32 BCD2-AC5C
└─sda2 ext4 1.0 4f415d63-c9d4-4a50-850a-fb6834f5be0e
sdb
├─sdb1 vfat FAT32 CB5E-9E17 248,5M 17% /boot/efi
└─sdb2 ext4 1.0 8080d019-ef7a-4d0e-b0ce-827979107f74 2G 93% /
bootctl status
System:
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
File: └─/EFI/BOOT/BOOTX64.EFI
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
File: └─/EFI/BOOT/BOOTX64.EFI
Title: UEFI OS
ID: 0x0005
Status: active, boot-order
Partition: /dev/disk/by-partuuid/bbbdfa05-4f85-6046-a7f3-0f5bbb5292da
File: └─/EFI/BOOT/BOOTX64.EFI
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
/initramfs-linux.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 …
- EFI system partition - Typical mount points and
- 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
/bootzu 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!