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