Can't connect to EVISTR Digital Voice Recorder

[borffis]

My trouble begins when I plug it in and observe that its MBR is aberrant.

dmesg:

da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
da0: <EVISTR L157 2.00> Removable Direct Access SCSI device
da0: 40.000MB/s transfers
da0: 16122MB (16508928 1024 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
GEOM_PART: integrity check failed (da0, MBR)

ls -l /dev/da0:

crw-rw----  1 root  operator  0xb1 Jan 15 18:27 /dev/da0

diskinfo -v /dev/da0:

/dev/da0
    1024            # sectorsize
    16905142272     # mediasize in bytes (16G)
    16508928        # mediasize in sectors
    0               # stripesize
    0               # stripeoffset
    1027            # Cylinders according to firmware.
    255             # Heads according to firmware.
    63              # Sectors according to firmware.
    EVISTR L157     # Disk descr.
                    # Disk ident.
    No              # TRIM/UNMAP support
    Unknown         # Rotation rate in RPM
    Not_Zoned       # Zone Mode

file -s /dev/da0

/dev/da0: DOS/MBR boot sector; partition 1 : ID=0xb, start-CHS (0x0,1,1), end-CHS (0x3ff,254,63), startsector 128, 16508928 sectors, extended partition table (last)

gpart show da0:

gpart: No such geom: da0.

mount -o ro -t ntfs /dev/da0 /mnt/2:

mount: /dev/da0: Operation not supported by device

mount -o ro -t ntfs /dev/da0s1 /mnt/2:

mount: /dev/da0s1: Operation not supported by device

Is this is a familiar problem?

 

[jbo@]

It's always useful if you could provide some information regarding functionality with a different OS. i.e. can you mount it on a Windows, MacOS or Linux machine?

I am a bit surprised that it would contain a boot sector. This should just be a simple mass storage device, right?

Can you provide the output of usbconfig -d x.y dump_device_desc where x.y is the USB device (check dmesg).

 

[ralphbsz]

My trouble begins when I plug it in and observe that its MBR is aberrant.

It's actually worse than that.

...
diskinfo -v /dev/da0: ...

1024 # sectorsize
...

So this device claims to be disk-like, meaning a block device (also known as a random access device). Great. But it has an extremely odd sector size, namely 1024 bytes. Sector sizes for common block devices are 512 bytes (traditional disks), 4096 bytes (modern disks), and 2048 bytes (CD-ROMs). A sector size of 1024 bytes is nearly unheard of. I think the last time I saw such things was the CD-ROM drives used for Digital Equipment's MicroVAX line of computers ... in the 80s and early 90s.

I very much doubt that any modern Unix file system can operate with 1024-byte sectors.

file -s /dev/da0
/dev/da0: DOS/MBR boot sector; partition 1 : ID=0xb, start-CHS (0x0,1,1), end-CHS (0x3ff,254,63), startsector 128, 16508928 sectors, extended partition table (last)

gpart show da0:
gpart: No such geom: da0.

OK, so it looks like the first 512 bytes of the first sector on the disk are in the correct format for a MBR boot sector. That's what the file command says. But has anyone ever seen a MBR that expresses its sizes in 1024-byte sectors?

The gpart command tells us that the disk does not have a GPT header.

Question: Does FreeBSD even recognize partitions on this disk? Is there a set of /dev/da0s* files?

mount -o ro -t ntfs /dev/da0 /mnt/2:

What makes you think that the file system stored on the whole disk (not the first partition) is NTFS? I would actually suspect FAT more.

mount: /dev/da0: Operation not supported by device

That tells you that the mount code attempted to perform an operation on the disk (probably a read), which the disk said it could not perform. Most likely the file system code attempted to do a 512-byte read, and that may be impossible: block devices typically can only be accessed by reading/writing full blocks, in our case 1024-byte sectors.

 

[covacat]

try

sysctl kern.geom.part.check_integrity=0 and re-plug it

 

[borffis]

It's always useful if you could provide some information regarding functionality with a different OS. i.e. can you mount it on a Windows, MacOS or Linux machine?

Alas, no: I no longer run Debian on any of my machines, and the recorder's owner only has some frivolous tablet that can read (but never transfer data from or to) storage devices....though not this one.

I am a bit surprised that it would contain a boot sector. This should just be a simple mass storage device, right?

Yes, but....!

Can you provide the output of usbconfig -d x.y dump_device_desc where x.y is the USB device (check dmesg).

Sure:

ugen1.5: <EVISTR USB FlashDisk> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0000 <Probed by interface class>
bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0040
idVendor = 0x20d6
idProduct = 0x1101
bcdDevice = 0x0100
iManufacturer = 0x0001 <EVISTR>
iProduct = 0x0002 <USB FlashDisk>
iSerialNumber = 0x0003 <>
bNumConfigurations = 0x0001


 

[jbo@]

I've just checked with my friend who used to operate devices like these (although different brands) and he confirmed that the ones which provide a USB interface with mass storage mode usually have an option (in the device menu) to format the storage. That would setup a clean slate by formatting the storage the way that the device is intended to. This might fix an issue in case somebody (or something) messed with the formatting. You might want to consider giving that a try (your existing recordings/data will be inaccessible afterwards tho).

Yes, but....!

Just to avoid any miscommunication: Do you have any reason to believe that it should contain a boot sector?

 

[borffis]

I very much doubt that any modern Unix file system can operate with 1024-byte sectors.

From gpart's output, I assumed that some such factor was my obstacle. I appreciate your explanation.

What makes you think that the file system stored on the whole disk (not the first partition) is NTFS? I would actually suspect FAT more.

That's a good point, but....
mount -o ro -t msdosfs /dev/da0 /mnt/2:
mount_msdosfs: /dev/da0: Invalid argument
mount -o ro -t msdosfs /dev/da0s1 /mnt/2:
mount_msdosfs: /dev/da0s1: No such file or directory
mount -o ro -t msdosfs /dev/da0s2 /mnt/2:
mount_msdosfs: /dev/da0s2: No such file or directory

That tells you that the mount code attempted to perform an operation on the disk (probably a read), which the disk said it could not perform. Most likely the file system code attempted to do a 512-byte read, and that may be impossible: block devices typically can only be accessed by reading/writing full blocks, in our case 1024-byte sectors.

Can you imagine why this device is so designed? Might the manufacturers have intended it to be accessed only by Win/Mac....?

 

[borffis]

I've just checked with my friend who used to operate devices like these (although different brands) and he confirmed that the ones which provide a USB interface with mass storage mode usually have an option (in the device menu) to format the storage. That would setup a clean slate by formatting the storage the way that the device is intended to. This might fix an issue in case somebody (or something) messed with the formatting. You might want to consider giving that a try (your existing recordings/data will be inaccessible afterwards tho).

This option is certainly available, but the probability that anybody tinkered with this is nil. Its owner wouldn't have done so, and he purchased it new. I will consider this, though.

Just to avoid any miscommunication: Do you have any reason to believe that it should contain a boot sector?

No, none whatsoever. It strikes me as oddly as anyone else.

 

[borffis]

try

sysctl kern.geom.part.check_integrity=0 and re-plug it

I'll essay this. Thanks!

 

[ralphbsz]

mount -o ro -t msdosfs /dev/da0s1 /mnt/2:
mount_msdosfs: /dev/da0s1: No such file or directory

That tells you that there is no BSD slice /dev/da0s1 on the device. That's to be expected: unlikely that this thing would be formatted with BSD-style slices. You might have instead tried /dev/da0p1, in case it has a (MSDOS-style) partition on it. Even better: Do a ls on /dev/da0*, and see what partitions/slices are even found.
EDIT: Never mind, see Covecat's post below. But do do an ls to see /dev/da0*, if there is anything there.

Can you imagine why this device is so designed? Might the manufacturers have intended it to be accessed only by Win/Mac....?

That seems plausible: The people who built this thing only intended it to be used with custom software. They may have used a software stack for a USB mass-storage device (fake disk) just for convenience, with no intent of supporting generic file system access. They may have picked the 1024-byte sector size for their own reasons.

If you had a lot of spare time, you could buy a USB protocol analyzer, and connect this device to its own software, and see what operations it performs. Reverse engineer that, and come up with some compatible software. That is probably a lot of work.

 

[covacat]

da0s1 is expected in any mbr setup, you don't need bsd slices (p1 is gpt setup)