Re: [gentoo-user] Re: [O/T] RAID help - now won't boot

[Mick <michaelkintzios@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 6208 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]