November 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[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#c21 --- Comment #21 from Takashi Iwai <tiwai(a)suse.com> --- (In reply to Martin Wilck from comment #19) > My experiments showed that at levels >~15, compression with zstd may > actually be slower than xz (that was with initramfs payloads). > *decrompression* with zstd is always at 10-15x faster than with xz, > independent of the compression level. Also, multithreading can be enabled > with zstd, speeding it up (can't be done with xz easily, because compression > results may not be reproducible any more). 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. In the case of module compressions, it's done at the kernel package build time, not at the run time, so a slightly longer build time should be acceptable. -- 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#c20 --- Comment #20 from Michal Suchanek <msuchanek(a)suse.com> --- (In reply to Dominique Leuenberger from comment #17) > (In reply to Martin Wilck from comment #16) > > Let me ask again how we are supposed to proceed now. > > The tests we discussed continues in home:dimstar:Live - when we overcome the > obstacle, we can move to zstd again and build TW using this. Thanks for setting this up. The build with Factory packages showed the CD size as 630MB which is less than 650MB but maybe it's supposed to be in different units. > > > 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 > > > 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. I was not aware that there is a medium built that has exactly CD size. All the media I work with are either way over 4G or 100-300MB so I do not see the problem there. > > > Therefore if we want to have this feature, we > > need to deal with that and free the required space on the media. > > 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. When I did some project setup it would not build presumably because there is some size quota on the home projects. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1189791] btrfs filesystem corruptions with HyperPAV
by bugzilla_noreply＠suse.com 10 Nov '21

10 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1189791 https://bugzilla.suse.com/show_bug.cgi?id=1189791#c16 --- Comment #16 from Berthold Gunreben <azouhr(a)opensuse.org> --- (In reply to LTC BugProxy from comment #15) > ------- Comment From stefan.haberland(a)de.ibm.com 2021-11-09 11:23 EDT------- > Can you please also share the output of lsdasd? Unfortunately, I only had z/VM 7.2 available during a PoC of openshift. The machine in question actually was the bastion server for that. I will update the other z/VM when I am back from vacation (in 2 weeks) and will try to reproduce, but at the moment I do not have more data. With regards to thick provisioned: I can only emulate that by doing a full format. This will have to wait until I upgraded z/VM as well. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192473] DE0-Nano-SoC boot fails on 15.3
by bugzilla_noreply＠suse.com 10 Nov '21

10 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192473 https://bugzilla.suse.com/show_bug.cgi?id=1192473#c5 Matthias Brugger <mbrugger(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(christian.gross@c | |enterofgravity.at) --- Comment #5 from Matthias Brugger <mbrugger(a)suse.com> --- Can you double check that the system doesn't boot with Tumbleweed + FORTIFY_SOURCE. I just started a test kernel build. You can download the RPMs once finished here: https://build.opensuse.org/project/show/home:mbrugger:bsc1192473 -- 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#c19 --- Comment #19 from Martin Wilck <martin.wilck(a)suse.com> --- Sure, we could so that. As you can see xz compresses still better than zstd on high levels, but the difference to xz goes down from 18 to 7MB, or 28% to 12%, in your example. Not sure if that would be enough for Dominique. My experiments showed that at levels >~15, compression with zstd may actually be slower than xz (that was with initramfs payloads). *decrompression* with zstd is always at 10-15x faster than with xz, independent of the compression level. Also, multithreading can be enabled with zstd, speeding it up (can't be done with xz easily, because compression results may not be reproducible any more). -- 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#c18 --- Comment #18 from Takashi Iwai <tiwai(a)suse.com> --- BTW, I wonder now whether trying a higher compression level would be worth or not. Through a quick test, the size reduction varies much (also the compression time increases, though). % du -sh * 64188 xz 82128 zst03 79508 zst05 75160 zst10 71788 zst19 -- 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#c17 --- Comment #17 from Dominique Leuenberger <dleuenberger(a)suse.com> --- (In reply to Martin Wilck from comment #16) > Let me ask again how we are supposed to proceed now. The tests we discussed continues in home:dimstar:Live - when we overcome the obstacle, we can move to zstd again and build TW using this. > In my understanding, the existence of this "Sould have" Jira ticket implies > that engineering got an order from PM for the implementation this feature. > So we should try. Trying implies exposing the feature to a larger audience > for testing and finding possible rough edges. 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. > 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. > 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. > Therefore if we want to have this feature, we > need to deal with that and free the required space on the media. Be my guest: branch it, fix it, submit it. > That's > difficult, and it might mean that live image creation fails for a certain > period of time. This implies: no product deliverables are generated, which means no snapshot is generated, which means no user gets the new fancy feature. Tumbleweed is NOT a beta product. It is a fast-moving target, it accepts some rough edges here and there, but it is to be considered a stable product. > 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. > By pulling back and switching to xz for both Factory and SP4 at this point > in time, we basically give up the chance to "test if fully on TW first" as > Takashi said above. That puts the implementation of this feature for SP4 at > high risk. We don't give up - we move back to the drawing board with the findings and work out the issues. -- 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#c16 --- Comment #16 from Martin Wilck <martin.wilck(a)suse.com> --- (Copied this from https://jira.suse.com/browse/PM-2971 for information - I think further discussion should happen there, or possibly on the kernel ML, rather than on BZ). Let me ask again how we are supposed to proceed now. In my understanding, the existence of this "Sould have" Jira ticket implies that engineering got an order from PM for the implementation this feature. So we should try. Trying implies exposing the feature to a larger audience for testing and finding possible rough edges. 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 expected that some issues would occur. It was known beforehand that package size would increase. Therefore if we want to have this feature, we need to deal with that and free the required space on the media. That's difficult, and it might mean that live image creation fails for a certain period of time. 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. By pulling back and switching to xz for both Factory and SP4 at this point in time, we basically give up the chance to "test if fully on TW first" as Takashi said above. That puts the implementation of this feature for SP4 at high risk. I don't want to push this feature forcibly. If there are strong reasons not to implement it, I won't insist. But I believe this pull-back was premature. -- 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#c15 Jiri Slaby <jslaby(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby(a)suse.com --- Comment #15 from Jiri Slaby <jslaby(a)suse.com> --- JFYI Michal reverted stable back to xz for the time being. And I submitted 5.15.1 to factory incl. this change. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1191229] [Staging][rpm4.17] Kernel fails to build with rpm 4.17
by bugzilla_noreply＠suse.com 09 Nov '21

09 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1191229 https://bugzilla.suse.com/show_bug.cgi?id=1191229#c16 --- Comment #16 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-SU-2021:3640-1: An update that solves 11 vulnerabilities and has 35 fixes is now available. Category: security (important) Bug References: 1065729,1085030,1133021,1152489,1154353,1156395,1157177,1167773,1172073,1173604,1176940,1184673,1185762,1186063,1187167,1188563,1189841,1190006,1190067,1190349,1190351,1190479,1190620,1190642,1190795,1190941,1191229,1191241,1191315,1191317,1191384,1191449,1191450,1191451,1191452,1191455,1191456,1191628,1191731,1191800,1191934,1191958,1192040,1192041,1192107,1192145 CVE References: CVE-2021-3542,CVE-2021-3655,CVE-2021-3715,CVE-2021-3760,CVE-2021-3772,CVE-2021-3896,CVE-2021-41864,CVE-2021-42008,CVE-2021-42252,CVE-2021-42739,CVE-2021-43056 JIRA References: Sources used: SUSE Linux Enterprise Module for Public Cloud 15-SP2 (src): kernel-azure-5.3.18-18.72.2, kernel-source-azure-5.3.18-18.72.2, kernel-syms-azure-5.3.18-18.72.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 the assignee for the bug.

1 0