Only reason for this logic is to limit what entries in /proc/partitions
mdadm scans for arrays.
However this seems to break raids in containers (example Intel fakeraids)
as those containers are never scanned for arrays.
(On my system it activates /dev/md/imsm0, but never /dev/md/Gentoo_0 which
is the real RAID with the removed logic)
If someone has something dead-slow they do not want scanned for raids,
it is better if they specify their own mdadm.conf.
If someone finds an example of something that mdadm scans for arrays that
is not supposed to be scanned, we may handle that then.
Make it possible to choose a custom mdadm.conf for your ramdisk.
If not set, no mdadm.conf will be copied, and ramdisk will auto-detect.
This also fixes a regression where genkernel always tried to copy
/etc/mdadm.conf to the ramdisk, failing if it was non-existant.
This makes the ramdisk always mount some kind of /dev,
and then try to move it to the new root.
This unbreaks handling of nodes created pre-udev likefor example lvm does.
This can be considered good practice, likely less chance that nodes
created in the ramdisk disapperes when switching root.
Some applications (mostly debugging/benchmarking) also needs this to
survive the switch_root.
Change vgscan and vgchange so they are done in one go.
Faster since less work for the lvm command.
vgscan is still needed for some cases like dmcrypt where
/etc/lvm/cache is created, but not updated with the unlocked devices.
Sebastian Pipping
Peter Hjalmarsson
craig
Raúl Porcel