transactional-update and /opt
Hello,
This is mostly about MicroOS Desktop. So, leaving it alone whether or
not it should be done, one may want to install Google-Chrome with
transactional-udpate.
Now, Chrome (but also other apps, I think) lives in /opt. Back when I
installed this workstation that I am using as my desktop with MicroOS,
this just worked. You go in `t-u shell`, add the repo, import the key
and `zypper in google-chrome-stable`.
In fact, in this system, I have /opt/google with the browser in it. In
a fresh install in a VM, I can do all that same thing. However, when I
exit the `t-u shell`, I'm warned that:
The following files were changed in the snapshot, but are shadowed by
other mounts and will not be visible to the system:
/.snapshots/4/snapshot//opt/google/chrome/....
[bunch of lines like this, all with /opt in path]
And as "promised", after reboot, /opt is just empty.
Sooo... What's going on? :-)
Is this a bug or a feature? If it's a feature, it's preventing user to
install things like Chrome in MicroOS desktop, so it would be wonderful
if we also could think of a workaround. :-O
In fact, I've done this test because a user on Telegram was reporting
this very behavior (browser installed but not really there).
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<
Hi, On Fri, Mar 05, Dario Faggioli wrote:
And as "promised", after reboot, /opt is just empty.
Sooo... What's going on? :-)
You did not follow the main mantra: your workload should run in containers or flatpak ;)
Is this a bug or a feature? If it's a feature, it's preventing user to install things like Chrome in MicroOS desktop, so it would be wonderful if we also could think of a workaround. :-O
/opt is for 3rd party software and needs to be writeable, thus is not part of the snapshot. RPM does not have the concept of two databases ... So, if you install an RPM with files in /opt, we have a problem: 1. if we mount /opt for transactional-update, your running services will see the update immeaditly (no longer atomic) and even worse, the software could be broken until the next reboot. 2. if we don't mount /opt for transactional-update, the real /opt will shadow the transactinal-update /opt later, as in your case. The currently only possible solution, and for this the whole system was designed: your workload should run in containers/flatpaks. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Fri, 2021-03-05 at 13:48 +0100, Thorsten Kukuk wrote:
On Fri, Mar 05, Dario Faggioli wrote:
And as "promised", after reboot, /opt is just empty.
Sooo... What's going on? :-)
You did not follow the main mantra: your workload should run in containers or flatpak ;) Yeah, guilty as charged! :-)
In my defence, an year ago, the choice of browsers available as flatpak where, ehm, pretty limited. :-D Situation is indeed better now, although some are not yet perfect...
/opt is for 3rd party software and needs to be writeable, thus is not part of the snapshot. RPM does not have the concept of two databases ... So, if you install an RPM with files in /opt, we have a problem:
Yep, I totally see, understand and agree with that. Also, the reason why the Chrome RPM would install stuff in /opt is something that I'll never understand! (And not that I'm asking it to anyone in here, I'm just ranting :-/). What surprised me is the difference in behavior. I guess it's a change that occurred in some t-u version, and I just didn't notice (but then, what does it do when I update google chrome, which is in opt in this box, using these new versions... Oh, well). But even putting that aside, what I'm really after is what to tell users that wants to install Chrome as an RPM (because there will be always someone that will want to try that, I'm sure :-() and what to put in blog posts/documentation/guide about this.
1. if we mount /opt for transactional-update, your running services will see the update immeaditly (no longer atomic) and even worse, the software could be broken until the next reboot. 2. if we don't mount /opt for transactional-update, the real /opt will shadow the transactinal-update /opt later, as in your case.
Right.
The currently only possible solution, and for this the whole system was designed: your workload should run in containers/flatpaks.
Yeah, indeed. Now, I'm reading Ignaz answer as well right now, but this
is surely the case, and we knew that very well already. So, back at the
issue of people wanting Chrome, my plan now is:
- test myself and, if it works reasonably well, push users toward the
flatpak in the beta channel
- start using it from inside toolbox, and make sure it has all it
needs and works well from there too
Thanks and Regards!
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<
Am 05.03.21 um 13:23 Uhr schrieb Dario Faggioli:
Hello,
This is mostly about MicroOS Desktop. So, leaving it alone whether or not it should be done, one may want to install Google-Chrome with transactional-udpate.
Now, Chrome (but also other apps, I think) lives in /opt. Back when I installed this workstation that I am using as my desktop with MicroOS, this just worked. You go in `t-u shell`, add the repo, import the key and `zypper in google-chrome-stable`.
In fact, in this system, I have /opt/google with the browser in it. In a fresh install in a VM, I can do all that same thing. However, when I exit the `t-u shell`, I'm warned that:
The following files were changed in the snapshot, but are shadowed by other mounts and will not be visible to the system: /.snapshots/4/snapshot//opt/google/chrome/.... [bunch of lines like this, all with /opt in path]
And as "promised", after reboot, /opt is just empty.
Sooo... What's going on? :-)
Is this a bug or a feature?
In this case it's a bug. The /opt bind mount seems to have gone missing somewhere during the C++ transition: /opt has been available from within the transactional-update environment in the 2.x line. I'll fix this in the next release. Cheers, Ignaz
participants (3)
-
Dario Faggioli
-
Ignaz Forster
-
Thorsten Kukuk