On Thu, Apr 21, 2016 at 10:00 PM, Chris Murphy <lists@colorremedies.com> wrote:
On Wed, Apr 20, 2016 at 6:04 PM, Felix Miata <mrmazda@earthlink.net> wrote:
Thread https://lists.opensuse.org/yast-devel/2016-04/msg00019.html explains my situation (I hope). YaST2 simply does not support creating in a degraded state.
As a consequence, apparently I must use mdadm. Its man page is a mile long. I'm having a hard time determining what is required to do what I wish done, prepare a disk with 10 degraded md devices, in advance on one machine, for subsequent 42.1 and TW installation in another machine, minimizing downtime in the target machine. My proposed creation commands are as follows:
mdadm -Cv /dev/md0 -e 1.2 --homehost=fi965 -l 1 -N r130tmp -n /dev/sdb8 missing mdadm --create /dev/md1 --metadata=1.2 --homehost=fi965 --level=1 --name=r131root --raid-devices=/dev/sdb9 missing mdadm --create /dev/md2 --metadata=1.2 --homehost=fi965 --level=1 --name=r132root --raid-devices=/dev/sdb10 missing mdadm --create /dev/md3 --metadata=1.2 --homehost=fi965 --level=1 --name=r133root --raid-devices=/dev/sdb11 missing mdadm --create /dev/md4 --metadata=1.2 --homehost=fi965 --level=1 --name=r134root --raid-devices=/dev/sdb12 missing mdadm --create /dev/md5 --metadata=1.2 --homehost=fi965 --level=1 --name=r135srv --raid-devices=/dev/sdb13 missing mdadm --create /dev/md6 --metadata=1.2 --homehost=fi965 --level=1 --name=r136ulcl --raid-devices=/dev/sdb14 missing mdadm --create /dev/md7 --metadata=1.2 --homehost=fi965 --level=1 --name=r137home --raid-devices=/dev/sdb15 missing mdadm --create /dev/md8 --metadata=1.2 --homehost=fi965 --level=1 --name=r138pub --raid-devices=/dev/sdb16 missing mdadm --create /dev/md9 --metadata=1.2 --homehost=fi965 --level=1 --name=r139isos --raid-devices=/dev/sdb17 missing
I find the mdadm man page entirely unclear whether I should want the partitions to be of type 0xDA or 0xFD.
Strictly speaking is should be 0xDA for mdadm metadata 1.x and 0xFD for mdadm metadata 0.9. The former uses detection/assembly in the initramfs and the latter uses kernel autodetect which is deprecated but because no regressions are allowed, it stays in the kernel as is I guess forever. The problem is I think only fdisk supports 0xDA, and GNU parted doesn't support it nor does it support arbitrary OStype codes.
So in practice it seems to be 0xFD and no one dies, but there are probably edge cases where it could cause trouble. Mainly comment 5. https://bugzilla.redhat.com/show_bug.cgi?id=1118065
Due in large part to this kind of nonsense, we in effect have an artificial shortage of GUIDs if parted is the partition tool. I'd rather like to see parted just pass silently into the night. http://lists.alioth.debian.org/pipermail/parted-devel/2014-November/004593.h... -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org