http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c1 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |dsterba@suse.com --- Comment #1 from Franck Bui --- David, I'm assigning this bug to you as you're btrfsmaintenance maintainer. Please re-assign it accordingly if that was a wrong guess. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c2 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt@suse.com --- Comment #2 from Fabian Vogt --- Alternative would be to move away from sysconfig for configuration and just keeping the systemd timer units, which can be configured using systemd directly. Or using a generator for creating the timer (override) units based on sysconfig. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c6 --- Comment #6 from Karl Mistelberger --- See also: https://en.opensuse.org/SDB:Fix_btrfsmaintenance-refresh -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c8 --- Comment #8 from Karl Mistelberger --- Created a pull request: https://github.com/kdave/btrfsmaintenance/pull/79 But I am lost with: https://build.opensuse.org/package/show/filesystems/btrfsmaintenance?rev=48 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c9 --- Comment #9 from Franck Bui --- (In reply to Karl Mistelberger from comment #8)

Created a pull request: https://github.com/kdave/btrfsmaintenance/pull/79

Are you sure that this PR is addressing the current issue ? AFAICS it doesn't reduce the number of PID1 reloading, does it ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c11 --- Comment #11 from Karl Mistelberger --- I checked on a machine running Tumbleweed. Before applying the patch, btrfsmaintenance-refresh.path triggered btrfsmaintenance-refresh.service while /etc/fstab processing was underway. Journalctl listed 4 reloads of systemd. After applying the patch btrfsmaintenance-refresh.service wasn't triggered anymore. No reloads of systemd occured. Additionally default state of units should be checked: erlangen:~ # systemctl list-unit-files btrfsmaintenance-refresh.* UNIT FILE STATE btrfsmaintenance-refresh.path enabled btrfsmaintenance-refresh.service disabled 2 unit files listed. erlangen:~ # -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c13 --- Comment #13 from Franck Bui --- (In reply to Fabian Vogt from comment #10)

AFAICT it moves the PID reloading to happen only after local-fs.target, which mitigates bug 1137373. It's mostly for symmetry to btrfsmaintenance-refresh.service, which already has After=local-fs.service.

Since both units (.path and .service) have the default dependencies both units don't need "After=local-fs.service" as it's already implied.

It still reloads systemd at least three times during boot and when sysconfig changes.

This is what should be optimized IMHO. That said the idea of automatically (re)starting a unit if a config file was changed is disputable, assuming it's the purpose of btrfsmaintenance-refresh.path. IMHO reloading a new config should be done explicitly like it's always been the case, and who knows the state of the contents of the config file when sysadmin is saving it. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c15 --- Comment #15 from Karl Mistelberger --- (In reply to Franck Bui from comment #12)

Hmm actually considering the fact that path units have After=sysinit.target as part of their default dependencies, I'm wondering how your change would help since local-fs.target has Before=sysinit.target.

Whether this claim holds or not there are the points I verified. Experiment contradicts theory. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c17 --- Comment #17 from Franck Bui --- (In reply to Karl Mistelberger from comment #16)

Yet another claim which is not supported by evidence. I reiterate: removing After=local-fs.target from unit btrfsmaintenance-refresh.path results in btrfsmaintenance-refresh.serviceb being triggered before local-fs.target is reached. This has been verified on one of my machines and has been confirmed independently by several users at https://forums.opensuse.org/forum.php,

