From: nospam@needed.invalid
On Mon, 5/12/2025 8:43 PM, Carlos E.R. wrote:
> On 2025-05-13 00:22, CtrlAltDel wrote:
>> On Fri, 9 May 2025 17:59:41 -0000 (UTC), evanmac wrote:
>>
>>> con fecha5 May 2025 y hora 11:21:46 GMT+1, "CtrlAltDel"
>>> sacó de su cabeza:
>>>
>>>> if there are any apps I can use to convert them to SSD's?
>>>
>>> app is *SOFTware*, while HDD/SSD are *HARDware*
>>>
>>> Beyond that, you'd like to "convert" a fish into a bird (via software),
>>> seems it possible to you?
>>
>> Well, I'm using Linux Mint 22.1 if that helps any. I know you probably
>> couldn't do anything like this on Windows but, I am using Linux.
>>
>> I mean, I already have these HDD's, why not re-purpose them and give them
>> another function as SSD's. I've been researching it and they say solid
>> state drives give you faster boot times, less power consumption, faster
>> read/write speeds, etc...
>>
>> Why in the world wouldn't I want to take what I have and upgrade them into
>> more powerful and useful drives? I know how to solder and if I need to
>> buy a few parts, as long as they are very inexpensive, I can do that.
>
> What the fuck are you talking about?
>
> We told you, it is impossible to convert a hard disk into an SSD, or the
reverse.
>
It could be a terminology issue.
You can *clone* a slow HDD onto a faster SSD. This is
not exactly the best way to do it, and is merely an
illustration of doing it in the old days. This would cause
excess wear on the destination SSD (writing 512 byte chunks
to 64K pages would be stupid). However, the Linux System Write cache
is going to change the transaction size at some point, so this
is not as bad as a superficial analysis would indicate.
sudo dd /dev/sda /dev/sdb # Works well if the disks are exactly the
same size.
# We actually have some SSDs that are exactly
the same size to the byte. as 1TB HDDs.
You can't convert motors and heads into NAND flash chips,
so you cannot exactly convert between hardware type.
This is not exactly a "Tea, Earl Gray, Hot" machine :-)
By cloning an older disk, you can move the contents
from one place to another.
*******
As an experiment, I took my Lexar NS100 256GB SSD and tried to move
it to my WD Blue 250GB HDD. This was just a test to see how
easy it is for a Year Of The Linux Desktop user, to move from one
disk to another.
1) Clonezilla
It warned that it does not handle destination disks which are smaller than
the source.
while I did not test it, there is no reason to believe they could handle the
other case. (If you move a GPT partitioned disk to a larger disk, you have
to relocate
the GPT table to the correct offset, and not all softwares do this
correctly. There are
yet other softwares that detect this error, and they will put up a warning
dialog.)
Clonezilla still offered to carry on, even though the partition would not
fit, and
a second error dialog appeared when the transfer failed ("no space").
Conclusion: Not ready for prime time. This kind of behavior causes user
hair loss.
2) Gparted
Now, I like Gparted. You can (almost) always get a result with it.
Only once did it trip in a spectacular fashion and drop all its drinks on
the floor.
sudo gparted
OK, so to start with, I thoroughly erased the destination disk. That's
for the purposes of doing experiments, I don't want to pollute the
results via the "history" of the disk drive.
The first step, is getting GParted to prepare the device for GPT partitioning.
This might be termed as "Initialize" or "Disk Initialize", and you have to
select MSDOS or GPT, to match the partition scheme used on the source disk.
Next, in Gparted, the menu has "Copy" and "Paste". This is how we clone!
You can highlight a partition on /dev/sda, select "Copy", then change
the disk selector to the blank-GPT /dev/sdb and press "Paste".
When the destination drive is too small, or, there is no available space
big enough for a too-large partition, the Paste menu item is greyed out.
This means you need to do a "shrink" on the source partition, before
a Copy/Paste to the second smaller disk drive will work. Fair enough.
GParted will not do an on-the-fly resize like some commercial
softwares offer. That's fine. Breaking the operation into two atomic steps,
is all part of the "component nature" of Partition Management. Utilities
do not act greedy with the convenience functions. They strive for accuracy
and "no damage to user goods". That's the way it should be.
So I got my materials onto the destination.
Two issues and three work items:
1) Partition types (not IDs as such) are still wrong. Dest was 0700, should be
EF00.
2) There are duplicate UUID and since the boot sequence may depend
on the exact UUIDs, fooling with them can break boot.
3) Once UUID issue has been resolved, the Boot Repair from YannUbuntu
is needed, for a convenient reinstallation of GRUB.
Using
sudo blkid
I got a dump of the identifiers for the partitions on the source and
destination.
The PARTUUID (not used for boot but used as identifiers on the GPT partition
table entries), are easily randomized. The "sudo gdisk /dev/sda" then X and K,
can use the expert mode randomize function, and that changes the PARTUUID.
I think it's a natural part of cloning, that the destination disk PARTUUID
ends up different anyway. We are "over-covered" on that one. The PARTUUID is
highly likely to be treated well.
The main UUID number listed is for the filesystem itself, and when you clone
partitions,
the destination disk should have new UUID values generated. I expect the
"blkid" utility can do this for you, but I did not complete that part.
When I checked with GDisk, I noticed
/dev/sda EF00 (EFI ESP partition type
[Source Disk]
/dev/sdb 8300 Linux partition type (there is now a value just for this)
/dev/sdb 0700 When GParted cloned, it only noticed the FAT32 aspect,
it did *not* make an ESP declaration
/dev/sdb 8300 This one was cloned properly. No complaint.
Then I had to do
sudo gdisk /dev/sdb
and change the partition declaration on small EFI partition to "EF00".
By doing this, the Boot Repair DVD I used, it stopped complaining about
my setup on /dev/sdb . I was trying to do a boot repair, while pretending
my UUID values were fixed (didn't finish that part), and the Boot Repair
was puking when it saw the "0700" and not "EF00".
The 2023 disk is the latest "boot repair disc". If you make a DVD of this,
[continued in next message]
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
