How to make installed packages persistant with bind dirs?

I am installing snapd on debian 11.

I use bind-dir ‘/var/lib/dpkg’ to backup installed packages on whonix-ws and the remain installed on reboot.

On debian 11 /var/lib/dpkg/status mentions snapd but when I reboot it says snapd is not installed. So is there are different directory I need to backup as well?

Here is my current 50_user.conf for snapd based off of dpkg -L snapd:

binds+=( '/var/lib/dpkg' )
binds+=( '/etc/apparmor.d/usr.lib.snapd.snap-confine.real' )
binds+=( '/etc/apt/apt.conf.d/20snapd.conf' )
binds+=( '/etc/profile.d/apps-bin-path.sh' )
binds+=( '/etc/xdg/autostart' )
binds+=( '/lib/systemd' )
binds+=( '/lib/udev/snappy-app-dev' )
binds+=( '/snap' )
binds+=( '/usr/bin/snap' )
binds+=( '/usr/lib/environment.d/990-snapd.conf' )
binds+=( '/usr/lib/snapd' )
binds+=( '/usr/lib/systemd' )
binds+=( '/usr/share' )
binds+=( '/var/lib/snapd' )
binds+=( '/var/snap' )
binds+=( '/usr/bin/snapctl' )
binds+=( '/usr/bin/ubuntu-core-launcher' )

It still says snap command not found on reboot even though I specifically bind /usr/bin/snap and /usr/bin is in my path.

The dpkg folder works on whonix but I feel like I’m missing a folder for debian 11.

Any tips would be appreciated. Thanks a bunch!

EDIT: see reply below

Even after adding:

binds+=( '/var/lib/dpkg' )
binds+=( '/var/lib/apt' )
binds+=( '/etc/dpkg' )
binds+=( '/etc/apt' )

Dpkg is reporting snapd installed now but /usr/bin/snap is gone on reboot even though I have it in my bind dirs

If this means that you tried to start snap in a template prior to an AppVm, that you restarted your computer after binding, and that neither binding /usr/local/bin helps then disregard my post, please.

Doubts via Qubes OS Forum qubes_os@forum.qubes-os.org writes:

Dpkg is reporting snapd installed now but /usr/bin/snap is gone on reboot even
though I have it in my bind dirs

I remember it was not easy to grasp the first time for me … The doc says:

Creation of the files and folders in /rw/bind-dirs should be automatic
the first time the app qube is restarted after configuration.

If you want to circumvent this process, you can create the relevant file
structure under /rw/bind-dirs and make any changes at the same time that
you perform the configuration, before reboot.

(emphasize is mine)

So to make it clear, you cannot install snap in an AppVM and expect it
to survive just modifying the bind-dir array. You have to also modify
the structure under /rw/bind-dirs.

It says in the docs on reboot it will automatically copy everything in 50_user.conf to /rw/bind-dirs

So I install the app which creates all the folders in the normal file system. Edit the 50_user.conf to include all those folders and then reboot. It says it will automatically copy those folders to /rw/bind-dirs on reboot in the docs but it doesn’t.

Am I misinterpreting the docs?

Anyway ya I can create all the folders manually. I can write a script for it. I just have to create the folders and make the same file structure in /rw/bind-dirs right? I don’t have to copy the actual content from all the folders to /rw/bind-dirs right or do I?

Thanks a bunch for the help

Yes, you are. At least, you are misinterpreting what will happen
with a template based qube.

Without bind-dirs - you install the application, which creates all
folders in the normal file system.
When you reboot, only files under /rw, /home or /usr/local persist. The
rest disappear.

With bind-dirs - you install the application, which creates all
folders in the normal file system.
You configure the bind-dirs.
When you reboot, only files under /rw, /home or /usr/local persist. The
rest disappear.
Any files/directories that you specify in bind-dirs will be copied to
/rw/bind-dirs from the root filesystem, but the files/directories
created by the application have not persisted so there is nothing to
copy.

This is why you create these folders manually.
Copying the directories with content will save time and trouble.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

@unman
Sorry to bump an old thread, I have got bind dirs to work with simple applications. However, I am confused about how to handle applications with lots of dependencies.

Right now I have a f35-kleopatra template for my offline gpg qube which is just normal f35 with kleopatra installed. I would love to make this a bind-dir instead of a whole new template but i don’t know, with the current system of how bind-dirs works it doesn’t seem worth the effort.

For example look at how many things kleopatra installed when put in my template.

So I basically need to add all the files installed by 64 packages to the bind-dirs file.

I guess it could be done with a script that follows this logic:
For dep in dependencies:
for each line in $(dnf repoquery -l dep)
$BindsFile >> "binds+=( ‘$line’ ) # add each file installed by dep to config file.
sudo mkdir -p “/rw/bind-dirs/$LineUpToFinalSlashAkaFolder” #create folders in /rw/bind-dirs
sudo cp $line "/rw/bind-dirs/$line #copy actual file installed by dep to /rw/bind-dirs/$line

I mean this script is obviously just a pseudo code example and wouldn’t be hard to right? Has anyone by chance already made a script like this which would make the current bind dirs system actually usable?

I don’t know it seems like more effort than it’s worth that’s why I just made a new template. However, I do think not having an easy system to install one extra application to the main template and nothing else should be easier than it is or maybe even considered to be redesigned completly.

For example:
in fedora35:
qvm-freeze-template #save current fedora35 as in a current state/base layer.
dnf install kleopatra
qvm-create-layer (new template name)

Then on update of the new update instead of treating it as a seperate template and upgrade f35 multipe times, update f35 once, copy base to layered template, then upgrade all packages installed between qvm-free-template and create layer.

So on update of f35-kleopatra:
cp fedora35 to f35-kleopatra:
dnf install/upgrade kleoatra (in f35-kleopatra)
Done.

So basically we only update f35 once instead of many times over, /just remember this is also the base for the layered template instead of upgrading f35 a 2nd time. Then in the layered template just install/upgrade any packages that were installed in the “top layer” (kleopatra). This could be done with lvm snapshots.

The goal of this would be to save space, by simply remembering that fedora35 is also the base for the other template. So size of kleopatra template would be just the size of kleopatra instead of 5GB etc.

On boot of f35-kleopatra, set root file system to default fedora-35 base. Put snapshot CoW changes from when kleopatra was installed on top of this. Done. This could be accomplished easily with either lvm snapshots or btrfs snapshots. Considering 4.1 is already taking lvm backup snapshots of vms, that would be the easiest root. Then we could create layered templates based of CoW changes and only update f35 once instead of updating the same packages over and over for each vm, Then the size of additional layer based templates would just be the size of the application not of all of f35 as well (5gb).

Am I crazy or does this idea at least make sense? I’m not expecting this to be added any time soon or anything, but this at least makes sense right? Or is there a problem with this idea I am missing?

Seems like this would be a much more user friendly system than the way bind-dirs work currently. Just because as a user I feel it’s not even worth the effort to use bind-dirs even for a simple app like kleopatra even though I would like to.

Thanks

For me it is unclear what are you trying to achieve exactly and why, and not how (we know that - by binding dirs, scripting, etc).

Beside this, these things are unclear to me

Then

Do I understand this as you propose to copy single updated template to the other template? If so, for me it’s a big no-no from a security point of view, beause of this, among other things

Why would you create multiple templates if they’re not customized and different to each other? Who says that everyone wants the same package version in cloned templates?

For me it wouldn’t. You propose multiple manual actions, instead of simple “Update” button pressing, right?

I just have a feeling something isn’t perceived here as per design, so still thinking the answer on my first question from this post could help to help you (by me, or anyone else)