|
[RESOLVED] The new compression schemes break unionfs?
I have reports that MX, AVLinux, and antiX users can't use the kernels to boot their snapshots in live sessions after around 5.19-16 or -22, around when the debug info was added and the newer compression schemes then also added.
They get a report that the system can't find unionfs, which the live sessions use to boot. I just got a report that it persists with the latest 6.0 kernels, too. Is there a relatively easy way to back off the debug-info and compression changes that broke unionfs for our own MX Linux Liquorix ports, or One Simple Trick anyone knows to get them to work as is? < Edited by stevenpusser :: Nov 30, 22, 13:28 > Back to top |
|||||
|
Do you have the exact message that occurs when you try booting from a live cd? A loglevel=7 in the boot parameters might reveal what the problem is, like missing modules or applications in the init ramdisk.
And I don't think you need to, but if that is the issue, maybe seeing if bundling xz for decompression purposes might help. But, this is me just thinking out loud. EDIT: Are you using the same UnionFS here? [1] It looks abandoned, last update in 2014. Current Live CD tooling builds SquashFS images. And I'm also assuming they use the builtin OverlayFS if needed. Many live CDs used to use AUFS but we stop bundling that long time ago due to how invasive it was. [1] unionfs.filesystems.org/ Back to top |
|||||
|
Sorry, it was overlayfs that the livesystem uses, but can't find now. Here's the error that comes up for AVLinux:
:: Code :: Fatal Error
Neither aufs nor overlayfs is available :: Quote :: Those are the Live boot filesystems and you can't Live boot an ISO without them and Liquorix always has one or both...? The previous Liquorix 5.19-14.2 live boots fine and doesn't have this error, was there a change in Liquorix upstream or did these filesystems get omitted or missed in this Liquorix build?
Just asking and letting you know in case it's a build config issue..? Will ask for a loglevel=7 boot... Back to top |
|||||
|
Ok yep, most likely there's something buggy in the code that builds the live cd. The code that builds the ramdisk or copies modules over must be assuming the file extension(s).
For example, the overlayfs module's path is now: kernel/fs/overlayfs/overlay.ko.xz. The kernel understands how to load this but old code that never knew you could compress module might fail here. As far as I'm aware, Debian's initramfs tooling handles this fine for XZ, but not for ZSTD. There was a brief moment where Liquorix was built with ZSTD but Debian's tooling couldn't figure out how to manage those files, so now we're back on XZ. Back to top |
|||||
|
:: damentz wrote :: Ok yep, most likely there's something buggy in the code that builds the live cd. The code that builds the ramdisk or copies modules over must be assuming the file extension(s).
For example, the overlayfs module's path is now: kernel/fs/overlayfs/overlay.ko.xz. The kernel understands how to load this but old code that never knew you could compress module might fail here. As far as I'm aware, Debian's initramfs tooling handles this fine for XZ, but not for ZSTD. There was a brief moment where Liquorix was built with ZSTD but Debian's tooling couldn't figure out how to manage those files, so now we're back on XZ. Hi, I'm the maintainer of AV Linux (now based on the build tools of MX Linux) I am experiencing this issue and reported it to @stevenpusser, everything worked perfectly until Liquorix 5.19-14.1 (using MX Linux versioning). The ISO build script has not had any recent changes and works as expected with regular Debian kernels and worked with Liquorix until the version stated above.. I booted with 'loglevel=7' but cannot get to a console as I'm greeted with these 2 boot options: bandshed.net/images/screenshots/shot-2022-11-16_22-31-33.jpg Please advise, thanks! Back to top |
|||||
|
It looks like it's the MX scripts that needed fixes to recognize compressed modules, and the MX devs already are testing the updated versions:
:: Quote :: so it load now like KMS in live the qxl module for KVM/Qemu testing.:: Code :: Snapshot created on: 20221030_0223
System: Kernel: 6.0.0-9.1-liquorix-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1 parameters: audit=0 intel_pstate=disable hpet=disable rcupdate.rcu_expedited=1 BOOT_IMAGE=/antiX/vmlinuz quiet lang=de kbd=de,us tz=Europe/Amsterdam persist_root toram norepo live_swap=off blacklist_module=floppy pw Desktop: Xfce 4.16.0 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm 4.16.1 vt: 7 dm: LightDM 1.26.0 Distro: MXtest2-21.2.1 dev_x64 Wildflower Oktober 30 2022 base: Debian GNU/Linux 11 (bullseye) ... Graphics: Device-1: Red Hat QXL paravirtual graphic card driver: qxl v: kernel bus-ID: 00:02.0 chip-ID: 1b36:0100 class-ID: 0300 Display: x11 server: X.Org 1.20.14 compositor: xfwm4 v: 4.16.1 driver: loaded: qxl note: n/a (using device driver) unloaded: fbdev,modesetting,vesa display-ID: :0.0 screens: 1 Screen-1: 0 s-res: 1600x900 s-dpi: 96 s-size: 423x238mm (16.7x9.4") s-diag: 485mm (19.1") Monitor-1: Virtual-1 res: 1600x900 hz: 60 OpenGL: renderer: llvmpipe (LLVM 14.0.5 256 bits) v: 4.5 Mesa 22.0.5 direct render: Yes ... Boot Mode: UEFI Back to top |
|||||
|
Ok, that's good! It's unfortunate that the change I made is uncovering this bug now, but it's understandable when Debian stock doesn't enable module compression itself.
Back to top |
|||||
|
snapshot iso creation error
Yes, I have similar error with my AVL_MXE workstation Liquorix kernel-amd64 5.19.0-16.2. Tried to make a snapshot iso and flash to USB and would not boot with the following errors in images below. Highlight, copy and paste.
file:///home/jt/Pictures/snapshot_iso_output_warning.png. Back to top |
|||||
|
Just to close the loop, here's the thread (at least that I found), discussing this issue on the MX Linux forums: forum.mxlinux.org/viewtopic.php?t=72693
I'll take a look periodically to see the status, but I'm assuming this thread can be marked [RESOLVED] by the end of this year. Back to top |
|||||
|
Is zstd still required as a build-depend as listed in control.source.in, after the switch to xz-compressed modules?
I'm trying a build for the MX repo of 6.0-6 with it disabled to see what happens--if it fails, I'll have my answer. Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||
