On 1/28/26 02:32, D. R. Evans wrote:
...
It turns out that the BIOS on the computer doesn't seem to provide any
way to boot from USB. The best I can do, as far as I can tell, is to
create a live DVD and boot from that.
So I have booted from a live CD (which is very slow, but does
eventually succeed), and made sure that the only hard drive in the
machine is the RAID device that I am trying to fix.
That is strange, how old is your hardware? When you mentioned 2013 I was
thinking 4th gen Intel CPU and Haswell-era hardware, which should
support USB-boot.
What's model and make of your motherboard?
This could be another clue, because we are dealing with an old BIOS, MBR
partition table, which has 2TB boundary limit and 3TB disk.
After looking at the output you sent so far, it is possible that grub
has nothing to do with the problems you have.
Grub seems to identify every piece of the puzzle correctly and loads all
necessary modules from its core image to do that.
It is starting to look a lot like a hardware incompatibility between old
BIOS, ICH, MBR and 3TB Disk with advanced format.
Can you test this theory by trying to boot from this disk using another
possibly newer motherboard?
...
_Exactly_ what chroot command do you want me to type at this point?
I am sorry I wasn't more clear. What I meant to say is that you have to
get the output data from the OS you trying to rescue, not the host OS.
In other words, after you change root "/etc/fstab" will point to fstab
on the RAID disk you trying to rescue, and if you don't it will point to
fstab of the host system on non-RAID disk.
So "to chroot" means the same sequence of commands as before, but
without grub-install:
mkdir /tmp/RFS
mount /dev/md126 /tmp/RFS #Mount root filesystem
mount --bind /dev /tmp/RFS/dev #Mount bind real /dev to populate
chroot-ed /dev
mount --bind /proc /tmp/RFS/proc #Mount bind real /proc to
populate chroot-ed /proc
mount --bind /sys /tmp/RFS/sys #Mount bind real /systo populate
chroot-ed /sys
chroot /tmp/RFS /usr/bin/bash #Change root into directory /tmp/RFS
Now you can issue those commands and get output:
cat /etc/fstab
cat /boot/grub/grub.cfg | grep -iE -- "--set=root|root=|insmod"
At this point, you can also enable debug mode to maybe get some more
information from grub at boot time:
grub-editenv - set pager=1
grub-editenv - set debug='kern init modules device disk drive drivemap'
It could be helpful to regenerate initramfs and reinstall grub once again:
update-initramfs -c -k all
dpkg-reconfigure grub-pc #Install grub to /dev/sda only, of
course after checking that /dev/sda is the 3TB disk you want to rescue.
"dpkg-reconfigure grub-pc" will complain about missing disks on the
arrays, but will complete the install. I've tested it on the VM and boot
was successful.
To exit chroot and disassemble it:
exit #Exit chroot
umount /tmp/RFS/dev
umount /tmp/RFS/proc
umount /tmp/RFS/sys
umount /tmp/RFS
...
That's the next thing to try to do, now that I have Internet access
back so that I can download and study the documents.
Just some ideas, there are more options to try, but they are extremely
risky and complicated, so if you want to try any of them, you have to
make reliable backups of your data first.
I am thinking about removing completely dead array on /dev/sda1, and
repurpose /dev/sda1 to make it a simple 16GB volume with ext3 filesystem
and move "/boot" to it.
I'm calling md127 array on /dev/sda1 dead, because apparently md127 only
has one drive assigned to it and that drive is assigned as spare, so
that array has no data at all.
Maybe dead array somehow confuses grub and its mdraid1x module during
boot time and its removal will fix the problem.
Another option to try is to use an old disk of smaller size, 180GB or
250GB if you have it, and use it just to boot the system and this way
defeat possible hardware incompatibility with BIOS and MBR.
Or you could try to convert MBR partition table to GPT partition table
to possibly improve compatibility with grub and 3TB disk, but there
could be some compatibility problems with an old BIOS and GPT.
Maybe it will be better to reinstall OS on another disk, with GPT
partition table (if the new disk will be larger than 2TB) and migrate
the data from 3TB disk.
None of these are simple tasks and they are very difficult to do over
email...
--
With kindest regards, Alexander.
Debian - The universal operating system
https://www.debian.org
