[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#993274: marked as done (machine unbootable after upgrade)

Your message dated Mon, 23 Dec 2024 16:09:35 +0000
with message-id <CAJ3BuoTEaVXvWd6_-N9dm9g9La+e-7eiH9y1cSYW+ccgK1kfNg@mail.gmail.com>
and subject line Re: Bug#993274: machine unbootable after upgrade
has caused the Debian Bug report #993274,
regarding machine unbootable after upgrade
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
993274: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993274
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: upgrade-reports
Severity: grave


Hi,

I have recently upgraded a machine from Buster to Bullseye. The machine
runs on an mdadm RAID1. After the upgrade, it had the symptom outlined
in #931896.

I followed the upgrade process, as described in

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html


After completing this procedure, I ran

# apt install -f
# dpkg --configure -a

which both came up empty, suggesting that there was really no problem
left.


Since the machine didn't boot after upgrade, I'd say that warrants
'grave'.


As a fix, once I got access to the machine, running

# lsblk

to figure out the boot disks, then manually installing grub there like
this:


# grub-install /dev/sda
# grub-install /dev/otherdisk


solved the problem.


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.



Cheers,
Toni

--- End Message ---
--- Begin Message --- 
On Mon, 30 Aug 2021 21:49:45 +0100 Toni Mueller <toni@debian.org> wrote:
> On Mon, Aug 30, 2021 at 10:10:12PM +0200, Paul Gevers wrote:
> > On 29-08-2021 23:39, Toni Mueller wrote:

> > 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.

closing this report as it relates to buster, which is no longer supported.

It seems to have been disputed whether this was a bug in mdadm or not,
but unfortunately
i dont think anyone is likely to investigate it any more.

Please reopen if i have misunderstood, or there is a better solution

--- End Message ---
Reply to: