[SOLVED] Issues trying to look at hard drive from a windows machine

Ketrel · 2023-08-17 15:58:37

I have an 8TB drive that I'm trying to look at in Arch, but it's behaving oddly.

It shows up as /dev/sdb
I do NOT see a /dev/sdb1

If I do fdisk -l, I see a sdb1 that's listed as 16T for size

Thinking this was a FS issue from the machine it's from dying, I got a Hiren's PE CD and spun up a virtualbox VM and gave it direct access to that drive. In the WinPE environment, the drive showed up correctly as expected. I did a chkdsk on it which completed with the drive still showing up fine. Going back to Linux, I'm still getting the same results when I try to look at it.

I'm at a loss here.

Disk /dev/sdb: 7.28 TiB, 8001563222016 bytes, 1953506646 sectors
Disk model:                 
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 32768 bytes / 32768 bytes
Disklabel type: dos
Disk identifier: 0x13ab13aa

Device     Boot Start        End    Sectors Size Id Type
/dev/sdb1           1 4294967295 4294967295  16T ee GPT

Partition 1 does not start on physical sector boundary.

But also

ls -l /dev/sd*
brw-rw---- 1 root disk 8,  0 Aug 17 00:06 /dev/sda
brw-rw---- 1 root disk 8,  1 Aug 17 00:06 /dev/sda1
brw-rw---- 1 root disk 8,  2 Aug 17 00:06 /dev/sda2
brw-rw---- 1 root disk 8,  3 Aug 17 00:06 /dev/sda3
brw-rw---- 1 root disk 8, 16 Aug 17 11:54 /dev/sdb

And gdisk -l shows

