On Sat, May 17, 2025 at 08:55:45PM +0200, Pascal Hambourg wrote:
> (Trimming the Cc list, no need to bother everyone)
Very thoughtful, thanks! :)
> [...]
> > Hrrmm, interesting - I did assume that the "method" := "efi" approach that my
> > patch uses would cause the resulting partition to have the proper metadata to
> > be universally recognized as an ESP
>
> method=efi would only make partman try to set the "esp" flag (representing
> the ESP type identifier) on the resulting RAID array /dev/mdX, not on member
> partitions. "boot" is only a duplicate of "esp" on GPT.
Yeah, I can see now how this makes sense, and I guess my mind was playing a
nasty trick on me and wrongly assumed that this would somehow affect the
partition metadata, too. Thinking about it now, that cannot work, as that part
of the block range of the disk (where partition metadata resides) is outside
of the range that the md array itself cares about, so writing to the assembled
array device could never ever touch that data.
> [...]
> > I am not sure what (if anything) is at fault here, and won't have enough time
> > today to go into the details, but looking at hexdumps from two legs of a
> > resulting RAID1 and my own desktop's single-m.2.EFI setup, the crucial bit
> > (ESP GUID) seems to be OK? (I am not a EFI expert, unfortunately, so I am very
> > open to hearing your corrections!)
>
> I would trust more parted -l or fdisk -l output.
That doesn't change the picture, they still identify the partition as "Linux
RAID" - and that seems to be because of the Type-UUID, as displayed by fdisk
in expert mode.
A proper ESP has Type-UUID of "C12A7328-F81F-11D2-BA4B-00A0C93EC93B", while
these md partitions pop out of d-i as "A19D880F-05FC-4D3B-A006-743F0F84911E"
(Linux RAID).
I just checked what happens if I use fdisk in expert mode to coerce a
Type-UUID of "C12A7328-..." (ESP) for the partitions holding both RAID1 legs
instead: That change keeps the md RAID1 array assembling and working fine,
fdisk and parted agreeing upon the nature of the partition ("ESP", as I want
it to), and is, I think, what the result of this exercise SHOULD be.
md, for all I know, identifies candidate disks not by *partition* UUIDs, but
by scanning LBA ranges of block devices for its own metadata, and that still
holds when the Type-UUID has been altered to that of an ESP.
So I guess if this is to be included in Debian proper, I will have to make
sure that the RAID1 legs' partitions' Type-UUIDs will have to be bent to match
the expected value for an ESP. What do you think, does that sound sane?
> PS: Any opinion about my latest comment ("nitpick") in the MR ?
Yeah, that is perfectly reasonable - I will update the MR as soon as I can :)
--
with best regards:
- Johannes Truschnigg ( johannes@truschnigg.info )
www: https://johannes.truschnigg.info/
Attachment:
signature.asc
Description: PGP signature