13.1 can't read disk formatted & written in Leap?

I have a 4 TB hard drive that I formatted using an external usb sata adapter, under Leap x64, and all seemed to go well. YaST partitioner created it as a single primary ext4 partition. I copied many files to it, but when I plug the USB cable into my 13.1 install, there is no response from KDE/Dolphin of an insertion event. The YaST 13.1 partitioner claims the drive needs to be formatted. I tried two different USB/SATA adapters to see if that was the problem, but 13.1 doesn’t red. I checked again, and Leap can read that drive just fine. What is the discrepancy? Is this, like, a GPT error - I looked in partitioner and don’t see any clues.

Thanks in advance for any help,

I should have mentioned the formatting laptop was an HP8440p (Leap) and the 13.1x64 install is on an HP touchsmart 17. And it’s just a data backup drive, not a system drive.

Check the output of “fdisk -l /dev/sdX” and “gdisk -l /dev/sdX” (for the appropriate X) on each system. Are there significant discrepancies. Look particularly at logical blocksize, physical blocksize, drive capacity.

It might be a hardware limitation or a limitation of the older kernel used by 13.1.

Also, is this USB3 or USB2? If USB3, does it make a difference whether you plug into an USB2 port?

Note that I’m only guessing at possible issues here.

Thanks for the reply… Does any of this look suspect to you? IT doesn’t seem to matter whether plugged into a USB2 or USB3 port.

This is the Leap computer (a rather old HP):

linux-h1tp:/home/patti # fdisk -l /dev/sdc

Disk /dev/sdc: 3.7 TiB, 4000787030016 bytes, 7814037168 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: dos
Disk identifier: 0x00000000

Device     Boot Start End Sectors  Size Id Type
/dev/sdc4           1   1       1  512B ee GPT

linux-h1tp:/home/patti # gdisk -l /dev/sdc
GPT fdisk (gdisk) version 0.8.8

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

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 7814037168 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 0ACEB83D-F1F1-488B-9E42-EAAE6158E6C5
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3693 sectors (1.8 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      7814035455   3.6 TiB     0700  primary
linux-h1tp:/home/patti # 

This is from the newer computer with 13.1x64

HPE-OS131:/home/patti # fdisk -l /dev/sdb

Disk /dev/sdb: 4000.8 GB, 4000787030016 bytes, 976754646 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb4               1           1           4   ee  GPT
HPE-OS131:/home/patti # gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.7

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

Creating new GPT entries.
Disk /dev/sdb: 976754646 sectors, 3.6 TiB
Logical sector size: 4096 bytes
Disk identifier (GUID): CA23624B-2804-4241-9E2B-A7E2744426D5
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 976754640
Partitions will be aligned on 256-sector boundaries
Total free space is 976754635 sectors (3.6 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
HPE-OS131:/home/patti # 

Hm. on both systems fdisk sees the same. It is in fact a GPT partitioned disk witth one partition. But, the first part of the GPT table can be interpreted as a DOS partitioning table. When that is done, one partition with number 4 (!)) is found and a length of only 1 byte. That is of course rubbish. I do not know very much about GPT, but IMHO the first part of a GPT table is not used by GPT just to avoid such confusion. It may however contain a DOS table that mirrors as good as it can the GPT partitioning. In this case it does not for some reason (I guess that a reason could be that the partition size is to large for DOS partitioning).

Now a guess is that in the 13. 1 system, the DOS (faulty) partitionig is used instead of the GPT partitioning.

In any case I would try a mount to see that gives an error message. Thus, on the 13.1 system:

mount -t ext4 /dev/sdb1 /mnt 


First computer:

Sector size (logical/physical): 512 bytes / 4096 bytes

Second computer:

Sector size (logical/physical): 4096 bytes / 4096 bytes

That’s what is causing the problem.

The effect is that the sector numbers, as seen on one computer, are referring to different sectors as seen on the other computer.

I’ve seen that here, though fortunately it didn’t much matter (I had not written important data to the disk). A 1T disk on an external enclosure has 4096 logical sector size, but when later mounted internally in the computer it has 512 logical sector size. As far as I know, that’s a limitation of the disk enclosure and/or BIOS.

In my case, I purchased the disk enclosure for a smaller disk where there wasn’t a problem. But I tried it with that 1T disk. I actually created the protective MBR using the enclosure. When seen later as an internal disk, the protective MBR only covered a small part of the disk (I guess 1/8 of it). But no data was stored. The enclosure is doing fine with a smaller disk. And I later purchased a SATA disk docking station, which handles the larger disk properly (see 512 byte logical sectors).

I missed that one (512 vs. 4096). But I still do not realy understand how this can happen :(. Hardware/firmware case I presume. I never was very good at those.

So I played around with this some more. Since it’s two external hard drive interfaces through USB 2/3, this is really tough to troubleshoot. Leap is the only system which seems to have no problems (and seems to be independent of the USB2/3 aspect) - BUT - I noticed Leap mounts the 3TB drive (formatted on USB2 ext4 and OS13.1x64) as an 3TB “removable” drive. The USB3 interface on Leap (in an old laptop) reads the 4TB drive as “primary” - does this provide any clues? It’s a little problematic that all drives are referred to as “primary” in Dolphin/KDE. But the drive I formatted on OS13.1x64, then read on Leap, gets a designation as a “removable” drive.

BTW: All my many USB thumb drives are referred-do in Dolphin/KDE by their drive names, not as “primary” or “removable.” Weird!!!:\ But does it mean anything or is this just an overlooked feature of Dolphin?

OpenSuSE 13.1 does not automount a USB hard disc drive like a USB memory stick. You have to mount it the old-fashioned way: mount /dev/sdb1 mount. Note that your USB drive may be recognized as something else, e.g. /dev/sdd1 if you have another USB device like a memory card reader installed. However, a kernel update will allow automounting.

I think some of this depends on the controller chips in those external USB drive adapters.