problem with boot from raid - How To Set Up Software RAID1 on a running system (etch)

Discussion in 'HOWTO-Related Questions' started by Marsbar, Sep 3, 2008.

  1. Marsbar

    Marsbar New Member

    Hi

    I'm trying to follow the instructions at http://www.howtoforge.com/software-raid1-grub-boot-debian-etch but I'm hitting a brick wall at the point of first reboot: whatever I do the machine comes up with its root partition as /dev/sda2 (the original root) not /dev/md1 (the root raid partition). This means I can't add sda2 to the RAID array because it's in use, which scuppers the whole thing, really :(

    I've looked at the initrd image and it seems like it's loading the right modules; I've even added the raid module to the manual module list but it made no difference.

    This is compounded in that I can't see the machine boot - it's a remotely hosted box and I can only get one KVMoIP session a month without paying for it, so I'd rather not do the KVM thing unless I absolutely have to.

    I've about 13 years experience with various flavours of Linux (mostly Slackware, Redhat and Debian) but I've never dealt with grub, debian's initrd (which seems massively overcomplex) or software RAID before, so I'm feeling a bit lost.

    Any help much appreciated!

    Geoff
     
  2. falko

    falko Super Moderator

    What's in /boot/grub/menu.lst, /etc/fstab, and /etc/mtab, and what are the outputs of
    Code:
    cat /proc/mdstat
    and
    Code:
    fdisk -l
    ?
     
  3. Marsbar

    Marsbar New Member

    Thanks for the reply!

    Code:
    $ cat /boot/grub/menu.lst
    # menu.lst - See: grub(8), info grub, update-grub(8)
    #            grub-install(8), grub-floppy(8),
    #            grub-md5-crypt, /usr/share/doc/grub
    #            and /usr/share/doc/grub-doc/.
    
    ## default num
    # Set the default entry to the entry number NUM. Numbering starts from 0, and
    # the entry number 0 is the default if the command is not used.
    #
    # You can specify 'saved' instead of a number. In this case, the default entry
    # is the entry saved with the command 'savedefault'.
    # WARNING: If you are using dmraid do not change this entry to 'saved' or your
    # array will desync and will not let you boot your system.
    default         0
    fallback        1
    
    ## timeout sec
    # Set a timeout, in SEC seconds, before automatically booting the default entry
    # (normally the first entry defined).
    timeout         5
    
    # Pretty colours
    color cyan/blue white/blue
    
    ## password ['--md5'] passwd
    # If used in the first section of a menu file, disable all interactive editing
    # control (menu entry editor and command-line)  and entries protected by the
    # command 'lock'
    # e.g. password topsecret
    #      password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/
    # password topsecret
    
    #
    # examples
    #
    # title         Windows 95/98/NT/2000
    # root          (hd0,0)
    # makeactive
    # chainloader   +1
    #
    # title         Linux
    # root          (hd0,1)
    # kernel        /vmlinuz root=/dev/hda2 ro
    #
    
    #
    # Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST
    title           Debian GNU/Linux, kernel 2.6.18-6-686
    root            (hd1,1)
    kernel          /boot/vmlinuz-2.6.18-6-686 root=/dev/md1 ro debug
    initrd          /boot/initrd.img-2.6.18-6-686
    savedefault
    
    title           Debian GNU/Linux, kernel 2.6.18-6-686
    root            (hd0,1)
    kernel          /boot/vmlinuz-2.6.18-6-686 root=/dev/sda2 ro quiet
    initrd          /boot/initrd.img-2.6.18-6-686
    savedefault
    
    ### BEGIN AUTOMAGIC KERNELS LIST
    ## lines between the AUTOMAGIC KERNELS LIST markers will be modified
    ## by the debian update-grub script except for the default options below
    
    ## DO NOT UNCOMMENT THEM, Just edit them to your needs
    
    ## ## Start Default Options ##
    ## default kernel options
    ## default kernel options for automagic boot options
    ## If you want special options for specific kernels use kopt_x_y_z
    ## where x.y.z is kernel version. Minor versions can be omitted.
    ## e.g. kopt=root=/dev/hda1 ro
    ##      kopt_2_6_8=root=/dev/hdc1 ro
    ##      kopt_2_6_8_2_686=root=/dev/hdc2 ro
    # kopt=root=/dev/sda2 ro
    
    ## default grub root device
    ## e.g. groot=(hd0,0)
    # groot=(hd0,1)
    
    ## should update-grub create alternative automagic boot options
    ## e.g. alternative=true
    ##      alternative=false
    # alternative=true
    
    ## should update-grub lock alternative automagic boot options
    ## e.g. lockalternative=true
    ##      lockalternative=false
    # lockalternative=false
    
    ## additional options to use with the default boot option, but not with the
    ## alternatives
    ## e.g. defoptions=vga=791 resume=/dev/hda5
    # defoptions=
    
    ## should update-grub lock old automagic boot options
    ## e.g. lockold=false
    ##      lockold=true
    # lockold=false
    
    ## Xen hypervisor options to use with the default Xen boot option
    # xenhopt=
    
    ## Xen Linux kernel options to use with the default Xen boot option
    # xenkopt=console=tty0
    
    ## altoption boot targets option
    ## multiple altoptions lines are allowed
    ## e.g. altoptions=(extra menu suffix) extra boot options
    ##      altoptions=(single-user) single
    # altoptions=(single-user mode) single
    
    ## controls how many kernels should be put into the menu.lst
    ## only counts the first occurence of a kernel, not the
    ## alternative kernel options
    ## e.g. howmany=all
    ##      howmany=7
    # howmany=all
    
    ## should update-grub create memtest86 boot option
    ## e.g. memtest86=true
    ##      memtest86=false
    # memtest86=true
    
    ## should update-grub adjust the value of the default booted system
    ## can be true or false
    # updatedefaultentry=false
    
    ## ## End Default Options ##
    
    title           Debian GNU/Linux, kernel 2.6.18-6-686
    root            (hd0,1)
    kernel          /boot/vmlinuz-2.6.18-6-686 root=/dev/sda2 ro
    initrd          /boot/initrd.img-2.6.18-6-686
    savedefault
    
    title           Debian GNU/Linux, kernel 2.6.18-6-686 (single-user mode)
    root            (hd0,1)
    kernel          /boot/vmlinuz-2.6.18-6-686 root=/dev/sda2 ro single
    initrd          /boot/initrd.img-2.6.18-6-686
    savedefault
    
    title           Debian GNU/Linux, kernel 2.6.18-5-686
    root            (hd0,1)
    kernel          /boot/vmlinuz-2.6.18-5-686 root=/dev/sda2 ro
    initrd          /boot/initrd.img-2.6.18-5-686
    savedefault
    
    title           Debian GNU/Linux, kernel 2.6.18-5-686 (single-user mode)
    root            (hd0,1)
    kernel          /boot/vmlinuz-2.6.18-5-686 root=/dev/sda2 ro single
    initrd          /boot/initrd.img-2.6.18-5-686
    savedefault
    
    ### END DEBIAN AUTOMAGIC KERNELS LIST
    
    Note that I added the "quiet" option to the second boot stanza so I could check whether that one is actually being chosen or if something else is forcing the root to sda2. quiet does appear in dmesg, so it really is using stanza id 1.

    Code:
    $ cat /etc/fstab
    # /etc/fstab: static file system information.
    #
    # <file system> <mount point>   <type>  <options>       <dump>  <pass>
    proc            /proc           proc    defaults        0       0
    #/dev/sda2       /               ext3    defaults,errors=remount-ro 0       1
    #/dev/sda1       none            swap    sw              0       0
    /dev/md1        /               ext3    defaults,errors=remount-ro 0       1
    /dev/md0        none            swap    sw              0       0
    
    Code:
    $ cat /etc/mtab
    /dev/md1 / ext3 rw,errors=remount-ro 0 0
    tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
    proc /proc proc rw,noexec,nosuid,nodev 0 0
    sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
    procbususb /proc/bus/usb usbfs rw 0 0
    udev /dev tmpfs rw,mode=0755 0 0
    tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
    devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
    
    Code:
    $ cat /proc/mdstat
    Personalities : [raid1]
    md1 : active raid1 sdb2[1]
          154336384 blocks [2/1] [_U]
    
    md0 : active raid1 sda1[0] sdb1[1]
          1951744 blocks [2/2] [UU]
    
    unused devices: <none>
    
    Code:
    # fdisk -l
    
    Disk /dev/sda: 160.0 GB, 160041885696 bytes
    255 heads, 63 sectors/track, 19457 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    
       Device Boot      Start         End      Blocks   Id  System
    /dev/sda1               1         243     1951866   82  Linux swap / Solaris
    /dev/sda2             244       19457   154336455   83  Linux
    
    Disk /dev/sdb: 160.0 GB, 160041885696 bytes
    255 heads, 63 sectors/track, 19457 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    
       Device Boot      Start         End      Blocks   Id  System
    /dev/sdb1               1         243     1951866   fd  Linux raid autodetect
    /dev/sdb2             244       19457   154336455   fd  Linux raid autodetect
    
    Disk /dev/md0: 1998 MB, 1998585856 bytes
    2 heads, 4 sectors/track, 487936 cylinders
    Units = cylinders of 8 * 512 = 4096 bytes
    
    Disk /dev/md0 doesn't contain a valid partition table
    
    Disk /dev/md1: 158.0 GB, 158040457216 bytes
    2 heads, 4 sectors/track, 38584096 cylinders
    Units = cylinders of 8 * 512 = 4096 bytes
    
    Disk /dev/md1 doesn't contain a valid partition table
    
     
  4. Marsbar

    Marsbar New Member

    It just occurred to me: would it be because the /boot folder isn't on a separate partition? So /dev/sdb2 would be in use at boot time and therefore unable to be used as part of /dev/md1 to mount as root=?

    I would have expected that the fact that the initrd is copied to ram using initramfs ought to get around that, but I might try repartitioning sdb to have a separate /boot and see what happens.

    That's unless you can see something obviously wrong with my setup above, of course!

    Cheers

    Geoff
     
  5. falko

    falko Super Moderator

    That's what has just come to my mind as well.

    That's what I'd suggest.
     
  6. Marsbar

    Marsbar New Member

    Solved

    Well the short answer to that is, No.

    The long answer is that the problem was actually because my hosting provider hadn't enabled the additional drive in the BIOS. So while Linux could see the drive (because it ignores the BIOS and goes straight to the hardware) grub could not.

    Once enabled in the BIOS everything just worked (except I forgot to run grub properly once I wiped /dev/sda2 ready for the repartitioning and had to boot up using a Live CD to point /sda's MBR at /dev/sdb2 instead), so many thanks for the HOWTO, if it weren't for the engineer who put in my drive it would have worked flawlessly :).
     

Share This Page