I'm trying to decide on a method to move data between my
Legacy-BIOS desktopo and my EFI laptop. My initial plan
was to use one of the 3.5" drives normally sitting in the
desktop raid tray and connect it in turn to the laptop via
a sata/usb adapter. Looks like a problematic avenue but I
don't wanna buy a usb-portable disk just for this. It's my
first rodeo involving an EFI/Legacy hardware mix and it gets
dizzying, even though I split it into two separate threads :-)

Using my Lenovo T480 laptop

If I do 'fdisk -l' with just a 2tb sata plugged-in via a sata usb adapter
=========================================================================

# fdisk -l
Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: SPCC M.2 PCIe SSD
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1F5BF8E3-EF76-4A16-BF3E-78B891EAB2B3

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 2099199 2097152 1G EFI System
/dev/nvme0n1p2 2099200 14682111 12582912 6G Linux swap
....
/dev/nvme0n1p17 1986019328 2000408575 14389248 6.9G Linux filesystem

*GPT PMBR size mismatch (3907029167 != 488378645) will be corrected by
write*

Disk /dev/sdc: 1.82 TiB, 2000398934016 bytes, 488378646 sectors
Disk model: EZBX-00AYRA0
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 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/sdc1 1 488378645 488378645 1.8T ee GPT*

If I do 'fdisk -l' with a usb stick plugged-in as well
==================================================================
# fdisk -l
Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: SPCC M.2 PCIe SSD
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1F5BF8E3-EF76-4A16-BF3E-78B891EAB2B3

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 2099199 2097152 1G EFI System
/dev/nvme0n1p2 2099200 14682111 12582912 6G Linux swap
....
/dev/nvme0n1p16 1818247168 1986019327 167772160 80G Linux root (x86)
/dev/nvme0n1p17 1986019328 2000408575 14389248 6.9G Linux filesystem

Disk /dev/sdb: 29.3 GiB, 31457280000 bytes, 61440000 sectors
Disk model: Flash Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdefe1877

Device Boot Start End Sectors Size Id Type
/dev/sdb1 8192 61439999 61431808 29.3G 83 Linux
*GPT PMBR size mismatch (3907029167 != 488378645) will be corrected by
write*

Disk /dev/sdc: 1.82 TiB, 2000398934016 bytes, 488378646 sectors
Disk model: EZBX-00AYRA0
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 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/sdc1 1 488378645 488378645 1.8T ee GPT*

If I do 'fdisk -l' with a 1tb dos data disk and a usb stick plugged-in
======================================================================

# fdisk -l
Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: SPCC M.2 PCIe SSD
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1F5BF8E3-EF76-4A16-BF3E-78B891EAB2B3

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 2099199 2097152 1G EFI System
/dev/nvme0n1p2 2099200 14682111 12582912 6G Linux swap
.....
/dev/nvme0n1p15 1650475008 1818247167 167772160 80G Linux filesystem
/dev/nvme0n1p16 1818247168 1986019327 167772160 80G Linux root (x86)
/dev/nvme0n1p17 1986019328 2000408575 14389248 6.9G Linux filesystem

Disk /dev/sdb: 29.3 GiB, 31457280000 bytes, 61440000 sectors
Disk model: Flash Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdefe1877

Device Boot Start End Sectors Size Id Type
/dev/sdb1 8192 61439999 61431808 29.3G 83 Linux

Disk /dev/sdc: 931.51 GiB, 1000204886016 bytes, 244190646 sectors
Disk model: JPVT-00A1YT0
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x8efc6e65

Device Boot Start End Sectors Size Id Type
/dev/sdc1 256 244190645 244190390 931.5G 83 Linux

This 2.5" 1tb WD dos spinner may have other issues but
that's another topic to keep this one simple :-)

1
the following appears in both cases but in different places:

"GPT PMBR size mismatch (3907029167 != 488378645) will be corrected by
write"

- which disk does it apply to?
- why is it there at all?
- what's the fix?

2
the single partition on my 2tb data disk created on my
Legacy-BIOS desktop and plugged-in via the sata/usb
adapter shows up in the EFI laptop as :

/dev/sdc1 1 488378645 488378645 1.8T ee GPT

doesn't make any sense and *cannot be mounted*. Fdisking
it on the Legacy-BIOS desktop shows:

Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EZBX-00A
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: 6EED7FA9-4976-4436-9309-71A2D6371B80

Device Start End Sectors Size Type
/dev/sdb1 2048 3907029134 3907027087 1.8T Linux filesystem

bad sector wrote:

>I'm trying to decide on a method to move data between my
>Legacy-BIOS desktopo and my EFI laptop.

The T480 has pretty good Wifi, it connects to my router at 866Mbit/s
(5GHz) and I use it regulary to copy BIG files (5 - 20 GB) to my NAS.
If you do not have a NAS you could use tools like Synthing or you could
just do it via ftp.

-jw-

--

And now for something completely different...

On Sat, 10 Feb 2024 05:19:07 -0500, bad sector <forgetski@_invalid.net> wrote:

> I'm trying to decide on a method to move data between my
> Legacy-BIOS desktopo and my EFI laptop. My initial plan
> was to use one of the 3.5" drives normally sitting in the
> desktop raid tray and connect it in turn to the laptop via
> a sata/usb adapter. Looks like a problematic avenue but I
> don't wanna buy a usb-portable disk just for this. It's my
> first rodeo involving an EFI/Legacy hardware mix and it gets
> dizzying, even though I split it into two separate threads :-)

The question/subject is misleading as this is about partition tables, not
about boot firmware.

Uefi firmware supports using either gpt or mbr partition tables though some badly
written firmware requires the boot drive to use a gpt partition table.

