Gyro:/home/SJL # fdisk -l
Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
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: 0x389a1131
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 16771071 16769024 8G 82 Linux swap / Solaris
/dev/sda2 * 16771072 446851071 430080000 205.1G 83 Linux
Disk /dev/sdb: 111.8 GiB, 120034123776 bytes, 234441648 sectors
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: 0x0001cc68
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sdb2 * 206848 234436607 234229760 111.7G 7 HPFS/NTFS/exFAT
Thank you. ‘Almost’ Everything seems to be in working order minus a few unexpected side-effects:
1.gnome-system-monitor is broken. It first of all looks different, like the default GTK Theme, and I triple checked, I have them set as something else, not default.
google-chrome keeps on asking me to set it to default. It IS default.
Do these suggest data corruption, and I should give it another go, while booted from a flash?
FYI, I did the
dd if/of while booted from if mount.
a partitions is simply the container how the files are actually arranged in that container is do to a file system. In Linux there are many possible file systems. in 13.2 the default was I think BTRFS for root and XFS for home. But others are possible but you would have had to set it when you installed. Otherwise you have the default.
Recently I had a HDD failure and cloned it in the identical manner as I’ve shown.
Something I didn’t quite expect is that partition UUID has also been cloned? I didn’t have to change the /etc/fstab, or mess around in Windows to get the new drive to work identically. Is this typical?
Depends on the software used. The UUID is stored at the front of each partition. If you do a binary copy (clone) of the whole partition the UUID is also copied. If a new partition is created in the process then a new UUID is generated.
If you are cloning to a previously used SSD, then, because of the flash architecture underneath the hood of an SSD, it is helpful to reset the target SSD, to which you are cloning, to factory defaults, before cloning. This can restore the write speed that had been naturally degrading over time and use due to internal fragmentation (again, under the hood – you don’t see this and can’t). The issue is that the internal architecture of an SSD knows nothing of your filesystem; it is operating at a lower level than that. The SSD firmware will not know that you are wiping the SSD, regardless of how you do it (dd, Clonzilla, gparted, whatever).
The following is best done with the device connected directly using SATA and not a USB/SATA adapter, because not all USB/SATA adapter controllers will be transparent to the operation:
Make sure the target SSD’s partitions are not mounted.
hdparm -I /dev/sdX
Verify “not frozen”
If " frozen," then try pulling the SATA power cable, quickly re-insert it, and check again.
hdparm --user-master u --security-set-pass 1234 /dev/sdX
hdparm --user-master u --security-erase 1234 /dev/sdX
Setting the password blocks all further system access to the drive until the erase is done. The erase operation will then also remove the password, as it will reset the SSD to factory defaults.
That is a good idea I haven’t thought of. I will start doing that when I am upsizing/replacing the SSDs.
At the moment, the majority of what I’m using this for is for replacing a failing HDD with an equal size or larger size HDD. It’s been a while since I could afford a larger SSD since I am already at ~512GB for mSATA and NVMe.