Say I have a PureOS installation on a MacBook Air (EFI boot). It’s been used for quite a while, kept up-to-date, configured to my taste, lots of stuff installed (a fleet of browsers, docker containers, KVM machines etc.).
Now I want (possibly temporarily) to just swap the hardware: replace the Mac with Librem 13 (SeaBIOS boot). I don’t want to install PureOS on it from scratch and configure/install all the stuff all over again. Ideally, I just want to rsync the existing installation from the Mac to the L13. After a while I might want to rsync it back to the Mac, and so on.
The approach I have tried so far was to install a fresh/clean PureOS on the L13 (to ensure BIOS boot works), update it and then use rsync to overwrite the root file system from the Mac’s one, paying special attention not to overwrite the boot/grub/i386-pc folder. (Of course this was done while booted from a 3rd installation on a USB stick so that both the source and target root filesystems were not “live”).
Yet it bumps into various difficulties during boot. For example, the last brick wall was some missing firmware somewhere:
Is there some solid/robust/canonical approach to accomplish the mission? How exactly should the root filesystems be rsynced to avoid any boot issues? (Let’s assume there is no separate /boot partition on either side — the boot folder is included in the root filesystem).
In practice, probably not. I don’t think your approach will ever be robust. It could work but it could just as easily break.
A safer approach might be
to save a listing of what is installed on the old computer, then use that as a shell script to install stuff on the new computer until the installs match (a fairly exact match of package and version will be needed - and for this to work you will need to ensure first that your old computer is fully up to date)
to save your entire home directory tree and punt that you can replace it in its entirety on the new computer with the copy from the old computer.
That won’t replicate some system configuration however.
That won’t handle the situation that there is additional hardware on the new computer that requires the installation of additional packages.
A different and somewhat theoretical approach (that can’t be applied retrospectively) would be to develop a shell script on the old computer that gets you from a virgin install to the current state - and then apply that shell script on the new computer. That’s only going to work if absolutely everything significant that you have done can be captured in a shell script and you are rigorous about capturing changes.
This is basically what I do except that a document replaces the shell script and hence there is a lot more typing and a lot more to do but with less risk than install and configure from scratch.
rsync is a non-starter if the architectures don’t match e.g. x86_64 going to ARM. So let’s assume that we are exclusively talking about x86_64.
Realistically both computers would need to use DHCP on any network interfaces that they have if using any kind of replication approach.
I haven’t even considered the implications for containers / VMs.
After hours of cloning filesystems between various block devices, I regret to admit the truth of that statement.
Something like that would certainly make sense when replicating installs across many devices often.
But if doing it 1-2 times a year to move from just one laptop to another — nope. The scripts will outdate quickly.
A PureOS feature called “Clone Installation” would be nice to have one day.
Nah. Moving data around isn’t a problem (I use partclone by the way, much more smart/efficient than dd). Getting different hardware to boot with the same data is the problem.
I recently had cause to do something similar for Mrs Wade’s iPhone. So understanding that we are talking about a highly proprietary, locked-in, locked-up environment where Apple controls everything … migrating from one iPhone to another, which is an automated process, … even then it didn’t work 100%.
Yes, definitely beats having to move everything by hand and reconfigure everything but even then there were some glitches i.e. some things that didn’t work immediately after the migration (and which I therefore had to tidy up manually).
Now imagine what would happen with Linux, where you are encouraged to own your own computer and control your own computer. And let’s face it, we do like to tinker.
I wouldn’t dissuade Purism from providing such a function but I would dissuade users from having inflated expectations of how well it will work.
As a philosophical question … when the system automates things for you, it cuts out 98% of the work but it makes you 98% less competent to fix the 2%? Just ponderin’
