I did a search and replace in the patch to replace YYNOMEM with YYENOMEM for gcc-10 (Debian Bullseye) and ENOMEM for gcc-8 (Buster) as suggested by the build failure error messages on those distros, and the packages then built, but I don't know if that created an actual working kernel...
Back to top

does the packaged kernel work in a vm test environment? Good to see you still active by the way.
Back to top

I set up MX 21 in Virtual Box, then installed the new kernel and booted to it, and can't really see anything out of the ordinary, but don't know how to stress test to see if the changes I made borked anything.




I suppose I could put them up for our own user testing, since they can always use the standard kernel as a backup boot option.
Back to top

Interesting, is there any official statement about certain GCC versions no longer being compatible? If not then it's a real regression that upstream needs to fix.

And speaking of which, when transitioning to v6.5 I noticed that Bullseye stopped building, so I simply dropped it [1] considering it's oldstable. I had to do this recently too for Ubuntu Focal (20.04) because it was missing a dependency to build the perf tooling.

If you find a simple fix for old GCC, let me know and I can bring back Bullseye support

[1] github.com/damentz/liquorix-package/commit/94212ced31900f08bfc237abcccc7f8d4baa103f
Back to top

stevenpusser, if you want to give the kernel a real stress test, it's short, but does an insane amount of work, just run inxi --debug 20 a few times in a loop, that does an _insane_ amount of work very rapidly, and it's real work.

If you set up a loop to run that say, 10 or 20x, that's a lot of work on the system, and it's all kinds of work, the 20 option does not upload the generated data, but this test basically reads thousands, many thousands, of files in /sys, all kinds of stuff, runs commands, so it's a very intensive operation.

I'd say if a kernel had some intrinsic issue that only happens under real stress of real actions, that is not a terrible test to run, and it's fast and easy. If you see a failure on that, you can definitely assume the kernel has a real issue.

If you see no issues with it, while you cannot assume it's totally stable and reliable as you've compiled and packaged it, you could maybe consider it safe for users to test to at least see if various scenariors, or maybe more likely, various hardware drivers cause some issues. Your idea of a limited release to users is a good one to test I think since I find if there is a corner case that is not predictable, at some point local tests are just not going to capture it as a general rule.
Back to top

I put up MX 21 and 19 builds of 6.5-5 in the respective MX repos (bullseye and buster), and so far that seems to be working for users--no explosions yet.

I'll let them know how to stress the kernel.
Back to top

I'm not sure if anything can be done about this, but the latest 11.8 Bullseye update, in combination with the latest bullseye liquorix build (I believe it was 6.5.3), caused intermittent kernel panics during boot and some amdgpu related errors in dmesg log.

I was unable to track down which package was responsible, since there were in total 139 packages updated and I had already lost a lot of time on it. My only solution was to upgrade to Bookworm, which thankfully went a lot smoother than I was anticipating.

So maybe this is just a warning for others on bullseye with AMD hardware (Zen-2 based Thinkpad in my case).
Back to top

This is a belated update about this issue: the patches became no longer necessary with the next major kernel release, as both gcc-8 and gc-10 now don't throw the compile errors.
Back to top