| 1 |
On Sunday, 15 September 2019 09:36:53 BST Peter Humphrey wrote: |
| 2 |
> Morning all, |
| 3 |
> |
| 4 |
> Yesterday I found I couldn't boot this box. I use bootctl from systemd-boot |
| 5 |
> to manage my boot partition (nothing else of systemd, though), and when I |
| 6 |
> ran 'bootctl install' after compiling a new kernel, I got strange error |
| 7 |
> messages, and a new directory under /boot with (I think) a 24-digit hex |
| 8 |
> number as a name. I brought efibootmgr up and found I had 30 entries in the |
| 9 |
> boot list (from 00 to 1D), including several apparent duplicates of genuine |
| 10 |
> entries. |
| 11 |
|
| 12 |
What are/were the contents of the 24-digit hex named directory? I don't use |
| 13 |
systemd-boot or bootctl to have first hand experience of what it does, but I |
| 14 |
thought I does not create new hex named directories to dump its files in. It |
| 15 |
first goes to the ESP partition's mountpoint, typically /boot and copy in |
| 16 |
there /boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI. I |
| 17 |
don't know if it requires the ESP partition to have been mounted at the time, |
| 18 |
or if it is clever enough to auto-probe and mount it itself. It also creates |
| 19 |
/boot/loader/loader.conf, copied from /usr/share/systemd/bootctl/loader.conf |
| 20 |
and finally /boot/loader/entries/*.conf for all the boot menu items. I |
| 21 |
understand it will create configuration files for MSWindows boot loader(s) and |
| 22 |
for any Linux OS installations as long as it finds linux kernels listed under |
| 23 |
/boot/EFI/Linux/. All of this is unnecessarily complicated for my use cases, |
| 24 |
TBH it even makes GRUB2 look simple, which is why I have avoided this |
| 25 |
particular systemd component and use efibootmgr manually to configure the boot |
| 26 |
menu. |
| 27 |
|
| 28 |
Do you see any difference in the bootable kernels listed between 'bootctl |
| 29 |
list' and 'efibootmgr -v' |
| 30 |
|
| 31 |
What do you see in the / filesystem when the ESP partition is *not* mounted? |
| 32 |
|
| 33 |
|
| 34 |
> The only way I found to clear up the mess was to write a new gpt partition |
| 35 |
> table, re-create all the partitions and restore from backup. |
| 36 |
|
| 37 |
Were your partitions messed up, or only the ESP? If the latter you could have |
| 38 |
recreated that alone and copied files over from a back up. |
| 39 |
|
| 40 |
|
| 41 |
> Any idea what could have cause this? I've attached a gparted diagram of the |
| 42 |
> disk layout in case it helps. |
| 43 |
|
| 44 |
It may be the systemd-boot auto-magic does not detect an unmounted partition |
| 45 |
and it proceeds with spewing its goodness all over the / partition's |
| 46 |
filesystem - but I don't know much about systemd or its components. |
| 47 |
|
| 48 |
> And is there a good way to clear the efi system partition, short of dd-ing a |
| 49 |
> load of zeroes into it? Would that even have helped? |
| 50 |
|
| 51 |
I would first run 'fsck.vfat -v /dev/nvme0n1p2' with the partition not mounted |
| 52 |
to see if there is any fs corruption. If there is something wrong with its |
| 53 |
filesystem, I would simply reformat the partition with 'mkfs.vfat -v /dev/ |
| 54 |
nvme0n1p2' and rsync the contents back from a back up. |
| 55 |
|
| 56 |
HTH. |
| 57 |
-- |
| 58 |
Regards, |
| 59 |
|
| 60 |
Mick |
Archives