On 1/31/26 19:16, David wrote:
On Sat, 31 Jan 2026 at 09:12, Alexander V. Makartsev<[email protected]> wrote:
On 1/31/26 11:28, David wrote:
On Thu, 29 Jan 2026 at 11:34, Alexander V. Makartsev<[email protected]> 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
