Porteus Kernel Builder

[Rava]

I didn't used the zstd module compression patches
Seems I must to use 0009-add-zstd-compressed-modules.patch

Not created a kernel in ages myself, and for sure not one in need of xz or zstd compression, but does the above mean this version Porteus Kernel Builder (Post by Blaze #80931) should be updated to include the 0009-add-zstd-compressed-modules.patch ?

[Blaze]

should be updated to include the 0009-add-zstd-compressed-modules.patch ?

No, it does not need. Its experimental patch for very faster booting Porteus.

[roadie]

When compiling the kernel to include zstd module compression, the system you're using must have the patched kmod in place and working. The reason for this is that when

Code: Select all

make modules && make modules_ install

is executed, depmod is run at the end on the newly installed modules. If you're using the standard kmod version in Porteus, then depmod doesn't recognize the .zst modules.

The result of this is that the files in /lib/modules/5.10.4-porteus are not updated and modules.dep is in fact empty. So, when you boot with your shiny new modules, modprobe doesn't recognize them and can't load them. This is one of the reasons my kernel isn't acting nice, I've yet to find the others........but on the bright side, it only took an entire day to figure this out.

EDIT: This still doesn't fix the depmod problem, there are a couple of other files that still aren't updated, I've yet to figure out why they're not.

[babam]

EDIT: This still doesn't fix the depmod problem, there are a couple of other files that still aren't updated, I've yet to figure out why they're not.

You must use kmod with zstd support, try to compile kmod with zstd support.

kmod zstd support

Good luck.

[roadie]

EDIT: This still doesn't fix the depmod problem, there are a couple of other files that still aren't updated, I've yet to figure out why they're not.

You must use kmod with zstd support, try to compile kmod with zstd support.

kmod zstd support

Good luck.

babam,

Yes, it has to be a patched kmod, and I'm using kmod-28 which was released a couple of days ago. It does work to modprobe a .zst module. The problem seems to be that kmod and udev are not playing together nicely. The kernel boots well, udev finds all the hardware, but modprobe isn't called for some reason.

The system works as far as functioning well. If the modules were loaded when they should be, then it would boot to the desktop like any other. It does with gzipped modules, as well as xz compressed modules, no problems with either one. It's the zstd compressed ones that give trouble, and I have to think it's because kmod isn't doing what it should be doing.

I tried the patch at the link you show with kmod-27, but it wouldn't compile properly whereas kmod-28 built well and is already patched. It wouldn't take any patches I tried to apply, saying that those files were already done. As I said, it handles the compressed modules fine when you call it manually, it just doesn't do it during the boot process when it should. I'll try building kmod-27 again with the Arch patch and see if there's a difference.

[babam]

I tried the patch at the link you show with kmod-27, but it wouldn't compile properly

Maybe this will help kmod patch

[roadie]

I tried the patch at the link you show with kmod-27, but it wouldn't compile properly

Maybe this will help kmod patch

Thanks babam, but that one isn't finding the modules with modprobe. I recompiled kmod-28 with the same results, it loads the modules manually, but not when booting.

Code: Select all

root@porteus:/home/guest# kmod -V
kmod version 28
+ZSTD +XZ +ZLIB -LIBCRYPTO -EXPERIMENTAL

So, I don't think the problem is kmod except maybe how it's working with udev. But, I noticed an error in dmesg:

Code: Select all

Module has invalid ELF header

From what I've seen, that error is caused by compiling on one machine and using on a different machine. That's not the case here, kernels are compiled and used on the same machine. All the other kernels work fine, uncompressed modules, gzipped, xz compressed, no problems and that error isn't in dmesg with any of them.

I use the same .config to compile for zstd as for the others, just changing the compression algorithm, nothing else. It's frustrating in that zstd is the only thing different, yet it won't work properly. I'm posting this from the zstd version and everything seems fine, I can modprobe whatever I need, no errors show.

Code: Select all

ls /lib/modules/5.10.4-porteus/kernel/drivers/hid
hid-lg-g15.ko.zst       hid-logitech-hidpp.ko.zst  hid-multitouch.ko.zst
hid-logitech-dj.ko.zst  hid-logitech.ko.zst        i2c-hid/

I'll try different things in the .config, maybe something there is causing problems.

[roadie]

Finally, it's working.

I rebuilt 001-core.xzm to update the kmod files which I think were being messed with by the Porteus version. The kmod-28 locates the library files in /usr/lib rather than lib64 which is where Porteus has them. It boots to the desktop with no errors and seems to run good, too early to tell. I also went to 5.10.5 for the kernel, I doubt that makes a difference as I used the same .config as for 5.10.4.

Code: Select all

guest@porteus:~$ uname -r
5.10.5-porteus

Code: Select all

guest@porteus:~$ ls /lib/modules/5.10.5-porteus/kernel/drivers/hid
hid-lg-g15.ko.zst       hid-logitech-hidpp.ko.zst  hid-multitouch.ko.zst
hid-logitech-dj.ko.zst  hid-logitech.ko.zst        i2c-hid/

Now, on to the next shiny thing.

[babam]

Finally, it's working.

Congrats!
Is the boot time getting faster?

[Blaze]

Code: Select all

Sat Jan  9 20:53:30 UTC 2021
a/kmod-28-x86_64-1.txz:  Upgraded.
  Built using --with-zstd to support zstd compressed modules. This means that
  this package depends on libzstd or it will not function.
  Thanks to Robby Workman

Awesome. Thanks.

[raja]

I don think there will be any noticeable speed boost. As discussed long ago , Porteus boots to Desktop in 12 seconds(AUFS), and 10 seconds with Nekoś overlay and with application modules compressed with zstd.

If you see dmesg, Kernel completes its main job in under 2 seconds further delay of 4-7 seconds is only due to device enumeration and network related
activity.

So kernel,initrd and kernel modules compression with zstd, may not result in any benefits.

3-4 seconds of boot time is consumed by xorg, after init 4.

[fortix]

I rebuilt 001-core.xzm

Hi roadie, I was wondering, if U could share Ur rebuilt 001-core.xzm with us. This might inevitably solve a couple of prob´s I´ve been facing - thanks in advance

[babam]

fortix,

Code: Select all

$ getpkg kmod

[roadie]

Finally, it's working.

Congrats!
Is the boot time getting faster?

Thanks babam,

I wish I could say it's blazing fast, but it's not much different to anything else. It might take 1 second off the boot time compared to xz, but that's it. We have to look elsewhere for it.

[roadie]

I rebuilt 001-core.xzm

Hi roadie, I was wondering, if U could share Ur rebuilt 001-core.xzm with us. This might inevitably solve a couple of prob´s I´ve been facing - thanks in advance

fortix,

I'm not using the modified core, I built a module instead. I like to keep the base files original so they don't cause problems when testing stuff.

https://www.mediafire.com/file/gvs1eg8c ... s.xzm/file