On Sunday, 15 September 2019 10:29:13 BST Mick wrote: > What are/were the contents of the 24-digit hex named directory?
It was empty. Actually it was 32 digits. > I don't use systemd-boot or bootctl to have first hand experience of what it > does, but I thought I does not create new hex named directories to dump its > files in. It first goes to the ESP partition's mountpoint, typically /boot > and copy in there /boot/EFI/systemd/systemd-bootx64.efi and > /boot/EFI/BOOT/BOOTX64.EFI. I don't know if it requires the ESP partition > to have been mounted at the time, or if it is clever enough to auto-probe > and mount it itself. It also creates /boot/loader/loader.conf, copied from > /usr/share/systemd/bootctl/loader.conf and finally > /boot/loader/entries/*.conf for all the boot menu items. I understand it > will create configuration files for MSWindows boot loader(s) and for any > Linux OS installations as long as it finds linux kernels listed under > /boot/EFI/Linux/. All of this is unnecessarily complicated for my use > cases, TBH it even makes GRUB2 look simple, which is why I have avoided > this particular systemd component and use efibootmgr manually to configure > the boot menu. Now you see, there seem to be two ways to arrange the esp and boot partitions. The gentoo wiki says to leave a small unpartitioned space for esp data, then create a vfat partition for /boot. That's what I did. Other people seem to have both functions served by the /boot partition. I think I tried that once but got snarled up somewhere. > Do you see any difference in the bootable kernels listed between 'bootctl > list' and 'efibootmgr -v' I don't think so. > What do you see in the / filesystem when the ESP partition is *not* mounted? The ESP space is not a partition here. > > The only way I found to clear up the mess was to write a new gpt partition > > table, re-create all the partitions and restore from backup. > > Were your partitions messed up, or only the ESP? If the latter you could > have recreated that alone and copied files over from a back up. The ESP, plus one file in /boot: # cat /boot/loader/loader.conf #timeout 3 #console-mode keep default 45b3c9f27eedd9ca60997b555d46f90d-* It should have been this: # cat boot/loader/loader.conf default 30-gentoo-4.19.72 timeout 15 > > Any idea what could have cause this? I've attached a gparted diagram of > > the disk layout in case it helps. > > It may be the systemd-boot auto-magic does not detect an unmounted partition > and it proceeds with spewing its goodness all over the / partition's > filesystem - but I don't know much about systemd or its components. > > > And is there a good way to clear the efi system partition, short of dd-ing > > a load of zeroes into it? Would that even have helped? > > I would first run 'fsck.vfat -v /dev/nvme0n1p2' with the partition not > mounted to see if there is any fs corruption. If there is something wrong > with its filesystem, I would simply reformat the partition with 'mkfs.vfat > -v /dev/ nvme0n1p2' and rsync the contents back from a back up. First I need to decide which ESP and /boot arrangement to use from now on. Meanwhile, as I said before, I wrote a new GPT label, then created the partitions again and restored them from backup. -- Regards, Peter.
