I’ve been trying to move my filesystem (manjaro cinnamon) between drives using lots of different methods over the past few weeks and have run into errors every step of the way. At the moment, my plan is to move it from my 256gb xpg nvme ssd to a 512 gb wd blue ssd.
I previously successfully moved my system from a 500gb HGST hard drive (from an old laptop that got fried) to the 256gb ssd, by first installing a fresh manjaro cinnamon on the ssd, then using clonezilla to replace the ext part of the ssd with the ext on the hard disk (my filesystem). After I edited /etc/fstab and updated grub ( and probably did some other stuff i dont remember) which worked after a lot of struggling.
Now, I’d like to move the files back to that hard drive, in order to move them to the 512 gb ssd as i only have 1 nvme m.2 slot. Copying the full 256gb drive at once (not by part) gives a blue screen with kernel panic (this was expected) but the previous method I detailed involving clonezilla puts me into an emergency prompt. Also of note is that I’ve started using rEFInd in order to avoid having to update grub.
I haven’t run through this in a week or so, so I don’t have pictures or anything readily available. I’d just like to know if anyone here has experienced similar difficulty (particularly with the bootloader) and how you fixed it… if more details are needed I will gladly give them. I’d also like to change desktop environment to plasma at a later point; if it would be simpler to do it as a part of this process then I’m open to it
You want to move your system from one nvme to another, but need an intermediary because you can only connect one nvme at a time.
That intermediary is /dev/sdc
Correct?
That intermediary is just that - you don’t really need to boot and run the system from it.
Correct?
You probably only really need your data, what is stored in your $HOME
As opposed to: the whole system needs to be transferred.
Copying the contents of your $HOME to the intermediary
or the whole system, including $HOME, to the intermediary
is most easily done by using some live system booted from USB.
It’s basically what a backup is …
Format your /dev/sdc with an ext4 file system
and then simply copy from nvme to there
while you are in a live system.
Then change your nvme, install a fresh system on it
and copy your user data back to it from /dev/sdc
I would simply adapt it in your situation. It’s an example, not a “copy&paste into the terminal, and you’re done”.
Format the HDD /dev/sdc completely anew, as image files are now stored there.
Shrink the partitions/filesystem with gparted on /dev/nvme0n1 as much as possible to reduce transfer time. You can expand it after writing to the new NVME.
As I understand it, the “old” nvme has a capacity of 256 GB
the target, the “new” one, has a capacity of 512 GB
The method you describe - using dd - would result in a file system 256 GB in size on the “new”, larger, nvme,
leaving half of it’s capacity unused.
Would it not?
It could easily be expanded to use the whole capacity in an additional step, of course.
Or does the last step
take care of that and I just don’t understand what that does?
By saving and transferring only the actual contents of the file system (what I broadly described)
the amount of data which has to be stored and moved around twice would be ~31 GB only,
compared to the 256 GB image of the whole device.
… or even less than 31 GB, when only $HOME is transferred …
Sure. That’s how copying works. It makes a 1:1 copy and doesn’t enlarge it.
Sure.
If you copy the partition table 1:1, the sizes of the partitions will be exactly the same, but if the drive is bigger or smaller, the endpoint won’t be correct. cgdisk is able to read it and repair/correct it, then just write the corrected partition table.
No, it doesn’t expand a file system, ONLY the partition size.
You are correct. In that case, I would actually shrink the filesystem/partition before doing a dump. Which for me would be a logical step not to mention. Thanks for the hint.
be very careful with clonezilla :
it duplicate UUID , so do not mount 2 disks with same UUID , because you dont know which one will be updated , as is come from /etc/fstab
also copying from dd 256 go to 512go with clonezilla will put only a 256go size disk
… but that is not important - this is just the intermediary storage location
Why would you want to boot that system from the hdd? (rhetorical question).
You want to have it on the other, new, bigger, nvme. No?
Start over.
Choose one of the methods - what I suggested or what @megavolt suggested.
The reason is simple: Linux can recognize and read any file system on block devices or images without a partition table. A partition table is just a table, like marked boxes on a checkerboard. Then you fill the marked boxes with content (file system). So you usually need 2 steps. Increase the partition size and increase the file system size. Gparted does both.
There’s a much easier way,
Copy the contents from your home directory to your intermittent drive. Don’t forget your browsers bookmarks and passwords. And make a list of any applications that you’ve added to the basic installation.
Remove the old drive and do an installation. Here you may have to hold press the key combination to permit you to boot from whatever your using as your installation medium.
Then after you’re set up, copy the information over.
The installation will do all of the partition sizing without any need for you to do interact, unless you have special partitions, like a second home partition or a separate backup partition
Format the HDD /dev/sdc completely anew, as image files are now stored there.
(or something like that the saying goes …).