Porteus Kernel Builder

[M. Eerie]

That's disturbing

"... on my part."
I remember the early days when I built my own PC, using ATI (now AMD) motherboard and graphics. That was a less expensive alternative to Intel Pentiums, but I always had problems with drivers. Since then, every machine I bought was Intel and I don't remember having these problems at all. Now I went for an HM80 Elite MiniPC and those nightmares come back to me. In both Nemesis and Ubuntu, I must start with this set of parameters:

amd_iommu=force_enable iommu=pt idle=nomwait rcu_nocbs=0-15 processor.max_cstate=3

Otherwise, the system freezes immediately.

And that doesn't prevent the system from freezing sometimes, but at least I have reduced the chances by 95-98%, while on Windows, obviously, there is no problem (I hardly use it, but I browse and encode video without problems).

I also know that there are other Linux distros that don't have these problems, but then....

https://www.phoronix.com/forums/forum/h ... hm90-linux

That is, the problem has existed for at least a couple of years and not even Ubuntu has managed (or bothered) to solve it. Not that they are the ones to patch a driver that is alien to them, but one hopes not to have to mess with hacks to start their (presumably robust) system.

This is not acceptable from my point of view, although logically there will be many people who are delighted with a similar product. It's just me been unlucky again, it seems.

On PorteuX it works though

Indeed!
I'm very pleased with your derivative. Fast, predictable... Very workable. I just miss a couple of things, primarily the power of pacman and the amount of packages available in Arch, but that's another story. On the other hand, in Arch I can't get the latest version of 7z to work with Engrampa, but in Porteux it works fine. Porteux Atril and Zenity don't need so many monstrous dependencies... Anyway...

[fulalas]

@M. Eerie, there was a problem in the AMD motherboard specification for some mobile Ryzen motherboard so all those mini PCs were struggling to be 100% stable, regardless of the system. After AMD released an update in the specification a few months ago, the mini PCs manufactures could finally fix the issue. More information here: https://www.reddit.com/r/BeelinkOfficia ... rdt=54087

Some distros have updated 7z so it doesn't work properly with most of the frontends, including Engrampa and file-roller, to name just a few. This is because official 7zip project has broken the API a few years ago and nobody ever bothered to fix it. PorteuX uses the latest version that is still compatible with the old API.

I'm not sure what you mean by 'Porteux Atril and Zenity don't need so many monstrous dependencies'.

[M. Eerie]

there was a problem in the AMD motherboard specification

Not sure mine is affected (mine is MiniForums not Beelink). I'm aware that quite a few people report problems when the miniPC goes from low power consumption state to perform an intense task. It sounds like a problem of lack of voltage at critical times. Maybe due to a design flaw, but I'm more inclined to think it's a fault in the drivers because in Windows it doesn't happen.

Some more examples of people reporting problems with AMDGPU:
https://www.reddit.com/r/linux/comments ... ility_like

PorteuX uses the latest version that is still compatible with the old API

Ah, that explains it.

I'm not sure what you mean by 'Porteux Atril and Zenity don't need so many monstrous dependencies'.

Yours seems to be a very streamlined "MATE current" version. No webkit2gtk adding 100Mb to the party, using Adwaita gtk-2.0, etc.

[M. Eerie]

I've run a modprobe on my hardware and uploaded a log:

https://linux-hardware.org/?probe=592f538099

As you can see, the modprobe failed on my graphics card, reporting:

Driver is not found or not configured.

The device is supported by kernel versions 5.4 and newer.

I'm using the previous 6.5.3 kernel with these settings referring to the CONFIG_DRM_AMDGPU:

# CONFIG_DRM_RADEON_USERPTR is not set
CONFIG_DRM_AMDGPU=m
CONFIG_DRM_AMDGPU_SI=y
CONFIG_DRM_AMDGPU_CIK=y
# CONFIG_DRM_AMDGPU_USERPTR is not set
# CONFIG_DRM_AMDGPU_WERROR is not set


How would I configure in order to get it working?

Thanks

[Blaze]

