On Sunday, 15 September 2019 09:36:53 BST Peter Humphrey wrote: > Morning all, > > Yesterday I found I couldn't boot this box. I use bootctl from systemd-boot > to manage my boot partition (nothing else of systemd, though), and when I > ran 'bootctl install' after compiling a new kernel, I got strange error > messages, and a new directory under /boot with (I think) a 24-digit hex > number as a name. I brought efibootmgr up and found I had 30 entries in the > boot list (from 00 to 1D), including several apparent duplicates of genuine > entries.
What are/were the contents of the 24-digit hex named directory? 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. Do you see any difference in the bootable kernels listed between 'bootctl list' and 'efibootmgr -v' What do you see in the / filesystem when the ESP partition is *not* mounted? > 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. > 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. HTH. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
