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
signature.asc
Description: OpenPGP digital signature
