On Sat, 31 Jan 2026 at 20:47, Alexander V. Makartsev <[email protected]> wrote: >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. >> 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, Hi Alexander, Ok, listen carefully ... > 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. Possibly not. You are overlooking some relevant factors. 1. The 3TB drive was not in the system when the RAID was created, it was swapped in later. So the initial grub-install when the system was created did not touch that drive. 2. Possibly grub-install was never run while that drive was part of the working RAID. 3. When grub-install was run recently, that drive was not part of a working RAID. So grub-install may not have added the RAID modules into the recently created core image on that drive. These factors are one possible explanation of the latest symptoms that Doc is reporting. > We already checked contents of "grub.cfg" and "fstab" to be certain that > "grub-install" did its job properly. I missed the evidence that led you to that conclusion, so I would like to see the details of that. > 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. That is a good point. But as I've repeatedly stated, I have no experience with RAID or any RAID installations, so I welcome your contribution on those topics. And I don't feel like learning all about RAID just to help solve this problem, because that would be unnecessary when there are others here such as yourself with knowledge about that. >> 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. No, I did not waste my time, because that was not my only goal. As well as progressing the conversation with you, the transcript provides an example method that Doc could use on his drive to provide factual answers to these questions instead of our speculation. I don't mind about being right or wrong, what I am interested in is moving from speculation to tested facts, and I provided a method to do that. Currently, neither you nor I have all the answers to solve Doc's problem. Discussion is beneficial for everyone if it helps to discover a solution. > 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>". Such a test does not include points 1. 2. 3. above. If you want to conduct a VM test that does include these factors, and do that with a 3 TB drive, then that would be interesting to hear what you discover.
