On Tuesday 22 Oct 2013 08:10:18 Nicolas Sebrecht wrote: > The 21/10/13, Mick wrote: > > I'm fast gravitating towards this option ... > > > > Although with metadata 0.90 I was able to progress with the installation > > (after I deselected the swap partitions) the grub-install script wanted > > to install in /dev/md127p1 but it failed. I had to override the Ubuntu > > installer since I could only install grub in the /dev/md127 block > > device. > > Which is the one we expect. /dev/md127p1 is the first partition of > /dev/md127.
Right, although Ubuntu's installer would point only to /dev/md127p1. I had to ask it to not install GRUB in the MBR (why would it choose /dev/md127p1 as the device where the MBR resides is another matter) which then allowed me to edit the entry and point it to /dev/md127. Pointing GRUB installer to /dev/sda or sdb failed (no filesystem found). > > Either way, it won't boot again. Now it stays on a blank screen, no > > error at all shown. > > I don't understand why this blank screen. Or do you mean a black screen? Yes, sorry, poor choice of words the colour of the screen is black, and the content blank (well, there is a horizontal, non-flashing cursor at the top left of the screen). > > I'll have another go with sysrescueCD to see if I install grub on > > /dev/sda and /dev/sdb and if this does not work either, > > It should work. Linux software RAID is assembled once the kernel is up > and running. Before, the system boot as usual on a single disk. Though, > I'm not sure how mdadm will handle the disk change behind his back. Yes, it will! :-) OK, having tried a couple of options this is what I have concluded. Superblock with metadata 0.90 is written at the front of the disk. No need to partition each disk separately, because any partitions created on /dev/md0 also show up on each disk, i.e. the partition table created on /dev/md0 seems to be readily recognised on each /dev/sda & sdb disks, as can be verified with fdisk -l. Installing grub on /dev/sda and /dev/sdb is a straight forward exercise either with the Ubuntu installer, or afterwards once booted into the new installation with sysrescueCD. With any other metadata format things are more complicated. This may be because the location of the metadata changes (not always at the start of the disk) or because the format is different and the kernel doesn't deal with it natively. Not sure and it doesn't matter. This is what I did to be able to use mdadm -e 1.2, which is the default metadata format these days: Boot with sysrescueCD to create the array and partitions on it ============================================================== mdadm --create --auto=mdp --verbose /dev/md0 --level=mirror --raid-devices=2 \ /dev/sda /dev/sdb Then fdisk /dev/md0 and create 4 partitions. Leave them all with the default linux type of 83 (unless you want to use some fs exotica here). Then 'fdisk /dev/sda' which will create an MSDOS partition table automatically, in case the disk doesn't yet have a partition table on it. Then I created one primary partition accepting the default start and end values offered by fdisk. Repeat for /dev/sdb. Create fs on the RAID array: =========================== 'mkfs.ext4 -c -L <label_name> /dev/md0p1' and repeat for each partition on the RAID except for the swap partition (if you have created one for this purpose). Boot with Ubuntu server CD to install the OS: ============================================ Go through the tedious installation process; yeah, I know - it is faster than Gentoo, but it *feels* more tedious to me! :p You'll find that the fs and labels are not recognised by Ubuntu's partition manager. Select each RAID partition (except swap) and set a fs plus a mount point. These are used by the installer to populate the fstab with. Leave the partitions unformatted and ignore any warnings that come up later when you write these changes on disk. Continue with the installation until it is time to install GRUB. The installer will choose /dev/md127p1. Select to *not* install GRUB in the MBR, which will allow you to edit the drive entry. Choose /dev/md127 and complete the installation. Format a swap partition on the RAID: =================================== Reboot with sysrescueCD, use fdisk /dev/md0 (that's how it will be recognised by sysrescueCD) and change the fs type of the swap partition to 82. Then, 'mkswap -c -l swap /dev/md0p2' or whichever partition you have your swap on. Edit /etc/fstab to include your new swap partition. I don't know why Ubuntu's installer would not accept the swap partition on a RAID1 device, but this was the work around I used. Install GRUB on each disk: ========================= Reboot sysrescueCD, but now use the alternative option to boot into a Linux OS on the disk. It will probe the disks, assemble the RAID1 array and boot into Ubuntu OS. Install grub on /dev/sda and /dev/sdb - no need to stop the array. Then 'update-initramfs -u' and from then on you can reboot into your new installation. Note, if you get a drive failure, you will need to reinstall grub in the MBR of the new disk. I've written all this from memory so please correct any errors I've made. The problem (at least with grub2 which is all that I tried) is that the grub installer does not take kindly to installing itself on the MBR of disks which are partitionless and the position of the RAID metadata on the disk messes up GRUB's ability to find the partition table. I thought that creating a partition table alone will stop it having a fit, but ultimately the creation of an empty partition with fd partition type was necessary. I'm posting this in the odd chance that anyone would like to run a RAID1 with RAID partitions on a single RAID device, with no LVM. It makes removing/adding a disk a single line command, which reduces the likelihood of operator error for the users I have in mind for this particular implementation. Thanks again for your help! :-) -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
