Porteus-v5.01 bug reports

[babam]

Blaze,
you are using Nvidia.

[Blaze]

babam, no.
I prefer AMD. My video card is Radeon RX 6600

[babam]

Blaze, I thought nv12 was nvidia, it seems this issue only affects Intel GPUs.

[Blaze]

babam, do you see anything errors in Xorg or in dmesg log?

[babam]

Blaze, I don't see any errors in dmesg.
I believe this issue is caused by the kernel, perhaps caused by the i915 driver on 6.5.5
I have Kernel 5.18.8, 6.1.1 and 6.2.11 and this issue does not occur.

UPDATE:
In Kernel 6.5.5 there are 2 additional messages in dmesg related to i915

Code: Select all

[    8.395158] i915 0000:00:02.0: [drm] *ERROR* Port F/TC#3: timeout waiting for PHY ready
[    8.395290] i915 0000:00:02.0: drm_WARN_ON(tc->mode == TC_PORT_LEGACY)

[Blaze]

babam, I found
https://yhbt.net/lore/all/167947833279. ... top.org/T/
and
https://sbexr.rabexc.org/latest/sources ... cc2ee.html

How about errors in /var/log/Xorg.0.log?

[beny]

babam in terminal: glxinfo -B is mesa that have the intel driver...

[Rava]

I am using an older kernel since there is no NVidia driver 108.* provided for Port 5.0.1 but it is not working. I would happily use an official Porteus NV 108.* module, but there is none.

Booting the 5.0.1 initrd and kernel 5.4.30-porteus
And the sha256sum of my loaded initrd is the same as the one beny provided above:

root@rava:~# sha256sum /mnt/sdc1/boot/syslinux/initrd5.0.1.xz
1b1bc2acb98c7bf985129b5ccc38560961ee98068b379f22759ccdc0a52f45be /mnt/sdc1/boot/syslinux/initrd5.0.1.xz

Issues:
Not able to load a single module. The base/ has only symlinks in it that are all valid and point to a different partition of sda because my sda1 is only 1.5GB of size and not large enough to hold all my various Porteus versions.

There are long pauses prior:
"using Porteus data from /mnt/sda1/…" and
"creating live filesystem and inserting modules"

Both things happen almost instantaneous when booting Porteus 5.0

There are long pauses prior the attempt in loading of any of the failed modules.


I aborted the obviously failed boot attempt via REISUB. All modules are listed as "corrupted module".

Here some sha256 checksums showing that my modules should load just fine:

guest@rava:/mnt/sda1/Porteus_5.0.1/porteus/base$ sha256sum 001-core.xzm 002-xorg.xzm
c9092802dbd3301acc3090138c176627942b812d7c58a28190890dc43f40dc2c 001-core.xzm
0742287fa9acab126882fc7c87d57dfd4ba456299c312037e83b8bde808e8210 002-xorg.xzm
guest@rava:/mnt/sda1/Porteus_5.0.1/porteus/base$ ls -o 001-core.xzm 002-xorg.xzm
lrwxrwxrwx 1 root 53 2023-09-29 17:25 001-core.xzm -> /mnt/sda2/bin/linux/porteus/5.0.1/x86-64/001-core.xzm
lrwxrwxrwx 1 root 53 2023-09-29 17:25 002-xorg.xzm -> /mnt/sda2/bin/linux/porteus/5.0.1/x86-64/002-xorg.xzm

[beny]

hi Rava, but isn't too weird the mount point of the sda2 for core and xorg? or am i wrong...

[Rava]

hi Rava, but isn't too weird the mount point of the sda2 for core and xorg? or am i wrong...

Works perfectly for all these:
Porteus4.0
Porteus5.0rc?
Porteus5.0 (finale version)

Is it the new initrd that cannot handle the symlinks?

Because I am running the same kernel right now and it works with that kernel perfectly for years. (and its the only kernel where an NV driver 340.* exists)

[ncmprhnsbl]

Is it the new initrd that cannot handle the symlinks?

the only difference is the new busybox and supporting libs, which i find doubtful that would have this effect.
but it's easy enough to test by swapping out it with the older initrd.

i'm wondering if some of the problems(Ravas and benjibassons) are related to have multiple installs on the same media, and that the porteus-v5.0-x86_64.cfg remains the same name (ie. i didn't change it to v5.01) and stuff gets confused.
if this is the case, a workaround would be to rename that file and use the cfgfile=some_name.cfg cheatcode

