Re: [gentoo-user] UEFI data corruption?

[Mick]

On Sunday, 15 September 2019 23:26:47 BST Peter Humphrey wrote:
> On Sunday, 15 September 2019 10:29:13 BST Mick wrote:

> > What do you see in the / filesystem when the ESP partition is *not*
> > mounted?
> The ESP space is not a partition here.

I think we are confusing terms.  Your screenshot definitely shows a partition, 
/dev/nvme0n1p2 which is your ESP partition and is flagged as such by parted.  
The "small unpartitioned space" at the beginning of the disk is not a 
partition and should be left well alone. (see my next email response on a 
disambiguation of these two items).


> > > 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.

OK, it seems the systemd-boot decided to create a directory 
45b3c9f27eedd9ca60997b555d46f90d-* within your ESP partition and expect to 
find the default OS kernel in this path.  I have no idea why it would do this.

It could be a bug related to systemd-boot, or something you ran, but some 
systemd user or dev should chime in as to what might have caused it.  My 
exposure to systemd is limited, I continue to find it awkward/unpleasant to 
use on binary distros.

-- 
Regards,

Mick