Skip to content

Instantly share code, notes, and snippets.

@baatochan
Last active February 18, 2024 18:57
Show Gist options
  • Save baatochan/99589fb030f8bda9113dd9495febd539 to your computer and use it in GitHub Desktop.
Save baatochan/99589fb030f8bda9113dd9495febd539 to your computer and use it in GitHub Desktop.
Differentiate a Linux installation after cloning it to a different machine

Differentiate a Linux installation after cloning it to a different machine

Recently I started a habit of cloning my personal Linux installation instead of installing it clean because I don't wanna spend a time of setting my whole workspace, again and again. However this solution results in an unwanted drawback of having everything the same on two machines (surprising, I know).

When I started to use the KDE Connect app I encountered issues with it because 3 machines had the same key and it didn't work properly. Then I started to think about a list of things that should be changed/regenerated after cloning Linux installation. Just to make it clear - none of the things beside KDE Connect that I describe here are needed for the system to work. I never experienced any other issues related to running three machines with the exact cloned OS but I wanted to do it to mitigate any possible problems that may arise in the future.

Note: Before removing any files, you may do a backup of them in case something goes wrong.

Things that I tend to change/regenerate

Hostname

The first thing that almost everyone thinks of changing is a hostname of a new machine. I like having all of my devices to have a custom unique hostname that is based on my private template.

Changing of the hostname is easy and can be done with a following command:

hostnamectl set-hostname <your-hostname>

After that it is suggested to also edit the /etc/hosts file and replace the old name with the new one.

If you're using google chrome it may happen that your profile will became locked after reboot because Chrome will detect that the profile has been used on a "different" PC. In that case to unlock the profile simply delete all the files Singleton* that are present in your chrome profile directory (keep in mind that the path my be different depending on the version and the way you installed your Chrome).

rm -rf ~/.config/google-chrome/Singleton*

However that's not all as your hostname is also indirectly used by some apps that require you to change it manually. In my case it is a Bluetooth device name and KDE Connect.

In case of the Bluetooth name I tend to have it very similar to the hostname, but with the proper formatting (having ' and spaces). In KDE you can change it using the system Bluetooth settings.

KDE Connect

KDE Connect uses its own host keys and you need to delete KDE Connect settings on a cloned PC in order for it properly work. If you have two instances of KDE Connect with the same keys in the network other KDE Connect apps will see only the first available one. You may be OK with just deleting *.pem files from KDE Config dir but I suggest deleting the whole directory altogether, because other config files present there are temporary ones, or the ones that needs to be changes/regenerated anyway. I also suggest closing the KDE Connect process before removing the files.

rm -rf ~/.config/kdeconnect

After removing the config - reboot the PC or kill the KDE Connect process (if present) and restart it.

If the keys are properly regenerated other devices should correctly list all your devices. If you want to have the hostname for KDE Connect different than the real hostname then remember to change it in the KDE Connect settings.

Partitions UUID

This is the least needed one to change from the ones described in this gist, but I want to change it anyway to prevent any issues if I ever connect both of this drives to the same PC.

To change a partitions' UUIDs and PARTUUIDs you need to boot the PC using a live Linux (we have to be able to unmount the partitions).

The first step which is optional (but I want to do it) is to remove and recreate EFI partition (to remove all unnecessary stuff out of it). To do it just use any partition manager (can be KDE Partition Manager) to remove the partition and create it again. After that format it as FAT32 and leave empty for now (GRUB will be reinstalled on it later on). Make sure that the newly created partition has an EFI/ESP flag set up (GRUB can work without it, but it may results in the issues in a long run; that flag might be called "boot" by some tools such as KDE Partition Manager).

The next step is to change the UUID of the other partitions (if you didn't recreate the EFI partition change the UUID for it as well). To do it use the tune2fs. Use blkid to check if the UUID has been correctly changed.

tune2fs -U random <your-system-partition> # eg. /dev/sda2
blkid

After that use gdisk to change the PARTUUID. This tool can be used only if your drive has GPT partition table.

gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.9.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): x                                 # enter x to change to experts menu

Expert command (? for help): f                          # enter f to randomize PARTUUIDs for all partitions

Expert command (? for help): m                          # enter m to go back to main menu

Command (? for help): w                                 # enter w to write the change to disk

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y                        # enter Y to confirm
OK; writing new GUID partition table (GPT) to /dev/sda.
The operation has completed successfully.

After that use chroot into your installation. If you use manjaro-chroot or something similar for your distro it will probably fail trying to mount any partitions - it is expected. Edit your /etc/fstab file with correct UUIDs for all the partitions that was changed. After that chroot again and everything should mount correctly.

If you have a hibernation set-up, remember to change the value of UUID in /etc/default/grub as well.

The next step is to reinstall grub, regenerate initrd and update-grub.

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Manjaro --recheck
mkinitcpio -P
update-grub

After that exit the chroot, reboot the PC and everything should work OK.

Machine ID

Machine ID is an ID used by systemd. Generally it is a risky operation to change it on a running system, but I didn't encountered any issues because of that.

To change the machine ID you need to remove the /etc/machine-id file and recreate it using systemd-machine-id-setup. There is also another file that have the machine ID (/var/lib/dbus/machine-id) but in Manjaro it is just a symlink to /etc/machine-id. If it's a standalone file for you, then make sure both of the files contains the correct new value.

rm -f /etc/machine-id
systemd-machine-id-setup

SSH host keys

It is generally not advised to have two machines running ssh server with the same host keys. To regenerate them just remove the keys and generate them with ssh-keygen. It is advised to turn off the ssh server while doing that. After the keys are regenerated restart the ssh server.

shred -u /etc/ssh/*key*
ssh-keygen -A
systemctl restart sshd

Note: I'm using shred command here for safely deleting the keys.

Additionally as I don't have anything important in the ~/.ssh/known_hosts while having there entries for localhost I also tend to delete that file.

rm -rf ~/.ssh/known_hosts

Summary

This list isn't comprehensive to any extend. There might more stuff that should be changed, but I just didn't think of it. If there is anything that is missing in your opinion, just comment under my gist and I may add it. If I decide that there is something more that should be changed I will update this gist in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment