Subject: Re: Use grub-rescue on a non-bootable RAID-formatted drive [WAS: Re: status: how to install grub to non-bootable RAID-formatted drive?]

On Sun, 25 Jan 2026 at 18:01, D. R. Evans <doc.evans@gmail.com> wrote:

Hello, David

Hi.

I will print out your e-mail and study it, and the referenced documents, carefully -- putting aside the temptation to rush and skip things in my
hurry to get things working again.

As the attempt to get everything working without using grub rescue seems
to be stalled (see my e-mail
<eca2ee9a-ae7c-46b1-ab6a-101365e2a73f@gmail.com> in another sub-thread), trying to understand grub rescue seems like the best use of my time at
the moment.

If you want to reference other list messages, can you please do that by providing links into the list archive which can be found at for example:
https://lists.debian.org/debian-user/2026/01/threads.html

I think that understanding grub-rescue was always the best use of your
time, because it's simpler and safer than the other stuff you've been attempting, and we know it's never going to make things more complicated
than they already are. Or were :)

One comment:

David wrote on 1/25/26 5:04 AM:

given us some detail to work with. We can see your incorrect 'prefix'
(or something like it, because I'm guessing that you retyped that
because 'debain@' looks weird.

I agree that it looks weird (and that I had to retype it): it should have been "debian@" [which also looks weird to me, but that's what it said].

Having gone through the procedure in the other sub-thread, and thereby installing a new MBR

What's also important is that by running 'grub-install' on this drive, at
the same time as installing a new MBR it also (see my reference [wgft]) installed a new "core image", overwriting the one that was there
previously. This new core image will now be providing the initial values of 'prefix' and 'root' that you show below.

It's curious that previously [2] the core image had no sign of RAID (md devices) but now it does, even though there was no active RAID when the new core image was written. I've no experience with RAID so I'm unable to offer
any explanation of this.

I'm unsure what to trust more: the original simple (hd0) or the new values.
I note that in the new values there is no (md/1), only (md/0).

what I now see at the "grub rescue>" prompt is quite different (I have to take a photo of the screen, upload it to this computer, and type what it
says into this e-mail; I think I have done that without any mistakes)

I know it's tedious but it's very helpful that you provided this info.

[recall from that sub-thread that when the RAID MBR was written there
were two drives in the machine: /dev/sda was the non-booting RAID disk,
and /dev/sdb was the non-RAID disk that had supplied the running OS]:

I've no interest or time to spend digging into that other thread, but
I follow what you are saying here, and I agree with what you are saying
about the two drives being present as detected by grub, except you have no
way of knowing that /dev/sda corresponds to hd0 and /dev/sdb corresponds to hd1, it might be the other way around. If needed, you could figure out
which is which if they have any different content, which you can observe
using 'ls' command in 'grub-rescue'. But it would be better if you removed
all hard drives except the one that you are trying to rescue, more comments
on this below.

"ls" now returns:

(hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos5) (hd1,msdos1) (md/0) (fd0) error: failure reading sector 0xb30 from 'fd0'.

I interpret that to mean, in order:
the entire RAID disk (/dev/sda)
the second partition on the RAID disk (/dev/sda2)
the first partition on the RAID disk (/dev/sda1)
the entire non-RAID disk (/dev/sdb)
the fifth partition on the non-RAID disk (/dev/sdb5)
the first partition on the non-RAID disk (/dev/sdb1)
the logical RAID disk
the floppy drive
and there was an error accessing the floppy, probably because there was nothing in the drive.

"set" now returns ("8d86...0aed" is shorthand for a long UUID):

prefix='(mduuid/8d86...0aed)/boot/grub'
root = 'mduuid/8d86...0aed'

Right, that's where we are right now. Now to print out your e-mail and everything else, and when I get a bit of time -- this afternoon, I hope
-- I'll try get my head around grub rescue.

Ok. It's important to keep in mind: 'ls' is showing you what's actually detected right now, and 'prefix' and 'root' are showing you what got
written the last time you used 'grub-install' on that drive.

The rest of my comments below are motivated by the fact that your 'ls'
results above contain more than one hard drive (some of them have "hd0" and some have "hd1").

This is why in the first email I wrote [1] on this subject (in the two paragraphs beginning "So, ..." and "While ...") , I recommended to utilise 'grub-rescue' *before* ever using 'grub-install' to modify what is on the drive, because 'grub-install' has destroyed the evidence of what was there previously, which you showed in [2]. That would have avoided these extra uncertainties that have been introduced.

Anytime using 'grub-rescue' it will greatly reduce the scope of confusion
if 'ls' reports only one hard drive (hd0) as you showed in your previous message [2]. To achieve this now, I suggest to disable or remove all drives from the machine except the drive you are trying to rescue, before booting
it, so that 'ls' returns only "(hd0) (fd)" as you showed in your previous
email [2]. Hopefully when you do that, you will still see a 'grub-rescue' prompt that you can use to attempt recovery.

Given that I'm entirely clueless about RAID, I'd suggest to ignore grub's detection of any devices that look like RAID devices, such as the (md/0) or (mduuid/8d86..) that you mention above. My thinking on this point being
that at the time we can get the recovered drive to boot successfully, I'm assuming there will be no RAID active. On the other hand, we might want
RAID to be active, I don't know. My focus is on getting the drive to boot somehow, not being concerned about getting the previous RAID working again.
If there are any other people reading here with actual experience of
degraded RAID systems, please share your thoughts on this point.

Emphasising gain: 'grub-rescue' will not modify the drive and is just a way
to get the drive to boot one time. What you do after it has booted is up to you. I imagine that would be the best time to be running 'grub-install' or trying to recover the RAID, or whatever else you need to do.

[1] https://lists.debian.org/debian-user/2026/01/msg00411.html
[2] https://lists.debian.org/debian-user/2026/01/msg00449.html

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re:Referencing mail messages (was: Use grub-rescue on a non-bootable RAID-formatted drive)

On 26/01/2026 5:01 am, David wrote:

On Sun, 25 Jan 2026 at 18:01, D. R. Evans wrote:

As the attempt to get everything working without using grub rescue seems
to be stalled (see my e-mail
<eca2ee9a-ae7c-46b1-ab6a-101365e2a73f@gmail.com> in another sub-thread),

If you want to reference other list messages, can you please do that by providing links into the list archive which can be found at for example:
https://lists.debian.org/debian-user/2026/01/threads.html

David, if you wish to open that message in a browser then you may easily
do it:

https://lists.debian.org/msgid-search/?m=MESSAGE_ID

Actually every message has a bit broken header with a link to the list archive, see List-Archive.

Having Message-ID, it is more convenient to open that message inside
mailer or in another web mailing list archive. Instead, your are
suggesting to use a link that is local to the lists.debian.org web site.

There is even "mid:" URL scheme to make Message-ID links explicit.

P.S. Usually I am trying to postpone replies unrelated to topic main
issue till it can be considered solved. This case the suggestion is a
bit controversial.

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Referencing mail messages (was: Use grub-rescue on a non-bootable RAID-formatted drive)

On Mon, 26 Jan 2026 at 03:18, Max Nikulin <manikulin@gmail.com> wrote:

On 26/01/2026 5:01 am, David wrote:

On Sun, 25 Jan 2026 at 18:01, D. R. Evans wrote:

As the attempt to get everything working without using grub rescue
seems to be stalled (see my e-mail
<eca2ee9a-ae7c-46b1-ab6a-101365e2a73f@gmail.com> in another
sub-thread),

If you want to reference other list messages, can you please do that by providing links into the list archive which can be found at for
example: https://lists.debian.org/debian-user/2026/01/threads.html

David, if you wish to open that message in a browser then you may easily
do it:

https://lists.debian.org/msgid-search/?m=MESSAGE_ID

Actually every message has a bit broken header with a link to the list archive, see List-Archive.

Having Message-ID, it is more convenient to open that message inside
mailer or in another web mailing list archive. Instead, your are
suggesting to use a link that is local to the lists.debian.org web site.

There is even "mid:" URL scheme to make Message-ID links explicit.

P.S. Usually I am trying to postpone replies unrelated to topic main
issue till it can be considered solved. This case the suggestion is a bit controversial.

Hi Max,

Thanks for using a separate thread to discuss this.

Here's an example link that I wrote recently in another message: https://lists.debian.org/debian-user/2026/01/msg00411.html

If I click on that link, the Message-ID you prefer is provided in
line 7 of the served page. So the Message-ID is available there for anyone
who needs it.

Here are the reasons why I am inclined to continue preferring the direct
link to the archive:
1) It is human-readable, so it is clear and safe to click on.
2) Its format and use is consistent with links to other web sources.
3) It does not require special knowledge for any (eg newbie) reader to find
the information, because everyone knows how to follow https links.
4) It works for readers who are not using a dedicated mail client.
5) It works for readers who are reading the archive in a web browser.
5) Sometimes the Message-ID search of the Debian mail archives fails to
find messages, so I prefer to use a method that seems to always work.

