I am thinking about (coming from Fedora 33/34) switching to Silverblue.
My system is organized with having mountpoints
/data, /data/docs, aso. additionally to /, /home aso.
How could I organize things so that I have acess to such mountpoints from inside a toolbox?
–
Thanks, Manfred
On Silverblue, you need all mountpoints to be located in sub directory under /var. /home is /var/home, etc.
For toolbox access this is a bit trickier. I don’t have an answer right now 
Thanks. Ok, mounting under /var could be done. But as you indicate this is the easy part.
It’s not quite as seemless as being able to customize the bind mounts, but inside a toolbox, the entire host filesystem is mounted at /run/host. So you can create symlinks in a toolbox container
/var/data → /run/host/var/data
Right now, you need to do this manually after creating a toolbox - there’s no way of automating setup steps like this.
Owen
For the usual mount points (/, /home, etc.) as said everything should be done under /var.
For the rest, let me phrase it like that… What’s the point of using a toolbox container for you? Is there anything you need to containerize/isolate/reliably-reproduce?
If it’s not the case and you need your toolbox to access “everything”, you might as well just overlay.
Do remember that toolboxes are not “free”: you have to keep them up-to-date so each one becomes a new system you have to maintain (or redeploy, but that’s hardly the point: if you have 30 toolboxes you have to periodically ensure none of them jeopardizes your system). I’m also unsure of how base images are handled (e.g. if runtimes are shared of copied every time).
That’s the pull request related to what would gracefully solve the problem: Support ~/.config/toolbox with TOOLBOX_CREATE_ARGS by cgwalters · Pull Request #100 · containers/toolbox · GitHub
In the meantime if you really need containers, either bind mount your data in an accessible location yourself (or might be able to access it in /run/host) or use podman directly. If you don’t, just overlay.
Well, actually I would like to have a toolbox to access basically everything.
I was not sure how much overlay could/should be used. Therefore I was asking how to have access from toolbox.
Well, actually I would like to have a toolbox to access basically everything.
Then it sounds like a toolbox/containers is a bad fit: it is additional work just to shift the “state problem” elsewhere. What I mean is you basically went from “Fedora Workstation” (or similar “traditional” distro) to “Fedora Workstation within a container in Fedora Silverblue”. If you get nothing out of containerisation, why would you spend time to maintain 2 systems instead of 1…
AFAIK, Toolbox is recommended for “everything stateful that can’t be done with flatpaks” out of simplicity and because when conflicts arise when updating (as they would also arise in Workstation), rpm-ostree (that handles the update) does not fail graciously (yet)… At least that’s what I read, not something I have personally experienced. But in principle you can always rollback, fix things and do the update again (which is exactly what happened in the reads I mentioned).
In contrast, you might feel better with the idea such conflicts would only affect toolboxes but the fix is the same anyway: if you can fix your toolboxes, you can fix an update in Silverblue.
Toolbox is a bit of a weird beast as it is though. I find it absolutely wonderful to make throw-away systems. But for actual reproducible development/deployment I would go with podman/buildah. For isolation, depending on what I want, I would go with bubblewrap or podman (or a VM in some rare cases). That being said, I know lots of people are using toolbox to maintain a long-term system-in-a-system which is fair but, to me, feels like trying to cram a square peg in a round hole with all the extra effort it involves.
In the meantime I think that I have to go like follows
If something is needed globally look for flatpak otherwise install it as a layered package.
Specifically, use rpmfusion as a layered package. Useful for stuff where there is no flatpak package available
Nevertheless, some stuff should be installed layered anyway like for example: zsh, vim, gvim aso which I use everywhere.
Overlaying packages is fully supported with rpm-ostree. It’s a trade off whether or not to use it instead of using a toolbox.
With rpm-ostree, updates are atomic. They either happen or don’t at all. The more packages you overlay, the more likely you might run into a conflict during the preparation for an update, especially if you replace RPMs or use RPMs from external sources or coprs. But your system will always be in a usable & stable state an any time and you will have all the time you need to figure out what’s blocking the update.
Before really switching my FC34 to Silverblue 34 I will test things thoroughy in a VM and then even on a spare laptop. As I have been using btrfs for years I can setup the required mounting scheme for Silverblue during installation so that things should work properly.
Regarding overlaying packages I will test things in the Fedora Silverblue 33 VM, i.e. I will try
The last testing will be on my spare laptop
As I said, I’ve never encountered any problem first-hand. If that is the case everywhere (including when there are conflicts in /etc), that really is an amazing guarantee! That is a strong case for Silverblue (vs. Workstation).
Educating people not to thing “overlaying first, containers if I really have the time” is one thing but it really feels like saying “overlaying is ok though” would be nice too. 
/etc/ is also included in this guarantee. rpm-ostree performs a three way merge of changes when you do an update, just before you reboot. If something bad happens, you simply reboot into the same version instead of getting a broken /etc.
Overlaying may not be the best solutions for all cases nor the one you should look at by default but it is fully supported.
Amazing!
I should probably start my own thread if we need to talk more about that but it seems to me that’s precisely my point, especially when flatpaks exist. I’m just saying that now that the “overlay last” message has been successfully conveyed to the end users, saying
is very important too.
Most people around me who “dislike” Silverblue these days are generally super impressed by the guarantees rpm-ostree provide and wish libostree would come to other distros but they are “unconvinced” by all the “oh just run it in a container” for everything, especially on the desktop.