Andrei Borzenkov composed on 2015-02-01 09:13 (UTC+0300): Thank you for your response.
Felix Miata wrote: ...
md118 = sda8 + sdb8 label: 1md08tmp md119 = sda9 + sdb9 label: 1md09root1 ...
After completing the YaST2 build process, I installed 13.1 on 1md09root1. This is the (condensed) mdadm.conf installation created, with appended the 2 sda/sdb partitions making up each device:
DEVICE containers partitions ARRAY /dev/md/srv10:md-home UUID=99e6... ARRAY /dev/md/srv10:md-isos UUID=637f... # P17 ...
I'd like to get back the orderly simplicity of md0-md9
Do not use meaningful names then. Use md0 - md9 as name (or possibly simply 0 - 9). X in mdX is device minor number which is allocated at runtime; if array name looks like number, mdadm is using it as minor number; otherwise it allocates one from upper half to reduce possibility of collision.
It's already done. I've spent more than 14 hours trying to fix, booting, shutting down, switching the cables back to make more changes, booting again, etc. By the time I get from one end to the other of the mdadm.conf or mdadm man pages, I don't remember enough of what I read to do any good. When I started, I expected the ease YaST gave me in older releases, but the evolved metadata format apparently backfired on me.
Can I simply edit away the hostname portion, sort the balance into partition order, and have the boot process assign device names in predictable sequence each time?
You already have predictable stable unique name that you yourself assigned. Why do you care what minor number device gets?
The unique volume name on partitions being independent of logical order of partitions works for me. The randomization of minors does not. My memory is virtually opposite of eidetic, and growing worse. Logical order that I can recognize helps a lot. It looks like I'm at the point I need to wipe it all and start all over from zero, which means the many days (I bought the disks in November, 2 months after Evergreen support end was announced, then started planning, and got interrupted many times when trying to focus and progress) already invested is lost, with more to be invested, without knowing enough about what went wrong to avoid repeating the same mistake(s). 13.1's emergency shell is broken, so I can't get rdsosreport.txt from it, while 13.2's lsinitrd is broken, vexing my attempts to fix whatever's broken in or missing from the initrd. I tried modprobe raid1; mknod /dev/md2 b 9 2 (md2 is 9,2 on this system), but apparently I don't understand more than I know, with mount doing the bad fs type, yada message trying to mount using it. Dracut's rescue shell has no mdadm in it either. Maybe it would not be that bad yet, if only I could grasp and retain how to get what needs to be in an initrd into it. Having the md devices named as I please works fine, but only as long as I'm in no need to boot from any of them. It seems my transitory hostname could be involved, but attempts to use HOMEHOST <none>/<ignore> have been fruitless. Latest rdsosreport.txt from 13.2: http://fm.no-ip.com/Tmp/SUSE/rdsosreport132big41.txt Latest 13.2 initrd: http://fm.no-ip.com/Tmp/SUSE/initrd-3.16.7-7-desktop (5.4M) Latest 13.1 initrd (1st boot success, none since): http://fm.no-ip.com/Tmp/SUSE/initrd-3.11.6-4-desktop (6.5M) TIA for any help untangling this. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org