Hi Paul,
On Mon, Aug 30, 2021 at 10:10:12PM +0200, Paul Gevers wrote:
> On 29-08-2021 23:39, Toni Mueller wrote:
> > I am not sure why the upgrade process didn't handle this case, but think
> > the severity of the problem warrants a warning in the release notes.
>
> Can you give a proposal for some text? After reading the old (closed)
> bug report, it's not clear to me what to warn for exactly as it seems
> that Colin there claims it's a broken configuration on your system.
the system was installed as a standard no-frills Buster system. I
haven't read why Colin thought that's a misconfiguration on the system,
but in my case, there has been no disk change, the system was installed
and then, sometime later, upgraded, which is when the problem occurred.
> Nobody brought it up to the release notes, so nothing was added.
Of course, I can only suggest something after seeing a problem. I would
suggest a text like this:
If your system is configured to boot from a RAID array, eg. MDADM, you
need to take extra precautions. After the upgrade procedure, but before
the reboot, you need to manually ensure that GRUB is properly installed
on all relevant disks. In the case of RAID1 (mirrored disks), do this:
# lsblk
sda...
sdc... # or sdb
You'll find the boot disks by their partitioning. For this example, it's
sda and sdc. Then run these commands:
# grub-install /dev/sda
# grub-install /dev/sdc
The other question is, why did this happen at all? I have previously
upgraded other systems with the same RAID configuration (ie, RAID1 via
mdadm), and can't remember having seen this problem. It would be better
to actually fix the problem, if possible.
Cheers,
Toni