Legacy bios firmware supports using either gpt or mbr partition tables though some
very old bios firmware requires the boot drive to use a mbr partition table.

> Using my Lenovo T480 laptop
>
> If I do 'fdisk -l' with just a 2tb sata plugged-in via a sata usb adapter
> =========================================================================
>
> # fdisk -l
> Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
> Disk model: SPCC M.2 PCIe SSD
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: 1F5BF8E3-EF76-4A16-BF3E-78B891EAB2B3
>
> Device Start End Sectors Size Type
> /dev/nvme0n1p1 2048 2099199 2097152 1G EFI System
> /dev/nvme0n1p2 2099200 14682111 12582912 6G Linux swap
> ...
> /dev/nvme0n1p17 1986019328 2000408575 14389248 6.9G Linux filesystem
>
> *GPT PMBR size mismatch (3907029167 != 488378645) will be corrected by
> write*

I've never seen the GPT PMBR size mismatch before. A search leads to
https://arstech.net/gpt-pmbr-size-mismatch/
which recommends running "parted -l" and responding with "fix" when asked.

Do that before continuing to use the drive in either system.

The sata/usb adapter should work fine in both systems using either a gpt or
mbr partition table, since it will not be used as the boot drive.

Once the existing gpt partition table has been fixed, how is using it
problematic?

Regards, Dave Hodgins

On 2/10/2024 5:19 AM, bad sector wrote:
> I'm trying to decide on a method to move data between my
> Legacy-BIOS desktopo and my EFI laptop. My initial plan
> was to use one of the 3.5" drives normally sitting in the
> desktop raid tray and connect it in turn to the laptop via
> a sata/usb adapter. Looks like a problematic avenue but I
> don't wanna buy a usb-portable disk just for this. It's my
> first rodeo involving an EFI/Legacy hardware mix and it gets
> dizzying, even though I split it into two separate threads :-)

I don't know what your problem is in this case, but
Linux has two utilities now.

sudo gdisk /dev/sda # Identifies whether disk is GPT or MBR

sudo fdisk /dev/sda # If MBR, use this utility

GDisk has an Advanced options thing that offers some useful
features. I think one of the features, is clearing the two
GPT tables (primary, and the secondary at the end of the disk),
so some of the dumber utilities stop thinking a disk is GPT
when it isn't.

*******

Your other thread, refers to materials such as this.

512n The original hard drives. Up until recently, a few were still available
512e Most modern drives for consumers are like this. 512 on the outside, 4K on the inside.
The cache is used to hide read-modify-write operations to support 512e.
4Kn Server room 4K logical, 4K physical drives. Up until recently,
these were definitely to be avoided, and Newegg stopped selling these
to consumers (too many returns).

Then there is this item:

4Ke Adapter. Converts some kind of drive, into a 4K logical, 4K physical drive.
An OS which really supports 4Kn, would likely eat the declaration it
is 4Kn and pretend not to know or care there is monkey business going on.
Older OSes, will not like this adapter emulation, any more than they
would like it if you connected a 4Kn to a SATA port.

Paul

On 2/10/24 21:16, Paul wrote:
> On 2/10/2024 5:19 AM, bad sector wrote:
>> I'm trying to decide on a method to move data between my
>> Legacy-BIOS desktopo and my EFI laptop. My initial plan
>> was to use one of the 3.5" drives normally sitting in the
>> desktop raid tray and connect it in turn to the laptop via
>> a sata/usb adapter. Looks like a problematic avenue but I
>> don't wanna buy a usb-portable disk just for this. It's my
>> first rodeo involving an EFI/Legacy hardware mix and it gets
>> dizzying, even though I split it into two separate threads :-)
>
> I don't know what your problem is in this case, but
> Linux has two utilities now.

My previous laptop was a 16" Asus G7 gaming type i7 which I thought was
overkill. When it finally crapped out I promised myself I would not buy
another one. BUT I could move not just data but entire Linux partitions
between that and my AMD desktop with no regard or respect for anything
using just a SATA/usb adapter.

> sudo gdisk /dev/sda # Identifies whether disk is GPT or MBR
>
> sudo fdisk /dev/sda # If MBR, use this utility

I've been using fdisk only

> GDisk has an Advanced options thing that offers some useful
> features. I think one of the features, is clearing the two
> GPT tables (primary, and the secondary at the end of the disk),
> so some of the dumber utilities stop thinking a disk is GPT
> when it isn't.
>
> *******
>
> Your other thread, refers to materials such as this.
>
> 512n The original hard drives. Up until recently, a few were still available
> 512e Most modern drives for consumers are like this. 512 on the outside, 4K on the inside.
> The cache is used to hide read-modify-write operations to support 512e.
> 4Kn Server room 4K logical, 4K physical drives. Up until recently,
> these were definitely to be avoided, and Newegg stopped selling these
> to consumers (too many returns).
>
> Then there is this item:
>
> 4Ke Adapter. Converts some kind of drive, into a 4K logical, 4K physical drive.
> An OS which really supports 4Kn, would likely eat the declaration it
> is 4Kn and pretend not to know or care there is monkey business going on.
> Older OSes, will not like this adapter emulation, any more than they
> would like it if you connected a 4Kn to a SATA port.
>
> Paul

As I've since learned here, the mickey-mouse adaptor and EFI are the
root issues and one answer might be FTP transfering instead of adapters.
Interim I've just ordered a 124 gb usb stick, I might even set
Legacy-BIOS only in the laptop BIOS seeing that I really have less than
no use for it myself and w10 doesn't need it either if run in vBox.