18/09/2011 05:04, Joey L wrote: > Thanks for the info and quick reply. > > My /dev/md0 has rebuilt itself and is okay. > My /dev/md1 is gone after a reboot - and is no longer showing - > I get nothing when i run: > > root@rider:~# mdadm --detail /dev/md1 > mdadm: cannot open /dev/md1: No such file or directory
You could try to examine each members of the array, see if meta-data are found or if everything vanished. You can use "mdadm --examine /dev/sdd1" /dev/md1 not neing found doesn't mean everything is lost, just means it hasn't been detected or assembled at boot time, so udev didn't create the device /dev/md? for it. But maybe the array can be brought back (at least in degraded mode) manually. You are using 1.2 metadata on your arrays, is you mdadm.conf info up to date ? > > > Questions for you: > 1. How do I figure out which drive that made up /dev/md1 DRIVES: > /dev/sdc or /dev/sdc1 and /dev/sdd or /dev/sdd1 is okay to be the > master where I would rebuild the second ?? There is no "master" in a raid1 array, otherwise data wouldn't be truly redundant. A drive is becoming a temporary "gold master" when it is alone in the array (the other one is failed). So regarding your "md1" array sdc1 is the last known working member, this is what you should use to try to start and rebuild the array. When you "--examine" a member of an array, you'll be shown the array UUID it belongs to, and the device UUID (if meta-data are not gone). Personally after creating a raid I always take good note of those informations (outside of the array) in case I need to do "manual" intervention. If you need to boot from a live-cd to recover a damaged system there is no warranty that the array names or array members names will be consistent with what it was on the working system. But the UUID's will. And don't mix up /dev/sd? (the physical disk device) with /dev/sd?? (the partition which is included in the array). There could be only one partition on the disk, but not necessarily, or the raid could be a partitioned on. You have no business using the physical device level to troubleshoot a raid array, only if you want to image a damaged device for later forensic work you'll need to work at disk level. Don't take my word for it, try to: mdadm --examine /dev/sdc You will see no mdadm raid meta-data on it. > > 2. How do I "zero superblocks" a drive ?? I know how to fail, remove and > add to a raid device. mdadm --zero-superblock /dev/sdc1 You have to fail and remove the drive first. You must do that when you break an array and want to later reuse the members in a new array. You should carefully read man mdadm. Unfortunately the raid wiki seems to be down at the moment due to kernel.org problems, hope it's back online soon. https://www.raid.wiki.kernel.org/index.php/Linux_Raid > > 3. Should I use /dev/sdd1 as the master ?? the system marked it as a > spare before. /dev/sdc1 is the last known working member of the array, so I would start with it. But you can try to unplug one or the other device to prevent any further damage to it, and try to start the array in degraded mode from either sdd1 or sdc1, you'll see what works, and what data you can find on it. Be aware that if you restart the array and it is rebuilt from one member, the data on the other will be effectively wiped out. The "--assume-clean" flag could prevent that, but then you'll have no warranty that the data are consistent on the array. Work on a degraded array with only one member for now is my advice. You can try to force the assembling of a degraded or "dirty" array at boot time with the boot option "md-mod.start_dirty_degraded=1" (see "modinfo md_mod"), but don't do that with the two members plugged in, it could further damaged it and compromise your chances to recover from one of the array member. It is by far a better practice for recovery to boot without assembling the array, then manually assemble and run it as needed. > thanks > mjh > > > > Hope it helps. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e75c417.8020...@googlemail.com
