| 1 |
Hello again, Rich (and everybody else who answered me). |
| 2 |
|
| 3 |
On Tue, Feb 03, 2015 at 08:36:27AM -0500, Rich Freeman wrote: |
| 4 |
> On Tue, Feb 3, 2015 at 8:14 AM, Alan Mackenzie <acm@×××.de> wrote: |
| 5 |
> > So, what was it that chewed up my RAID configuration so badly that |
| 6 |
> > /dev/md6 got renamed to /dev/md127? Can I change it back to /dev/md6, |
| 7 |
> > somehow? Do I need to bother? |
| 8 |
|
| 9 |
> I ran into similar issues a while back. In my case some of my arrays |
| 10 |
> were using older metadata (which was required at the time to boot |
| 11 |
> without an initramfs). |
| 12 |
|
| 13 |
Older metadata being, presumably, 0.90? I have 0.90 too, also so that my |
| 14 |
kernel will assemble my RAID root partition. I don't won't an initramfs |
| 15 |
either. |
| 16 |
|
| 17 |
> I suspect that either this metadata lacked the info needed for a boot |
| 18 |
> CD to assign the same ID, or perhaps the ID I was using was already |
| 19 |
> allocated somehow and the boot CD chose another one and wrote that ID |
| 20 |
> to the metadata so that it stuck. |
| 21 |
|
| 22 |
Something like this, yes. But the metadata MUST have contained |
| 23 |
"/dev/md6" somewhere - how else could the kernel recreate the right |
| 24 |
device? |
| 25 |
|
| 26 |
> My solution was to move to using UUIDs or labels for everything and |
| 27 |
> not relying on array numbering. This of course requires an initramfs |
| 28 |
> - personally I've found Dracut to be the best one out there. It is |
| 29 |
> just far less prone to breakage when some update causes stuff to move |
| 30 |
> around like this. |
| 31 |
|
| 32 |
But I don't want an initramfs. ;-) Specifying the root partition as |
| 33 |
"/dev/md6" (or, now, "/dev/md127") also feels like the Right Thing. |
| 34 |
|
| 35 |
Anyhow, I've reported this to bugs.gentoo.org as bug #539162. We'll see |
| 36 |
what comes out of it. |
| 37 |
|
| 38 |
> -- |
| 39 |
> Rich |
| 40 |
|
| 41 |
-- |
| 42 |
Alan Mackenzie (Nuremberg, Germany). |
Archives