I believe this issue is caused by the kernel, perhaps caused by the i915 driver on 6.5.5

it's always a bit of gamble with using the latest kernel release
as far as 002-xorg goes there's barely any changes since the last update, one being libX11 patch update, but wouldn't think that would be it (especially, as you say earlier kernels work fine)

[Rava]

i'm wondering if some of the problems(Ravas and benjibassons) are related to have multiple installs on the same media, and that the porteus-v5.0-x86_64.cfg remains the same name (ie. i didn't change it to v5.01) and stuff gets confused.
if this is the case, a workaround would be to rename that file and use the cfgfile=some_name.cfg cheatcode

I go via UUID and the path name:

Code: Select all

APPEND initrd=initrd5.0.1.xz from=UUID:CoRrEcTuUiD/Porteus_5.0.1 [other append stuff]

and the system tells me which folder it is loading from:

It is the one it should load from. So that is no possible source of any issues as far as I can tell. (But I am far away from the knowledge of ncmprhnsbl )

I have now copied all my modules onto a 4 GB VFAT USB thumbdrive (there was the historic Porteus 2.? on it, *snicker*) and then yours truly will try the following:

● Boot all (kernel V5.4.30-porteus, initrd5.0.1) via that USB thumbdrive (no symlinks cause VFAT is too silly to support symlinks)

● Alter my main approach (editing my main porteus.cfg) by using the older 5.0 initrd and boot like so (kernel V5.4.30-porteus, all else stays the same, symlinks and whatnot).

And report back here if both succeed, if one succeeds or if *gasp* both fail.

[Rava]

As I was hoping for it was happening:

● Alter my main approach (editing my main porteus.cfg) by using the older 5.0 initrd and boot like so (kernel V5.4.30-porteus, all else stays the same, symlinks and whatnot).

all I did was swap the 5.0.1 initrd with an older one from porteus 5.0 (but when I recall correct, not the original one since that was unable to fsck one ext4 filesystem) and I am in:

Code: Select all

guest@rava:~$ cat /etc/porteus/*
001-core.xzm:20230922
002-xorg.xzm:20230922
002-xtra.xzm:20230922
003-xfce.xzm:20230922
06-man.xzm:20230915
initrd.xz:20220928
guest@rava:~$ uname -a
Linux rava.myporteus.net 5.4.30-porteus #1 SMP Sat Apr 4 20:11:00 UTC 2020 x86_64 Intel(R) Core(TM) i7 CPU       Q 720  @ 1.60GHz GenuineIntel GNU/Linux

And once more, my olden days kernel and 010-nvidia-340.108-k.5.4.30-porteus-v5.0-x86_64_rava.xzm work as flawlessly as they did on its first day. Yay.

[Rava]

The announcement post Porteus-v5.01 is released! states this:

Perl has been moved to 05-devel (so those that need it for some perl script will need get it, so as not to need to run with devel)

Slackware package managers included: slapt-get and slackpkg (in core) and slpkg (in 05-devel)

But where is 05-devel ?
What is written as quoted lets me assume one must use the Port 5.0.1 own 05-devel module and not this one from Port 5.0: (as identified by its md5sum)

Code: Select all

4ad2c0217ec914cb02aab3b77fd55fe5  05-devel.xzm

I looked into http://www.mirrorservice.org/sites/dl.p ... 1/modules/ and no file 05-devel.xzm to be found.
Same with http://ftp.vim.org/ftp/os/Linux/distr/p ... 1/modules/
Same with http://ftp.nluug.nl/os/Linux/distr/port ... 1/modules/

I also searched for "05-dev" in all 3 locally downloaded sha256 / md5sum checksum files:

Code: Select all

guest@rava:/mybin/linux/porteus/5.0.1/x86-64$ ls -o *txt
-rw-r--r-- 1 guest  514 2023-09-25 14:32 md5sums-bundles.txt
-rw-r--r-- 1 guest  775 2023-09-25 14:31 sha256sums-iso.txt
-rw-r--r-- 1 guest 2139 2023-09-26 15:15 sha256sums-modules.txt
guest@rava:/mybin/linux/porteus/5.0.1/x86-64$ grep 05-dev *txt
guest@rava:/mybin/linux/porteus/5.0.1/x86-64$ 

to no prevail.

What am I missing here or was 05-devel.xzm overlooked when it came to upload all files?

[ncmprhnsbl]

But where is 05-devel ?

<mirror>// x86_64/Porteus-v5.01/kernel/
same place it's been for the last several versions