Thanks for the suggestion: ============================= hbarta@oak:~$ sudo fdisk -luc /dev/sd[bc] Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes 255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdb1 2048 20973567 10485760 fd Linux raid autodetect /dev/sdb2 20973568 3907029167 1943027800 fd Linux raid autodetect Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes 255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdc1 2048 20973567 10485760 fd Linux raid autodetect /dev/sdc2 20973568 3907029167 1943027800 fd Linux raid autodetect hbarta@oak:~$ ============================= Everything seems OK as far as I can see. thanks, hank On Thu, Jan 27, 2011 at 5:56 AM, Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx> wrote: > Hi, > > Show fdisk -l on both disks, are the partitions type 0xfd Linux raid Auto > Detect? If not, you will have that exact problem. > > Justin. > > On Wed, 26 Jan 2011, Hank Barta wrote: > >> I followed the procedure below. Essentially removing one drive from a >> RAID1, zeroing the superblock, repartitioning the drive, starting a >> new RAID1 in degraded mode, copying over the data and repeating the >> process on the second drive. >> >> Everything seemed to be going well with the new RAID mounted and the >> second drive syncing right along. However on a subsequent reboot the >> RAID did not seem to come up properly. I was no longer able to mount >> it. I also noticed that the resync had restarted. I found I could >> temporarily resolve this by stopping the RAID1 and reassembling it and >> specifying the partitions. (e.g. mdadm ---assemble /dev/md2 /dev/sdb2 >> /dev/sdc2) At this point, resync starts again and I can mount >> /dev/md2. The problem crops up again on the next reboot. Information >> revealed by 'mdadm --detail /dev/md2' changes between "from boot" and >> following reassembly. It looks like at boot the entire drives >> (/dev/sdb, /dev/sdc) are combined into a RAID1 rather than the desired >> partitions. >> >> I do not know where this is coming from. I tried zeroing the >> superblock for both /dev/sdb and /dev/sdc and mdadm reported they did >> not look like RAID devices. >> >> Results from 'mdadm --detail /dev/md2' before and after is: >> >> ============================= >> root@oak:~# mdadm --detail /dev/md2 >> /dev/md2: >> Version : 00.90 >> Creation Time : Tue Jan 25 10:39:52 2011 >> Raid Level : raid1 >> Array Size : 1943027712 (1853.02 GiB 1989.66 GB) >> Used Dev Size : 1943027712 (1853.02 GiB 1989.66 GB) >> Raid Devices : 2 >> Total Devices : 2 >> Preferred Minor : 2 >> Persistence : Superblock is persistent >> >> Update Time : Wed Jan 26 21:16:04 2011 >> State : clean, degraded, recovering >> Active Devices : 1 >> Working Devices : 2 >> Failed Devices : 0 >> Spare Devices : 1 >> >> Rebuild Status : 2% complete >> >> UUID : 19d72028:63677f91:cd71bfd9:6916a14f (local to host oak) >> Events : 0.13376 >> >> Number Major Minor RaidDevice State >> 0 8 32 0 active sync /dev/sdc >> 2 8 16 1 spare rebuilding /dev/sdb >> root@oak:~# >> root@oak:~# mdadm --detail /dev/md2 >> /dev/md2: >> Version : 00.90 >> Creation Time : Tue Jan 25 10:39:52 2011 >> Raid Level : raid1 >> Array Size : 1943027712 (1853.02 GiB 1989.66 GB) >> Used Dev Size : 1943027712 (1853.02 GiB 1989.66 GB) >> Raid Devices : 2 >> Total Devices : 2 >> Preferred Minor : 2 >> Persistence : Superblock is persistent >> >> Update Time : Wed Jan 26 21:25:40 2011 >> State : clean, degraded, recovering >> Active Devices : 1 >> Working Devices : 2 >> Failed Devices : 0 >> Spare Devices : 1 >> >> Rebuild Status : 0% complete >> >> UUID : 19d72028:63677f91:cd71bfd9:6916a14f (local to host oak) >> Events : 0.13382 >> >> Number Major Minor RaidDevice State >> 0 8 34 0 active sync /dev/sdc2 >> 2 8 18 1 spare rebuilding /dev/sdb2 >> ============================= >> >> Contents of /etc/mdadm/mdadm.conf are: >> ============================= >> hbarta@oak:~$ cat /etc/mdadm/mdadm.conf >> # mdadm.conf >> # >> # Please refer to mdadm.conf(5) for information about this file. >> # >> >> # by default, scan all partitions (/proc/partitions) for MD superblocks. >> # alternatively, specify devices to scan, using wildcards if desired. >> DEVICE partitions >> >> # auto-create devices with Debian standard permissions >> CREATE owner=root group=disk mode=0660 auto=yes >> >> # automatically tag new arrays as belonging to the local system >> HOMEHOST <system> >> >> # instruct the monitoring daemon where to send mail alerts >> MAILADDR root >> >> # definitions of existing MD arrays >> #ARRAY /dev/md2 level=raid1 num-devices=2 >> UUID=19d72028:63677f91:cd71bfd9:6916a14f >> #spares=2 >> >> # This file was auto-generated on Wed, 26 Jan 2011 09:53:42 -0600 >> # by mkconf $Id$ >> hbarta@oak:~$ >> ============================= >> (I commented out the two lines following "definitions of existing MD >> arrays" because I thought they might be the culprit.) >> >> They seem to match: >> ============================= >> hbarta@oak:~$ sudo mdadm --examine --scan >> ARRAY /dev/md0 level=raid1 num-devices=2 >> UUID=954a3be2:f23e1239:cd71bfd9:6916a14f >> ARRAY /dev/md2 level=raid1 num-devices=2 >> UUID=19d72028:63677f91:cd71bfd9:6916a14f >> spares=2 >> hbarta@oak:~$ >> ============================= >> except for the addition of a second RAID which I added after installing >> mdadm. >> >> I have no idea how to fix this (*) and appreciate any help with how to do >> so. >> >> >> (*) All I can think of is to zero both entire drives and start from >> the beginning. >> >> On Tue, Jan 25, 2011 at 9:41 AM, Hank Barta <hbarta@xxxxxxxxx> wrote: >>> >>> My previous experiment with USB flash drives has not gone too far. I >>> can install Ubuntu Server 10.04 to a single USB flash drive and boot >>> my Eee PC 901 and Thinkpad T500 from it, but I cannot boot the Intel >>> D525MW from it. The Intel board will boot install media on USB flash, >>> but not a normal install. (This is an aside.) The desire to use an >>> alternate boot was to avoid having to fiddle with a two drive RAID1. >>> The drives have a single partition consisting of the entire drive >>> which is combined into the RAID1. >>> >>> My desire to get this system up and running is overrunning my desire >>> to get the USB flash raid to boot. My strategy is to >>> - remove one drive from the raid, >>> - repartition it to allow for a system installation >>> - create a new RAID1 with that drive and format the new data >>> partition. (both would be RAID1 and now both degraded to one drive) >>> - copy data from the existing RAID1 data partition to the new RAID1 >>> data partition. >>> - stop the old RAID1 >>> - repartition the other drive (most recently the old RAID1) to match >>> the new RAID1 >>> - add the second drive to the new RAID1 >>> - watch it rebuild and breathe big sigh of relief. >>> >>> When convenient I can install Linux to the space I've opened up via >>> the above machinations and move this project down the road. >>> >>> That looks pretty straightforward to me, but I've never let that sort >>> of thing prevent me from cobbling things up in the past. (And at this >>> moment, I'm making a copy of the RAID1 to an external drive just in >>> case.) For anyone interested, I'll share the details of my plan to the >>> command level in the case that any of you can spot a problem I have >>> overlooked. >>> >>> A related question Is what are the constraints for partitioning the >>> drive to achieve best performance? I plan to create a 10G partition on >>> each drive for the system. Likewise, suggestions for tuning the RAID >>> and filesystem configurations would be appreciated. Usage for the RAID >>> is backup for my home LAN as well as storing pictures and more >>> recently my video library so there's a mix of large and small files. >>> I'm not obsessed with performance as most clients are on WiFi, but I >>> might as well grab the low hanging fruit in this regard. >>> >>> Feel free to comment on any aspects of the details listed below. >>> >>> many thanks, >>> hank >>> >>> This is what is presently on the drives: >>> ======================== >>> root@oak:~# cat /proc/mdstat >>> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] >>> [raid4] [raid10] >>> md1 : active raid1 sdc1[0] sda1[1] >>> 1953511936 blocks [2/2] [UU] >>> >>> unused devices: <none> >>> root@oak:~# fdisk -l /dev/sda /dev/sdc >>> >>> Disk /dev/sda: 2000.4 GB, 2000398934016 bytes >>> 255 heads, 63 sectors/track, 243201 cylinders >>> Units = cylinders of 16065 * 512 = 8225280 bytes >>> Sector size (logical/physical): 512 bytes / 512 bytes >>> I/O size (minimum/optimal): 512 bytes / 512 bytes >>> Disk identifier: 0x00000000 >>> >>> Device Boot Start End Blocks Id System >>> /dev/sda1 * 1 243201 1953512001 fd Linux raid >>> autodetect >>> >>> Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes >>> 255 heads, 63 sectors/track, 243201 cylinders >>> Units = cylinders of 16065 * 512 = 8225280 bytes >>> Sector size (logical/physical): 512 bytes / 512 bytes >>> I/O size (minimum/optimal): 512 bytes / 512 bytes >>> Disk identifier: 0x00000000 >>> >>> Device Boot Start End Blocks Id System >>> /dev/sdc1 1 243201 1953512001 fd Linux raid >>> autodetect >>> root@oak:~# >>> ======================== >>> >>> One drive is a Seagate ST32000542AS and the other a Samsung HD204UI. >>> The Samsung is one of those with 4K sectors. (I think the Seagate may >>> be too.) >>> >>> Selecting /dev/sdc to migrate first (and following more or less the >>> guide on >>> http://mkfblog.blogspot.com/2007/11/resizing-raid1-system-partition.html) >>> >>> Fail the drive: >>>> >>>> mdadm --manage /dev/md1 --fail /dev/sdc1 >>> >>> Remove from the array: >>>> >>>> mdadm --manage /dev/md1 --remove /dev/sdc1 >>> >>> Zero the superblock: >>>> >>>> mdadm --zero-superblock /dev/sdc1 >>> >>> <Repartition drive with one 10G primary partition at the beginning and >>> a second primary partition using the remainder of the drive: /dev/sdc1 >>> and /dev/sdc2> >>> >>> Create new RAID: >>>> >>>> mdadm --create /dev/md2 -n 2 --level=1 /dev/sdc2 missing >>> >>> Format: >>>> >>>> mkfs.ext4 /dev/md2 >>> >>> Mount: >>>> >>>> mount /dev/md2 /mnt/md2 >>> >>> Copy: >>>> >>>> rsync -av -H -K --partial --partial-dir=.rsync-partial /mnt/md1/ >>>> /mnt/USB/ >>> >>> Stop the old RAID: >>>> >>>> mdadm --stop /dev/md1 >>> >>> Zero the superblock: >>>> >>>> mdadm --zero-superblock /dev/sda1 >>> >>> Repartition to match the other drive >>> >>> Add the second drive to the RAID: >>>> >>>> mdadm --manage /dev/md2 --add /dev/sda2 >>> >>> Watch the resync complete. >>> >>> Done! (Except for doing something with the new 10G partition, but >>> that's another subject.) >>> >>> Many thanks for reading this far! >>> >>> best, >>> hank >>> >>> -- >>> '03 BMW F650CS - hers >>> '98 Dakar K12RS - "BABY K" grew up. >>> '93 R100R w/ Velorex 700 (MBD starts...) >>> '95 Miata - "OUR LC" >>> polish visor: apply squashed bugs, rinse, repeat >>> Beautiful Sunny Winfield, Illinois >>> >> >> >> >> -- >> '03 BMW F650CS - hers >> '98 Dakar K12RS - "BABY K" grew up. >> '93 R100R w/ Velorex 700 (MBD starts...) >> '95 Miata - "OUR LC" >> polish visor: apply squashed bugs, rinse, repeat >> Beautiful Sunny Winfield, Illinois >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-raid" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- '03 BMW F650CS - hers '98 Dakar K12RS - "BABY K" grew up. '93 R100R w/ Velorex 700 (MBD starts...) '95 Miata - "OUR LC" polish visor: apply squashed bugs, rinse, repeat Beautiful Sunny Winfield, Illinois -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
