Re: [gentoo-user] Re: raid1 grub ext4

[Florian Philipp <lists@binarywings.net>]

[-- Attachment #1: Type: text/plain, Size: 3611 bytes --]

Am 14.04.2011 17:07, schrieb James:
> Florian Philipp <lists <at> binarywings.net> writes:
> 
> 
>> I don't think the missing partition table is your problem.
> 
> OK, let's assume you are correct, ignoring .....
> 
>> However, you might be onto something with the changed sector offset. But
>> I don't know enough of this to help you.
> 
> Well if I have to reformat I look everything on the install.
> Not ready to start over yet.....
> So after a fresh reboot I see:
> livecd ~ # cat /proc/mdstat
> Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
> md125 : active (auto-read-only) raid1 sdb3[1] sda3[0]
>       1948226512 blocks super 1.2 [2/2] [UU]
> md126 : active (auto-read-only) raid1 sda2[0] sdb2[1]
>       5022708 blocks super 1.2 [2/2] [UU]
> md127 : active (auto-read-only) raid1 sda1[0] sdb1[1]
>       262132 blocks super 1.2 [2/2] [UU]
> 
> If you look at previous posts of mine on the md<part>
> names, and focus on the sized, you'll see something
> very troubling...
> 
> The minimal CD keeps using the md125-127 names but assigns
> them to the different partitions:
> NOW
> /boot is: md127 : active (auto-read-only) raid1 sda1[0] sdb1[1]
>       262132 blocks super 1.2 [2/2] [UU]
> 
> /     is md125 : active (auto-read-only) raid1 sdb3[1] sda3[0]
>       1948226512 blocks super 1.2 [2/2] [UU]
> 
> swap  is md126 : active (auto-read-only) raid1 sda2[0] sdb2[1]
>       5022708 blocks super 1.2 [2/2] [UU]
> 
> Something is morphing the numbers each time I reboot
> with minCD....
> 
> So no what I put in /etc/fstab, it's going to be wrong.
> 

I guess you can resort to labels or UUIDs. The real problem is the
root=... parameter for the kernel. That's why I suggested overriding the
auto detection and define the raids explicitly on the kernel parameter list.

> grub cannot find the partition with the kernel? OR
> is this not a problem? 
> 

Wild guess: Does grub maybe rely on the partition type to identify file
system? Does it work if you change the type from 0xfd to standard 0x82?

> Plus, since  I'm never able to write the grub stuffage to the
> MBR, grub nor the kernel every run.....
> 

As a workaround to get your system into a usable state, you can still
try to put /boot on a USB stick.

In the past, I've also had a system where grub (whole /boot except
kernel) was located on a floppy and then located the kernel file on the
HDD. You could try this in order to find out whether an working grub
still has trouble with your file system.

> after rebooting I tried this step to correct for the metadata
> problem you previously posted about:
> 
> mdadm --create /dev/md1 --level=1 --raid-devices=2 --metadata=0.90 /dev/sda1
> /dev/sdb1
> mdadm: super0.90 cannot open /dev/sda1: Device or resource busy
> mdadm: /dev/sda1 is not suitable for this array.
> mdadm: super0.90 cannot open /dev/sdb1: Device or resource busy
> mdadm: /dev/sdb1 is not suitable for this array.
> 
> mdadm --create /dev/md127 --level=1 --raid-devices=2 --metadata=0.90 /dev/sda1
> /dev/sdb1
> mdadm: super0.90 cannot open /dev/sda1: Device or resource busy
> mdadm: /dev/sda1 is not suitable for this array.
> mdadm: super0.90 cannot open /dev/sdb1: Device or resource busy
> mdadm: /dev/sdb1 is not suitable for this array.
> 

Are you sure sda1 and sdb1 are not in use? Did the kernel activate the
already present RAID? Then you have to deactivate it. Use
mdadm --stop /dev/md*

Additionally, check that you did not mount sda1 or sdb1 by accident.

Hope this helps,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]