https://bugzilla.suse.com/show_bug.cgi?id=1216196 https://bugzilla.suse.com/show_bug.cgi?id=1216196#c12 Wenruo Qu <wqu@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(wqu@suse.com) | --- Comment #12 from Wenruo Qu <wqu@suse.com> --- (In reply to Fabian Vogt from comment #11)

(In reply to Wenruo Qu from comment #9)

...

My bad, I should take more care about this BZ earlier. (And feel free to mark #1219199 as duplicated)

With the help of David, the possible cause is pinned down to the microos specific initramfs hooks (that SElinux relabling part). But it's still pretty hard to reproduce if using the micros image (everything is read-only, pretty small disk, not enough development tools)

It's not the SELinux relabelling part, it's the whole

- mount /sysroot - SELinux relabel - Using transactional-update, create a new rootfs snapshot and do stuff with it

The problem is, from the duplicated report, the leak happens on @/var subvolume, not sure if it's one-time or with randomness involved.

- umount /sysroot

And the umount triggers it. I guess it's the snapshot creation which triggers it. It's basically the only place the root fs is actually unmounted except during shutdown.

Snapshot creation doesn't seem to cause the problem. As our regular fstests includes fsstress, which would create snapshot/subvolume. I'm suspecting the subvolume ro->rw and rw->ro switching, as that is not included in fsstress workload.

...

I'm wondering if it's possible for me to use openSUSE tumbleweed as the base, and just intall that micro os specific dracut hook to reproduce it?

What are you issing from MicroOS? There shouldn't be significant differences.

The SLEM has its rootfs set to RO, I'm not sure if it's designed to be so or not. (Sorry, spend most of my time on upstream, thus really unfamiliar with SLE product lines)

On plain TW, there is no relabel and combustion uses plain snapper instead of t-u, and the issue does not occur: https://openqa.opensuse.org/tests/3950956

...

Meanwhile, I have several upstream backport candidates which are not yet in our v6.4 branches, I will backport them soon and would it be possible to test the newer branches (without waiting for the proper fix)? As if those backport fixes the problem, it would save us a lot of time to setup the reproducer initramfs.

It still happens on current TW, i.e. kernel 6.7.5: https://openqa.opensuse.org/tests/3951060#step/journal_check/21

OK, this TW result helps a lot, it means it's a new cases we don't have coverage at all. Let me find a way to setup an environment allowing me to tinker the kernel code and generate an initramfs with needed hooks. Any good advice on setting an easy to reproduce environmen? (My daily drive testing VM is not even deb/rpm based, nor using dracut to generate an initramfs, although I have all the infrastructure to testing kernel easily, I don't have a good plan to testing it with dracut generated initramfs.)

(In reply to Wenruo Qu from comment #10)

...

If anyone can try the following branch and verify if it resolves the problem, it would be very helpful:

users/wqu/SLE15-SP6/for-next

Do you have a build in OBS or IBS? That way I could easily build an image with it.

I think it's already merged into the latest SLE15-SP6 kernel-source. But I don't think it's going to solve the problem. -- You are receiving this mail because: You are on the CC list for the bug.