On Thursday 28 May 2015 15:36:04 I wrote: > On Thursday 28 May 2015 08:44:27 Rich Freeman wrote: > > With an approach like yours, mdadm will attempt to create md1 by > > looking ONLY at sda1 and sdb1, and if that pair forms a valid array it > > is started, and if not it is not. If you add a new drive to your > > system or for whatever reason the kernel/udev rules change a little or > > some race condition changes a little then your devices might get > > different names, and the array will not be assembled. > > Hmm. I wonder if that's what's happening to me. Perhaps I'd better adopt > UUIDs then, once I work out what mine are. Thanks for the advice.
I've found blkid, which tells me the UUIDs of my various devices, thus: # blkid /dev/md7 /dev/md7: UUID="ycGMf9-hEP2-tjT4-AtkJ-n8RI-pZ44-RqvlEY" TYPE="LVM2_member" Two odd things: 1. /dev/md7 is the physical volume in which logical volumes are defined, so I'm surprised to see TYPE="LVM2_member". 2. There is no entry corresponding to /dev/md7 under /dev/disk/by-uuid, though /dev/md1 and /dev/md5 do have entries there [1]. To recap, md1 and md5 are raid-1 with metadata < 1.0; they contain extN file-systems; md7 has metadata > 1.0 and is a container for 15 logical volumes, each of which has an extN file-system and is mounted somewhere under / (/usr is not among them; it's in the root file-system). What should I be doing about this? [1] For reference, here's the complete list of entries under /dev/disk/by- uuid, minus the date etc: 1bb4ba53-677a-4a0e-b737-f3e274f0e71e -> ../../sda2 1e20e3e6-e218-485b-b5ff-be85a287e364 -> ../../sda3 3a2a6e94-a6f0-4479-ae87-44887946148c -> ../../sda6 3befff76-2a0e-49fa-9e6f-2bd0ed73cf31 -> ../../md5 43e655ca-a6ef-4931-99b6-3aa2ad6c30cb -> ../../sda8 443ae151-0dd5-47a5-9ff6-56cc1027b4f7 -> ../../dm-3 47b057a0-3454-4777-8b53-ae5d240b608c -> ../../dm-11 47fe6d95-38be-4581-983c-a6368bd085b2 -> ../../dm-6 53f0c9c2-c21f-4c26-942d-8760e0697fe4 -> ../../dm-9 72b063b2-76bd-4080-aca0-f0109c1ab25d -> ../../dm-4 8e2a7e68-ac48-4aa2-9d33-64fd5ffbe759 -> ../../dm-1 94612986-3a94-4de0-85b4-3ee822dca0ef -> ../../dm-8 96ba30f0-dc69-4083-ab76-df117432bfae -> ../../sdb2 b24e7a6f-8f27-420b-aed5-bc1272ba4856 -> ../../dm-12 c05dab85-aff2-4402-ae91-7d9097e68206 -> ../../sdb8 c1145ff8-f3c0-48ad-a4fe-50330280be69 -> ../../dm-5 d0f6c604-2ef9-4812-afbf-5fd6965201e2 -> ../../md1 d531c442-7a7f-4595-a4f3-4e7416b3ec47 -> ../../dm-13 d66bad37-84d6-4cf7-9414-3d9535261c41 -> ../../dm-2 db56ddb3-3106-40fc-8345-d92a2354eb58 -> ../../dm-0 e69863b9-8fcd-4d7a-b94f-64baa3a77852 -> ../../sdb3 e7ed40e0-826e-406d-bc5a-5e5b9ef37434 -> ../../dm-10 ee1f1925-3e2b-4964-9ad5-248fff623b3c -> ../../sdb6 ee39723d-b950-4d00-8c8e-9dac75fe478c -> ../../dm-7 (It would have been nice to sort on the final field but I can't see how to do that.) I assume that the ../../dm-N links refer to the LVs - there are 15 of them. md7 is conspicuous by its absence. This seems like a problem to me, and it may account for /dev/md7 sometimes not being started at boot time. -- Rgds Peter
