Bug 539162 – install-amd64-minimal-20141204.iso corrupts existing RAID setup, "renaming" /dev/md6 to /dev/md127.

• Product: Gentoo Release Media
• Status: RESOLVED WORKSFORME

[Description Alan Mackenzie 2015-02-06 22:05:47 UTC]

[Description in the summary line and under the following rubrics is adequately complete.]

Reproducible: Didn't try

Steps to Reproduce:
1. Boot from installation CD on a PC already containing a working Gentoo system.  Give the parameter which enables LVM2.
2. In the installation setup, mount various partitions (forgotten whether /dev/md6 was amongst them) to check that the installation kernel can access them.  Generally play around with the system.
3. Remove the installation CD and attempt to reboot into working Gentoo system.
Actual Results:  
At this point there is a kernel panic.  The root partition /dev/md6 no longer exists.  Something in the installation CD has corrupted the RAID setup by "renaming" /dev/md6 to /dev/md127.  This change in device name is permanent.  Nothing else was corrupted or lost, as far as I can tell.

Expected Results:  
The PC should have booted normally; /dev/md6 should have remained unmolested.

/dev/md6 was created on 2012-06-30 with the command:
  # mdadm --create /dev/md6 --level=1 --raid-devices=2 --metadata=0.90 /dev/sda6 /dev/sdb6
.  It is normally assembled by the kernel at boot-up time.

At the time of the corruption, the only other RAID device was /dev/md3, which additionally is managed by LVM2.  This device also has 0.90 metadata.

It would also be nice to learn how to restore /dev/md127 to /dev/md6.  TIA!

[Comment 1 Fernando (likewhoa) 2015-02-06 22:52:35 UTC]

to restore your array just run the assemble command again and just point it to /dev/md6. Show the output of "mdadm -Esv"?

[Comment 2 Jorge Manuel B. S. Vicetto (RETIRED) 2015-02-07 14:04:30 UTC]

The installation medium doesn't "change" device names. The kernel in the installation medium might use different device names, though.
About the issue with mdadm device names, there was (still is?) a genkernel busybox mdadm bug that caused it not to use the minors from the devices and thus /dev/mdX shows up as /dev/md1XX.
Are you sure that you didn't boot a new kernel, built with genkernel, when you booted your system again?

[Comment 3 Alan Mackenzie 2015-02-07 14:54:22 UTC]

(In reply to Jorge Manuel B. S. Vicetto from comment #2)
> The installation medium doesn't "change" device names. The kernel in the
> installation medium might use different device names, though.

"Using" different names isn't a problem.  The problem is when the installation system writes those names into the RAID admin areas on the HDDs.

> About the issue with mdadm device names, there was (still is?) a genkernel
> busybox mdadm bug that caused it not to use the minors from the devices and
> thus /dev/mdX shows up as /dev/md1XX.
> Are you sure that you didn't boot a new kernel, built with genkernel, when
> you booted your system again?

Yes.  I've never used genkernel in my life.  I did use busybox's mdev for a few months in 2012, though.

The kernel which panicked due to the loss of /dev/md6 was 3.8.13, configured by hand a (shockingly) long time ago.  I don't use an initramfs.

[Comment 4 Alan Mackenzie 2015-02-07 15:01:15 UTC]

(In reply to Fernando (likewhoa) from comment #1)
> to restore your array just run the assemble command again and just point it
> to /dev/md6. Show the output of "mdadm -Esv"?

Thanks for the tip!  I used the assemble command as follows:
  # mdadm --assemble /dev/md6 --super-minor=127 --update=super-minor
, which (after some chrooting and fixing my boot manager configuration) has restored my /dev/md6.

[Comment 5 Jorge Manuel B. S. Vicetto (RETIRED) 2017-02-06 21:35:40 UTC]

No more reports, so I'm going to close this as WORKSFORME.