On 2021-11-12 at 11:42, Gene Heskett wrote: > On Friday 12 November 2021 10:18:07 Dan Ritter wrote: > >> Gene Heskett wrote:
>> > Not in the stretch man page. And its sounding as if I should do >> > that during the bullseye install to get the more capable mdadm, but >> > will the devices have the same names? With the reputation for >> > volatility of device names a mistake there could destroy 23 years of >> > data. >> >> After you have set them up, mdadm.conf has things like this: >> >> ARRAY /dev/md/0 metadata=1.2 name=debian:0 >> UUID=aeac6271:676b1852:04f077d6:fcd285d6 ARRAY /dev/md/1 metadata=1.2 >> name=debian:1 UUID=d74ff881:2e966c37:ec6ef1ec:75b8cdce ARRAY /dev/md/2 >> metadata=1.2 name=debian:2 UUID=7c56166b:0d5aed8b:a9d03c45:e9b8080c > That doesn't appear to be true. I have run the create which seemed to be > ok, then mkfs -text4 /dev/md0, then mounted it at /home2. > > But /etc/mdadm/mdadm.conf doesn't yet have any of that, only this: <snip> > Which from your descriptions is not complete. No ARRAY statements at > all. What did I do wrong? Not sure if you did anything wrong, but now that you've done the --create operation, you might try running # mdadm --detail --scan again. You might see that it now outputs definition lines like the ones Dan presented as examples; if so, you can append those lines to mdadm.conf, and if I'm not mistaken the result should (in theory) be valid. > And again, I don't trust UUID's as moving a drive cable to a > different socket has invalidated the whole lot of them once before. Eh? That doesn't make any sense at all. The UUID is supposed to be stored *on* the drive, so that it is independent of connection. I can testify that this has been the case in my experience with mdadm RAID-array UUIDs. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
