On 8/8/26 05:07, mick.crane wrote:
root@melon:~# fdisk -l
Disk /dev/sdb: 111.79 GiB, 120034123776 bytes, 234441648 sectors
Disk model: CT120BX500SSD1
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: D97B2271-48BB-4988-BEFA-5153C05D7C94
Device Start End Sectors Size Type
/dev/sdb1 2048 2000895 1998848 976M EFI System
/dev/sdb2 2000896 222339071 220338176 105.1G Linux filesystem
/dev/sdb3 222339072 234440703 12101632 5.8G Linux swap
STFW "CT120BX500SSD1", I find the Crucial BX500 SSD:
https://www.crucial.com/support/ssd-support/bx500-support
Note that the production description/ marketing size is "120 GB" due to
the International System of Units (SI, French: Système international
d'unités):
https://en.wikipedia.org/wiki/International_System_of_Units
120034123776 bytes =~ 120 GB
GPT PMBR size mismatch (234441647 != 468862127) will be corrected by write.
The backup GPT table is corrupt, but the primary appears OK, so that
will be used.
The backup GPT table is not on the end of the device.
Disk /dev/sdg: 223.57 GiB, 240057409536 bytes, 468862128 sectors
Disk model: SA400S37240G
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: D97B2271-48BB-4988-BEFA-5153C05D7C94
Device Start End Sectors Size Type
/dev/sdg1 2048 2000895 1998848 976M EFI System
/dev/sdg2 2000896 222339071 220338176 105.1G Linux filesystem
/dev/sdg3 222339072 234440703 12101632 5.8G Linux swap
STFW "SA400S37240G", I find the Kinston A400 SATA SSD in size "240 GB":
https://www.kingston.com/en/ssd/a400-solid-state-drive
Regarding cloning and the GUID Partition Table issues, WikiPedia appears
to have good information:
https://en.wikipedia.org/wiki/GUID_Partition_Table
Cloning the 120 GB SSD to the 240 GB SSD is expected to cause GPT
problems on the 240 GB SSD because the disks have different sizes:
* The primary GPT header will have the wrong "Backup LBA" field value
(Offset 0x20).
* The primary GPT header will have the wrong "Last usable LBA" field
value (Offset 0x30).
* The secondary GPT header is in the wrong location.
* I expect the secondary GPT header and/or table will have multiple
wrong field values.
I suppose an expert could hack the GPT primary and secondary (backup)
headers and tables with a hex editor (including "CRC-32" field values,
Offset 0x10), but I would prefer using a tool:
1. Clonezilla is well-known FOSS cloning software. I believe it can
deal with GPT disks of differing sizes:
https://clonezilla.org/
2. gdisk(8) might be able to do the GPT adjustments after cloning with
dd(1).
3. sgdisk(8) is another possibility.
The KISS solution would be to do a fresh install of your preferred OS
onto the 240 GB SSD, mount the 120 GB SSD read-only, and migrate your
configuration settings and data from the 120 GB SSD to the 240 GB SSD.
David
