* udev doesn't detect ddf-format raid array
@ 2008-10-02 21:09 Peter
2008-10-02 22:47 ` Kay Sievers
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: Peter @ 2008-10-02 21:09 UTC (permalink / raw)
To: linux-hotplug
Hi!
I have an adaptec hostraid controller (fakeraid) with 2 drives connected in a
RAID1 array (metadata is in DDF format) which is nicely detected and enabled
by dmraid, there is no problem with it after it's enabled.
Recently debian's dmraid-booter has switched to use udev. But udev does not
detect my drives as raid type, ID_FS_USAGE is missing from the drive info (it
should be "raid"), so the result is that dmraid does not called at boot. Also
vol_id sees the partitions as normal partitions.
I've recognised that one of my disks has a HPA, the other hasn't. I'm not sure
if this has any effect, but because of this, the DDF1-headers are not at the
same position on the 2 drives.
Below are some outputs. The last one is a 'dmraid -n' output, and what is
strange for me at first sight is that both drives has 2 DDF1-headers. Is this
normal? Or do you think I should try to rebuild the raid array with the bios
utility (maybe after some bios upgrade)? Or is this rather an udev problem?
Thanks,
Peter
$ udevinfo --query=all --name=sda
P: /block/sda
N: sda
S: disk/by-id/ata-SAMSUNG_SP2004C_S07GJ1LYB11332
S: disk/by-id/scsi-SATA_SAMSUNG_SP2004CS07GJ1LYB11332
S: disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0
E: ID_VENDOR=ATA
E: ID_MODEL=SAMSUNG_SP2004C
E: ID_REVISION=VM10
E: ID_SERIAL=SATA_SAMSUNG_SP2004CS07GJ1LYB11332
E: ID_SERIAL_SHORT=S07GJ1LYB11332
E: ID_TYPE=disk
E: ID_BUS=scsi
E: ID_ATA_COMPAT=SAMSUNG_SP2004C_S07GJ1LYB11332
E: ID_PATH=pci-0000:03:00.0-scsi-0:0:0:0
$ udevinfo --query=all --name=sdb
P: /block/sdb
N: sdb
S: disk/by-id/ata-SAMSUNG_SP2004C_S07GJ1LYB11326
S: disk/by-id/scsi-SATA_SAMSUNG_SP2004CS07GJ1LYB11326
S: disk/by-path/pci-0000:03:00.0-scsi-1:0:0:0
E: ID_VENDOR=ATA
E: ID_MODEL=SAMSUNG_SP2004C
E: ID_REVISION=VM10
E: ID_SERIAL=SATA_SAMSUNG_SP2004CS07GJ1LYB11326
E: ID_SERIAL_SHORT=S07GJ1LYB11326
E: ID_TYPE=disk
E: ID_BUS=scsi
E: ID_ATA_COMPAT=SAMSUNG_SP2004C_S07GJ1LYB11326
E: ID_PATH=pci-0000:03:00.0-scsi-1:0:0:0
# vol_id /dev/sda
/dev/sda: unknown volume type
# vol_id /dev/sdb
/dev/sdb: unknown volume type
# vol_id /dev/sda2
ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUIDÛ631065-7ca8-45fc-bf60-a9259a732dec
ID_FS_UUID_ENCÛ631065-7ca8-45fc-bf60-a9259a732dec
ID_FS_LABELID_FS_LABEL_ENCID_FS_LABEL_SAFE
# vol_id /dev/sdb2
ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUIDÛ631065-7ca8-45fc-bf60-a9259a732dec
ID_FS_UUID_ENCÛ631065-7ca8-45fc-bf60-a9259a732dec
ID_FS_LABELID_FS_LABEL_ENCID_FS_LABEL_SAFE
dmesg:
[ 3.676575] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 3.676504] ata1.00: HPA detected: current 390719855, native 390721968 <=
[ 3.676504] ata1.00: ATA-7: SAMSUNG SP2004C, VM100-33, max UDMA7
[ 3.676504] ata1.00: 390719855 sectors, multi 0: LBA48 NCQ (depth 31/32)
[ 3.683147] ata1.00: configured for UDMA/100
[ 6.244512] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 6.247775] ata2.00: ATA-7: SAMSUNG SP2004C, VM100-33, max UDMA7
[ 6.247817] ata2.00: 390721968 sectors, multi 0: LBA48 NCQ (depth 31/32)
[ 6.559336] ata2.00: configured for UDMA/100
[ 6.559336] scsi 0:0:0:0: Direct-Access ATA SAMSUNG SP2004C VM10
PQ: 0 ANSI: 5
[ 6.559336] scsi 1:0:0:0: Direct-Access ATA SAMSUNG SP2004C VM10
PQ: 0 ANSI: 5
# dmraid -r
/dev/sdb: ddf1, ".ddf1_disks", GROUP, ok, 390361088 sectors, data@ 0
/dev/sda: ddf1, ".ddf1_disks", GROUP, ok, 390361088 sectors, data@ 0
# dmraid -s
*** Group superset .ddf1_disks
--> Active Subset
name : ddf1_system
size : 390361088
stride : 128
type : mirror
status : ok
subsets: 0
devs : 2
spares : 0
# dmraid -n
/dev/sdb (ddf1):
DDF1 anchor at 390721967 with tables in little-endian format.
DDF1 Header at 0x875e760
0x000 signature: 0xDE11DE11
0x004 crc: 0xD1DB18B7
0x008 guid: ".. L..B... L8.!L(.!L...." [a8 fd 20 4c 95 10 42 02 a8
fd 20 4c 38 09 21 4c 28 15 21 4c ff ff ff ff]
0x020 rev: "02.00.00" [30 32 2e 30 30 2e 30 30]
0x028 seqnum: -1
0x02c timestamp: 0xFFFFFFFF
0x030 open: 0xFF
0x031 foreign: 0xFF
0x032 grouping: 0xFF
0x060 primary header: 390721956
0x068 secondary header: 4294967295
0x070 header type: 0x0
0x074 workspace len: 32768
0x078 workspace lba: 390689188
0x080 max pd: 15
0x082 max vd: 4
0x084 max part: 1
0x086 vd_config len: 2
0x088 max_primary_elts: 65535
0x0c0 adapter_offset: 1
0x0c4 adapter_len: 1
0x0c8 pd_offset: 2
0x0cc pd_len: 2
0x0d0 vd_offset: 4
0x0d4 vd_len: 1
0x0d8 config_offset: 5
0x0dc config_len: 4
0x0e0 disk_data_offset: 9
0x0e4 disk_data_len: 1
0x0e8 badblock_offset: -1
0x0ec badblock_len: 0
0x0f0 diag_offset: -1
0x0f4 diag_len: 0
0x0f8 vendor_offset: 10
0x0fc vendor_len: 1
DDF1 Header at 0x875e9a0
0x000 signature: 0xDE11DE11
0x004 crc: 0x5A569EF2
0x008 guid: ".. L..B... L8.!L(.!L...." [a8 fd 20 4c 95 10 42 02 a8
fd 20 4c 38 09 21 4c 28 15 21 4c ff ff ff ff]
0x020 rev: "02.00.00" [30 32 2e 30 30 2e 30 30]
0x028 seqnum: -1
0x02c timestamp: 0xFFFFFFFF
0x030 open: 0xFF
0x031 foreign: 0xFF
0x032 grouping: 0xFF
0x060 primary header: 390721956
0x068 secondary header: 4294967295
0x070 header type: 0x1
0x074 workspace len: 32768
0x078 workspace lba: 390689188
0x080 max pd: 15
0x082 max vd: 4
0x084 max part: 1
0x086 vd_config len: 2
0x088 max_primary_elts: 65535
0x0c0 adapter_offset: 1
0x0c4 adapter_len: 1
0x0c8 pd_offset: 2
0x0cc pd_len: 2
0x0d0 vd_offset: 4
0x0d4 vd_len: 1
0x0d8 config_offset: 5
0x0dc config_len: 4
0x0e0 disk_data_offset: 9
0x0e4 disk_data_len: 1
0x0e8 badblock_offset: -1
0x0ec badblock_len: 0
0x0f0 diag_offset: -1
0x0f4 diag_len: 0
0x0f8 vendor_offset: 10
0x0fc vendor_len: 1
Adapter Data at 0x875eba8
0x000 signature: 0xAD111111
0x004 crc: 0x28004959
0x008 guid: ".. L8.!L(.!L. !LADPT...." [a8 fd 20 4c 38 09 21 4c 28
15 21 4c a8 20 21 4c 41 44 50 54 ff ff ff ff]
0x020 pci vendor: 0x1095
0x022 pci device: 0x242
0x024 pci subvendor: 0x9005
0x026 pci subdevice: 0x242
Disk Data at 0x875edb0
0x000 signature: 0x33333333
0x004 crc: 0x5F4EA96C
0x008 guid: "S07GJ1LYB11326 ..1Z...." [53 30 37 47 4a 31 4c 59 42
31 31 33 32 36 20 20 c8 ac 31 5a ff ff ff ff]
0x020 reference: 0x38BC1348
0x024 forced_ref_flag: 255
0x025 forced_guid_flag: 0
Physical Drive Header at 0x875efb8
0x000 signature: 0x22222222
0x004 crc: 0x504EF65
0x008 num drives: 2
0x00a max drives: 15
Physical Drive at 0x875eff8
0x000 guid: "S07GJ1LYB11326 ...Z...." [53 30 37 47 4a 31 4c 59 42
31 31 33 32 36 20 20 08 db dd 5a ff ff ff ff]
0x018 reference #: 0x38BC1348
0x01c type: 0x2
0x01e state: 0x1
0x020 size: 390361088
0x028 path info: ".................." [01 00 00 00 ff ff ff ff ff ff ff
ff ff ff ff ff ff ff]
Physical Drive at 0x875f038
0x000 guid: "S07GJ1LYB11332 @..Z...." [53 30 37 47 4a 31 4c 59 42
31 31 33 33 32 20 20 40 9d de 5a ff ff ff ff]
0x018 reference #: 0x38BCBED8
0x01c type: 0x2
0x01e state: 0x1
0x020 size: 390361088
0x028 path info: ".................." [00 00 00 00 ff ff ff ff ff ff ff
ff ff ff ff ff ff ff]
Virtual Drive Header at 0x875f3c0
0x000 signature: 0xDDDDDDDD
0x004 crc: 0xAF8547DB
0x008 num drives: 1
0x00a max drives: 4
Virtual Drive at 0x875f400
0x000 guid: "@50Z..B. .#.8:5JE" [40 35 30 5a 95 10 42 02 20
20 20 20 20 20 20 20 f8 23 bb 38 3a 35 4a 45]
0x018 vd #: 0x0
0x01c type: 0xFFFFFFFF
0x020 state: 0x0
0x021 init state: 0x2
0x030 name: "system.........." [73 79 73 74 65 6d 00 00 00 00 00
00 00 00 00 00]
Virtual Drive Config Record at 0x875f7c8
0x000 signature: 0xEEEEEEEE
0x004 crc: 0xC8A3CACF
0x008 guid: "@50Z..B. .#.8:5JE" [40 35 30 5a 95 10 42 02 20
20 20 20 20 20 20 20 f8 23 bb 38 3a 35 4a 45]
0x020 timestamp: 0x4C8
0x024 seqnum: 1224
0x040 primary count: 2
0x042 stripe size: 7KiB
0x043 raid level: 1
0x044 raid qualifier: 0
0x045 secondary count: 1
0x046 secondary number: 0
0x047 secondary level: 255
0x060 spare 0: 0xFFFFFFFF
0x064 spare 1: 0xFFFFFFFF
0x068 spare 2: 0xFFFFFFFF
0x06c spare 3: 0xFFFFFFFF
0x070 spare 4: 0xFFFFFFFF
0x074 spare 5: 0xFFFFFFFF
0x078 spare 6: 0xFFFFFFFF
0x07c spare 7: 0xFFFFFFFF
0x080 cache policy: 0x20
0x088 bg task rate: 16
0x048 sector count: 390361088
0x050 size: 390361088
Drive map:
0: 38BC1348 @ 0
1: 38BCBED8 @ 0
/dev/sda (ddf1):
DDF1 anchor at 390719854 with tables in little-endian format.
DDF1 Header at 0x875ffd0
0x000 signature: 0xDE11DE11
0x004 crc: 0x6087F66D
0x008 guid: ".. L..B... L8.!L(.!L...." [a8 fd 20 4c 95 10 42 02 a8
fd 20 4c 38 09 21 4c 28 15 21 4c ff ff ff ff]
0x020 rev: "02.00.00" [30 32 2e 30 30 2e 30 30]
0x028 seqnum: -1
0x02c timestamp: 0xFFFFFFFF
0x030 open: 0xFF
0x031 foreign: 0xFF
0x032 grouping: 0xFF
0x060 primary header: 390719843
0x068 secondary header: 4294967295
0x070 header type: 0x0
0x074 workspace len: 32768
0x078 workspace lba: 390687075
0x080 max pd: 15
0x082 max vd: 4
0x084 max part: 1
0x086 vd_config len: 2
0x088 max_primary_elts: 65535
0x0c0 adapter_offset: 1
0x0c4 adapter_len: 1
0x0c8 pd_offset: 2
0x0cc pd_len: 2
0x0d0 vd_offset: 4
0x0d4 vd_len: 1
0x0d8 config_offset: 5
0x0dc config_len: 4
0x0e0 disk_data_offset: 9
0x0e4 disk_data_len: 1
0x0e8 badblock_offset: -1
0x0ec badblock_len: 0
0x0f0 diag_offset: -1
0x0f4 diag_len: 0
0x0f8 vendor_offset: 10
0x0fc vendor_len: 1
DDF1 Header at 0x8760210
0x000 signature: 0xDE11DE11
0x004 crc: 0xEB0A7028
0x008 guid: ".. L..B... L8.!L(.!L...." [a8 fd 20 4c 95 10 42 02 a8
fd 20 4c 38 09 21 4c 28 15 21 4c ff ff ff ff]
0x020 rev: "02.00.00" [30 32 2e 30 30 2e 30 30]
0x028 seqnum: -1
0x02c timestamp: 0xFFFFFFFF
0x030 open: 0xFF
0x031 foreign: 0xFF
0x032 grouping: 0xFF
0x060 primary header: 390719843
0x068 secondary header: 4294967295
0x070 header type: 0x1
0x074 workspace len: 32768
0x078 workspace lba: 390687075
0x080 max pd: 15
0x082 max vd: 4
0x084 max part: 1
0x086 vd_config len: 2
0x088 max_primary_elts: 65535
0x0c0 adapter_offset: 1
0x0c4 adapter_len: 1
0x0c8 pd_offset: 2
0x0cc pd_len: 2
0x0d0 vd_offset: 4
0x0d4 vd_len: 1
0x0d8 config_offset: 5
0x0dc config_len: 4
0x0e0 disk_data_offset: 9
0x0e4 disk_data_len: 1
0x0e8 badblock_offset: -1
0x0ec badblock_len: 0
0x0f0 diag_offset: -1
0x0f4 diag_len: 0
0x0f8 vendor_offset: 10
0x0fc vendor_len: 1
Adapter Data at 0x8760418
0x000 signature: 0xAD111111
0x004 crc: 0x28004959
0x008 guid: ".. L8.!L(.!L. !LADPT...." [a8 fd 20 4c 38 09 21 4c 28
15 21 4c a8 20 21 4c 41 44 50 54 ff ff ff ff]
0x020 pci vendor: 0x1095
0x022 pci device: 0x242
0x024 pci subvendor: 0x9005
0x026 pci subdevice: 0x242
Disk Data at 0x8760620
0x000 signature: 0x33333333
0x004 crc: 0xB6F20A59
0x008 guid: "S07GJ1LYB11332 ...Z...." [53 30 37 47 4a 31 4c 59 42
31 31 33 33 32 20 20 f0 da eb 5a ff ff ff ff]
0x020 reference: 0x38BCBED8
0x024 forced_ref_flag: 255
0x025 forced_guid_flag: 0
Physical Drive Header at 0x8760828
0x000 signature: 0x22222222
0x004 crc: 0x5D01040B
0x008 num drives: 2
0x00a max drives: 15
Physical Drive at 0x8760868
0x000 guid: "S07GJ1LYB11326 0..Z...." [53 30 37 47 4a 31 4c 59 42
31 31 33 32 36 20 20 30 ad 98 5a ff ff ff ff]
0x018 reference #: 0x38BC1348
0x01c type: 0x2
0x01e state: 0x1
0x020 size: 390361088
0x028 path info: ".................." [01 00 00 00 ff ff ff ff ff ff ff
ff ff ff ff ff ff ff]
Physical Drive at 0x87608a8
0x000 guid: "S07GJ1LYB11332 .h.Z...." [53 30 37 47 4a 31 4c 59 42
31 31 33 33 32 20 20 98 68 99 5a ff ff ff ff]
0x018 reference #: 0x38BCBED8
0x01c type: 0x2
0x01e state: 0x1
0x020 size: 390361088
0x028 path info: ".................." [00 00 00 00 ff ff ff ff ff ff ff
ff ff ff ff ff ff ff]
Virtual Drive Header at 0x8760c30
0x000 signature: 0xDDDDDDDD
0x004 crc: 0xAF8547DB
0x008 num drives: 1
0x00a max drives: 4
Virtual Drive at 0x8760c70
0x000 guid: "@50Z..B. .#.8:5JE" [40 35 30 5a 95 10 42 02 20
20 20 20 20 20 20 20 f8 23 bb 38 3a 35 4a 45]
0x018 vd #: 0x0
0x01c type: 0xFFFFFFFF
0x020 state: 0x0
0x021 init state: 0x2
0x030 name: "system.........." [73 79 73 74 65 6d 00 00 00 00 00
00 00 00 00 00]
Virtual Drive Config Record at 0x8761038
0x000 signature: 0xEEEEEEEE
0x004 crc: 0xC8A3CACF
0x008 guid: "@50Z..B. .#.8:5JE" [40 35 30 5a 95 10 42 02 20
20 20 20 20 20 20 20 f8 23 bb 38 3a 35 4a 45]
0x020 timestamp: 0x4C8
0x024 seqnum: 1224
0x040 primary count: 2
0x042 stripe size: 7KiB
0x043 raid level: 1
0x044 raid qualifier: 0
0x045 secondary count: 1
0x046 secondary number: 0
0x047 secondary level: 255
0x060 spare 0: 0xFFFFFFFF
0x064 spare 1: 0xFFFFFFFF
0x068 spare 2: 0xFFFFFFFF
0x06c spare 3: 0xFFFFFFFF
0x070 spare 4: 0xFFFFFFFF
0x074 spare 5: 0xFFFFFFFF
0x078 spare 6: 0xFFFFFFFF
0x07c spare 7: 0xFFFFFFFF
0x080 cache policy: 0x20
0x088 bg task rate: 16
0x048 sector count: 390361088
0x050 size: 390361088
Drive map:
0: 38BC1348 @ 0
1: 38BCBED8 @ 0
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: udev doesn't detect ddf-format raid array 2008-10-02 21:09 udev doesn't detect ddf-format raid array Peter @ 2008-10-02 22:47 ` Kay Sievers 2008-10-03 7:59 ` Peter Leipold ` (4 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: Kay Sievers @ 2008-10-02 22:47 UTC (permalink / raw) To: linux-hotplug On Thu, Oct 2, 2008 at 11:09 PM, Peter <ple@upcmail.hu> wrote: > I have an adaptec hostraid controller (fakeraid) with 2 drives connected in a > RAID1 array (metadata is in DDF format) which is nicely detected and enabled > by dmraid, there is no problem with it after it's enabled. > > Recently debian's dmraid-booter has switched to use udev. But udev does not > detect my drives as raid type, ID_FS_USAGE is missing from the drive info (it > should be "raid"), so the result is that dmraid does not called at boot. Also > vol_id sees the partitions as normal partitions. > > I've recognised that one of my disks has a HPA, the other hasn't. I'm not sure > if this has any effect, but because of this, the DDF1-headers are not at the > same position on the 2 drives. > > Below are some outputs. The last one is a 'dmraid -n' output, and what is > strange for me at first sight is that both drives has 2 DDF1-headers. Is this > normal? Or do you think I should try to rebuild the raid array with the bios > utility (maybe after some bios upgrade)? Or is this rather an udev problem? Likely, that volume_id needs a fix. I never really tested with a real ddf volume. What udev version are you running? Is this an Adaptec controller? Can you send me a copy of the sectors containing the ddf header? Along with the exact dd commandline you used to extract it, so can copy it to a drive and test it. Thanks, Kay ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev doesn't detect ddf-format raid array 2008-10-02 21:09 udev doesn't detect ddf-format raid array Peter 2008-10-02 22:47 ` Kay Sievers @ 2008-10-03 7:59 ` Peter Leipold 2008-10-03 8:17 ` Kay Sievers ` (3 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: Peter Leipold @ 2008-10-03 7:59 UTC (permalink / raw) To: linux-hotplug [-- Attachment #1: Type: text/plain, Size: 1615 bytes --] On Friday 03 October 2008 00.47.23 Kay Sievers wrote: > Likely, that volume_id needs a fix. I never really tested with a real > ddf volume. > > What udev version are you running? 0.125-7 But I downloaded 0.129 yesterday and compiled it (I cannot install it system-wide, as I'm not that expert to know what stuff needs to be copied where, and I don't want to break this system). I tried to run udevadm and vol_id from the place of the compilation, the former didn't work, the latter gave the same result as in the 0.125 version: # ./udev-129/udev/udevadm info --query=all --name=sda device node not found # ./udev-129/extras/volume_id/vol_id /dev/sda2 ID_FS_USAGE=filesystem ID_FS_TYPE=ext3 ID_FS_VERSION=1.0 ID_FS_UUID=db631065-7ca8-45fc-bf60-a9259a732dec ID_FS_UUID_ENC=db631065-7ca8-45fc-bf60-a9259a732dec ID_FS_LABEL= ID_FS_LABEL_ENC= ID_FS_LABEL_SAFE= > Is this an Adaptec controller? Yes, it's their simplest 2-port card, model name 1220SA I think. It has a Silicon Image chip on it, the kernel use the sata_sil24 driver to reach the drives. > Can you send me a copy of the sectors containing the ddf header? Along > with the exact dd commandline you used to extract it, so can copy it > to a drive and test it. Attached. I hope I did the right thing. I got the offset and size with dmraid's help (dumping raid metadata). So these dd commands resulted the same files as dmraid -rD: dd if=/dev/sda of=sda_ddf1.dat bs=1 count=6144 skip=200048559616 dd if=/dev/sdb of=sdb_ddf1.dat bs=1 count=6144 skip=200049641472 (As I wrote, because one disk has a HPA, the offsets do differ.) Thanks, Peter [-- Attachment #2: sda_ddf1.dat --] [-- Type: application/octet-stream, Size: 6144 bytes --] [-- Attachment #3: sdb_ddf1.dat --] [-- Type: application/octet-stream, Size: 6144 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev doesn't detect ddf-format raid array 2008-10-02 21:09 udev doesn't detect ddf-format raid array Peter 2008-10-02 22:47 ` Kay Sievers 2008-10-03 7:59 ` Peter Leipold @ 2008-10-03 8:17 ` Kay Sievers 2008-10-03 8:59 ` Peter Leipold ` (2 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: Kay Sievers @ 2008-10-03 8:17 UTC (permalink / raw) To: linux-hotplug On Fri, Oct 3, 2008 at 9:59 AM, Peter Leipold <ple@upcmail.hu> wrote: > On Friday 03 October 2008 00.47.23 Kay Sievers wrote: >> Likely, that volume_id needs a fix. I never really tested with a real >> ddf volume. >> >> What udev version are you running? > > 0.125-7 That's fine, there have been no changes to ddf after udev 111 > But I downloaded 0.129 yesterday and compiled it (I cannot install it > system-wide, as I'm not that expert to know what stuff needs to be copied > where, and I don't want to break this system). I tried to run udevadm and > vol_id from the place of the compilation, the former didn't work, the latter > gave the same result as in the 0.125 version: > > # ./udev-129/udev/udevadm info --query=all --name=sda > device node not found I guess it's because configure uses the default --prefix=/usr anf therefore /usr/local/dev/ to look for device nodes. But 125 sounds fine anyway. > # ./udev-129/extras/volume_id/vol_id /dev/sda2 > ID_FS_USAGE=filesystem > ID_FS_TYPE=ext3 > ID_FS_VERSION=1.0 > ID_FS_UUIDÛ631065-7ca8-45fc-bf60-a9259a732dec > ID_FS_UUID_ENCÛ631065-7ca8-45fc-bf60-a9259a732dec > ID_FS_LABEL> ID_FS_LABEL_ENC> ID_FS_LABEL_SAFE> >> Is this an Adaptec controller? > > Yes, it's their simplest 2-port card, model name 1220SA I think. It has a > Silicon Image chip on it, the kernel use the sata_sil24 driver to reach the > drives. Ah, they don't conform to the ddf standard and put their signatures not exactly to the end of the volume, I'll add that to vol_id. >> Can you send me a copy of the sectors containing the ddf header? Along >> with the exact dd commandline you used to extract it, so can copy it >> to a drive and test it. > > Attached. I hope I did the right thing. I got the offset and size with > dmraid's help (dumping raid metadata). So these dd commands resulted the same > files as dmraid -rD: > > dd if=/dev/sda of=sda_ddf1.dat bs=1 counta44 skip 0048559616 > dd if=/dev/sdb of=sdb_ddf1.dat bs=1 counta44 skip 0049641472 Looks good: hexdump -C sda_ddf1.dat | head -1 00000000 11 de 11 de e2 e6 4c ae 38 5a b0 49 95 10 42 02 |......L.8Z.I..B.| 0xDE11DE11 is the signature we are looking for. I'll see if I can make that work. Kay ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev doesn't detect ddf-format raid array 2008-10-02 21:09 udev doesn't detect ddf-format raid array Peter ` (2 preceding siblings ...) 2008-10-03 8:17 ` Kay Sievers @ 2008-10-03 8:59 ` Peter Leipold 2008-10-03 13:33 ` Kay Sievers 2008-10-03 16:53 ` Peter Leipold 5 siblings, 0 replies; 7+ messages in thread From: Peter Leipold @ 2008-10-03 8:59 UTC (permalink / raw) To: linux-hotplug On Friday 03 October 2008 10.17.37 Kay Sievers wrote: > 0xDE11DE11 is the signature we are looking for. I'll see if I can make > that work. Thank you Kay! As I fell into the mistake of buying such a card and believing it's true raid, I really appreciate your work! Peter ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev doesn't detect ddf-format raid array 2008-10-02 21:09 udev doesn't detect ddf-format raid array Peter ` (3 preceding siblings ...) 2008-10-03 8:59 ` Peter Leipold @ 2008-10-03 13:33 ` Kay Sievers 2008-10-03 16:53 ` Peter Leipold 5 siblings, 0 replies; 7+ messages in thread From: Kay Sievers @ 2008-10-03 13:33 UTC (permalink / raw) To: linux-hotplug On Fri, Oct 3, 2008 at 10:17 AM, Kay Sievers <kay.sievers@vrfy.org> wrote: > On Fri, Oct 3, 2008 at 9:59 AM, Peter Leipold <ple@upcmail.hu> wrote: >> On Friday 03 October 2008 00.47.23 Kay Sievers wrote: >>> Can you send me a copy of the sectors containing the ddf header? Along >>> with the exact dd commandline you used to extract it, so can copy it >>> to a drive and test it. >> >> Attached. I hope I did the right thing. I got the offset and size with >> dmraid's help (dumping raid metadata). So these dd commands resulted the same >> files as dmraid -rD: >> >> dd if=/dev/sda of=sda_ddf1.dat bs=1 counta44 skip 0048559616 >> dd if=/dev/sdb of=sdb_ddf1.dat bs=1 counta44 skip 0049641472 > > Looks good: > hexdump -C sda_ddf1.dat | head -1 > 00000000 11 de 11 de e2 e6 4c ae 38 5a b0 49 95 10 42 02 |......L.8Z.I..B.| > > 0xDE11DE11 is the signature we are looking for. I'll see if I can make > that work. Here is what I get now from the sector you sent: $ dd if=~/Desktop/sdb_ddf1.dat bs=1 seek 0049641472 of›f-header.img $ losetup /dev/loop0 ddf-header.img $ ./vol_id /dev/loop0 ID_FS_USAGE=raid ID_FS_TYPE›f_raid_member ID_FS_VERSION\x02.00.0 ID_FS_UUID=8Z_I__B_8Z_I_e_I_q_I____ ID_FS_UUID_ENC=8Z\xb0I\x95\x10B\x028Z\xb0I\xc8e\xb0I\xb8q\xb0I\xff\xff\xff\xff ID_FS_LABEL ID_FS_LABEL_ENC If you want to try, let me know what it says: $ git clone git://git.kernel.org/pub/scm/linux/hotplug/udev.git $ cd udev $ ./autogen.sh $ cd extras/volume_id/ $ make $ ./vol_id /dev/sda $ ./vol_id /dev/sdb Note, that ./vol_id is just a autotools wrapper script, which runs the program with libvolume_id from the source tree, so don't copy the script to your system. :) Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: udev doesn't detect ddf-format raid array 2008-10-02 21:09 udev doesn't detect ddf-format raid array Peter ` (4 preceding siblings ...) 2008-10-03 13:33 ` Kay Sievers @ 2008-10-03 16:53 ` Peter Leipold 5 siblings, 0 replies; 7+ messages in thread From: Peter Leipold @ 2008-10-03 16:53 UTC (permalink / raw) To: linux-hotplug On Friday 03 October 2008 15.33.29 Kay Sievers wrote: > If you want to try, let me know what it says: Great, it works, thanks! :) # ./vol_id /dev/sda ID_FS_USAGE=raid ID_FS_TYPEÝf_raid_member ID_FS_VERSION\x02.00.0 ID_FS_UUID=_VsJ__B__VsJ0bsJ_nsJ____ ID_FS_UUID_ENC=\x08VsJ\x95\x10B\x02\x08VsJ0bsJ\x18nsJ\xff\xff\xff\xff ID_FS_LABELID_FS_LABEL_ENC # ./vol_id /dev/sdb ID_FS_USAGE=raid ID_FS_TYPEÝf_raid_member ID_FS_VERSION\x02.00.0 ID_FS_UUID=_VsJ__B__VsJ0bsJ_nsJ____ ID_FS_UUID_ENC=\x08VsJ\x95\x10B\x02\x08VsJ0bsJ\x18nsJ\xff\xff\xff\xff ID_FS_LABELID_FS_LABEL_ENC > Note, that ./vol_id is just a autotools wrapper script, which runs the > program with libvolume_id from the source tree, so don't copy the > script to your system. :) Ok, it's not crucial, I have a workaround to my original problem, so I can wait until debian-unstable starts using this upgraded libvolume_id. Peter ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-10-03 16:53 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-10-02 21:09 udev doesn't detect ddf-format raid array Peter 2008-10-02 22:47 ` Kay Sievers 2008-10-03 7:59 ` Peter Leipold 2008-10-03 8:17 ` Kay Sievers 2008-10-03 8:59 ` Peter Leipold 2008-10-03 13:33 ` Kay Sievers 2008-10-03 16:53 ` Peter Leipold
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).