Bug#1135137: upgrade-reports: Bookworm -> Trixie mdadm raid EFI not updated on both disks

[Thorsten Behrens]

On Thu, 30 Apr 2026 00:46:30 +0200 Pascal Hambourg <pascal at plouf.fr.eu.org> wrote:
> Thorsten Behrens wrote:
> >
> > On a fresh install of Debian 12, on an OVH baremetal machine with mdadm
> > raid-0, I upgraded to Debian 13. After upgrade, grub in EFI had been
> > upgraded in one drive, but not the other.
>
> What is the point of having multiple ESPs with RAID 0 ? It does not
> provide any redundancy, so if either drive fails the system would fail
> to boot anyway.

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.

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.

> > Completely amazing ofc would be that grub-install or "whatever
> > responsible component" sees all EFI entries in efibootmgr and upgrades /
> > installs into all of them
>
> EFI boot entries are not reliable enough. They do not even exist on some
> systems.
>
> > A thought on how to improve the postinst of grub
> > Something along these lines - not this exact script, but in spirit - would update grub on all ESPs
>
> This is a bad idea. Not all detected ESPs may belong to this system.
> A correct solution requires to record the ESPs which are managed by this
> system and must be updated.

Noted. So, that solution is bad. A solution, of some kind, would be great. As that's clearly not trivial, a note at https://www.debian.org/releases/stable/release-notes/issues.en.html#things-to-be-aware-of-while-upgrading-to-releasename 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.

Sincerely yours
Thorsten

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-grub-devel/attachments/20260501/a849f119/attachment.htm>