XPost: linux.debian.maint.boot
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/
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEGu9IhkI+7/aKLUWF95W3jMsYfLUFAmgq0UIACgkQ95W3jMsY fLVCPRAAreS1WUWgVybigDl5VF9l/FoEEwMMZJorHRJaw8xyezCf8XGRA81mrz6e mqOz8wUWjgwVog17nu8Btg2La6nCzTVtg/1LxUk1Z9FtC2ep5/icGu2/RVQ3yh++ eiR6iB2tMYeWa/TVHpBf8TJf94lQqWig4qx70LpBQvttkZqvv3aEvV4gJUwygBka wBVurM1sQEhJZDBQsafCej/mBoPSN0UhMYSqiS64dTvi85eqSXvIHZrUCQHHiwRF hrZWowD2+ZLnqEOkiFpQeN+iCFCwezkoqhVOjMpRi4xIC2WBQ1ETihvh6ov3Io0V d+1WUUotazMYlJHrL2cKq5grcLxy0Pn/E3YE5PXeDhH5ZQDjJPQx9mNHnfoMAnK0 RENzOcDZ7uSRJv7P3nhlDHFpwGHrDQOGPT3iI+BVCd+Yg96J5GE4t7QVlB29YTA+ A0Z/L7tET4sWvKVKlNCvJmDzdrsf+XxHTIoIlfjrfkJtbNArJKMSAWGPgAK2fvN5 G0f6D94zEpcK9cM1tJKZTzTIjt72LqOQItJRfautWI2zNEl7b3PsQdKRJEo9azsj xpF1lyivjzSI4Llz6cs24g29LCgp+Dc9OeXqYAoKjXw0LCiXs47FrwQgFVwgfYQW xDNhBSiqsiwrVosCNpL+0D8iqY4cjACqUhW63JTwnCJEQvSEPzw=
=+Lv2
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet