Best method to transfer to new laptop

[jserink]

Hi All:

What is the suggested best method to transfer my current system to a new laptop?
I have used the dd in the past but was made aware that its sort of a "blunt" way to do it.
Any suggestions on this?

Cheers,
John

[Banana]

dd just copies "everything" and you have a copy which likely does not match your new hardware. Which means, if you have the exact same hardware again, you can use dd.

I'm guessing the new laptop does also have new hardware. In this case it can be simpler to install it from the start and then copy over your data (your home folder and usage data from other applications.). Done.

[NeddySeagoon]

jserink,

Cheat

Do a new install but before you update @world copy over /home, /etc/portage and your world file.

Change the content of /etc/portage to suit your new hardware.

Now emerge -e @world to rebuild all your installed applications in their new home to match the new hardware.

When you add your normal users, make sure they have the same userIDs on both systems.
if you don't want to rotate your passwords *carefully* copy the /etc/shadow entries for your normal users from the old system to the new one.
You should really rotate credentials though.

dd does a block by block copy, so incurrs one write cycle for used and unused space on SSD. With modern Flash storage, it probably won't matter but in general, it's a bad thing.

[Hu]

Another reason to discourage dd is that since it copies everything, it can be much slower than necessary. If your old system has only 25% of its disk space currently used, a file-aware copy can copy that 25% and skip the 75% of empty space. dd will copy the used 25% and the unused 75%, so even if you don't mind the unnecessary writes to the new storage, you wait much longer than necessary.

As another alternative, if we assume that your new hardware is a superset of what your old system actually uses[1], and we assume you prioritize getting the new system up as soon as possible, then you could make the filesystems on the new system, boot the old system in a read-only state, then rsync all the files over from the old. Be very careful with your rsync options, to avoid inappropriate permissions changes, unintended disconnection of hard links, and so on. This requires a bit of thought up front, but the upside is zero required rebuilds on the new system.

[1]: This depends on whether the CFLAGS of your old system allow the compiler to use any features that the new system does not offer. I believe I have seen references to some recent AMD CPUs deliberately dropping features that were available in AMD CPUs offered a few years prior. I don't know if Intel has done the same. If you're switching from AMD to Intel or vice versa, the risk of incompatibility is even higher. If in doubt, go with Neddy's approach instead. If you want to pursue this route, tell us your old CFLAGS and as much as you can about the old and new hardware.

[figueroa]

If computer 2 is very different from computer 1, you may just have to rebuild everything anyway. Therefore, a fresh install may be the easiest. Otherwise;

Restore a current back from computer 1 to computer 2.
Reconfigure kernel if necessary, i.e. using gentoo-sources. If using a binary kernel, it may just work.
Make other configuration changes needed to new partition layout in /etc/fstab, and /etc/conf.d/net if needed.
Install boot loader.
Reboot; enjoy.

I do this all the time between machines with identical or very similar hardware. Note: If you haven't mastered the backup/restore routine, you should work on that.

[saturnalia0]

I recently changed MOBO and CPU which is somewhat similar, but I kept the drives. Sounds like you'll not keep the drives. In this case a fresh install as suggested above is probably the best option. If you or anyone reading this intends to keep the drives though, here is an alternative approach: viewtopic.php?t=1177300

[rab0171610]

I feel like this is maybe not a popular answer, especially in highly configurable Linux distribution circles such as with Gentoo and/or Arch communities. I don't expect you will do this but I want to put it out there for the permanent record in case any users on the web, even if they are not Gentoo users, stumble across this conversation.
I personally use Timeshift. It is now maintained by Linux Mint, I maintain my own ebuild in my local repository. It is really just a frontend for rsync, which the command used under the hood.
Timeshift can back up (i.e. create a copy of) the entire system on a separate drive, home directories (if selected) and root. The drive for the backup can also be an external USB drive or removable media. By default, It will skip necessary and temporary files and directories (i.e. "/dev/*", "/proc/*", "/sys/*", "/media/*", "/mnt/*", etc.) Linux Mint includes timeshift on their live install media. I then boot using that media, create my partitions on the new disk and then do a Timeshift restore to the new drive. Timeshift has a graphical interface but also a command line interface that works just as well. A Timeshift restore will automatically update the restored system's /etc/fstab to reflect the new UUID's of the new partitions. If the hardware is completely different I may use a gentoo install media to chroot into the system and make any adjustments and rebuild the system as needed. This may also include editing make.conf for the new system, any updates or rebuilds, modifying any configuration files, and/or rebuilding the kernel, updating grub, etc. Most of the time this is seamless and results in the least amount of direct hands on work for me.
Everyone has a different approach. I have found this method to provide good reliable results, time after time.
I think Timeshift is an overlooked application that many assume is geared only towards inexperienced users (newbies) and those with little Linux skills or knowledge. Over the last 25+ years, I have used everything from Clonezilla, dd, and rsync (rsync -axHAWXS --numeric-ids --info=progress2). Timeshift has always been the easiest and foolproof of all the methods and I use it as a backup solution on all of my systems. If I wasn't using Timeshift, my next peferred option is creating the new partitions on the new drive and then using the previous rsync command (with the options) to copy the entire contents of an existing offline partition to the new partitions, one at a time. I usually take the system offline to do this by using a live media or when possible remove the drives to a separate system.
As a side note, I could be wrong but I believe Timeshift was originally created by TeeJeeTech before it was turned over to the Mint Linux team for further development. If that is correct, I believe teejee is now a developer of ZenLake OS, a distro originating from India which was just added to Distowatch this past week. As I have always loved Timeshift utility since I discovered it, I always wondered about this person that created it, Teejee. And then by chance I happened to notice the new addition of ZenLake OS on Distrowatch this week. Upon reading about it, I noticed that that distro's homepage is hosted on teejeetech.com. Anyways, a shoutout to TeeJee, whoever you are.

[pietinger]

[...] I personally use Timeshift. [...] It is really just a frontend for rsync, which the command used under the hood.
[...] Timeshift has a graphical interface [...]

Luckybackup was something similar and also used rsync; I used it as my backup program until it was discontinued. Since then, I've been using rsync directly. What framework does the Timeshift graphical interface use? (QT, GTK)

[rab0171610]

Luckybackup was something similar and also used rsync; I used it as my backup program until it was discontinued. Since then, I've been using rsync directly. What framework does the Timeshift graphical interface use? (QT, GTK)

It uses gtk The command for the graphical interface is timeshift-gtk. However, it has a command line interface that works wonderfully and has simple syntax. The gui is nice but is not really necessary, which makes it easy to operate outside of the desktop environment. By default it uses cron but I have systemd timers instead. I use it with ext4. What I like about it is that the backups are in dated directories on, in my case, a separate drive. I usually keep ten and can just manually restore or inspect individual files from it if necessary, rather than doing a complete restore. This gives me freedom to experiment or test software or updates and I can easily roll back. This is probably similar to btrfs except that I can actually browse through the back up files. I can also compare with diff to see what has changed in an updated file since 3 days ago. I have also installed another distro over my Gentoo on the rare occasion I wanted to see what it was like on real hardware. I then booted a live media, deleted everything on the partitions using a simple "rm"(to avoid issues), and did a restore and had my Gentoo back the way it was on the last backup. I just like the convenience of knowing I have duplicate copies of my Gentoo drive for the last ten days or so. It provides a peace of mind.
Also, it is great for doing a restore on a newly partitioned disk. As I said before, I can chroot in to modify the newly copied but pre-existing Gentoo to work with the different hardware on the new machine and rebuild what is necessary.
The ebuild in in GURU. I posted about this previously, and grknight helped me with the solution. . . I disabled the x11-libs/xapp
dependency in my own ebuild (it should only be useful in Cinnamon, Mate or a Linux Mint installation):

Code: Select all

src_configure() {
        local emesonargs=(
        -Dxapp=false
)

Also, to note, Timeshift does not backup home directories by default but can be set to do so. Directories can be explicitly included or excluded. Configuration options (done through the gui) is stored in simple .json files and can edited manually.

[pietinger]

rab0171610,

thank you very much for your detailed answer! ... Maybe someone reads this and think it would be nice to have it in our repo (our guru) ...

[rab0171610]

You are most welcome. I forgot to mention that it also supports btrfs snapshots. According to the Arch wiki,

Configuring btrfs snapshots - Timeshift requires a flat Btrfs layout with subvolumes for / and optionally /home being named as /@ and /@home."

That wiki page provides extensive information for anyone that is curious and wanting to know more:
https://wiki.archlinux.org/title/Timeshift

[figueroa]

Timeshift is available in the guru repository:

Code: Select all

$ eix /timeshift
* app-backup/timeshift [1]
     Available versions:  ~23.07.1 ~25.12.4
     Homepage:            https://github.com/linuxmint/timeshift
     Description:         A system restore utility for Linux

* app-backup/timeshift-autosnap [1]
     Available versions:  ~0.9-r1
     Homepage:            https://gitlab.com/gobonja/timeshift-autosnap
     Description:         Automatically creates a timeshift-snapshot when executed

[1] "guru" /var/db/repos/guru

The backups, which are not compressed, take a lot of space. I use a variety of homegrown scripts that use tar to output zstd compressed tar archives which can then be restored in whole or in-part locally or to other computers. My scripts and others similar can be found here by searching for stage4.

[rab0171610]

The backups, which are not compressed, take a lot of space. I use a variety of homegrown scripts that use tar to output zstd compressed tar archives which can then be restored in whole or in-part locally or to other computers. My scripts and others similar can be found here by searching for stage4.

That is true. The number of backups you are able to keep is limited to the space you have. Each of my Gentoo laptops has a 1TB NVME drive dedicated to Timeshift backups. So for me, it is not really an issue. For many people, 1 complete relatively recent copy of their root partition minus temp files and populated directories like /sys and /dev is enough to be able to roll back in case of disaster or drive failure. Or in some cases restore a single configuration file. As timeshift saves only the root partition and not the home directories by default, many people easily have room somewhere to save up to 5 rotating uncompressed root partition backups for the average binary distro. My current Gentoo root partition is 58GB and my Debian root partition is 11GB. Obviously, with source distros like Gentoo, there is additional overhead in the build environment. Investing in additional storage media was an investment but for me it is worth it for the peace of mind.
Compressing and archiving the uncompressed backups is definitely a good option for those that need to do so. The compressed backup can always be uncompressed before a restore operation, which is something that under ideal circumstances should rarely need to be done.

[b11n]

so many reasons not to use `dd`. A few that don't seem to have been covered:
• dd won't notice filesystem corruption on the source volume, so neither will you. The copy will complete successfully, you'll hit it later, and not know what to suspect. There's never a good time to find out about FS corruption, but the best time is now, not later. If you're going to read every file anyway, you may as well validate the tree while you're at it.
• dd is so low level it preserves even fragmentation. Why would you want that.
• dd really only make sense on identically sized partitions. Yeah, some FS's will let you grow it after, but why bother?
• not trivially resumable if you have to interrupt the process
• fat-fingering the destination partition will be consequential, and it seems to happen to people often enough. Making the same mistake with mounted FS's will probably just result in a directory or ten that can be easily deleted, and at least mk*fs will squeak if the destination appears to already contain a filesystem, or is mounted. dd will just bulldoze it.
• (Gentoo specific) no option for screeds of busy terminal output during the operation like in the movies

[Zucca]

My method has quite often been

• edit /etc/portage/make.conf, set -march=x86-64 in *FLAGS
• emerge -e @world
• move the hard drive to a new computer
• Boot new computer, and adjust /etc/portage/make.conf

... This of course, if you plan to keep the hard drive.

I've also done The cheat method mentioned by Neddy. It let's you perform new partition scheme easily.

Sometimes I just start a new Gentoo install on the new computer, and after first boot I run rsync to transfer files I need from the old computer.

I'm also going to switch my laptop soon, so I'll need to perform similar task too. In my case I need to switch from arm64 to amd64.
If you're in similar situation, ie. switching to a completely different CPU architecture, the first method I mentioned won't work. In fact It only works with amd64 -> amd64 transfers.