[Bug 1071224] New: systemd: removes /usr/lib/systemd/system/tmp.mount in %post
http://bugzilla.suse.com/show_bug.cgi?id=1071224 Bug ID: 1071224 Summary: systemd: removes /usr/lib/systemd/system/tmp.mount in %post Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: systemd-maintainers@suse.de Reporter: lnussel@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- systemd's %post script removes /usr/lib/systemd/system/tmp.mount. That breaks rpm -V systemd, therefore delta rpms for systemd. Don't do that. If you don't want the file don't ship it. To mask it use systemctl mask. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c1
--- Comment #1 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c2
--- Comment #2 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c3
Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c4
--- Comment #4 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c5
--- Comment #5 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c6
--- Comment #6 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c7
--- Comment #7 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c8
--- Comment #8 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c9
--- Comment #9 from Franck Bui
Note that by default we have a btrfs subvolume for /tmp that is mounted via fstab, so according to https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/ this takes preference ie no change in behavior for a default install on btrfs actually.
Correct but if a customer selected ext4 I'm not sure that /tmp is referenced in fstab. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c10
--- Comment #10 from Ludwig Nussel
Just to make sure: you meant to stop shipping it and break any users that would rely on it ?
For this case you could still copy a backup of it to /etc in %pre of the new package. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c11
--- Comment #11 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c12
--- Comment #12 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c13
--- Comment #13 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c14
--- Comment #14 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c15
--- Comment #15 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c16
--- Comment #16 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c17
--- Comment #17 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c18
--- Comment #18 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c19
Thorsten Kukuk
So the only safe way I can see would be to mask the unit by default during the installation if no entry for /tmp is created in fstab by the installer.
We have many installation ways and methods, and also upgrade has to work. So, a solution based on special code in the installer violates with the requirement and goal, to have an universal usable installer. And it does not fix the problem for images (like build with kiwi), updates, rpm, SUSE Manager, and a lot of other cases I'm pretty sure I forgot to mention. The only good, reliable solution is one, which works if you install with rpm -ihv into a chroot environment: the it will always work. In my opinion, we should not ship tmp.mount in the default path, but as 'example' or documentation in /usr/share/doc/packages/systemd or so. Yes, there is the risk to break very few installations, but I really doubt that people outside there use it, since we remove it if not activated. So how should an user ever activate it, if it is already removed at that point in time? And if a user want's it, he can link the example to /etc/systemd/... or copy it. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c20
--- Comment #20 from Franck Bui
(In reply to Franck Bui from comment #18)
So the only safe way I can see would be to mask the unit by default during the installation if no entry for /tmp is created in fstab by the installer.
We have many installation ways and methods, and also upgrade has to work.
Updates of systemd package would take care of this.
In my opinion, we should not ship tmp.mount in the default path, but as 'example' or documentation in /usr/share/doc/packages/systemd or so.
That's what we're doing except that we care about users that already set up tmpfs on /tmp.
Yes, there is the risk to break very few installations, but I really doubt that people outside there use it, since we remove it if not activated. So how should an user ever activate it, if it is already removed at that point in time?
I don't agree with this and I'm wondering how you did figure out that few users are using tmpfs. Actually I'm using tmpfs on /tmp. And even if that would be true, breaking (voluntarily) user systems is a bad choice. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c21
--- Comment #21 from Thorsten Kukuk
(In reply to Thorsten Kukuk from comment #19)
(In reply to Franck Bui from comment #18)
So the only safe way I can see would be to mask the unit by default during the installation if no entry for /tmp is created in fstab by the installer.
We have many installation ways and methods, and also upgrade has to work.
Updates of systemd package would take care of this.
But not fresh installations not done by YaST2, which are the majority of our non-openSUSE installations.
Yes, there is the risk to break very few installations, but I really doubt that people outside there use it, since we remove it if not activated. So how should an user ever activate it, if it is already removed at that point in time?
I don't agree with this and I'm wondering how you did figure out that few users are using tmpfs. Actually I'm using tmpfs on /tmp.
But only either because you enabled it with a broken systemd package or by copying the file to /usr/lib/systemd/system/..., which was wrong, because you should have copied to /etc/systemd/... If you install systemd, the tmp.mount is immediately deleted during the install process, so as normal openSUSE or SLE user, you cannot enable it because it is already deleted. If you copy it correctly to /etc/systemd/... yourself, the removal of the file from systemd package will not break your system.
And even if that would be true, breaking (voluntarily) user systems is a bad choice.
The systems are not broken, you only don't use tmpfs anymore for /tmp. But it's still better that a few customers suffer than all customers by not beeing able to update systemd via delta-RPMs and by having warnings in their monitoring tools since rpm -Va reports missing files. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c22
--- Comment #22 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c23
--- Comment #23 from Ludwig Nussel
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c24
--- Comment #24 from Franck Bui
I am still not convinced about any complex solution.
Fair enough. But the previous solution is supposed to handle gracefully all the corner cases that we can encounter out there though. Also it would ease the switch to "tmpfs for /tmp" the day SUSE will decide to make it the default since we would simply have to stop shipping the new service that figures out if tmp.mount needs to be masked during the first boot. But if we're fine to forget those corner cases then shipping tmp.mount as a template (like we did already) only and recommending to symlink it from /etc if one wants to use tmpfs seems the simplest indeed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c25
--- Comment #25 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c26
--- Comment #26 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c27
Richard Brown
Ludwig, I guess this also needs to be fixed in SLE12-SP2+, right ?
The solution in Comment #22 has been submitted to factory https://build.opensuse.org/package/rdiff/openSUSE:Factory/systemd?linkrev=base&rev=269 It is now broken in Kubic https://openqa.opensuse.org/tests/603973#step/journal_check/14 You can not write to /usr/lib/systemd/scripts/ on a read only filesystem We support read-only root file systems on Kubic (based on tumbleweed) and CaaSP 3 (12 SP3) and 4 (15) I think this change needs to be reverted and reworked It should not be submitted in it's current form to SLE12-SP2+ because it will break on SUSE CaaSP. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c28
--- Comment #28 from Franck Bui
You can not write to /usr/lib/systemd/scripts/ on a read only filesystem
The problem happens when the system boots right, it doesn't happen when systemd package is upgraded ? And how are we supposed to implement "run this script once" on these platforms ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c29
--- Comment #29 from Richard Brown
(In reply to Richard Brown from comment #27)
You can not write to /usr/lib/systemd/scripts/ on a read only filesystem
The problem happens when the system boots right, it doesn't happen when systemd package is upgraded ?
And how are we supposed to implement "run this script once" on these platforms ?
Thanks.
The only time you can write to the rootfs on Kubic and CaaSP is during a package installation/upgrade - the rootfs is immutable, but the package changes are written to a new snapshot which will take effect on next boot So the only place you COULD implement this logic is in the %post I think you should not, I think this is an overly complex solution for little or no benefit. I think this is a perfect example in the flesh of why Ludwig and Thorsten were both right earlier in this thread. Please reconsider their advised solutions of a subpackage or packaged examples -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c30
--- Comment #30 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c31
--- Comment #31 from Thorsten Kukuk
BTW what is used for /tmp on Kubic and CaaSP ?
Whatever the customers configured. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c32
--- Comment #32 from Thorsten Kukuk
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c33
--- Comment #33 from Franck Bui
So whatever the solution will be, it has to work on a read-only root filesystem.
I'm fine to use the other solution but the main issue will remain and will need to be fixed the same way the day when SUSE will decide to make tmpfs the default for /tmp: everyone who don't use tmpfs will need to keep this setting once the default will be changed and the only solution I can see currently is to mask tmp.mount only *once*. And to implement that we need write access to /usr... OTOH if we're fine with the fact that some users will switch to tmpfs during an update then the problem is solved. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c34
--- Comment #34 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c35
--- Comment #35 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c36
--- Comment #36 from Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c37
Richard Brown
Created attachment 759425 [details] disable tmpfs on /tmp by removing /usr/lib/systemd/system/tmp.mount
I'm reasonably confident the change proposed should work on SLE 15, TW, Leap and _FRESH INSTALLATIONS_ of CaaSP and Kubic But I expect the following line will fail on any upgrade of CaaSP or Kubic ln -sf %{_datadir}/systemd/tmp.mount /etc/systemd/system/ IIRC /etc is not mounted during a transactional upgrade, as it's an overlayfs It might fail silently (which is still not good) but if the script fails vocally, this will mean systemd will be un-upgradable on CaaSP and Kubic if systemctl show -pFragmentPath tmp.mount is true Thorsten, am I missing something? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c38
--- Comment #38 from Ludwig Nussel
Ludwig, I guess this also needs to be fixed in SLE12-SP2+, right ?
I think it makes sense to include in any upcoming update to released code streams, yes. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c39
Thorsten Kukuk
But I expect the following line will fail on any upgrade of CaaSP or Kubic
ln -sf %{_datadir}/systemd/tmp.mount /etc/systemd/system/
IIRC /etc is not mounted during a transactional upgrade, as it's an overlayfs
It will work fine. The real /etc is available during upgrade, only the user modifications (which are stored in the overlayfs) are not. Which doesn't matter, in worst case we create a symlink, which is shadowed by the user modifications. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c41
Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=1071224
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c46
--- Comment #46 from Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1071224
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1071224
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1071224
Swamp Workflow Management
http://bugzilla.suse.com/show_bug.cgi?id=1071224
http://bugzilla.suse.com/show_bug.cgi?id=1071224#c47
--- Comment #47 from Swamp Workflow Management
https://bugzilla.suse.com/show_bug.cgi?id=1071224
https://bugzilla.suse.com/show_bug.cgi?id=1071224#c48
Martin Loviska
participants (2)
-
bugzilla_noreply@novell.com
-
bugzilla_noreply@suse.com