Linux Kernel 5.9 zstd

[user1111]

Just built kernel 5.9 (using Fatdog 811 devX sfs) with kernel compression of xz set and it compiled fine Recompiled with zstd kernel compression set and ... not fine Reported ...

zstd: error 11 : Allocation error : not enough memory

Recompiled again with lz4 kernel compression set, and again it compiled OK

[Duprate]

Good afternoon! I am very willing to thoroughly test your 5.9.0 Kernel! Good luck ...

[jamesbond]

Errr ... I think rufwoof's kernel is built without aufs. His kernel is compiled very tightly to meet the requirement of his own machine and it doesn't have drivers of other machines (that's why it can get down to as small as 8MB), and unless you have identical machine as his, his kernel's probably not going to work for you.

Please correct me if I'm wrong, @rufwoof.

[user1111]

Spot on James. Except 5.72MB (vmlinuz with initrd built into that) for 5.9.1

Oddly, once booted uses up twice as much memory space as earlier kernels, a whopping 40MB instead of 22MB (LOL!).

My laptop frugal and desktop systems are still both running with the 5.4.60 default kernel

s.png (170.6 KiB) Viewed 802 times

[user1111]

BTW, fbvnc (framebuffer vnc) through a compressed ssh tunnel using OpenSSH works really well (quick), around as quick as a standard fatdog that was tigervnc'd into another box. Dropbear's ssh however is sluggish by comparison. I see that Fatdog recipe for Dropbear has zlib (compression) disabled - when I tried dropbear with zlib enabled it didn't work very well and still seemed to run at speeds as though compression was disabled. So along with just having busybox (default build so quite extensive command wise) I've stuck with using OpenSSH (that also requires OpenSSL), along with wpa_supplicant and iwconfig (for wifi net connect), and fbvnc (so I can vnc into my desktop Fatdog system and have a full Fatdog gui desktop running on the laptop). Another benefit of OpenSSH is you also get sshfs thrown in - so I can sshfs mount my main Fatdog's session as though it were a local folder on the laptop.

That's all using Fatdog (811) as the 'tool-chain' to build the standard kernel as from kernel.org and busybox from busybox.net.

A few quirks, such as when running Chrome the ctrl + and - to zoom in/out doesn't work, nor does shift and arrow keys work when selecting text/Libre Calc cells. i.e. fbvnc's (the version including your patch and my UK/Europe extensions) still needs some work. For the time being I'm just using the three dots and zoom menu entry to zoom in chrome, and again using the mouse to select multiple cells in Libre Calc.

Our internet is throttled for upload speed, restricted to 10Mbs. We're still using a old 801.11g 2.4Ghz wifi network, so its nice to have the laptop connected via wifi 'receiving' at 100Mbs+

ss.jpg (9.53 KiB) Viewed 850 times

[Duprate]

In fact, I am content to keep the kernel-5.4.X LTS up to date ... Until the situation of suport aufs is defined. Or that the overlay pattern be adopted. May the best happen!
What I do know is that only simple things work and prosper ... And that my English is bad and I depend on Google Translate!

[user1111]

Until the situation of suport aufs is defined. Or that the overlay pattern be adopted.

As I understand it Duprate, aufs wont be entered into mainline Linux. Whilst its great in the concept of Puppy dynamically (live) loading/unloading sfs's etc, apparently in high intensity situations it can endure delays/errors. The 'advanced' element seems to have been deemed to be just too complicated for mainline Linux and as such aufs looks set to remain being a optional patch. 'Simpler' overlayfs has already been made mainline - but involves having to set up a fixed stack (of sfs's for instance) during bootup.

[wiak]

Until the situation of suport aufs is defined. Or that the overlay pattern be adopted.

As I understand it Duprate, aufs wont be entered into mainline Linux. Whilst its great in the concept of Puppy dynamically (live) loading/unloading sfs's etc, apparently in high intensity situations it can endure delays/errors. The 'advanced' element seems to have been deemed to be just too complicated for mainline Linux and as such aufs looks set to remain being a optional patch. 'Simpler' overlayfs has already been made mainline - but involves having to set up a fixed stack (of sfs's for instance) during bootup.

As you probably know, you can of course nest stacks within overlayfs. Indeed I experimented with that and discussed it somewhere on the old forum as a mechanism for providing functionality somewhat similar to aufs. That was a year or more ago so I've forgotten the details and don't think I documented it in particular detail either though I did decribe the method briefly to gyro I think. I thus forget how exactly I implemented these nested stacks but possibly I used chroot each time to switch to newest stack so may have had drawbacks/limitations; I can't say one way or the other about that now.

I doubt anyway that I will myself re-experiment with that since I generally prefer the simplicity of single stack overlayfs setup and don't use sfs addons very much so don't mind rebooting to incorporate them in the layout on the rare occasions I'd want new layer. Nothing particularly against aufs if it continues to work reliably for those who prefer that (though I'd rather, myself, let the upstream distro teams compile and test kernels on my behalf rather than trust myself, or anyone else, applying and testing unofficial patches, but no big worry either way for my generally relatively non-dangerous computer usage - well, except for internet banking - I admittedly never feel safe about that, whatever system I use, but just have to keep my fingers crossed).

wiak