Other diagnose iSCSI connected drive

M

michaelmichael

Hi guys,

I have an older Synology DiskStation, which I had been using as an iSCSI LUN
Then from the server the iSCSI connection works, but the disk cannot be mounted.

mount
Code: 
# mount /dev/da0 /mnt
mount: /dev/da0: No such file or directory

da0 is not part of any zpool and does not contain a zfs, as it does not appear in zfs list

If I do some checks with the tools I know I get the following

iscsictl
Code: 
# iscsictl -L
Target name                                              Target portal     State
iqn.2000-01.com.synology:DiskStation.Target-1.77ecfa12c6 192.168.61.87 Connected: da0

ls /dev
Code: 
# ls -al /dev
...
crw-r----- 1 root operator 0xa7 Jul 28 12:59 da0
...

geom
Code: 
# geom disk list
...
Geom name: da0
Providers:
1. Name: da0
Mediasize: 1469952557056 (1.3T)
Sectorsize: 512
Mode: r0w0e0
descr: SYNOLOGY iSCSI Storage
lunname: SYNOLOGYiSCSI Storage:4945af4b-630b-3886-a1ba-51f67238052d
lunid: 60014054945af4bd630bd3886da1bad5
ident: 4945af4b-630b-3886-a1ba-51f67238052d
rotationrate: unknown
fwsectors: 63
fwheads: 255


camcontrol
Code: 
# camcontrol devlist
<ADATA SP900 5.0.7b> at scbus0 target 0 lun 0 (pass0,ada0)
<WDC WD20EFRX-68EUZN0 82.00A82> at scbus3 target 0 lun 0 (pass1,ada1)
<WDC WD20EFRX-68EUZN0 82.00A82> at scbus4 target 0 lun 0 (pass2,ada2)
<WDC WD40EFRX-68N32N0 82.00A82> at scbus6 target 0 lun 0 (pass3,ada3)
<WDC WD40EFRX-68N32N0 82.00A82> at scbus7 target 0 lun 0 (pass4,ada4)
<WDC WD40EFRX-68N32N0 82.00A82> at scbus8 target 0 lun 0 (pass5,ada5)
<WDC WD40EFRX-68N32N0 82.00A82> at scbus9 target 0 lun 0 (pass6,ada6)
<SYNOLOGY iSCSI Storage 3.1> at scbus10 target 0 lun 0 (da0,pass7)

Therefore I assume the iSCSI connection is fine and the problem is on the file system level.


When I try to get some intel on the file system:

gpart
Code: 
# gpart show /dev/da0
gpart: No such geom: /dev/da0.

fsck
Code: 
# fsck /dev/da0
Can't open /dev/da0: No such file or directory

file
Code: 
# file -s /dev/da0
/dev/da0: data


fdisk however shows:

Code: 
# fdisk /dev/da0
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=178711 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=178711 heads=255 sectors/track=63 (16065 blks/cyl)

fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 2870992152 (1401851 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 534/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>


I am unable to find out which file system I formatted the disk in. Also, since ls /dev does only show da0 and not da0p1, da0p2, etc. it is well possible that the disk was encrypted, which I cannot remember. I use geli to encrypt a bunch of local disks (on the SATA busses) and when I try to attach /dev/da0 with geli I get:

Code: 
# geli attach -k <keyfile>.key /dev/da0 
geli: Cannot read metadata from /dev/da0: Invalid argument.
geli: There was an error with at least one provider.

If it was encrypted with geli I should get the password prompt.
If it is encrypted otherwise, how can I find out the encryption type? are there any other encryption tools on FreeBSD that I could have used?

Thanks for any help.

Michael
 
It's a bit of a long shot but does bsdlabel /dev/da0 output anything? It might have been a "dangerously dedicated" disk.
 
It's going to take a bit of sleuthing to figure out what was on there, if there was anything to begin with. You could start by looking at the first 1K or so of the disk using hexdump(1): hexdump -C -n 1024 /dev/da0

If you get all zeros there was probably nothing on it. If you get a bunch of random looking data then it may have been encrypted.
 
  • Like
Reactions: a6h
Code: 
# hexdump -C -n 1024 /dev/da0
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400

Interesting, I expected more than just zeros
 
That rules out encryption at least. And no partition table, not even a fragment. So it's likely just empty.
 
Thats weird.. I am quite certain I had put my media collection on it. The iscsictl config, the minidlna config are both present in rc.conf and the config files for minidlna and samba point to the directories I used for this.

Strangely there is nothing in /etc/fstab that hints to da0.

There is however some data if I increase the hexdump size to 32768

Anyway, thanks a lot for the help, appreciate it!
 
Does zpool import report anything? It may have been used as a single drive ZFS pool.
 
SirDice said:
Does zpool import report anything? It may have been used as a single drive ZFS pool.
Click to expand...

Code: 
# zpool import
   pool: TANK-DS
     id: 3441338476539008747
  state: ONLINE
 status: Some supported features are not enabled on the pool.
 action: The pool can be imported using its name or numeric identifier, though
    some features will not be available without an explicit 'zpool upgrade'.
 config:

    TANK-DS     ONLINE
      da0       ONLINE

🤦‍♂️

Code: 
# zpool import TANK-DS
# zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
TANK-DS                   1.05T   250G    19K  /mntz/TANK-DS
TANK-DS/Movies            1.05T   250G  1.05T  /mntz_srv/Movies
...

You are da man! Everything is there and accessible.
Thanks man.

But just for the record, why did hexdump not hint to a zpool?

Thanks & br,
Michael
 
michaelmichael said:
But just for the record, why did hexdump not hint to a zpool?
Click to expand...
Not sure how exactly ZFS stores its metadata, I do know it gets stored in multiple places. But all the ZFS disks I looked at where mostly empty at the first couple of sectors. If I recall correctly ZFS reserves this space at the beginning of the disk for things like boot code. But this isn't used on FreeBSD, so it remains empty.
 
You must log in or register to reply here.
Back
Top