I would like to transfer Opensuse 15.2 system from my old Asus x53z laptop to a new Lenovo Legion 5 15. The hardware specs are quite different. The old laptop has an AMD A6 cpu with built-in Radeon graphics. The new computer has an Intel Core I7 and Nvidia Geforce GTX 1660. I’ve loaded an amount of extra software from the repositories on the old system and have some proprietary software in root that I’d like to preserve as is. What I was wondering, is it possible to use something like Clonezilla to clone the old root file system to the new computer and then use the upgrade option on the OpenSuse installation disk to create a functioning, bootable system? If not, will I have to reinstall OpenSuse from scratch and recreate the old system? In any case, I will be cloning the old home file system, so either way at least that part of the system will be preserved.
Odds are the old disk if same media type could be plugged into the new laptop and booted. Automagic might even make X work without any tweaking, though not necessarily optimally. Only by trying would you find out. At worst you’d need to do some tweaking from a shell prompt or text mode YaST for network, sound and/or X. The new is probably Optimus, so would need suse-prime to be installed for optimal X operation. Proper cloning should produce the same result as simply putting old disk into new laptop. Cloning a disk to put into some other PC here is rather routine, ho-hum activity.
I’d expect that the disk is both better and might not be easily accessible (Today’s laptops aren’t always the easiest to open).
I’m a big fan of using Clonezilla, just do a “disk clone” to keep it simple, else you can clone individual partitions if you have good reason.
Of course, the cloned image won’t have all you need unless you do things like add the nVidia repository beforehand, drivers for your nVidia GPU won’t install on first boot but the nouveau driver will be loaded or you’ll be using the Intel GPU (less likely) which doesn’t require any action (Intel submits its GPU drivers to the mainline kernel).
TSU
Exactly this, may well be a sticking point –
- The old system has AMD firmware.
- The new system will need the newest Intel firmware and, possibly, a specific Nvidia graphics driver …
If the required packages aren’t installed on the old system , the clone to the new system will more than likely fail …
Although anything is possible,
I’d consider an unbootable system very unlikely…
As I noted, the proprietary nVidia driver wouldn’t be available if the nVidia repo wasn’t added before cloning (If the repo is available, the install happens automatically… the system should identify the new GPU automatically during boot using udev and find the new driver in the nVidia repo) but even if you don’t add the repo, your system will still recognize the GPU change and install the open source nouveau driver.
As for the firmware, if the existing already installed firmware package doesn’t already contain the definitions for the new hardware (including but more than the CPU), I don’t think any case should exist that would block booting… Without the firmware updates you just would be vulnerable to things like sidedoor attacks and not benefit from performance tweaks. With your first “zypper up” this will be addressed.
The main things that could be problems are drivers that have to do with I/O like keyboard/mouse before a system update because unlike the CPU and GPU, the possibilities are so numerous. But even if the best driver isn’t installed immediately, a backup generic should hopefully be used until a proper one can be installed with update.
Bottom line, there are possible glitches but nothing likely show stopping until you can login and run a system update.
TSU
If the disks are different architecture - it still can be done but you have to rebuild all the boot files.
old arch - /dev/sda
new arch - dev/nvme0n1
copy all the disks with clonezilla - then with recovery disk mount the new drive on /mnt and /mnt/boot/efi
mount -b /dev /mnt/dev - same for run proc and sys
chroot /mnt
grub2-install /dev/nvme0n1
mkinitrd
grub2-mkconfig -o /boot/grub2/grub.cfg
change /etc/fstab to the new UUID’s
ctrl-d to get out of the chroot
umount all the mount
shutdown remove recovery disk and boot
this worked fine moving from a Dell D820 to a Dell 7480.
No data lost.
I had to clean up /etc/udev/rules.d to get rid of D820 devices and change /etc/fstab
to clean up the grub menu to remove the recovery disk just grub2-mkconfig -o /boot/grub2/grub.cfg again.