I didn't say that your workaround has no effect, I was just pointing out that it doesn't look correct. So before considering merging your patch, it would be interesting to understand why btrfsmaintenance-refresh.service is triggered before local-fs.target. Please attach the debug logs (output of journalctl -b -o short-monotonic) after making sure to revert your changes. To enable the debug logs please append the following options to the kernel command line "printk.devkmsg=on systemd.log_level=debug" -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c19 --- Comment #19 from Karl Mistelberger --- Created attachment 836007 --> http://bugzilla.suse.com/attachment.cgi?id=836007&action=edit before -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 M Fredericks changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emfee@gmx.net -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c24 Karl Mistelberger changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #836007|0 |1 is obsolete| | --- Comment #24 from Karl Mistelberger --- Created attachment 836104 --> http://bugzilla.suse.com/attachment.cgi?id=836104&action=edit erroneous activation of btrfsmaintenance-refresh The attachment shows journal of rescue system (without debug enabled) with erroneous activation of btrfsmaintenance-refresh.service -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c26 --- Comment #26 from Karl Mistelberger --- With a fresh install of Tumbleweed 20200416 the problem no longer persists. Units btrfsmaintenance-refresh.path and btrfsmaintenance-refresh.service indeed wait until local-fs.target is reached. However due to btrfsmaintenance-refresh.service being enabled the unit runs during boot without /etc/sysconfig/btrfsmaintenance being changed: Apr 20 12:59:51 systemd[1]: Started Watch /etc/sysconfig/btrfsmaintenance. Apr 20 12:59:51 systemd[1]: Starting Update cron periods from /etc/sysconfig/btrfsmaintenance... Apr 20 12:59:51 btrfsmaintenance-refresh-cron.sh[1089]: Refresh script btrfs-scrub.sh for uninstall Apr 20 12:59:51 btrfsmaintenance-refresh-cron.sh[1089]: Refresh script btrfs-defrag.sh for uninstall Apr 20 12:59:51 btrfsmaintenance-refresh-cron.sh[1089]: Refresh script btrfs-balance.sh for uninstall Apr 20 12:59:51 btrfsmaintenance-refresh-cron.sh[1089]: Refresh script btrfs-trim.sh for uninstall Apr 20 12:59:51 btrfsmaintenance-refresh-cron.sh[1089]: Refresh timer btrfs-scrub for monthly Apr 20 12:59:52 systemd[1]: Started Balance block groups on a btrfs filesystem. Apr 20 12:59:52 systemd[1]: Started Defragment file data and/or directory metadata. Apr 20 12:59:52 systemd[1]: Started Scrub btrfs filesystem, verify block checksums. Apr 20 12:59:52 systemd[1]: Started Discard unused blocks on a mounted filesystem. Apr 20 12:59:52 btrfsmaintenance-refresh-cron.sh[1089]: Refresh timer btrfs-defrag for none Apr 20 12:59:52 systemd[1]: btrfs-defrag.timer: Succeeded. Apr 20 12:59:52 systemd[1]: Stopped Defragment file data and/or directory metadata. Apr 20 12:59:53 btrfsmaintenance-refresh-cron.sh[1089]: Refresh timer btrfs-balance for weekly Apr 20 12:59:53 btrfsmaintenance-refresh-cron.sh[1089]: Refresh timer btrfs-trim for none Apr 20 12:59:53 systemd[1]: btrfs-trim.timer: Succeeded. Apr 20 12:59:53 systemd[1]: Stopped Discard unused blocks on a mounted filesystem. Apr 20 12:59:53 systemd[1]: btrfsmaintenance-refresh.service: Succeeded. Apr 20 12:59:53 systemd[1]: Started Update cron periods from /etc/sysconfig/btrfsmaintenance. Disabling btrfsmaintenance-refresh.service and enabling btrfsmaintenance-refresh.path fixes this: Apr 20 13:08:44 systemd[1]: Started Watch /etc/sysconfig/btrfsmaintenance. Apr 20 13:08:45 systemd[1]: Started Balance block groups on a btrfs filesystem. Apr 20 13:08:45 systemd[1]: Started Scrub btrfs filesystem, verify block checksums. Apr 20 13:09:35 systemd[1]: Starting Update cron periods from /etc/sysconfig/btrfsmaintenance... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c28 --- Comment #28 from Karl Mistelberger --- (In reply to Franck Bui from comment #27)

(In reply to Karl Mistelberger from comment #26)

...

With a fresh install of Tumbleweed 20200416 the problem no longer persists. Units btrfsmaintenance-refresh.path and btrfsmaintenance-refresh.service indeed wait until local-fs.target is reached.

That should have always been the case otherwise that would be a bug.

I ask users affected to report: https://forums.opensuse.org/showthread.php/539905-How-to-fix-btrfsmaintenanc...

...

However due to btrfsmaintenance-refresh.service being enabled the unit runs during boot without /etc/sysconfig/btrfsmaintenance being changed:

[...]

Disabling btrfsmaintenance-refresh.service and enabling btrfsmaintenance-refresh.path fixes this:

Which is the reason why I asked the point of enabling btrfsmaintenance service in comment #18.

Actually this service doesn't seem to need a [Install] section at all.

I agree. However you may want to load it at boot: erlangen:~ # systemctl cat btrfsmaintenance-refresh.service # /etc/systemd/system/btrfsmaintenance-refresh.service [Unit] Description=Update cron periods from /etc/sysconfig/btrfsmaintenance [Service] ExecStart=/usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh systemd-timer Type=oneshot [Install] WantedBy=multi-user.target erlangen:~ # -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c30 --- Comment #30 from Franck Bui --- (In reply to Karl Mistelberger from comment #29)

UNIT FILE STATE VENDOR PRESET btrfsmaintenance-refresh.path enabled disabled btrfsmaintenance-refresh.service static enabled

That should be the other way around: .service should be disabled whereas .path should be enabled... Anyway could you send a patch to remove [Install] section from .service ? I think this change makes sense enough alone to be submitted. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c32 --- Comment #32 from Karl Mistelberger --- (In reply to Franck Bui from comment #30)

Anyway could you send a patch to remove [Install] section from .service ? I think this change makes sense enough alone to be submitted.

I never submitted a patch. Do you refer to that: https://openbuildservice.org/help/manuals/obs-user-guide/art.obs.bg.html#sec... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c34 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner@suse.com Flags| |needinfo?(meissner@suse.com | |) --- Comment #34 from Franck Bui --- (In reply to Franck Bui from comment #31)

Ah forget about this part of the comment, I misread the output of the units status, it's the preset stuff which still looks wrong but that's another issue.

Marcus, the preset stuff enables btrfsmaintenance-refresh.service by default. But that looks wrong, it should be the path unit, btrfsmaintenance-refresh.path, which should be enabled by default. Can you please fix it ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c36 --- Comment #36 from Karl Mistelberger --- (In reply to Franck Bui from comment #33)

(In reply to Karl Mistelberger from comment #32) No I was suggesting you to send a new patch that removes [Install] section from .service.

https://github.com/kdave/btrfsmaintenance/pull/81 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c38 Michal Suchanek changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://github.com/kdave/bt |https://github.com/kdave/bt |rfsmaintenance/pull/79 |rfsmaintenance/pull/81 CC| |dsterba@suse.com Assignee|kernel-maintainers@forge.pr |dsterba@suse.com |ovo.novell.com | Flags|needinfo?(meissner@suse.com |needinfo?(dsterba@suse.com) |), | |needinfo?(msuchanek@suse.co | |m) | --- Comment #38 from Michal Suchanek --- David, please merge the PR and submit to OBS. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1165780 Ludwig Nussel changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c41 --- Comment #41 from Franck Bui --- The change doesn't seem to be available in TW, anything wrong happened ? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c43 --- Comment #43 from Franck Bui --- IIRC this service is only useful when some BTRFS settings are changed somewhere in /etc/sysconfig. That's the reason why a path unit is used to monitor the relevant config file. If so it seems there's no point in giving to the user the possibility to enable/disable the service unit and start the service on each boot even if nothing changed in the relevant config file, which is very likely. At least I assumed that was correct since the maintainer accepted this change. Regarding the use of After=local-fs.target, I think its usefulness was discussed in the previous comments. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c45 --- Comment #45 from Fabian Vogt --- (In reply to Karl Mistelberger from comment #44)

(In reply to Fabian Vogt from comment #42)

...

(In reply to Franck Bui from comment #41)

...

The change doesn't seem to be available in TW, anything wrong happened ?

The sr got declined: https://build.opensuse.org/request/show/823587

For reference, this is my comment which lead to the decline:

...

Deleting the [Install] section is a noop, it will only break later calls to "systemctl enable btrfsmaintenance-refresh.service". Existing systems will not be impacted by that. In fact, the removal of After=local-fs.target might even break it.

Is that intentional?

I recommend updating systemd-presets-common-SUSE instead to not explicitly enable btrfsmaintenance-refresh.service.

To double check, I just updated btrfsmaintenance to the 0.5 version from the devel prj in a VM and btrfsmaintenance-refresh.service still runs on boot as the .service file is still linked to /etc/systemd/system/multi-user.target.wants/.

btrfsmaintenance-refresh.service was NEVER INTENDED to be enabled or installed.

btrfsmaintenance-refresh.path triggers btrfsmaintenance-refresh.service upon changes of /etc/sysconfig/btrfsmaintenance

Yes, that is so far correct. The issue is, it IS enabled as that's what previous versions did and so on existing systems it STAYS enabled because removing the [Install] section does not run a call to systemctl disable. As long as the service is still enabled in the preset, it will stay enabled. It might be enough to remove it from https://build.opensuse.org/package/view_file/Base:System/systemd-presets-common-SUSE/default-SUSE.preset?expand=1&rev=29 (line 12), but I'd add a systemctl disable call in %post to be sure, in case someone enabled it manually. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c47 --- Comment #47 from Karl Mistelberger ---

Indeed but playing with stuff in /etc during package update is usually not a good idea so I would be tempted to leave it unless the user is hit by the systemd race issue and in this case we can ask him to remove the symlink manually.

I fully agree on the above. However this is not a usual case. IIRC keeping the symlink and removing the install section will result in a runtime error for everybody updating. As you never want to install the service for a good reason removing the symlink upon update would be fine. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c49 --- Comment #49 from Karl Mistelberger --- (In reply to Fabian Vogt from comment #48)

I made the change to the preset and submitted it: sr 829721

Great! I am happy with what I asked for in comments #11, #22 and #29.

the removal of [Install] in btrfsmaintenance-refresh.service is mostly a cleanup and to avoid manual enabling in the future.

For me as a less experienced user the bogus preset and [Install] were extremely misleading and distracting. Making sure that btrfsmaintenance-refresh.service will never be enabled helps a lot. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c51 --- Comment #51 from Franck Bui --- (In reply to Fabian Vogt from comment #48)

I made the change to the preset and submitted it: sr 829721

Thanks !

So just systemd-presets-common-SUSE is enough to get the wanted behaviour and the removal of [Install] in btrfsmaintenance-refresh.service is mostly a cleanup and to avoid manual enabling in the future.

I wouldn't call that a clean up as it's only intended to be run via the path unit.

Care has to be taken that this version of btrfsmaintenance is not used together with old systemd-presets-common-SUSE, as it results in a disabled .path unit.

Indeed. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c53 --- Comment #53 from владимир путин <1000Hz.radiowave@gmail.com> --- I have removed the btrfsmaintenance from my system, yet after some time its back again. And doing scrub in the background, effectively locking the whole IO on the desktop. Which became unresponsive. I guess something installs it as a recommended dependency. Is it possible to not force this generally useless and quite harmful package on people? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c55 --- Comment #55 from Goldwyn Rodrigues --- How about enabling and starting the timer service only if /etc/systemd/system/$SERVICE.timer.d/schedule.conf does not match the $PERIOD in /etc/sysconfig/btrfsmaintenance? Would that solve the issue? We will still have to check "systemctl is-enabled $SERVICE.timer" and "systemctl is-active $SERVICE.timer" and enable/start iff it returns false. Would that slow down the boot process? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c57 --- Comment #57 from asf <1000Hz.radiowave@gmail.com> --- Thanks Karl. But what i'm trying to say, is they are all useless for general audience. So should not be forced on it. Im pretty sure there are many people not technical enough, to figure out why their desktop became unresponsive once a week or once a month. Coz of something, which is outdated and gives no benefits at all still intensively work in the background. Defaults should be sane and tied for general usecase. And btw there is already fstrim timer in suse systemd enabled by default. So even the last one is useless. Those who maintain servers and happened to have redundant raid, can easily enable scrub themselves in just a line of cron. Just like i did. And scrub is the only thing which could be potentially useful in some cases nowadays, out of the whole btrfsmaintenance package. In other words: the package is long outdated Karl! -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c59 --- Comment #59 from Franck Bui --- (In reply to Goldwyn Rodrigues from comment #55)

How about enabling and starting the timer service only if /etc/systemd/system/$SERVICE.timer.d/schedule.conf does not match the $PERIOD in /etc/sysconfig/btrfsmaintenance? Would that solve the issue?

I think we already discussed about what is actually needed: 1. btrfsmaintenance-refresh.service should not be enabled by default by the preset stuff but instead it should enable btrfsmaintenance-refresh.path On Factory this was dealt by sr#829721 2. since btrfsmaintenance-refresh.service is not supposed to be run at boot the unit file should have an [Install] section. Not sure if this was fixed... IIRC this was based on the fact that btrfsmaintenance-refresh.service needs to be started only when settings were changed in /etc/sysconfig/btrfsmaintenance. But please note that this addresses new installations only. For existing systems, the relevant symlink have to be changed manually because the presets stuff are only apply at installation time. Ideally after an update we should have renamed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service to point to btrfsmaintenance-refresh.path instead. AFAICS none of these changes has not been backported to *SLE*. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c61 --- Comment #61 from Fabian Vogt --- (In reply to Franck Bui from comment #59)

(In reply to Goldwyn Rodrigues from comment #55)

...

How about enabling and starting the timer service only if /etc/systemd/system/$SERVICE.timer.d/schedule.conf does not match the $PERIOD in /etc/sysconfig/btrfsmaintenance? Would that solve the issue?

I think we already discussed about what is actually needed:

1. btrfsmaintenance-refresh.service should not be enabled by default by the preset stuff but instead it should enable btrfsmaintenance-refresh.path On Factory this was dealt by sr#829721

2. since btrfsmaintenance-refresh.service is not supposed to be run at boot the unit file should have an [Install] section. Not sure if this was fixed...

It was part of https://build.opensuse.org/request/show/831373.

IIRC this was based on the fact that btrfsmaintenance-refresh.service needs to be started only when settings were changed in /etc/sysconfig/btrfsmaintenance.

But please note that this addresses new installations only.

For existing systems, the relevant symlink have to be changed manually because the presets stuff are only apply at installation time.

Change 2 is enough and also affects existing installations properly, see comment 48.

Ideally after an update we should have renamed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service to point to btrfsmaintenance-refresh.path instead.

AFAICS none of these changes has not been backported to *SLE*.

Backporting only sr#829721 should be sufficient. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c65 --- Comment #65 from Franck Bui --- (In reply to Fabian Vogt from comment #61)

Change 2 is enough and also affects existing installations properly, see comment 48.

You're right, I missed the fact that presets are also selectively applied at package updates. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c68 --- Comment #68 from asf <1000Hz.radiowave@gmail.com> --- (In reply to Franck Bui from comment #60)

Which suggests that btrfsmaintenance.path should be enabled only for SLE and disabled for openSUSE distros...

It may still screw up snapper rollbacks there. Im not sure if thats exactly what you want for the enterprise customers. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(rgoldwyn@suse.com | |) -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1178874 -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c75 --- Comment #75 from Swamp Workflow Management --- SUSE-RU-2021:0926-1: An update that has 5 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1083473,1112500,1115408,1165780,1183012 CVE References: JIRA References: Sources used: SUSE MicroOS 5.0 (src): systemd-presets-common-SUSE-15-8.3.1 SUSE Linux Enterprise Module for Basesystem 15-SP2 (src): systemd-presets-common-SUSE-15-8.3.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c77 --- Comment #77 from Oliver Kurz --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: jeos-filesystem@64bit_virtio-2G https://openqa.opensuse.org/tests/1694862 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" 3. The label in the openQA scenario is removed -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c80 --- Comment #80 from Michal Suchanek --- Is this needed in Leap/Factory as well? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c82 Santiago Zarate changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |santiago.zarate@suse.com, | |sweiberg@suse.com Flags| |needinfo?(sweiberg@suse.com | |) --- Comment #82 from Santiago Zarate --- I wonder if the same fix is needed for SP3: https://openqa.suse.de/tests/5847309#step/btrfsmaintenance/20 -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c84 --- Comment #84 from Swamp Workflow Management --- SUSE-RU-2021:1449-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1165780 CVE References: JIRA References: Sources used: SUSE Linux Enterprise Module for Basesystem 15-SP3 (src): systemd-presets-branding-SLE-15.1-20.8.1 SUSE Linux Enterprise Module for Basesystem 15-SP2 (src): systemd-presets-branding-SLE-15.1-20.8.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c86 --- Comment #86 from Martin Loviska --- Unfortunately we can still see failures of caused by incorrect presets in sle15sp2. https://openqa.suse.de/tests/5998504#step/btrfsmaintenance/20 -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c88 --- Comment #88 from Marcus Meissner --- The QR last snapshot might have been before the release. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 Jose Lausuch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jalausuch@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c90 --- Comment #90 from Oliver Kurz --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: jeos-filesystem https://openqa.suse.de/tests/5924075 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" 3. The label in the openQA scenario is removed -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c93 --- Comment #93 from openQA Review --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: mau-filesystem https://openqa.suse.de/tests/6493840 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The label in the openQA scenario is removed -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c95 --- Comment #95 from openQA Review --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: mau-filesystem https://openqa.suse.de/tests/6637925 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The label in the openQA scenario is removed -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c97 --- Comment #97 from openQA Review --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: mau-filesystem https://openqa.suse.de/tests/6637925 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234` -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c98 --- Comment #98 from Martin Loviska --- We cannot see the failure anymore in QR images nor among updates: * [sle-15-SP3-JeOS-for-kvm-and-xen-QR-x86_64-Build3.3.1](https://openqa.suse.de/tests/7160384#step/btrfsmaintenance/17) * [sle-15-SP2-JeOS-for-kvm-and-xen-QR-x86_64-Build15.93](https://openqa.suse.de/tests/7161356#step/btrfsmaintenance/17) * [sle-15-SP3-JeOS-for-kvm-and-xen-Updates-x86_64-Build20210923](https://openqa.suse.de/tests/7198657#step/btrfsmaintenance/17) * [sle-15-SP2-JeOS-for-kvm-and-xen-Updates-x86_64-Build20210923](https://openqa.suse.de/tests/7198626#step/btrfsmaintenance/17) -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c100 --- Comment #100 from openQA Review --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: mau-filesystem https://openqa.suse.de/tests/7501986 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234` -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c101 --- Comment #101 from openQA Review --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: mau-filesystem https://openqa.suse.de/tests/7639225 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234` -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c103 --- Comment #103 from openQA Review --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: mau-filesystem https://openqa.suse.de/tests/7812956 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234` -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c105 --- Comment #105 from openQA Review --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: mau-filesystem https://openqa.suse.de/tests/7950268 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234` -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c107 --- Comment #107 from openQA Review --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: mau-filesystem https://openqa.suse.de/tests/8104759 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234` -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c109 --- Comment #109 from openQA Review --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: mau-filesystem https://openqa.suse.de/tests/8341996 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234` Expect the next reminder at the earliest in 56 days if nothing changes in this ticket. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c111 --- Comment #111 from openQA Review --- This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: mau-filesystem https://openqa.suse.de/tests/8560139 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234` Expect the next reminder at the earliest in 40 days if nothing changes in this ticket. -- You are receiving this mail because: You are on the CC list for the bug.