asked on

Need help with pvcreate

I have a WD ShareSpace NAS which is a POS. No support.

I found a ton of people having the same problem I am having and there are some posted solutions. I am having an error that they didn't have and I don't understand it.

On this page: http://community.wdc.com/t5/WD-ShareSpace/Datavolume-doesn-t-exist-message/td-p/4440/page/2

There are two posted solutions by fibreiv and Cohiba88.

One lists the solution as:
pvcreate /dev/md2
vgcreate lvmr /dev/md2
lvcreate -l 714329 lvmr -n lvm0
lvcreate -l 714218 lvmr -n lvm0
fsck.ext fsck.ext2 fsck.ext3
fsck.ext3 /dev/lvmr/lvm0
(read their post for more info)

The other lists the solution as:

mdadm --assemble /dev/md2 /dev/sda4 /dev/sdb4 /dev/sdc4 /dev/sdd4
pvcreate /dev/md2
vgcreate lvmr /dev/md2
lvcreate -l 714329 lvmr -n lvm0
fsck.ext3 /dev/lvmr/lvmr0
mount -t ext3 /dev/lvmr/lvmr0 /DataVolume -o rw,noatime
(read their post for more info)

I issued this command:
mdadm --assemble /dev/md2 /dev/sda4 /dev/sdb4 /dev/sdc4 /dev/sdd4

And received:
mdadm: /dev/md2 assembled from 3 drives - not enough to start the array while not clean - consider --force.

Then I try:
pvcreate /dev/md2

And receive:
No physical volume label read from /dev/md2
/dev/md2: Size must exceed minimum of 1024 sectors.
Failed to setup physical volume "/dev/md2"

I am stuck...

I really need to get my NAS up even if only temporarily so I can copy some important files off of it.

arnold

Run fdisk -l
To see the available drives and the available partitions.

Is /dev/md2 already defined or are you trying to create it from scratch?
Does each drive have a fourth partition?
You are trying to reassemble, so issuing pvcreate/veg create is not advisable.

beapit

ASKER

Results of fdisk -l:
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 26 208844+ fd Linux raid autodetect
/dev/sda2 27 156 1044225 fd Linux raid autodetect
/dev/sda3 157 176 160650 fd Linux raid autodetect
/dev/sda4 177 121601 975346312+ fd Linux raid autodetect

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 26 208844+ fd Linux raid autodetect
/dev/sdb2 27 156 1044225 fd Linux raid autodetect
/dev/sdb3 157 176 160650 fd Linux raid autodetect
/dev/sdb4 177 121601 975346312+ fd Linux raid autodetect

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 26 208844+ fd Linux raid autodetect
/dev/sdc2 27 156 1044225 fd Linux raid autodetect
/dev/sdc3 157 176 160650 fd Linux raid autodetect
/dev/sdc4 177 121601 975346312+ fd Linux raid autodetect

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdd1 1 26 208844+ fd Linux raid autodetect
/dev/sdd2 27 156 1044225 fd Linux raid autodetect
/dev/sdd3 157 176 160650 fd Linux raid autodetect
/dev/sdd4 177 121601 975346312+ fd Linux raid autodetect

I don't totally understand what is going on. I suspect that I am creating it from scratch, but I am not sure.

From the solutions at the top where I posted the questioni, does it look to you like it is being created from scratch?

Throughout that link I provided in the original question, there are 13 pages of people saying that it worked for them. It did not appear to be a permanent solution. I think it just allowed the volume and shares to be mounted and the data copied off. Then the NAS is erased and recreated from scratch.

In a nutshell, here is the situation. The NAS says there is no DATAVOLUME. Since there is no DATAVOLUME, there is no access to the shares. Many people have said that the commands allowed temporary access to the data so that it could be copied off and the storage destructively reconfigured.

