Subject: 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, 24 Jan 2026 at 20:42, D. R. Evans <doc.evans@gmail.com> wrote:

David wrote on 1/24/26 11:03 AM:

Hi, thanks for making the effort to communicate well.

I do try, even though I don't always succeed.

Hi again, your ongoing effort motivates me to respond.

[... discussion about ancient methods for creating /dev in chroot ...]

Let's leave that for the other thread, so that this thread can focus on grub-rescue.

I looked at the documentation to which you pointed, and I found it
basically incomprehensible. Unless I missed something, it certainly
didn't seem to give a step-by-step procedure for doing what needs to be
done.

Well, the grub manual [gm] is high quality documentation of amazing free software, and it's what everyone relies on, so it can't be
incomprehensible. If I learned from it, anyone can. It doesn't give
a "step by step procedure", but it does describe everything needed.

But I know how disaster recovery can feel tiring, which makes it hard to understand new things, and I can see you working hard to function in that space, so I'm motivated to try to help with some de-mystification. You
seem well competent to do this, its not hard, you just need an overview and some tips.

The documentation said:

# Inspect the current prefix (and other preset variables):
set
# Find out which devices are available:
ls
# Set to the correct value, which might be something like this:
set prefix=(hd0,1)/grub
set root=(hd0,1)
insmod normal
normal

Saying "set to the correct value, which might be something like" leaves
me just shaking my head, and not having any idea what I'm actually
supposed to type.

Well, that would be the point when you read the [gm] sections that explain
what 'set', 'ls', 'prefix', 'root', 'insmod' and 'normal' do. See [gmp]
link below. But I'll give you a hand to get you started, and I see David
Wright has written a short guide as well. I also found an article [grm]
which illustrates some simple grub-rescue mode operation, but it falls well short of covering everything you need to know.

I'll start with some overview comments before getting into the details.

Some caveats:
- I've no experience with RAID, but I don't think that's going to be an
obstacle to booting this one disk, for reasons explained below.
- I've no experience with EFI, but you've said previously that this is an
MBR system.

The first thing to understand is that you can't do any damage while using
'grub rescue'. Its entire purpose is to recover from when the stored
'prefix' value is wrong, by allowing you to set a temporary value and then contine the boot. Thats what the documented steps above do.

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'

This is an example of good troubleshooting communication, because you've
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. But that's not important right now, because I'm
going to explain to you how to attempt to figure a value that hopefully
will get your system booted). And we can see that your grub is only aware
of two devices (hd0) and (fd0), which is helpful.

How do I know that the 'prefix' value is wrong? This will become clear if
you have a better understanding of how your grub should be working. Please
read "Where GRUB finds things" [wgft] (link below) to save me some writing.

The takeaway from [wgft] is that there are 3 different portions of grub involved. The first portion aka "bootloader" is tiny because it must be smaller than 512 bytes so that it can fit inside the MBR. Its job is just
to find the second portion aka "core image" or "core.img", which
'grub-install' customises for your machine and writes on the disk in some
space that it finds which is outside any filesystem. So what that author
is calling "core.img" is not a file, it has no name, it is just a bunch of bytes somewhere, because existing outside any filesytem it is more likely
to remain in a stable location, and because the bootloader is too small to understand how to navigate filesystems anyway.

So those un-named bytes can be hard to find manually. The good news is that
we know that isn't a problem in your case, because those bytes contain the
code that is displaying your "grub-rescue" prompt. So we know that grub
already found its second portion. What is failing in your case is that grub
is failing to find its third portion aka "modules", which is the various modules that are in the filesystem, typically seen in a /boot/grub
directory. Grub needs that code to be able to continue the boot process.

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.

So, what you need to do is use 'grub-rescue' to explore your filesystems
(as perceived by grub) to find a new value to try for "prefix". The way
this is done is by using the trick of "tab-completion" in the 'grub-rescue' shell.

You need to understand what "tab-completion" is. At link [tcv] is a video demonstrating how it works in a Bash-like shell. Note that it is nothing
to do with the 'ls' command, it is a shell feature. For example, in a Bash shell you could explore any working Linux filesystem by pressing the five
keys:
[:] [space] [/] [tab] [tab]
and the shell will show you some options. You could then press more keys:
[b] [o] [o] [t] [/] [tab] [tab]
and the shell will show you more options, being the names of directory
entries under /boot.

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. Type more, and continue the process until you find
where the grub modules are on your disk. The final result might look
something like (hd0)/boot/grub and when you 'ls' that directory in
grub-rescue you should see the contents of a typical /boot/grub directory. Using that result as an example, you would then
set prefix=(hd0)/boot/grub
set root=hd0
where the 'root' value is just the device in the prefix, assuming your
grub.cfg is typical and your output above is indicative.

Once you have those values set, the "insmod normal" will use them to load
the grub third portion "normal" from the disk. And the "normal" command
will then start running that code.

If you can get the disk to boot once, you can then run 'grub-install <your_device>' and grub should create a new core image with the correct
prefix value that was used during boot. How you then repair your RAID is
a problem that I'm unable to assist with.

Give that a try, and let us know how it goes. I hope I'm right about this, let's find out :)

Links:
[gm] https://www.gnu.org/software/grub/manual/grub/grub.html
[gmp] https://www.gnu.org/software/grub/manual/grub/grub.html#prefix
[grm] https://olinux.net/grub-rescue-mode/
[wgft] https://simonsafar.com/2021/grub/
[tcv] https://www.youtube.com/watch?v=pc3OgxD5IXQ

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