GPT fdisk (gdisk) version 1.0.9.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.
Disk /dev/sdb: 1953506646 sectors, 7.3 TiB
Model:                 
Sector size (logical/physical): 4096/4096 bytes
Disk identifier (GUID): 926912F8-E5BF-4629-A07B-651900C46746
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 5
First usable sector is 6, last usable sector is 1953506640
Partitions will be aligned on 256-sector boundaries
Total free space is 1953506635 sectors (7.3 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name

Last edited by Ketrel (2023-08-18 06:40:33)

seth · 2023-08-17 16:05:55

Unpartitioned "superdisk"?

sudo file -s /dev/sdb

Last edited by seth (2023-08-17 16:06:17)

Ketrel · 2023-08-17 19:07:39

seth wrote:

Unpartitioned "superdisk"?
sudo file -s /dev/sdb

/dev/sdb: DOS/MBR boot sector MS-MBR Windows 7 english at offset 0x163 "Invalid partition table" at offset 0x17b "Error loading operating system" at offset 0x19a "Missing operating system", disk signature 0x13ab13aa; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 4294967295 sectors

(I also tried "ldmtool scan" which looked to have returned nothing)

EDIT: I may need to look into other options, I just found this: https://askubuntu.com/questions/1436508 … r-gpt-disk
This looks to be the exact same symptoms as me, including the brand of the external bay for the drive. The only thing that's throwing me is that giving a VM raw access to /dev/sdb shows the drive ok in a Windows environment.

Last edited by Ketrel (2023-08-17 19:15:49)

Ketrel · 2023-08-18 06:01:53

Just wanted to say, I've confirmed the sector size issue mentioned in the edited in askubuntu issue is what's affecting me.

I found this post while digging more: https://superuser.com/questions/679725/ … 718#720718

and I was able to use that script with some modification (the dd command needs more than 1 count or the version of gdisk in Arch complains about available disk size (I did 70 count just to be safe)) but other than that it worked and created a loop device that I was able to mount as NTFS and get to the files.

Last edited by Ketrel (2023-08-18 06:29:47)

seth · 2023-08-18 06:20:18

\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Ketrel · 2023-08-21 05:57:02

Did just that.

Also in case that link is ever inaccessible, this is the script to fix it

#!/bin/sh
#
# This script solve the following problem:
#
# 1. create a GPT partition on a large disk while attached directly via SATA
#    when the device present itself with 512 bytes of block size:
#    sd 3:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
#
# 2. try to use a SATA to USB adapter like ID 067b:2773 Prolific Technology, Inc.
#    this present the device with 4096 bytes of block size:
#    sd 19:0:0:0: [sdc] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
#
# 3. The kernel is unable to read correctly the partition table with
#    the USB adaper.
#
#
# With the current tools (kernel and gdisk) in debian wheezy is
# possible to use losetup to remap the partitions to loop devices so
# you can use them as usual with any filesystem, raid or crypto
#
# I still do not know if this issue is originated by the adapter or by
# the disk and if there are any others workarounds.
#
# Known version of the software:
# $ apt-show-versions linux-image-3.2.0-4-amd64
# linux-image-3.2.0-4-amd64/wheezy uptodate 3.2.54-2
# $ apt-show-versions gdisk
# gdisk/wheezy uptodate 0.8.5-1


attach_device() {

    device="$1";

    MYTMPDIR=`mktemp -d`
    trap "rm -rf $MYTMPDIR" EXIT

    # gdisk on the device use the 4096 sector size
    # but we need to force it to 512
    # this is a knwon workaround from http://superuser.com/a/679800
    # basically we make a copy of the gpt partition table on a file
    dd if="/dev/$device" bs=16384 count=1 of="$MYTMPDIR/gpt" 2> /dev/null

    # we extract the offset and the size of each partition
    #
    # FIXME: the "+ 1" seems strange, but it is needed to get the same
    #        size value from:
    #
    #        blockdev --getsize64
    #
    #        without the "+ 1" some funny things happens, for example
    #        you will not be able to start a recognized md device:
    #
    #        md: loop1 does not have a valid v1.2 superblock, not importing!
    #        md: md_import_device returned -22
    #
    #        even if
    #
    #        mdadm --examine /dev/loop1
    #
    #        does not complaint

    gdisk -l \
     "$MYTMPDIR/gpt" 2> /dev/null | \
     awk '/^ *[0-9]/ {printf "%.0f %.0f\n", $2 * 512, ($3 - $2 + 1) * 512}' > $MYTMPDIR/offset-size

    # we create a loop device with the give offset and size
    while read line;
    do
        offset=$(printf "$line" | cut -d ' ' -f 1);
        size=$(printf "$line" | cut -d ' ' -f 2);
        losetup --verbose --offset "$offset" --sizelimit "$size" `losetup -f` /dev/$device;
    done < $MYTMPDIR/offset-size;
}

detach_device() {

    device="$1";

    for loopdevice in `losetup -a | grep "$device" | cut -d : -f 1`;
    do
        losetup --verbose --detach "$loopdevice";
    done;
}

usage() {
cat <<EOF
Usage:
- $0 -h to print this help
- $0 sda to attach the gpt partitions of sda
- $0 -d sda to detach the gpt partitions of sda
EOF
}


detach=0;

while getopts hd action
do
    case "$action" in
        d) detach=1;;
        h) usage;;
    esac
done
shift $(($OPTIND-1))

if [ $# -ne 1 ];
then
    usage;
fi

if [ "x$detach" = "x0" ]; then
    attach_device $1;
else
    detach_device $1;
fi

And this is the line I needed to change

dd if="/dev/$device" bs=16384 count=1 of="$MYTMPDIR/gpt" 2> /dev/null

I changed count=1 to count=70

Arch Linux

#1 2023-08-17 15:58:37

[SOLVED] Issues trying to look at hard drive from a windows machine

#2 2023-08-17 16:05:55

Re: [SOLVED] Issues trying to look at hard drive from a windows machine

#3 2023-08-17 19:07:39

Re: [SOLVED] Issues trying to look at hard drive from a windows machine

#4 2023-08-18 06:01:53

Re: [SOLVED] Issues trying to look at hard drive from a windows machine

#5 2023-08-18 06:20:18

Re: [SOLVED] Issues trying to look at hard drive from a windows machine

#6 2023-08-21 05:57:02

Re: [SOLVED] Issues trying to look at hard drive from a windows machine

Board footer