mdadm --detail /dev/md0 returns:
/dev/md0:
Version : 0.90
Creation Time : Wed Jun 2 23:53:21 2010
Raid Level : raid1
Array Size : 208768 (203.91 MiB 213.78 MB)
Used Dev Size : 208768 (203.91 MiB 213.78 MB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Sat Sep 1 11:44:14 2012
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

UUID : 60cc5e1c:622701f4:6dd2f708:6491739e
Events : 0.109672

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
2 8 33 2 active sync /dev/sdc1
3 8 49 3 active sync /dev/sdd1

mdadm --detail /dev/md1 returns:
/dev/md1:
Version : 0.90
Creation Time : Wed Jun 2 23:53:21 2010
Raid Level : raid1
Array Size : 1044160 (1019.86 MiB 1069.22 MB)
Used Dev Size : 1044160 (1019.86 MiB 1069.22 MB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1
Persistence : Superblock is persistent

Update Time : Sat Aug 11 20:22:50 2012
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

UUID : 37e5dbbb:9addb814:db622b44:c7cdc32d
Events : 0.11136

Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 18 1 active sync /dev/sdb2
2 8 34 2 active sync /dev/sdc2
3 8 50 3 active sync /dev/sdd2

mdadm --detail /dev/md2 returns:
mdadm: md device /dev/md2 does not appear to be active.

cat /proc/mdstat returns:
Personalities : [linear] [raid0] [raid1] [raid5]
md1 : active raid1 sdd2[3] sdc2[2] sdb2[1] sda2[0]
1044160 blocks [4/4] [UUUU]

md2 : inactive sda4[0] sdd4[3] sdc4[2] sdb4[1]
3901384960 blocks
md0 : active raid1 sdd1[3] sdc1[2] sdb1[1] sda1[0]
208768 blocks [4/4] [UUUU]

That is all I know.

arnold

Try mdadm --scan --run /dev/md2 /dev/sd[a-d]4
mdadm --examine /dev/md2 --detail
mdamd --run /dev/md2 --force after the assembly and the device is reflected as inactive.

Once the array is online, pvdisplay, vgdisplay, lvdisplay should reflect the volumes that are /dev/md2 would show up without the need to recreate them. The logical volume might be listed inactive, to make it active run vgchange -ay /dev/lvmr

beapit

ASKER

The first line gives me:
mdadm: --scan does not set the mode, and so cannot be the first option.

beapit

ASKER

So I tried:
mdadm --assemble --scan --run /dev/md2 /sd[a-d]4

And got:
mdadm: /dev/md2 not identified in config file.
mdadm: /sd[a-d]4 not identified in config file.

arnold

What are the contents of /etc/mdadm.conf?

Was it a raid5 volume?

beapit

ASKER

The file does not exist.

beapit

ASKER

Yes, RAID5.

ASKER CERTIFIED SOLUTION

arnold

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

beapit

ASKER

--force got me further.

mdadm --assemble /dev/md2 /dev/sd[a-d]4 --force
mdadm: /dev/md2 has been started with 3 drives (out of 4).

pvcreate /dev/md2
No physical volume label read from /dev/md2
Physical volume "/dev/md2" successfully created

vgcreate lvmr /dev/md2
Volume group "lvmr" successfully created

lvcreate -l 714218 lvmr -n lvm0
Logical volume "lvm0" created

fsck.ext3 /dev/lvmr/lvmr0
e2fsck 1.38 (30-Jun-2005)
fsck.ext3: while trying to open /dev/lvmr/lvmr0
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

lvmdiskscan
/dev/sda [ 931.51 GB]
/dev/md0 [ 203.88 MB]
/dev/md1 [ 1019.69 MB]
/dev/md2 [ 2.72 TB] LVM physical volume
/dev/sda3 [ 156.88 MB]
/dev/sdb [ 931.51 GB]
/dev/sdb3 [ 156.88 MB]
/dev/sdc [ 931.51 GB]
/dev/sdc3 [ 156.88 MB]
/dev/sdd [ 931.51 GB]
/dev/sdd3 [ 156.88 MB]
4 disks
6 partitions
0 LVM physical volume whole disks
1 LVM physical volume

pvdisplay
--- Physical volume ---
PV Name /dev/md2
VG Name lvmr
PV Size 2.72 TB / not usable 2.00 TB
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 714218
Free PE 0
Allocated PE 714218
PV UUID 743ujW-vfGM-k5TX-xv7b-oPxF-4PwA-ASVDKI

vgdisplay
--- Volume group ---
VG Name lvmr
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 255
Cur LV 1
Open LV 0
Max PV 255
Cur PV 1
Act PV 1
VG Size 2.72 TB
PE Size 4.00 MB
Total PE 714218
Alloc PE / Size 714218 / 2.72 TB
Free PE / Size 0 / 0
VG UUID M7L28o-jAVa-tnBR-K48O-5yQO-91FE-iKb9VK

lvdisplay
--- Logical volume ---
LV Name /dev/lvmr/lvm0
VG Name lvmr
LV UUID FWkuGA-Uw3S-KBR1-TfeK-cOsI-hVDj-SrfRpd
LV Write Access read/write
LV Status available
# open 0
LV Size 2.72 TB
Current LE 714218
Segments 1
Allocation next free (default)
Read ahead sectors 0
Block device 253:0

I really appreciate your time and help. Getting closer! Not sure how to read this.

beapit

ASKER

Looks like there was a typo on the page.

fsck.ext3 /dev/lvmr/lvmr0

should have been
fsck.ext3 /dev/lvmr/lvm0

It's doing some stuff. I'm getting excited!!

beapit

ASKER

BTW, this is what it is doing:

fsck.ext3 /dev/lvmr/lvm0
e2fsck 1.38 (30-Jun-2005)
Couldn't find ext2 superblock, trying backup blocks...
ext3 recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
NASRAID: recovering journal
Pass 1: Checking inodes, blocks, and sizes

beapit

ASKER

Success!

You rock, thanks for the help!

arnold

For future reference when an LVM is present, there is no need to run pvcreate/vgcreate
When you rerun pvcreate/vgcreate on a previously defined volume you are and might be overwriting reference points that could lead to data loss.
when trying to recover data bad words in options/commands are: initialize, create, build, sync, etc.
You have to be sure what you are looking at when resyncing/rebuilding to make sure that the data you have is not overwritten by data you do not want.

run mdadm --detail /dev/md2 to see which drive/partition of the four is being reflected as bad.