[Updated kernel Examples]
==== AUFS Kernel only for Porteus ====
Simple package (vmlinuz, 000-kernel.xzm, 06-crippled_sources-NNN-XXbit.xzm, 32bit.config)

6.7.5 <-- NEW : "All patches" patching was done.
32bit-ALL-kernel6.7.5.tar (~185 M)
https://www.mediafire.com/file/hhkf5nr7 ... l6.7.5.tar
b80e2c2504058cdb0401956e93fd7d96 32bit-ALL-kernel6.7.5.tar

==== AUFS Kernel only for Porteus ====
Simple package (vmlinuz, 000-kernel.xzm, 06-crippled_sources-NNN-XXbit.xzm, 64bit.config)

6.7.5 <-- NEW : "All patches" patching was done.
64bit-ALL-kernel6.7.5.tar (~196 M)
https://www.mediafire.com/file/wutj0d3o ... l6.7.5.tar
3aa80c40d4fa763ec817e83254222b21 64bit-ALL-kernel6.7.5.tar

Note 1: Compiler that was used.
for kernel 6.7.5: 11.2.0-x86_64

Note 2: Compilated under Porteus 5.01 (Slackware 15.0 base. Note. glibc-2.33 replaced on glibc-2.35)

Note 3: A new cryptsetup (version 2.3.5: presented by @ncmprhnsbl)

Thanks to neko for support

[AcnapyxoB]

Memory consumption is still higher compared to kernel 6.5.5, 6.6.11 !?

- On a real PC with 8 GB RAM (Always Fresh):

kernel 6.7.5:

Code: Select all

free -h
total        used        free      shared  buff/cache   available
7.5Gi       704Mi       6.1Gi       153Mi       747Mi       6.2Gi

kernel 6.6.11:

Code: Select all

free -h
total        used        free      shared  buff/cache   available
7.5Gi       442Mi       6.3Gi       155Mi       759Mi       6.5Gi

- VirtualBox 2GB RAM:

kernel 6.7.5:

Code: Select all

free -h
total        used        free      shared  buff/cache   available
1.9Gi       611Mi       702Gi       55Mi       674Mi       1.0Gi

kernel 6.5.5:

Code: Select all

free -h
total        used        free      shared  buff/cache   available
1.9Gi       434Mi       879Mi       55Mi       677Mi       1.2Gi

[Ed_P]

- VirtualBox 2GB RAM:

kernel 6.7.5:

Code: Select all

free -h
total        used        free      shared  buff/cache   available
1.9Gi       611Mi       702Gi       55Mi       674Mi       1.0Gi

Interesting that a 1.9Gi system has 702Gi free. That's almost a 1 Ti.

[Blaze]

Hi AcnapyxoB.
Thanks for your feedback.
How about to try kernel builded via fulalas script with Porteus config 64bit-ALL-kernel6.7.5-fulalas.tar 183.7 Mb?

[Ed_P]

How about to try kernel builded via fulalas script with Porteus config

But does that kernel support all the hardware that the Porteus kernel supports?

[Blaze]

Yes

[AcnapyxoB]

How about to try kernel builded via fulalas

kernel6.7.5-fulalas, no big difference:

Code: Select all

guest@guest:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       614Mi       687Gi       55Gi       676Gi       1.0Gi
Swap:             0B          0B          0B

[Blaze]

Code: Select all

# uname -r
6.7.5-porteus

# free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       1.2Gi        13Gi        18Mi       1.0Gi        13Gi
Swap:             0B          0B          0B

Code: Select all

# uname -r
6.6.11-porteus

# free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       794Mi        13Gi        17Mi       1.0Gi        14Gi
Swap:             0B          0B          0B

[AcnapyxoB]

Blaze strange, maybe the system allocates more RAM with 6.7.X kernels !

[Blaze]

AcnapyxoB, after these changes https://git.kernel.org/pub/scm/linux/ke ... fe9c12c534 ( https://github.com/sfjro/aufs-standalone/issues/35 ) in the main tree of kernel AUFS have trouble with RAM.
A new version of AUFS does not slove this issue.

[AcnapyxoB]

A new version of AUFS does not slove this issue

This explains everything.