Chris's Wiki :: blog/linux/Ubuntu2204MultiDiskUEFI Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu2204MultiDiskUEFI?atomcommentsDWiki2022-12-14T15:19:06ZRecent comments in Chris's Wiki :: blog/linux/Ubuntu2204MultiDiskUEFI.By Sam Nelson on /blog/linux/Ubuntu2204MultiDiskUEFItag:CSpace:blog/linux/Ubuntu2204MultiDiskUEFI:99e699e21dfef537e5edc90962dea9e390760892Sam Nelson<div class="wikitext"><p>Just wanted to say a quick thanks for your great writeup. There is a lot of confusing information online on how to properly sync up multiple EFI partitions. Your post cleared up all the questions I had!</p>
<p>Cheers,</p>
<p>Sam</p>
</div>2022-12-14T15:19:06ZBy David Magda on /blog/linux/Ubuntu2204MultiDiskUEFItag:CSpace:blog/linux/Ubuntu2204MultiDiskUEFI:7248f4b49453ee00ba9931f4286fcee81665bbf6David Magdahttp://www.magda.ca/<div class="wikitext"><p>Ivan wrote:</p>
<blockquote><p><em>If you assemble MD Array with 0.9 sub-version, superblock is located at the end of the device.</em></p>
</blockquote>
<p>For the record, the 1.0 <em>mdadm</em> superblock format is also only written at the end of the device:</p>
<ul><li><a href="https://raid.wiki.kernel.org/index.php/RAID_superblock_formats">https://raid.wiki.kernel.org/index.php/RAID_superblock_formats</a></li>
</ul>
<p>There may be advantages to using a 1.x-based format or the 0.9 in various situations.</p>
<p>If unspecified, <em>mdadm</em> uses 1.2 as of this writing, which is 4K from the beginning of the device.</p>
</div>2022-09-30T20:03:10ZBy Ivan on /blog/linux/Ubuntu2204MultiDiskUEFItag:CSpace:blog/linux/Ubuntu2204MultiDiskUEFI:5fe4fa6c4423d9e53578637af6fd84952886f36bIvanhttps://www.tomica.net<div class="wikitext"><blockquote><p>The BIOS boot process of going from the software RAID array name to the disks doesn't put the boot blocks in the partitions of the RAID array, it goes from the partition names of the RAID array (eg sda1 and sdb1) to the whole disks (sda and sdb).</p>
</blockquote>
<p>Indeed, BIOS boot process reads first 512 bytes of the drive and executes them directly, and that part usually holds Stage 1 bootloader which then has information about the partitions and where to find them (4 primary partitions).</p>
<blockquote><p>You could do a similar thing to go from the RAID partitions to the whole disk to some ESP partition on the disk, but the idea of finding and recognising the ESP partition on a disk raises a bunch of questions; what if there isn't one, or it's not clear if something is an ESP, or if there are more than one ESP candidate on a single disk?</p>
</blockquote>
<p>That is an interesting problem, and I have no clear answer to that one.</p>
<blockquote><p>The traditional two problems with making the ESP partitions themselves into a software RAID array is that historically some UEFI firmware would refuse to boot such a system, and if the firmware or something else ever updated an ESP, you would have inconsistent mirror data and doom might well ensue (including corrupted vfat filesystems, which would likely make UEFI boot unhappy). </p>
</blockquote>
<p>This is a layered issue, but let's hypothetically say that you have two partitions, each 512MB and each on the separate disk drive.</p>
<p>If you assemble MD Array with 0.9 sub-version, superblock is located at the end of the device. And then when you format that assembled device with FAT32, and install necessary things on it you basically get pure FAT32 partition from EFI/BIOS/OS perspective. If you examine each MD member partition individually, they would appear as regular fat32 partitions</p>
<p>Then, from the perspecitve of the boot process, you pick and choose either one. And from the perspective of upgrades, well, all changes are saved to the both drives/partitions since OS mounts /boot as MD device.</p>
<p>Issue that is still pending is eventual stage1 bootloader update or updates to the efi variables if those are in MoBo firmware.</p>
<p>Usually, in my scenarios, that worked fine, but I may be wrong and not seeing the whole picture, or understanding it properly for that matter. So if you would have the patience to expand on the issue, I would highly appreciate it.</p>
</div>2022-08-11T09:53:23ZBy Chris Siebenmann on /blog/linux/Ubuntu2204MultiDiskUEFItag:CSpace:blog/linux/Ubuntu2204MultiDiskUEFI:2ab38c3272a035921f87c0ff03c08eb48a1c7110Chris Siebenmann<div class="wikitext"><p>The BIOS boot process of going from the software RAID array name to the
disks doesn't put the boot blocks in the partitions of the RAID array,
it goes from the partition names of the RAID array (eg sda1 and sdb1)
to the whole disks (sda and sdb). Or at least it had better do that,
since most BIOS bootblocks are installed on the whole disk. You could
do a similar thing to go from the RAID partitions to the whole disk to
some ESP partition on the disk, but the idea of finding and recognizing
the ESP partition on a disk raises a bunch of questions; what if there
isn't one, or it's not clear if something is an ESP, or if there are
more than one ESP candidate on a single disk?</p>
<p>The traditional two problems with making the ESP partitions themselves
into a software RAID array is that historically some UEFI firmware would
refuse to boot such a system, and if the firmware or something else ever
updated an ESP, you would have inconsistent mirror data and doom might
well ensue (including corrupted vfat filesystems, which would likely
make UEFI boot unhappy). The third problem is that Linux installers
don't support it; as far as I know, the Ubuntu 22.04 installer has no
option for this if you're setting up a UEFI system (and in fact will
shoot you in the foot if you take the ESPs you've told it about and then
make them into a software RAID array).</p>
</div>2022-08-10T17:03:00ZBy Ivan on /blog/linux/Ubuntu2204MultiDiskUEFItag:CSpace:blog/linux/Ubuntu2204MultiDiskUEFI:679e9b9965e79cc05091c42ce336cbb6f36e9e46Ivanhttps://www.tomica.net<div class="wikitext"><blockquote><p>I assume that UEFI boot can't be supported this way because there would be more magic in going from a software RAID array to the ESP partitions (if any) on the same devices.</p>
</blockquote>
<p>I don't particularly understand this part to be honest, as you already noted that there's a posibillity of:</p>
<blockquote><p>Linux software RAID mirror with the RAID superblock at the end </p>
</blockquote>
<p>In theory, nothing should go wrong that way, as the only time you write is while the system is booted and installing updates for grub, this way you can never really break MD Array, yet, due to the fact that superblock is at the end of the partition, it will not really break EFI boot process because that FAT32 partition on top of the MD array looks like a regular fat32 partition early in the boot process.</p>
<p>And if one of the drive fails, md array still assembles, but is in degraded state, which can obviously be monitored and fixed.</p>
<p>Seems to me that's overall best solution we have at the moment.</p>
</div>2022-08-10T08:52:47Z