<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hello Nick!</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I pulled the trigger too soon.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I dug a bit deeper and discovered the problem is indeed mdadm itself, or more specifically, the config file.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">It turns out that either mdadm or kernel behaviour appears to have changed between versions, so I commented out the apparently-still-valid 'DEVICE' section in mdadm.conf then rebooted and I'm now back in business! 😁</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Thanks for the links though much appreciated. On that note, does anyone have any recommendations on doing bare-metal snapshot/restores at the root FS (preferably live)?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I'd love to find a solution to managing a bare-metal host like a VM to avoid situations like this in future.</div><div class="gmail_default" style="font-family:verdana,sans-serif">I can't really operate the host as a VM as it's a kind of hyperconverged hypervisor host, so I generally require bare-metal and direct access to all devices but the GPU.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font face="verdana, sans-serif"><br><span class="gmail_default" style="font-family:verdana,sans-serif">Kind </span>Regards,<br><br><i>Dean Bergin</i>.</font></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 28 Jun 2023 at 11:27, Nick Bannon <<a href="mailto:nick@ucc.gu.uwa.edu.au">nick@ucc.gu.uwa.edu.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jun 28, 2023 at 10:03:54AM +0800, Dean Bergin wrote:<br>
> I'm wondering if anyone can offer some sage advice around an issue I have<br>
> post-upgrade of a homelab server I maintain.<br>
> I'm stuck in emergency mode and it looks as though my LVM (device-mapper)<br>
> mounts aren't available.<br>
<br>
Heya, Dean! Sounds fixable, good luck. Can you boot with an "old" kernel?<br>
<br>
While it's usually possible to get away with just the installer<br>
"rescue" mode, I find it's more reassuring to reach for a different<br>
"live boot" at this stage and interactively use <a href="https://www.finnix.org/" rel="noreferrer" target="_blank">https://www.finnix.org/</a><br>
(small, Debian "testing" based, and also great for a headless server)<br>
or <a href="https://www.debian.org/CD/live/" rel="noreferrer" target="_blank">https://www.debian.org/CD/live/</a> . Either the latest, or occasionally<br>
going back to a version that more closely matches your current system.<br>
<br>
Boot it, let it scan for what's available, then interactively experiment<br>
to find exactly what you need to get your system mounted and self-bootable.<br>
<br>
> Before upgrading, I did have crypto-mount (or something) enabled, which<br>
> produced errors but did not prevent boot as I never encrypted the<br>
> underlying raid block device md0 (it was always planned but never<br>
> implemented, so it was skipped when building the server and I never<br>
> disabled the crypto boot service).<br>
<br>
It sounds like that specifically was "just" a harmless warning? We need<br>
to find the errors in console output, or `dmesg`, or what's totally<br>
missing that "ought" to be there, like a loaded working driver for your<br>
storage hardware (`lspci`/`lshw` ?).<br>
<br>
Maybe those devices were missing because of an `mdadm` error that<br>
scrolled past unnoticed, or a missing driver module in the `initramfs`,<br>
and it might be easier to see from a running live USB what was missing.<br>
<br>
( If the LVs are missing (`lvs`/`vgs`/`pvs`), the md0<br>
has probably not been assembled. Maybe that failed because the devices<br>
under md0 were missing, so that needs to be fixed before `vgchange -ay`<br>
will help. )<br>
<br>
There may be some known relevant issues that got written down in the<br>
"Upgrade" chapter 4 or "Issues to be aware of" chapter 5 of:<br>
<a href="https://www.debian.org/releases/oldstable/amd64/release-notes/" rel="noreferrer" target="_blank">https://www.debian.org/releases/oldstable/amd64/release-notes/</a><br>
<a href="https://www.debian.org/releases/stable/amd64/release-notes/" rel="noreferrer" target="_blank">https://www.debian.org/releases/stable/amd64/release-notes/</a><br>
<br>
[...]<br>
> I'm seeking some advice to try to quickly fix this before I consider<br>
> rebuilding. I do have a copy of /etc before upgrading FWIW.<br>
<br>
Good, could be handy to compare or know what devices or filesystem UUIDs<br>
to look for.<br>
<br>
Nick.<br>
<br>
-- <br>
   Nick Bannon   | "I made this letter longer than usual because<br>
<a href="mailto:nick-sig@rcpt.to" target="_blank">nick-sig@rcpt.to</a> | I lack the time to make it shorter." - Pascal<br>
_______________________________________________<br>
PLUG discussion list: <a href="mailto:plug@plug.org.au" target="_blank">plug@plug.org.au</a><br>
<a href="http://lists.plug.org.au/mailman/listinfo/plug" rel="noreferrer" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
Committee e-mail: <a href="mailto:committee@plug.org.au" target="_blank">committee@plug.org.au</a><br>
PLUG Membership: <a href="http://www.plug.org.au/membership" rel="noreferrer" target="_blank">http://www.plug.org.au/membership</a><br>
</blockquote></div>