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
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 ?
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
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
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 .