Re: status: how to install grub to non-bootable RAID-formatted drive?

["Alexander V. Makartsev" <avbetev@gmail.com>]

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 /sys to 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