I don't use a dedicated mail client to participate here. I already make
quite some effort to be a good citizen here and comply with email
etiquette, while using the Gmail web interface. For example, I precompose
all my messages using Vim to properly reflow and clean up quoted text.

How much of an inconvenience is this for folks who do? I am open to
changing this behaviour if people want to convince me that it is truly problematic. But optimisations are sometimes not universal.

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Use grub-rescue on a non-bootable RAID-formatted drive [WAS: Re: status: how to install grub to non-bootable RAID-formatted drive?]

On Thu, 29 Jan 2026 at 18:27, D. R. Evans <doc.evans@gmail.com> wrote:

All right, let's see where we are now, on this grub-rescue sub-thread.

Welcome back.

I will elide much of your (extremely useful/helpful) commentary, just to
make this e-mail less overwhelming.

Following several attempts to use a separate drive/CD/USB stick to get
things working (so far without success), the current situation if I take everything else out, and just leave the RAID drive in the machine, and
boot to the "grub rescue>" prompt, I now see (I have to type everything manually into this e-mail; I'll obviously try to be really careful about that):

ls:

(hd0) (hd0, msdos2) (hd0, msdos1) (md/0) (fd0) error: failure reading
sector 0xb30 from 'fd0'

Great, having only the one drive in the machine is exactly what we
need to see.

The fd error is, I'm sure, irrelevant.

I agree.

The actual RAID filesystem from which we want to boot is the second
partition on the hard drive: (hd0, msdos2).

Ok.

set: [in this output I'll use "<UUID>" to mean a UUID that it prints, whi

ch

starts with "8d86" and ends with "0aed"]

prefix='(mduuid/<UUID>)/boot/grub'
root='mduuid/<UUID>'

Grub looks for its third portion using the "prefix" value that 'grub-install' wrote into the second portion. That's what you see when typing 'set' at the 'grub-rescue' prompt. You're seeing the
'grub-rescue' prompt because that stored value of "prefix" is wrong,
and the second portion of grub is telling you that it can't find the
third portion.

That paragraph _really_ helped my understanding; it made the GNU documentation a lot clearer.

Great.

I note that your link to [grm], https://olinux.net/grub-rescue-mode/,
returns a 521 "Web server is down" error (at least, it has done so every
time I've tried it, so I have been unable to look at that information).

Don't worry about it. That was just a simple demo of some basic grub-rescue
use with no details specifically useful to you, so nothing there was
important.

So now that we are sure that you understand tab-completion, you can use grub-rescue's tab-completion in combination with its 'ls' command to explore your disk's filesystem with the aim of discovering where the
grub third portion files are. You would do this by typing something
like:

grub rescue> ls (hd0)/

and then using tab-completion to see what grub finds in the root
directory of your hard drive.

Perhaps I'm not understand something. I tried typing each of the
following in turn at the "grub rescue>" prompt:

ls (hd0)/<TAB><TAB>
ls (hd0, msdos2)/<TAB><TAB>
ls (hd0, msdos1)/<TAB><TAB>
ls (md/0)/<TAB><TAB>

None of them did anything at all.

You had written before that "Occasionally tab-completion does not work in grub-rescue. But it usually does,". Perhaps this is one of those
occasions where it does not :-(

I agree. Looks like tab-completion doesn't work there. That's not
a showstopper, because tab-completion is just a convenience feature. You
can use 'ls' to do the same work, it is just slightly more fiddly.

It seemed like, from what you said, that one of the following _should_
work:

prefix=(X)/boot/grub
root=X
insmod normal
normal

where X is one of: hd0
hd0,msdos2
hd0,msdos1
md/0
most likely either hd0,msdos2 or md/0 being the correct value.

I agree.

I tried them all, and at the "insmod normal" step, they all returned:
"error: unknown filesystem".

Ok, but that's trying too much at once. What I would do is to take each
of the devices that you reported above that your plain 'ls' found, namely

(hd0) (hd0, msdos2) (hd0, msdos1) (md/0) (fd0)

and I would ask grub-rescue to show us what content if anything it is able
to read in the root directory of each device in turn. Can you please
report the result of these interactive grub-rescue commands, after booting
your system with only the drive being rescued connnected:

ls (hd0)/
ls (hd0, msdos1)/
ls (hd0, msdos2)/
ls (md/0)/

Hopefully one or more of those will be readable by grub. If so, the next
step will be to use the directory names which that result showed, allowing
you to run another longer 'ls' command to explore the readable content of
those directory names, with the aim of finding your grub module files
(third portion) somewhere.

Just to be absolutely certain that the RAID disk hasn't somehow been compromised, I then reattached a drive with a bootable OS, booted into
that OS, and made sure that I could still mount the second partition on
the RAID drive; it still looks good, with the entire "/" hierarchy still
in place, including /boot.

Ok good.

My simple brain says that if I can access <partition 2 on the RAID drive>/boot from a running OS, we just haven't found the magic
incantation yet for doing the same for setting the value of prefix and
root in grub rescue.

I agree. We are close to finding out which if any of your partitions grub
is able to read and hopefully find the files it needs to continue booting.

On Thu, 29 Jan 2026 at 18:39, D. R. Evans <doc.evans@gmail.com> wrote:

D. R. Evans wrote on 1/29/26 11:27 AM:

You had written before that "Occasionally tab-completion does not work
in grub-rescue. But it usually does,". Perhaps this is one of those occasions where it does not :-(

FYI, I just found this:

https://superuser.com/questions/1237684/how-to-boot-from-grub-shell says:

When you?re at the grub> prompt, you have a lot of functionalit

y

similar to any command shell such as history and tab-completion. The
grub rescue> mode is more limited, with no history and no
tab-completion.

Yes, as I said, sometimes it does not work. Sometimes you just get tab characters.

More usefully, if you read the 5 paragraphs in the above link starting from "What?s all this msdos stuff?" and ending at "Reading /etc/issue co
uld be
useful", then that is describing exactly where you are at now.

And if you read further down, there's a heading "Booting From grub-rescue>" which describes exactly the same procedure from the grub manual that I've
been suggesting you follow (that uses the grub-rescue sequence that you
wrote "should work" above using the 'insmod normal' and 'normal' commands).

But let's proceed step-by-step and not get ahead of ourselves. As I asked above, what does 'ls' say for each root directory?

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Use grub-rescue on a non-bootable RAID-formatted drive [WAS: Re: status: how to install grub to non-bootable RAID-formatted drive?]

Hi Doc,

On Thu, 29 Jan 2026 at 23:54, D. R. Evans <doc.evans@gmail.com> wrote:

David wrote on 1/29/26 3:55 PM:

Can you please report the result of these interactive grub-rescue
commands, after booting your system with only the drive being rescued connnected:

ls (hd0)/
ls (hd0, msdos1)/
ls (hd0, msdos2)/
ls (md/0)/

They all return:
error: unknown filesystem

Ok, I take that to mean that the grub "second portion" that currently
exists on your drive is incapable of reading any filesystem that it is
aware of on that drive.

This is a strange situation, not sure how that has arisen, comments on that below, but at least concrete facts are progress.

For context, I'm going to quote some prior info you provided, and I have interleaved some comments.

On Thu, 22 Jan 2026 at 17:11, D. R. Evans <doc.evans@gmail.com> wrote: [a]

I had a linux-raid two-drive system that was working fine for many years.
The system uses legacy BIOS booting. My notes from long ago say that both drives had a working GRUB; but it seems that my notes were wrong: one of
the drives died without warning, leaving me with a drive with
a fully-functioning trixie (and all the user data, etc.) present, but
that drive seems to have no working GRUB in the MBR. Trying to boot it
gives me a "grub-rescue>" prompt.

[...]

I can physically remove the drive and place it on a functioning machine,
and have done so. With the drive in the functioning machine, I have
checked that indeed all the data on it (that were in the original "/" hierarchy) are readable. So I just want to find a way to install GRUB on
the MBR in a way that will cause the disk to be bootable into the system
that was on it. That is, I want to be able to remove the disk from the functioning machine that it's currently (temporarily) on, put the drive
back in the original machine, power on, and have the system come up as it used to (except now with just one active drive in the RAID array).

From there I can add a new drive to the array and get myself back
a fully-functioning two-drive RAID-based system.

Before we get lost in all the details again, can we do a sanity check:
Do you really need to take this approach?

You say that the old disk is readable when put into another functioning machine. So another approach could be to build a brand new RAID system and
just recover whatever old data you need off the old disk.

Do you really need to get the old disk to boot? Note that if you make
a mistake continuing with attempts to get the old disk to boot, you might corrupt it and lose the ability to read any old data off it.

On Thu, 22 Jan 2026 at 21:40, D. R. Evans <doc.evans@gmail.com> wrote: [b]

alain williams wrote on 1/22/26 11:01 AM:

You do not say what sort of RAID you are using, but you have 2 disks so
I assume RAID-1 (mirrored disks).

Yes, you are correct: RAID-1.

[...]

The command "parted -l" gives:

Model: ATA HGST HDN724030AL (scsi)
Disk /dev/sda: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 16.0GB 16.0GB primary boot, raid
2 16.0GB 2000GB 1984GB primary raid

All the system info is in that second partition. I don't rightly recall
why the first partition is present (it's been an awfully long time since
I installed this disk). I suspect that it's reserved for swap, although
I doubt that swapping has ever occurred.

[...]

I had a spare hard drive on which I installed a pristine copy of trixie
(on ext4), and that's what I've booted from.

[...]

Identify the hard disk that contains your system, look at
/proc/partitions.

major minor #blocks name

2 0 4 fd0
8 16 1953514584 sdb
8 17 1945125888 sdb1
8 18 1 sdb2
8 21 8385591 sdb5
8 0 2930266584 sda
8 1 15624192 sda1
8 2 1937889280 sda2
11 0 1048575 sr0
11 1 1048575 sr1
9 126 1937757184 md126

sdb (size 2TB) is the drive from which I booted. sda (size 3TB) is the
old RAID drive.

On Fri, 23 Jan 2026 at 15:30, D. R. Evans <doc.evans@gmail.com> wrote: [c]

Based on the above output from /proc/partitions, I think that the root filesystem is best described as /dev/md126.

mkdir /tmp/RFS

OK

mount /dev/sda1 /tmp/RFS

For just inspecting a disk I'd suggest 'mount -r' for a readonly mount, to avoid accidents.

I changed this to: mount /dev/md126 /tmp/RFS

I note that if I try to execute "mount /dev/sda2 /tmp/RFS" instead, then
I get an error about "linux_raid_member" being an unknown filesystem
type. But if I call that partition "md126", then the mount proceeds OK.

Ok, so we know that /dev/sda2 is "linux_raid_member", and not readable as
an ext2/3/4 device.

I am curious to know what is on /dev/sda1. You seem unclear about that,
maybe you could investigate. I notice above it has a boot flag.

What happens when you try to mount /dev/sda1? I suggest a similar 'mount
-r' inspection as you show below for /dev/sda2.

What does 'lsblk -f' command say about disk sda and its partitions
and their FSTYPE?

At this point, if I look at the contents of /tmp/RFS, I see (wrapped by
the e-mail agent):

[...]

and /tmp/RFS/boot/grub:

total 2428
drwxr-xr-x 5 root root 4096 Jan 10 08:32 .
drwxr-xr-x 3 root root 12288 Jan 10 08:34 ..
drwxr-xr-x 2 root root 4096 Feb 28 2020 fonts
-r--r--r-- 1 root root 16758 Jan 10 08:32 grub.cfg
-rw-r--r-- 1 root root 1024 Jan 20 11:44 grubenv
drwxr-xr-x 2 root root 24576 Sep 8 15:25 i386-pc
drwxr-xr-x 2 root root 4096 Sep 8 15:25 locale
-rw-r--r-- 1 root root 2411806 Sep 8 15:25 unicode.pf2

For your info, the "third portion" [1] of grub is the module files
contained in the i386-pc directory you see above. It would be interesting
to know what grub version is in that directory, you could try something
like the example below that I see on this machine:

[root@kablamm i386-pc]# strings normal.mod | grep -C 1 version
not in normal environment
GNU GRUB version %s
2.06-13+deb12u1

On Sun, 25 Jan 2026 at 20:47, D. R. Evans <doc.evans@gmail.com> wrote: [d]

I found my notes from when I first installed Linux software RAID on the machine in question (in 2013), and, without going into details, it
basically was simply done as a RAID1 installation from what was at the
time the official debian installer. I had to do it a couple of times to
get the partitioning on the two drives right. Both of the drives in that original installation were 2TB. My memory about the partitioning was
correct: the two original drives each had two partitions: i) 16GB, which
was used as swap on one drive, and merely formatted as ext3, but unused,
on the other; then the rest of each drive was the RAID mirror.

A few years later, one of the drives started to generate SMART errors, so
it was replaced. Although both the original drives were 2TB, I had to use
a 3TB drive as a replacement, because when I tried to use a replacement
2TB drive, something complained in the process that there was
insufficient space -- presumably because of disk-to-disk variation in
usable space. That replacement 3TB drive is the one that I am now trying
to make boot. My notes don't say that I ever tried to make that drive bootable, which was an obvious error on my part, and why I am now in this situation. (I probably knew it had to be done, and didn't have time, and
then forgot all about it.)

This replacement 3TB drive, was it new and unused, or had it been used previously? Because you initially showed:

On Sat, 24 Jan 2026 at 20:42, D. R. Evans <doc.evans@gmail.com> wrote: [e]

If I try to boot from the RAID disk, which drops me into grub rescue,
then type "ls", it responds with:
(hd0) (fd0)

If I type "set", it responds with:
prefix='(hd0)/BOOT/debain@/grub'
root='hd0'

so I wonder at what point those "second portion" values were created, where they came from, and if they are relevant to your RAID installation in any
way (I doubt it), or maybe a relic from some unrelated prior use of that
disk (I suspect so).

Unfortunately you never showed us any attempt to use 'ls' in grub-rescue to inspect the filesystems on the drive in that state, so we don't know if
that grub could read them or not.

And then you showed for two drives installed:

On Sun, 25 Jan 2026 at 18:01, D. R. Evans <doc.evans@gmail.com> wrote: [f]

Having gone through the procedure in the other sub-thread, and thereby installing a new MBR, what I now see at the "grub rescue>" prompt is
quite different (I have to take a photo of the screen, upload it to this computer, and type what it says into this e-mail; I think I have done
that without any mistakes) [recall from that sub-thread that when the
RAID MBR was written there were two drives in the machine: /dev/sda was
the non-booting RAID disk, and /dev/sdb was the non-RAID disk that had supplied the running OS]:

"ls" now returns:

(hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos5) (hd1,msdos1) (md/0) (fd0) error: failure reading sector 0xb30 from 'fd0'.

I interpret that to mean, in order:
the entire RAID disk (/dev/sda)
the second partition on the RAID disk (/dev/sda2)
the first partition on the RAID disk (/dev/sda1)
the entire non-RAID disk (/dev/sdb)
the fifth partition on the non-RAID disk (/dev/sdb5)
the first partition on the non-RAID disk (/dev/sdb1)
the logical RAID disk
the floppy drive
and there was an error accessing the floppy, probably because there was nothing in the drive.

"set" now returns ("8d86...0aed" is shorthand for a long UUID):

prefix='(mduuid/8d86...0aed)/boot/grub'
root = 'mduuid/8d86...0aed'

And now you're showing for one drive installed:

On Thu, 29 Jan 2026 at 18:27, D. R. Evans <doc.evans@gmail.com> wrote: [g]

Following several attempts to use a separate drive/CD/USB stick to get
things working (so far without success), the current situation if I take everything else out, and just leave the RAID drive in the machine, and
boot to the "grub rescue>" prompt, I now see (I have to type everything manually into this e-mail; I'll obviously try to be really careful about that):

ls:

(hd0) (hd0, msdos2) (hd0, msdos1) (md/0) (fd0) error: failure reading sector 0xb30 from 'fd0'

The fd error is, I'm sure, irrelevant.

The actual RAID filesystem from which we want to boot is the second
partition on the hard drive: (hd0, msdos2).

set: [in this output I'll use "<UUID>" to mean a UUID that it prints,
which starts with "8d86" and ends with "0aed"]

prefix='(mduuid/<UUID>)/boot/grub' root='mduuid/<UUID>'

So by contrast to previous [e], it seems that [f] and [g] show that you overwrote (I assume using grub-install command) the previous "second
portion" with a new one which is more capable to read the partition table
and find partitions (hd0,msdos1) (hd0,msdos2) which were not shown
previously.

However I suspect that this new "second portion" is somewhat useless
because whatever 'grub-install' command you used was not nuanced enough to
deal with the situation that grub would get confused between the two drives
and the various partitions RAID or otherwise that were present at the time.
The "second portion" now sees two additional partitions that it didn't see before, and an additional (md/0) device, but cannot read any of their
contents.

If you want to take the risk (eg possibly losing your data further, please
take a backup somehow first) then you could try using a more careful 'grub-install' command, but you will need to do this with the two disks
back in the machine as you showed at [f]. Because this method from [h]
won't work:

On Thu, 29 Jan 2026 at 11:34, Alexander V. Makartsev
<avbetev@gmail.com> wrote: [h]

I imagine you could type at grub rescue prompt something like this:
grub> set pager=1
grub> insmod normal
grub> insmod part_msdos
grub> insmod diskfilter
grub> insmod mdraid1x
grub> insmod ext2
grub> ls
(proc) (hd0) (hd0,msdos1) (hd0,msdos2) (md/0)
grub> set prefix=(md/0)/boot/grub
grub> set root=(md/0)
grub> linux ($root)/boot/vmlinuz-6.12.63+deb13-amd64 root=/dev/md126
grub> initrd ($root)/boot/initrd.img-6.12.63+deb13-amd64
grub> boot

It won't work because 'grub>' prompt is not the same as 'grub rescue>'
prompt. grub-rescue will have appeared *because* grub cannot find any
"third portion" (including modules normal, part_msdos, diskfilter,
mdraid1x, ext2, and others) so trying to 'insmod' them will fail, as David Wright explained:

On Fri, 30 Jan 2026 at 01:00, David Wright <deblis@lionunicorn.co.uk> wrote: [i]

That's worrying. A Grub rescue prompt could well fail because it needs modules to read the filesystems, but needs to read the filesystems to
find its modules, which is why it needs a human to help it search
every nook and cranny of all the devices for some modules to load.

So if:
- you have the two disks back in the machine, and
- you have booted it and confirm that they appear exactly as you have shown
at [f], and
- you have backups and are prepared to risk data loss, then
- you could try something like this, using ideas from [j]:

grub-install --modules='part_msdos diskfilter ext2 mdraid1x' /dev/sda

We cannot give a --boot-directory argument value to that command at this
time (which would create a 'prefix' value) because we do not know what
value to specify, and its grub device might be wrong.

Then remove the good drive and try to boot again using only the faulty
drive. It will fail and drop you into grub-rescue, because we have not provided a correct 'prefix' value yet. But there is a chance that retrying
the procedure I described in [k] (at "What I would do is ...") will be more successful this time, and maybe one of the filesystems will be readable by grub-rescue, allowing you to then try the procedure I described in [m].

If that succeeds it will allow you to boot one time only. You will need to
run a different grub-install command then, to permanently add the necessary values of 'prefix' and 'root' that you discovered into your
"second-portion".

After that you would need to recover your RAID-1 which I know nothing about beyond what I read at [n] which says:

Since support for MD is found in the kernel, there is an issue with using
it before the kernel is running. Specifically it will not be present if
the boot loader is either (e)LiLo or GRUB legacy. Although normally
present, it may not be present for GRUB 2. In order to circumvent this
problem a /boot filesystem must be used either without md support, or
else with RAID1. In the latter case the system will boot by treating the
RAID1 device as a normal filesystem, and once the system is running it
can be remounted as md and the second disk added to it. This will result
in a catch-up, but /boot filesystems are usually small.

Footnotes:

[1]: I will persist with this "Nth portion of grub" phrasing that we
introduced previously, because although it is not standard, it reduces confusion with some outdated info about grub on the web which has terms
like "Stage N". My "second portion" is the same as "core image" aka
"core.img" which is usually outside any file system. There is a good
diagram of GRUB2 MBR boot at
https://en.wikipedia.org/wiki/BIOS_boot_partition

[a]: https://lists.debian.org/debian-user/2026/01/msg00377.html
[a]: 33fd2721-cb2d-4e57-8d37-96241c0868b5@gmail.com

[b]: https://lists.debian.org/debian-user/2026/01/msg00392.html
[b]: 499f1130-0efb-4a6f-b9c9-ab0a3f1b7e4f@gmail.com

[c]: https://lists.debian.org/debian-user/2026/01/msg00420.html
[c]: a47df1f9-5373-4e63-93d3-2de64d69c5bc@gmail.com

[d]: https://lists.debian.org/debian-user/2026/01/msg00484.html
[d]: a6694f66-9ca2-45b1-a1fb-543dc34043eb@gmail.com

[e]: https://lists.debian.org/debian-user/2026/01/msg00449.html
[e]: 774c7024-6bcc-4a08-9ce4-88f6a5bdb0eb@gmail.com

[f]: https://lists.debian.org/debian-user/2026/01/msg00475.html
[f]: e0834e23-930d-4d93-af23-ffe27cc069d9@gmail.com

[g]: https://lists.debian.org/debian-user/2026/01/msg00557.html
[g]: 54e674d7-9b8b-4969-8768-96b81bb974c7@gmail.com

[h]: https://lists.debian.org/debian-user/2026/01/msg00551.html
[h]: 78b79bf7-3165-410c-98a0-337a74de3ca5@gmail.com

[i]: https://lists.debian.org/debian-user/2026/01/msg00578.html
[i]: aXwCjt1eYfDDj0wM@axis.corp

[j]: https://unix.stackexchange.com/questions/17481/grub2-raid-boot

[k]: https://lists.debian.org/debian-user/2026/01/msg00574.html
[k]: 54e674d7-9b8b-4969-8768-96b81bb974c7@gmail.com

[m]: https://lists.debian.org/debian-user/2026/01/msg00468.html
[m]: CAMPXz=qK7Dn4jjcrdKeLAjha2bGi8_DG2gvHoW-WO0Gm3izG5Q@mail.gmail.com

[n]: https://en.wikipedia.org/wiki/Mdadm

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Use grub-rescue on a non-bootable RAID-formatted drive [WAS: Re: status: how to install grub to non-bootable RAID-formatted drive?]

On 1/31/26 11:28, David wrote:

...
On Thu, 29 Jan 2026 at 11:34, Alexander V. Makartsev
<avbetev@gmail.com> wrote: [h]

I imagine you could type at grub rescue prompt something like this:
grub> set pager=1
grub> insmod normal
grub> insmod part_msdos
grub> insmod diskfilter
grub> insmod mdraid1x
grub> insmod ext2
grub> ls
(proc) (hd0) (hd0,msdos1) (hd0,msdos2) (md/0)
grub> set prefix=(md/0)/boot/grub
grub> set root=(md/0)
grub> linux ($root)/boot/vmlinuz-6.12.63+deb13-amd64 root=/dev/md126
grub> initrd ($root)/boot/initrd.img-6.12.63+deb13-amd64
grub> boot

It won't work because 'grub>' prompt is not the same as 'grub rescue>' prompt. grub-rescue will have appeared *because* grub cannot find any
"third portion" (including modules normal, part_msdos, diskfilter,
mdraid1x, ext2, and others) so trying to 'insmod' them will fail, as David Wright explained:

You don't know what you are talking about. This is not the "chicken-egg problem".
"insmod" commands will work in 'grub>' AND 'grub rescue>' and essential modules are provided by grub's core image.
"insmod normal" will fail and return "error: disk 'mduuid/...' not
found.", this was expected, because grub needs prefix to be available to
load it.
However, all essential modules, like "part_msdos, diskfilter, mdraid1x,
ext2" are available without prefix and in fact preloaded at boot time.
Grub's "ls" command outputs "(hd0) (hd0,msdos1) (hd0,msdos2) and (md/0)" because these modules are preloaded.
This is the reason why I called these commands "redundant" in my messages.
I've seen OP's reply about "ls (md/0) outputs Error: unknown filesystem"
which is strange, it should output "(md/0): Filesystem is ext2.".
The problem OP having is something else, as I've written before, but he
seems refusing to cooperate and provide more information, or is too busy
to work on it.
He seems to ignore the other possibilities that could interfere with
booting process, like old BIOS and too modern 3TB disk, MBR partitioned
3TB disk, Advanced Format disk, etc.
Since we already reinstalled grub properly and that didn't fix the
problem, next steps should be fixing broken array "/dev/md127" and
checking filesystem on "/dev/md126" with "fsck.ext4".
But before that he needs to make a good backup of his data, because it
becomes increasingly too risky to continue, as I told him before.
I've also told him other possible options like adding another disk less
than 2TB in size into PC, if he has it handy, and move "/boot" to it to
use it as a boot disk.
Or repurpose his dysfunctional swap on "/dev/md127" into a plain
partition with ext3 filesystem and move "/boot" to it.
These options I would pursue if I had the same problem.
--
With kindest regards, Alexander.
Debian - The universal operating system
https://www.debian.org


--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Use grub-rescue on a non-bootable RAID-formatted drive [WAS: Re: status: how to install grub to non-bootable RAID-formatted drive?]

On Sat, 31 Jan 2026 at 09:12, Alexander V. Makartsev <avbetev@gmail.com> wrote:

On 1/31/26 11:28, David wrote:

On Thu, 29 Jan 2026 at 11:34, Alexander V. Makartsev <avbetev@gmail.com> wrote:

I imagine you could type at grub rescue prompt something like this:
grub> set pager=1
grub> insmod normal
grub> insmod part_msdos
grub> insmod diskfilter
grub> insmod mdraid1x
grub> insmod ext2
grub> ls
(proc) (hd0) (hd0,msdos1) (hd0,msdos2) (md/0)
grub> set prefix=(md/0)/boot/grub
grub> set root=(md/0)
grub> linux ($root)/boot/vmlinuz-6.12.63+deb13-amd64 root=/dev/md126 grub> initrd ($root)/boot/initrd.img-6.12.63+deb13-amd64
grub> boot

It won't work because 'grub>' prompt is not the same as 'grub rescue>' prompt. grub-rescue will have appeared *because* grub cannot find any "third portion" (including modules normal, part_msdos, diskfilter, mdraid1x, ext2, and others) so trying to 'insmod' them will fail, as
David Wright explained:

You don't know what you are talking about. This is not the "chicken-egg problem".

"insmod" commands will work in 'grub>' AND 'grub rescue>' and essential modules are provided by grub's core image.

"insmod normal" will fail and return "error: disk 'mduuid/...' not
found.", this was expected, because grub needs prefix to be available to
load it.

Hi Alexander,

No, I do "know what I am talking about" on this point, and you are mistaken
on this point. Your error is perhaps to assume that what you see on your system is true for every installation.

What you might be overlooking in this case is that 'grub-install' is
designed to create a minimal size core image according to what it detects
to be necessary to boot the system. So if 'grub-install' is not aware of
any RAID on the system, such as when the boot files are not currently on an active RAID system, then it will omit the grub RAID modules when creating
and installing the core image.

I will demonstrate for you. I have a system here with MBR boot and no RAID.

To enter grub-rescue, I cause a deliberate error by renaming my /boot/grub directory to /boot/grubx, and reboot.

Because that change has now caused the prefix installed into grub core
image to be wrong, I get the grub-rescue prompt.

Below is a transcript of the grub-rescue session (I retyped it manually).

However, all essential modules, like "part_msdos, diskfilter, mdraid1x,
ext2" are available without prefix and in fact preloaded at boot time.

Line 5 and line 7 of transcript below show you that the diskfilter and
mdraid1x modules are not available in this grub-rescue environment, which proves that your above statement is incorrect.

That is the point that I wanted to show you, in TRANSCRIPT PART 1.

[...]

The problem OP having is something else, as I've written before, but he
seems refusing to cooperate and provide more information, or is too busy
to work on it.

He seems to ignore the other possibilities that could interfere with
booting process, like old BIOS and too modern 3TB disk, MBR partitioned
3TB disk, Advanced Format disk, etc.

These other points that you have made are all valuable. I agree that it is possible that Doc's 3TB drive might be too big for his BIOS or MBR to work with.

My transcript below is longer, because it has a second purpose, continuing
in TRANSCRIPT PART 2.

There, I temporarily forgot that on this system /boot is a symlink, so
I made a mistake when I first tried 'set prefix', I should have omitted
/boot.

However I think it is useful to provide the whole transcript of how
I recovered from this error as an example for anyone of how to discover the correct value to use for 'prefix' to get the system to boot.

Note that in this case, the process is to use the grub-rescue environment
to search until I find the 'grubx' directory, which contains the i386-pc directory, which is where I know the grub modules can be found in
a filesystem.

Also my 'reboot' command was a mistake, but I left it in to show that it
is unavailable at that moment, and that the 'normal' command is the way to continue the boot using the specified 'prefix' and 'root'.

#=====================================================================
## grub-rescue TRANSCRIPT PART 1 ##

error: file `/grub/i386-pc/normal.mod' not found.
Entering rescue mode...
grub rescue> insmod part_msdos
grub rescue> insmod diskfilter
error: file `/grub/i386-pc/diskfilter.mod' not found.
grub rescue> insmod mdraid1x
error: file `/grub/i386-pc/mdraid1x.mod' not found.
grub rescue> insmod ext2
grub rescue> insmod normal
error: file `/grub/i386-pc/normal.mod' not found.

#=====================================================================
## grub-rescue TRANSCRIPT PART 2 ##

grub rescue> echo $prefix
grub rescue> Unknown command `echo'.
grub rescue> set prefix=(hd0,msdos2)/boot/grubx
grub rescue> ls $prefix

error: file `/boot/grubx' not found.
grub rescue> ls $prefix/

error: file `/boot/grubx/' not found./
grub rescue> ls
(hd0) (hd0,msdos7) (hd0,msdos6) (hd0,msdos5) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1)
grub rescue> ls (hd0)/
error: unknown filesystem.
grub rescue> ls (hd0,msdos7)/
error: unknown filesystem.
grub rescue> ls (hd0,msdos6)/
error: unknown filesystem.
grub rescue> ls (hd0,msdos5)/
error: unknown filesystem.
grub rescue> ls (hd0,msdos3)/
./ ../ lost+found/ etc/ media/ vmlinux.old var/ bin usr/ sbin lib lib64 libx32 boot dev/ home/ proc root/ run/ sys/ tmp/ mnt/ srv/ opt/ vmlinuz initrd.img grub rescue> ls (hd0,msdos2)/
./ ../ lost+found memtest/ A/ X/ B/ rescue/ netinst_d12/ grubx/
grub rescue> ls (hd0,msdos1)/
error: unknown filesystem.
grub rescue> ls (hd0,msdos2)/grubx/
./ ../ grub.cfg fonts/ grubenv locale/ i386-pc/ unicode.pf2 [more elided]
grub rescue> set prefix=(hd0,msdos2)/grubx
grub rescue> set root=hd0,msdos2
grub rescue> ls $prefix
./ ../ grub.cfg fonts/ grubenv locale/ i386-pc/ unicode.pf2 [more elided]
grub rescue> insmod normal
grub rescue> reboot
Unknown command `reboot'.
grub rescue> normal

(system boots)

IMPORTANT: Remember to rename /boot/grubx back to /boot/grub as it should be.

#=====================================================================

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Use grub-rescue on a non-bootable RAID-formatted drive [WAS: Re: status: how to install grub to non-bootable RAID-formatted drive?]

On 1/31/26 19:16, David wrote:

On Sat, 31 Jan 2026 at 09:12, Alexander V. Makartsev<avbetev@gmail.com> wrote:

On 1/31/26 11:28, David wrote:

On Thu, 29 Jan 2026 at 11:34, Alexander V. Makartsev<avbetev@gmail.com> wrote:

I imagine you could type at grub rescue prompt something like this:
grub> set pager=1
grub> insmod normal
grub> insmod part_msdos
grub> insmod diskfilter
grub> insmod mdraid1x
grub> insmod ext2
grub> ls
(proc) (hd0) (hd0,msdos1) (hd0,msdos2) (md/0)
grub> set prefix=(md/0)/boot/grub
grub> set root=(md/0)
grub> linux ($root)/boot/vmlinuz-6.12.63+deb13-amd64 root=/dev/md126
grub> initrd ($root)/boot/initrd.img-6.12.63+deb13-amd64
grub> boot

It won't work because 'grub>' prompt is not the same as 'grub rescue>'
prompt. grub-rescue will have appeared *because* grub cannot find any
"third portion" (including modules normal, part_msdos, diskfilter,
mdraid1x, ext2, and others) so trying to 'insmod' them will fail, as
David Wright explained:

You don't know what you are talking about. This is not the "chicken-egg
problem".
"insmod" commands will work in 'grub>' AND 'grub rescue>' and essential
modules are provided by grub's core image.
"insmod normal" will fail and return "error: disk 'mduuid/...' not
found.", this was expected, because grub needs prefix to be available to
load it.

Hi Alexander,

No, I do "know what I am talking about" on this point, and you are mistaken on this point. Your error is perhaps to assume that what you see on your system is true for every installation.

What you might be overlooking in this case is that 'grub-install' is
designed to create a minimal size core image according to what it detects
to be necessary to boot the system. So if 'grub-install' is not aware of
any RAID on the system, such as when the boot files are not currently on an active RAID system, then it will omit the grub RAID modules when creating
and installing the core image.

If system is on md array, all necessary modules to access it will be
compiled into core image upon grub installation.
I don't get what do you trying to say, because OP's system is obviously
on md array, which means "grub-install" knows about it, which means core
image has everything necessary to access grub prefix and boot the system.
We already reinstalled grub properly inside chroot to be certain of that.
We already checked contents of "grub.cfg" and "fstab" to be certain that "grub-install" did its job properly.
We already seen OP's "ls" output inside "grub rescue>" shoving "(md/0)",
which could only mean that "diskfilter" and "mdraid1x" modules are
present inside grub's core image.

I will demonstrate for you. I have a system here with MBR boot and no RAID.

To enter grub-rescue, I cause a deliberate error by renaming my /boot/grub directory to /boot/grubx, and reboot.

Because that change has now caused the prefix installed into grub core
image to be wrong, I get the grub-rescue prompt.

You've got grub-rescue prompt not because grub can't _access_ the
prefix, but because it couldn't _find_ it. Big difference.
And you was able to find it and boot the system only because all
necessary modules (part_msdos, ext2 in your case) were preloaded from
core image and allowed you to access it.
Notice how you "insmod" them without error message and without something
you called "third portion".
Again, OP's situation is different, his grub core image has all
necessary modules, but he still can't access the filesystem on md array.

Below is a transcript of the grub-rescue session (I retyped it manually).

However, all essential modules, like "part_msdos, diskfilter, mdraid1x,
ext2" are available without prefix and in fact preloaded at boot time.

Line 5 and line 7 of transcript below show you that the diskfilter and mdraid1x modules are not available in this grub-rescue environment, which proves that your above statement is incorrect.

That is the point that I wanted to show you, in TRANSCRIPT PART 1.

You really just wasted your time, trying to prove me something (even
risked your system to do that), because your experiment only shows that, modules "diskfilter" and "mdraid1x" are not essential to boot _your_ system. For OP's system these modules are essential, so his core image has them,
like I said before.
If you don't believe me, test it on VM with two virtual disks.
Create MBR partition table and partition disks equally, make them into
md raid1 array during Debian installation and use that md array as root filesystem, with "/boot" on it.
You can even degrade the md array later by removing one of virtual disks
and observe that VM boots without any complains about degraded md array,
as it should, and without any interaction with "grub>" or "grub rescue>".

--
With kindest regards, Alexander.
Debian - The universal operating system
https://www.debian.org


--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)