No useful answer found into similar questions. In my case I have a disk from a Dell server (dead). It was in RAID-1 configuration. I need to recover data into a new different server. I can see the disk and fdisk say that there are the partitions, but if I try to mount them I get: mount: special device /dev/sdb1 does not exist
Fdisk show the partitions (sdb1, sdb2), lsblk and blkid only /dev/sdb
Thanks, P.
Evolution:
Thanks @jaroslav-kucera for kpartx hints. Tried without success:
Full tests (sdb is the disk of interest; sda & sdc are other not related disks; used SystemRescue-Cd 4.7.1):
root@sysresccd /mnt % fdisk -l /dev/sdb
Disk /dev/sdb: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D75FA363-2D6D-47F6-A79F-6C160BBB38B7
Device Start End Sectors Size Type
/dev/sdb1 2048 8000002047 8000000000 3.7T Linux filesystem
/dev/sdb2 8000002048 15626928094 7626926047 3.6T Linux filesystem
root@sysresccd /mnt % mount /dev/sdb1 /mnt/1
mount: special device /dev/sdb1 does not exist
root@sysresccd /mnt % kpartx -l /dev/sdb
GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:Alternate GPT header not at the end of the disk.
GPT: Use GNU Parted to correct GPT errors.
sdb1 : 0 8000000000 /dev/sdb 2048
sdb2 : 0 7626926047 /dev/sdb 8000002048
root@sysresccd /mnt % kpartx -av /dev/sdb
GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:Alternate GPT header not at the end of the disk.
GPT: Use GNU Parted to correct GPT errors.
device-mapper: reload ioctl on sdb1 failed: Invalid argument
create/reload failed on sdb1
add map sdb1 (0:0): 0 8000000000 linear /dev/sdb 2048
device-mapper: reload ioctl on sdb2 failed: Invalid argument
create/reload failed on sdb2
add map sdb2 (0:0): 0 7626926047 linear /dev/sdb 8000002048
root@sysresccd /mnt % mount /dev/sdb1 /mnt/1
mount: special device /dev/sdb1 does not exist
root@sysresccd /mnt % blkid
/dev/loop0: TYPE="squashfs"
/dev/sda1: LABEL="2TB" UUID="B4B0F3DAB0F3A0D2" TYPE="ntfs" PARTUUID="ee20b174-01"
/dev/sdb: UUID="Dell ^P" TYPE="ddf_raid_member"
/dev/sdc1: SEC_TYPE="msdos" LABEL="DellUtility" UUID="5450-4444" TYPE="vfat" PARTUUID="d636c095-01"
/dev/sdc2: LABEL="RECOVERY" UUID="52428FB1428F97FD" TYPE="ntfs" PARTUUID="d636c095-02"
/dev/sdc3: LABEL="OS" UUID="0C3E92443E92272C" TYPE="ntfs" PARTUUID="d636c095-03"
/dev/sdd: UUID="2016-01-18-20-46-30-00" LABEL="sysrcd-4.7.1" TYPE="iso9660"
root@sysresccd /mnt % lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
└─sda1 8:1 0 1.8T 0 part
sdb 8:16 0 7.3T 0 disk
sdc 8:32 0 465.8G 0 disk
├─sdc1 8:33 0 40M 0 part
├─sdc2 8:34 0 11.8G 0 part
└─sdc3 8:35 0 454G 0 part
sdd 8:48 1 2G 0 disk /livemnt/boot
loop0 7:0 0 337.6M 1 loop /livemnt/squashfs
HW RAID controller are often a strange world. Recently I used HP servers and the disks can be read without problems (ok, if I remount a boot disks in the original controller after mounting it in a standard controller, It can't boot, but data are still accessible). I suppose there is some trick also for This Dell PERC H330 ...
Thanks, P.
