[RESOLVED] liquorix 6.4-16.1~sid (2023-08-23): boot problems with the latest version of kmod
antdeveloper
Status: Interested
Joined: 10 Mar 2023
Posts: 15
Reply Quote
Hi,
I run Debian/sid install with liquorix kernel installed from your repository.

I have found that after upgrading the kmod package there are problems booting the system and the boot process stops.

I contacted the Debian maintainers who gave me the reasoning:

> The error message it gave was "decompresson failed with status 6"
Status 6 is XZ_OPTIONS_ERROR, which means "Input was encoded with settings that are not supported by this XZ decoder".
So it looks like you have compressed the modules (how?) with XZ settings which are supported by the userspace loader but not by the kernel one.

bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050586

You need recompile liquorix kernel?

Thanks,
Antonio
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1116
Reply Quote
That's interesting, there must have been some bad timing when the kernel was built.

In the next 1-2 hours you'll see a new kernel that was simply rebuilt with the latest packages in Debian Sid. Note, all kernels are built using docker images supplied by Debian, for their respective branch. The only way you'd get a conflict is if Debian introduced mismatched packages themselves, even for just a short time period that was unfortunate.

Also reading the bug report, it appears Debian doesn't use compressed modules themselves, so they probably inadvertently introduced a conflict they didn't intend, like an an alpha or beta update to XZ that makes it incompatible with upstream Linux. But we'll see in next update.
Back to top
DeepDayze
Status: Contributor
Joined: 21 May 2009
Posts: 128
Reply Quote
Hi Damentz, I had hit that same issue as the original poster (I am running Sid on my big machine) and perhaps why not simply use Zstd for compression if not already? Another idea would be to try various compress options that are supported for kernel module compression. I am willing to test new builds if needed. Seems like there might been a change in kmod as well as that package I upgraded yesterday. Let me know.
Back to top
DeepDayze
Status: Contributor
Joined: 21 May 2009
Posts: 128
Reply Quote
I think the issues with kmod vis a vis Liquorix may be related to this:

bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050427

EDIT: I downgraded kmod plus its lib and Liquorix kernel now boots, so there has to be something in the kmod update that broke decompression of xz-compressed modules. In this bug report didn't see any changes that could have adversely affected this, nor have there been any xz updates recently.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1116
Reply Quote
Latest kernel out for Trixie/Sid is built without module compression, and DEBUG_INFO was disabled to keep file sizes under control.

This will be a somewhat permanent change, when CONFIG_DEBUG_INFO was enabled initially, it was with hopes that it would help with kernel debugging. However, because the kernel package strips debug symbols regardless, it didn't do anything. If someone gets an OOPS from Liquorix, you can get the original lines by compiling the kernel sources with the same config and run decode_stacktrace.sh to get the original line numbers back.

antdeveloper, can you confirm latest kernel works? I tested from a VM and confirmed that the previous kernel failed to boot while the newest is able to get to desktop.
Back to top
DeepDayze
Status: Contributor
Joined: 21 May 2009
Posts: 128
Reply Quote
Why not offer a debug package that a user can install to provide the debug symbols and such? Is it possible to create one alongside your kernels?
Back to top
DeepDayze
Status: Contributor
Joined: 21 May 2009
Posts: 128
Reply Quote
I tried the new Liquorix kernel along with reinstalling the new kmod and it boots successfully for me. Perhaps revisit compressing the kernel modules with zstd in sid and xz in stable and I can help test zstd compressed kernels.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1116
Reply Quote
I'll probably not be enabling compression (maybe gzip at the least in the future), since the only concern now is installed size.

The original issue that prompted XZ compression was to override the compression algorithm used in user initramfs/mkinicpio configurations. If the user configured their initramfs for no compression or something light like LZ4, the module size would make the image too large to load at boot time. To work around that, I enabled XZ compression to force a high compression ratio regardless of what settings were on the installed system.

Now that we're not adding debug info to the modules, this compression is not necessary. I'll not be adding it back unless there's a good reason (outside of reducing installed size, which is fine right now).

Thanks for the feedback though, I'll mark this thread as resolved.
Back to top
antdeveloper
Status: Interested
Joined: 10 Mar 2023
Posts: 15
Reply Quote
I installed the latest kernel 6.4.12-1-liquorix-amd64 and subsequently updated the kmod that I had put in hold: I confirm that it works.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1116
Reply Quote
:: DeepDayze wrote ::
Why not offer a debug package that a user can install to provide the debug symbols and such? Is it possible to create one alongside your kernels?


Debug packages include all the symbols in package, and I think they also compile the kernel differently and run slower overall. The original need to enable CONFIG_DEBUG_INFO was to make those symbols available. However, that didn't work out the way I expected for a few reason:

1. Debug packages don't strip the binaries and modules. Since the Liquorix kernel package strips symbols and other data like that from binaries and modules, the debug info was effectively useless
2. There's some other kernel package code I'd need to add to make the debug data remaining useful (debug packages place symbol files very particularly on the filesystem)
3. It turns out that if you take a kernel OOPS stack trace and run decode_stacktrace.sh by following the kernel debugging guide [1] with the same exact source code, you can get the exact lines back that are problematic. This eliminates the need to distribute a "debug" kernel, since you can still get the information you need from the same OOPS.

So I'll not be producing a debug kernel, they're unnecessary and anyone with the right knowledge can decode a stack trace that comes from any Liquorix kernel, regardless if they have debug info added or not.

[1] docs.kernel.org/admin-guide/bug-hunting.html
Back to top
Display posts from previous:   

All times are GMT - 8 Hours