November 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1192457] ZSTD compressed kernel module files are 35% bigger
by bugzilla_noreply＠suse.com 11 Nov '21

11 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192457 https://bugzilla.suse.com/show_bug.cgi?id=1192457#c31 --- Comment #31 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Michal Suchanek from comment #25) > It's also possible to directly edit config.sh in the linked package. This isn't sufficient because mkspec needs to be run before check-in (otherwise the spec files will still use xz). It's possible to checkout from OBS locally, run mkspec in kernel-source.git, copy the spec files over to the obs dir, and commit to OBS. Running mkspec in a checked-out OBS repo doesn't work well. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192457] ZSTD compressed kernel module files are 35% bigger
by bugzilla_noreply＠suse.com 11 Nov '21

11 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192457 https://bugzilla.suse.com/show_bug.cgi?id=1192457#c30 --- Comment #30 from Martin Wilck <martin.wilck(a)suse.com> --- Does this mean zstd can be enabled again? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192549] Kernel 5.3.18-lp152.98-default breaks getdents(2) system call on NFS shares
by bugzilla_noreply＠suse.com 11 Nov '21

11 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192549 https://bugzilla.suse.com/show_bug.cgi?id=1192549#c6 --- Comment #6 from Marcus Meissner <meissner(a)suse.com> --- this report is for Leap 15.2, the SLES 15 SP2 kernel. Is the 5.3 kernel base also affected? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192457] ZSTD compressed kernel module files are 35% bigger
by bugzilla_noreply＠suse.com 10 Nov '21

10 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192457 https://bugzilla.suse.com/show_bug.cgi?id=1192457#c29 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt(a)suse.com --- Comment #29 from Fabian Vogt <fvogt(a)suse.com> --- The live CDs fit again after avoiding double-compression (both squashfs and the initrd), like suggested by comment 11: # Decompress kernel modules, better for squashfs (boo#1192457) find /usr/lib/modules/*/kernel -name '*.ko.xz' -exec xz -d {} + find /usr/lib/modules/*/kernel -name '*.ko.zst' -exec zstd --rm -d {} + depmod $(basename /usr/lib/modules/*) The size of the .iso shrank from 703MB to 619MiB! -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192457] ZSTD compressed kernel module files are 35% bigger
by bugzilla_noreply＠suse.com 10 Nov '21

10 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192457 https://bugzilla.suse.com/show_bug.cgi?id=1192457#c28 --- Comment #28 from Martin Wilck <martin.wilck(a)suse.com> --- FTR, I have set up projects on IBS/OBS, kernels with zstd module compression: OBS: home:mwilck:zstd:Factory (links to Kernel:stable) IBS: home:mwilck:zstd:SLE-15-SP4 (links to SUSE:SLE-15-SP4:GA) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192549] Kernel 5.3.18-lp152.98-default breaks getdents(2) system call on NFS shares
by bugzilla_noreply＠suse.com 10 Nov '21

10 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192549 https://bugzilla.suse.com/show_bug.cgi?id=1192549#c3 Marcus Meissner <meissner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P1 - Urgent --- Comment #3 from Marcus Meissner <meissner(a)suse.com> --- Neil? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192457] ZSTD compressed kernel module files are 35% bigger
by bugzilla_noreply＠suse.com 10 Nov '21

10 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192457 https://bugzilla.suse.com/show_bug.cgi?id=1192457#c25 --- Comment #25 from Michal Suchanek <msuchanek(a)suse.com> --- (In reply to Martin Wilck from comment #22) > (In reply to Michal Suchanek from comment #20) > > (In reply to Dominique Leuenberger from comment #17) > > > > > Everyone understands that if unsurmountable problems occur, the project > > > > fails. But what happened here is that we pulled back on the first occurence > > > > of an issue. The side effect of this is that real-world testing effectively > > > > doesn't happen any more. So possible other issues will not be found, and the > > > > known ones will be harder to solve. > > > > > > It was not 'pulled back' - but moved to the 'devel area' instead of the > > > product. OBS is powerful enough to let us work out kinks outside of the > > > actual product build as long as we need to. And only put it inside the > > > product when we feel ready for it. > > > > Then you probably want to link Kernel:HEAD rather than Kernel:stable > > That's the point - factory kernels come from Kernel:stable, and by reverting > to xz in Kernel:stable, the feature was effectively "pulled back" as far as > the factory kernel is concerned. > > Maybe we should create a temporary branch that's equivalent to Kernel:stable > but uses zstd? > It's also possible to directly edit config.sh in the linked package. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192457] ZSTD compressed kernel module files are 35% bigger
by bugzilla_noreply＠suse.com 10 Nov '21

