Question: reinstallation without breaking about rwfus HOT 5 CLOSED

You can edit the Directories line of /etc/opt/rwfus.conf and generate the new set of directories with rwfus --update/rwfus -u!

[Common]
# All other paths, if left unspecified, derive from this one
Base_Directory     ./test/opt/rwfus
Directories        /usr /etc/pacman.d /var/lib/pacman /var/cache/pacman /my/other/path
--- snip ---

That said, reinstallation shouldn't break anything. the btrfs formatter won't reformat a btrfs-formatted device unless you explicitly --force it to, which I don't

from rwfus.

Alright! I'm gonna try that. If I ever have any trouble, I'll repost here. Thanks!

from rwfus.

Follow-up question regarding my specific case...

I want to synchronize /etc/systemd/system/ because I think that some services symlinks are lost when I update. For instance, avahi-daemon service doesn't seem to be enabled when I update the Steam Deck (or may be I'm missing something), so I have to reenable the service. I wanted to save those paths:

/etc/systemd/system/multi-user.target.wants/avahi-daemon.service
/etc/systemd/system/sockets.target.wants/avahi-daemon.socket

So I figured I should save /etc/systemd/system/. However, I see that /etc/opt/rwfus.conf is part of /etc, but no parent of that path are part of the list of default directories rwfus saves. How is that file preserved ? Is /etc/opt/ safe to write to ? Is it merged with /etc/ in some manner ? Do you think I could write my service files under /etc/opt/ ? However, it would be cumbersome to write my files manually under /etc/opt/. Do you see any way to solve this with rwfus other than saving /etc/systemd/system ? Also, do you see any potential issues doing so ?

from rwfus.

SteamOS Offload overlays /var/lib/overlay/etc/upper on top of /etc/, so it won't get wiped when you update. (The contents of var-A and var-B are synced after the update installs to the inactive partset.) That's actually what inspired me to write Rwfus.
However, Systemd may be trying to start avahi-daemon before rwfus mounts the overlay filesystems. You might see something to that effect in journalctl -xeu avahi-daemon after an update/reboot.

from rwfus.

However, Systemd may be trying to start avahi-daemon before rwfus mounts the overlay filesystems. You might see something to that effect in journalctl -xeu avahi-daemon after an update/reboot.

OK, so you're suggesting I should append rwfus to the list of targets in After= of every service I enable, right?

I just restarted my Steam Deck and I can see that the service is enabled and running, so a reboot doesn't seem to trigger this issue:

● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; preset: disabled)
     Active: active (running) since Tue 2023-01-17 23:40:00 EST; 2min 55s ago
TriggeredBy: ● avahi-daemon.socket
   Main PID: 878 (avahi-daemon)
     Status: "avahi-daemon 0.8 starting up."
      Tasks: 2 (limit: 17686)
     Memory: 1.4M
        CPU: 65ms
     CGroup: /system.slice/avahi-daemon.service
             ├─878 "avahi-daemon: running [steamdeck.local]"
             └─968 "avahi-daemon: chroot helper"

Otherwise, I have this other service which wasn't started for some reason at some point, but I didn't have to re-enable it as the symlink lives in /home/deck/.config/systemd/user/default.target.wants/:

# /usr/lib/systemd/user/mpDris2.service
[Unit]
Description=mpDris2 - Music Player Daemon D-Bus bridge

[Service]
Restart=on-failure
ExecStart=/usr/bin/mpDris2 --use-journal
BusName=org.mpris.MediaPlayer2.mpd

[Install]
WantedBy=default.target
# WantedBy=daemon.target

I guess it could have failed to start for the same reason. I'm going to be more vigilant and try to reproduce this. If I can, then I'll try to add some rwfus to the After= targets list of my services. Then, I'll update...

from rwfus.