Say you are dual-booting Debian and Arch and want to upgrade Debian oldstable to Debian stable. But you want to keep the old installation available as a fall-back option. And you also want to re-use your configuration files and dot files, but in a way that incompatible changes to your dot files in the new Debian or Arch version do never break the old program versions.

How do you do that ?

(I describe my own approach in a comment below.)

  • hendrik@palaver.p3x.de
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    2 days ago

    Since both Debian and Arch aren’t atomic distros or offer rollback… The way I do it is connect my large external USB harddisk, do a backup and then upgrade. If there’s something wrong, I restore the backup, but in reality I was always able to resolve issues with the updates.

    On my server I do LVM snapshots, that’s fairly easy to do. I avoid BTRFS since that messed up one of my filesystems a few years ago, but I heard it got better since and it’s not supposed to do that any more.

  • HaraldvonBlauzahn@feddit.orgOP
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    2 days ago

    root partition / file system

    For my needs, the simplest way is to use an extra partition might be to keep it as a reserve to install the next Distribution release. So you go

    partition A: Debian 12’s root

    Partition B: /home

    Partition C: Debian 13’s root

    And swap A and C for the next upgrade. It is really nice to have a whole compatible fallback system.

    Alternative 1: BTRFS Another possibly quicker way to do this is a larger BTRFS disk and create subvolumes from snapshots and mount these. When the subvolumes are no longer needed, they can be deleted like any folder.

    Alternative 2: LVM One can also use LVM, the logical volume manager, for the same effect. It plays nicely with LUKS encryption for laptops. But I think BTRFS is simpler most times.

    How to move all packages over

    One can copy the system e.g. using a tar backup, fix the mount points by changing the volume label (which identifies the mount point), and do a dist upgrade then. I use “tar” here because it keeps all file attributes.

    I guess that’s the best way to do it on a server. But for desktop systems, I now think it is better to make a list of manually installed packages (there are tools which help with that), and to re-install the packages that are still needed from that list. This has two advantages:

    1. One gets rid of cruft and experimental installs that are no longer needed, which is really important in the long term. (If you have ever worked in a shop where software, files and configurations were not upgraded for ten or twenty years, you might know what I am talking about: IT systems absolutely need clearing out old stuff, too, and that makes the whole concept of “stability” a lot less important).
    2. Some systems (I am looking at you, GNOME) can break in an ugly way if doing an upgrade instead of a re-install. Very bad behaviour, but it can happen. (And this might answer the question whether Debian is more stable than Arch: Yes, as long as you don’t upgrade GNOME).

    keeping dot files, the copy-and-modify way

    And one more thing I do for the dot files:

    Say, my home folder is in /home/hvb . Then, I install Debian 13 and set /home/hvb/deb13 as my home folder (by editing /etc/passwd). I put my data in /home/hvb/Documents, /home/hvb/Photos/ and sym-link these folders into /home/hvb/deb13.

    Now, default dot files are automatically created in /home/hvb/deb13 or /home/hvb/deb13/.config .

    When I upgrade, I first create a new folder /home/hvb/deb14, copy my dot files from deb13, and install a new root partition with my home set to /home/hvb/deb14. Then, I again link my data folders , documents and media such as /home/hvb/Documents into /home/hvb/deb14 . The reason I do this is that new versions of programs can upgrade the dot files to a new syntax or features, but when I switch back to boot Debian 13, the old versions can’t necessarily read the newer-version config files (the changes are mostly promised to be backward-compatible but not forward-compatible).

    All in all this is a very conservative approach but it works for me with running Debian now for many years in a rather large desktop setup.

    And the above also worked well for me with distro-hopping. Though nowadays, it is more recommended to install parallel dual-booted distros on another removable disk since such installs can also modify grub and EFI setup, early graphics drivers and so on, even if in theory dual-boot installs should be completely independent… but my experience is that is not any more always guaranteed (especially if you have an NVidia graphics card which needs extra support in EFI, but well … in that case you asked for pain).

    For the last reason, I now also run Arch in a VM managed by virt-manager - this also allows it to run both systems at once.

    (What I want to point out is that there is nothing which you can’t do with running Debian as host compared to an Arch host and Debian in a VM. The differences are not really that large - Arch has just often newer software and can be nice if you want to participate in the FLOSS community and contribute packets).*

  • TheLeadenSea@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 days ago

    When I update Fedora to a new version it keeps the old version available to boot to on bootup by default. Just another reason why I like Fedora.

    • HaraldvonBlauzahn@feddit.orgOP
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      2 days ago
      • having a second system that boots can be very handy if something breaks - for example one can chroot intp the other system and fix a missing grub install
      • when disk space becomes scarce, one csn mount it where it makes sense
      • just_another_person@lemmy.world
        link
        fedilink
        arrow-up
        3
        arrow-down
        2
        ·
        edit-2
        2 days ago

        No:

        1. Every single modern distro keeps multiple known-good previously running copies of the system to boot back into
        2. The disk space argument is just insane. Having TWO versions of an OS takes TWICE as much space as having one. I don’t even get what you mean. You can mount a disk anywhere at any time
        3. No part of any installed Linux distro can get into a state where it cannot be accessed, unless you encrypt or delete your entire disk without thinking
        4. BTRFS or ZFS can shift back time or keep snapshots, so none of your reasoning is needed at all. Same with immutable distros.