<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div>On Thu, 30 Apr 2026 00:46:30 +0200 Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:<br>
> Thorsten Behrens wrote:<br>
> ><br>
> > On a fresh install of Debian 12, on an OVH baremetal machine with mdadm<br>
> > raid-0, I upgraded to Debian 13. After upgrade, grub in EFI had been<br>
> > upgraded in one drive, but not the other.<br>
><br>
> What is the point of having multiple ESPs with RAID 0 ? It does not<br>
> provide any redundancy, so if either drive fails the system would fail<br>
> to boot anyway.</div>
<div><br>
</div>
<div class="elementToProof">Fair. The same issue is present with RAID 1, and I am dealing with an installation where multiple ESPs are being created on RAID 0. A solution for RAID 1 would also solve RAID 0 systems.</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thank you for adding color re why my boot failures were random. Not great by OVH; also though with RAID 1, a boot failure would occur on disk failure even on a system with unique labels.</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof">> > Completely amazing ofc would be that grub-install or "whatever<br>
> > responsible component" sees all EFI entries in efibootmgr and upgrades /<br>
> > installs into all of them<br>
><br>
> EFI boot entries are not reliable enough. They do not even exist on some<br>
> systems.<br>
><br>
> > A thought on how to improve the postinst of grub<br>
> > Something along these lines - not this exact script, but in spirit - would update grub on all ESPs<br>
><br>
> This is a bad idea. Not all detected ESPs may belong to this system.<br>
> A correct solution requires to record the ESPs which are managed by this<br>
> system and must be updated.</div>
<div class="elementToProof"><br>
</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Noted. So, that solution is bad. A solution, of some kind, would be great. As that's clearly not trivial, a note at
<a href="https://www.debian.org/releases/stable/release-notes/issues.en.html#things-to-be-aware-of-while-upgrading-to-releasename">
https://www.debian.org/releases/stable/release-notes/issues.en.html#things-to-be-aware-of-while-upgrading-to-releasename</a> to look out for systems with multiple ESPs such as RAID 1 setups, and manually updating the ones belonging to Debian and not currently
mounted to /boot/efi, would be amazing.</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Sincerely yours</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thorsten</div>
<div class="elementToProof" style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
</body>
</html>