I want to clone the root O/S from one laptop (Lenovo) to another laptop (ASUS), where the hardware capabilities between them are different, of course.
I’m a UNIX guy and have done these kinds of acrobatics in the past via the CLI (on Solaris and Linux), but am hoping for a modern, more streamlined alternative. Ideally:
Just worry about the slash (/) filesystem, nothing else.
The solution would trigger a rebuild of device trees, nodes, etc
Would adjust device UUID and / or LABELS in destination system’s configuration files (e.g. grub.cfg, fstab, etc).
It would discover that Windows 10 is already present on mdXXXp1 (which, by way is hardware RAID) and adds it to GRUB.
No LVM is needed.
Both source and destination are configured for BIOS (not EFI).
This is probably a lot to ask for, but I may be surprised. The trick is always the device-tree rebuilding, which I forget how to trigger these days; as well as hunting down and editing all the files that reference a UUID or LABEL. As well, grub2-install /dev/xxx, while booted off a LiveDVD always seems to get fooled because because it’s booted off a USB or DVD.
It’s just a hassle. But I’m open to ideas and step-by-steps.
This approach looks very risky to me. You will be installing the OS in a nonstandard way. And that’s without the additional non-default requirements (Windows 10, BIOS instead of EFI). This means that the testing being done for Fedora is unlikely to have covered your use case and you may well hit obscure bugs that may be very hard to fix.
If you approach this as a user who just wants to end up with a “just works” system I would advise to install Fedora through the standard process, install additional packages and copy the contents of the /home directory from one laptop to another.
If you want to approach this as a “developer” where you want to give this a try and want to see what happens that’s ok. In that case however I don’t have the technical knowledge to answer your question.
You can take a full system image made with ddrescue, clonezilla, etc. and just transfer it to a new system (both operations conducted from a live environment, to keep things simple). If the available space on the target system is equal or larger, things are fairly easy, you run a resize after cloning. If not, you’ll have to get creative… Also, if the hardware is very different, you should create an initramfs with all the available drivers enabled (e.g. dracut --no-hostonly, read this) before cloning. From the live system, you will have to install GRUB.
You’ll need to do this.
Hardware RAID? On a laptop, no less. Vendor RAID implementations are a catastrophe waiting to happen, you should choose linux RAID whenever possible (but of course, you can’t install Windows on linux RAID…).
All the other things you mention, device trees, UUIDs, labels, etc. are non-issues.
Not arguing against @alexpl’s solution (which I’ve used myself in the past), but if you run into issues with straight-up copying your system, you could regenerate your original install using your installation’s kickstart file /root/anaconda-ks.cfg and a list of all installed packages generated with dnf history userinstalled. Then you’ll only be left with copying/adapting a few config files you might have edited manually.