10 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192457 https://bugzilla.suse.com/show_bug.cgi?id=1192457#c24 --- Comment #24 from Takashi Iwai <tiwai(a)suse.com> --- (In reply to Michal Suchanek from comment #20) > > > Everyone understands that if unsurmountable problems occur, the project > > > fails. But what happened here is that we pulled back on the first occurence > > > of an issue. The side effect of this is that real-world testing effectively > > > doesn't happen any more. So possible other issues will not be found, and the > > > known ones will be harder to solve. > > > > It was not 'pulled back' - but moved to the 'devel area' instead of the > > product. OBS is powerful enough to let us work out kinks outside of the > > actual product build as long as we need to. And only put it inside the > > product when we feel ready for it. > > Then you probably want to link Kernel:HEAD rather than Kernel:stable Having such a project would be really nice (that'll help the upstream development in RC phase, too), but it's certainly different from "ready to release". Instead, it'll be a position like linux-next, as the integration test of the latest kernel. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192457] ZSTD compressed kernel module files are 35% bigger
by bugzilla_noreply＠suse.com 10 Nov '21

10 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192457 https://bugzilla.suse.com/show_bug.cgi?id=1192457#c23 --- Comment #23 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Takashi Iwai from comment #21) > If the decompression speed (which is the most important factor for switching > to zstd) is comparable with lower compression levels, then it can be a good > win. That was a consistent finding in my testing. It's also documented in the technical papers about zstd, it's a property of the algorithm by design. I haven't digged deep enough into the math to explain why. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192457] ZSTD compressed kernel module files are 35% bigger
by bugzilla_noreply＠suse.com 10 Nov '21

10 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192457 https://bugzilla.suse.com/show_bug.cgi?id=1192457#c22 --- Comment #22 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Michal Suchanek from comment #20) > (In reply to Dominique Leuenberger from comment #17) > > > Everyone understands that if unsurmountable problems occur, the project > > > fails. But what happened here is that we pulled back on the first occurence > > > of an issue. The side effect of this is that real-world testing effectively > > > doesn't happen any more. So possible other issues will not be found, and the > > > known ones will be harder to solve. > > > > It was not 'pulled back' - but moved to the 'devel area' instead of the > > product. OBS is powerful enough to let us work out kinks outside of the > > actual product build as long as we need to. And only put it inside the > > product when we feel ready for it. > > Then you probably want to link Kernel:HEAD rather than Kernel:stable That's the point - factory kernels come from Kernel:stable, and by reverting to xz in Kernel:stable, the feature was effectively "pulled back" as far as the factory kernel is concerned. Maybe we should create a temporary branch that's equivalent to Kernel:stable but uses zstd? > > > It was expected that some issues would occur. It was known beforehand that > > > package size would increase. > > > > So why did nobody look at the product deliverables and verify that they can > > be produced? Throw over the fence and let Release Managers pick up the > > broken glass is not the way to go. > > And how do we look at them and ensure that they are buildable? > > That's what we have release managers for. To know the deliverables. Ack. This was in Jira for some time. IMO this is part of the reason why we have Jira. There are product managers and release engineers involved who should have this on their radar. You can't expect *kernel* people to anticipate issues in every area. > > Be my guest: branch it, fix it, submit it. > > That's not so easy. Last time I tried to branch a release package it would > not build because it requires some complex project setup which is not > documented. Image building requires special knowledge that only a few people have. I certainly don't. Also, I'm pretty sure that you wouldn't be pleased if Michal or myself started throwing things out of the Live image to our own taste. We need to do this together somehow. (In reply to Dominique Leuenberger from comment #17) @Dominique, I agree that the burden shouldn't be on _you_. The question is how it can be shared. > There are 'rough edged' and 'unbuildable product deliverables'. Rough edges > can be ok, rebuildable deliverables are not ok. If the lives ar enot being > built, there is no Tumbleweed snapshot being produced which in turn means: > no user gets the change to test anyway. So what do you win? Nada. I wasn't aware that building live images was a prerequisite for releasing snapshots. My expectation was that few people are using these images. I thought they were mainly for newcomers checking out openSUSE. I don't think I ever used one. > > And this is what happens with "factory first" - effectively > > we beta-test on a distribution that others use in production. It's not the > > first time something breaks in factory, and not a unique incident by any > > means. > > Guess what: there were plenty of cases where a snapshot is not published > because of broken submissions. We have QA, we block snapshots if they are > too broken. Developers are still meant to do their tasks and deliver > functioning pieces. The pieces do function. It's malfunctioning at an entirely different level, image creation, which is outside the scope of kernel developers. I believe that releasing a snapshot without a live CD image would have close to zero impact on regular TW users, unlike e.g. the move to glibc 2.34. > We don't give up - we move back to the drawing board with the findings and > work out the issues. Good, thank you very much. As Michal suggested, you may want to link your test project to Kernel:HEAD. That means you'll also get another kernel, but that shouldn't matter much, hopefully. -- You are receiving this mail because: You are the assignee for the bug.

1 0