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