Porteus 5.0 RC2 bug reports

[evergreen]

@Ed_p

why is this not being discussed in a grub2 or grub or grub4dos thread?

I dont know hehehe

@rava

I mean rewrite this file

/etc/profile.d/porteus.sh

with your parameters and then make a module but thinking further you are right with initrd, this doesnt make sense change the parameters here with porteus.sh if its already loaded

[Ed_P]

I think the porteus.sh file is created each boot based on the file's date.

And Multi-booting USB drive with no initrd file changes used.

[Rava]

^ & ^^

The solution should be to be able to create a multi-boot USB stick with either Porteus ISOs or the extracted modules in folders variant, or both mixed.

One should never have to create a new initrd to just to be able to boot a new variant, version, be it finale, alpha, beta, rc1 or rc3117 [¹] of Porteus, and like I wrote on the last post of page 14, the rc1-pre-rc2 initrd I used for booting rc2 and trying to boot rc2 was the same as the initrd in the rc2 iso all along (with me only realizing such while I wrote the above reply and did the md5sum tests)

I just hope changing my boot/syslinux/porteus.cfg from

Code: Select all

from=[…]/Porteus_5.0rc2/porteus

to a mere

Code: Select all

from=[…]/Porteus_5.0rc2

does the trick and I am finally able to fire up rc2.

_________________________

@Ed_p

why is this not being discussed in a grub2 or grub or grub4dos thread?

I dont know hehehe

One reason might be the undocumented change in from= behaviour, so that now you have to omit the /porteus/ part of the path?
I am not sure, but that change could have been happened between rc1-pre-rc2 and rc2.
_________________
[¹] unless of course the alpha or beta version has some specific explained in detail reason(s) for having an special initrd.

[Rava]

Indeed it finally worked:

Code: Select all

from=UUID:WhAt-EvEr/Porteus_5.0rc2

did the trick.

But the need for omitting the /porteus part of the from= path should be documented.

For now this is my rc2 basic system:

Code: Select all

# md5sum 001-core.xzm 002-xorg.xzm 002-xtra.xzm 003-xfce-4.12-20201108.xzm
13b9a87b6291a710446a418bca172dc8  001-core.xzm
2494fa52e2510c3bbbf75b1333ae6f11  002-xorg.xzm
1cd8e924b505c4e1fe4604a246c08860  002-xtra.xzm
6221bdcd5d4272e0717c26a6c975ace9  003-xfce-4.12-20201108.xzm

and since I run kernel 5.4.30 for my 010-nvidia-340.108-k.5.4.30-porteus-v5.0-x86_64_rava.xzm I also use

Code: Select all

000-kernel5.4.30.xzm

[Ed_P]

But the need for omitting the /porteus part of the from= path should be documented.

I can't find any documentation saying the /porteus part of the from=path is required.

from=/dev/device
from=/path/folder
from=/path/porteus.iso

... Loads Porteus from the specified device, folder or ISO file.
Examples:
'from=/dev/sdb2' will attempt to load unpacked Porteus ISO from
the second partition on your second drive.
'from=/mnt/sda2/linux-testing' will attempt to load unpacked ISO
from the 'linux-testing' folder placed on the second partition.
'from=/linux-ISO/porteus.iso' will attempt to load the Porteus
data from an ISO file placed inside the 'linux-ISO' folder.

If the destination partition is not provided with this
cheatcode, the booting script will search through all available
devices for your data.

I've never used it since starting with 3.0.

Added in 9 minutes 5 seconds:
And the contents of an unpacked ISO folder are:

Code: Select all

guest@porteus:/mnt/live/mnt/isoloop$ tree  -d
.
├── EFI
│   └── boot
├── boot
│   ├── docs
│   └── syslinux
└── porteus
    ├── base
    ├── modules
    ├── optional
    └── rootcopy

10 directories
guest@porteus:/mnt/live/mnt/isoloop$ 

[Rava]

I can't find any documentation saying the /porteus part of the from=path is required.

I let someone else answer that

.. when using an ISO the string from FROM= is just that and boots from there (Ed_P)

but when using separate base files (exported/unzipped/etc), there HAS TO BE the config file
AND the linuxrc automatically ADDS "porteus" to the path ! (Roadie and I)

so FROM=/mnt/sda1/porteus can never work .. since it gets passed on internally as /mnt/sda1/porteus/porteus
the cheatcode manual DOES NOT state to omit the porteus directory
renaming porteus to something else also does NOT work because of this (also case sensitive)
and if there is NO cfg file (within a directory called ../porteus) it halts the bootproces alltogether regardless of whether or not the path is correct in regards to FROM= (even though the cfg is empty anyway)

(highlighting using colour by me)

I wonder why you did not disagree when Buurman wrote the above but you disagree when I state the same. Double standard?

As you quoted, from is also named as

Code: Select all

from=/path/folder

so one would presume, since the Porteus cfg and base folder sits in whatever/porteus the correct path to use is

Code: Select all

from=whatever/Porteus_5.0rc2/porteus

instead of a mere

Code: Select all

from=whatever/Porteus_5.0rc2

Buurman, roadie and me found out the hard way that this is not the case.

Also, this:

my command line now looks like:

from=/mnt/sda1 extramod=/mnt/sda1/porteus/modules changes=/mnt/sda1/porteus

which internally gets treated as:

from=/mnt/sda1/PORTEUS extramod=/mnt/sda1/porteus/modules changes=/mnt/sda1/porteus/CHANGES

note the inconsistency ?


-> so linuxrc is inconsistent on directory-structure and manual needs to be clearer on the subject

But imo the whole 'PORTEUS' (incl BASE) and CHANGES paths should be omitted from the linuxrc altogether in order to give users true, full freedom of where to put what, also why the need to look for a cfg that is empty ? Don't 'search' just use or don't use the path given from command line. (so yeah, problems like these most probably only occur on very few occasions of stubborn users who rename their files and directories instead of doing and using what and how they are told / how they are supposed to)

(highlighting by me)

[Ed_P]

I don't recall Buurman saying the documentation needed to be changed. And if the documentation had been followed the problem wouldn't have occurred.

Hopefully one of the developers will notice the problem with people interpeting "/folder" to mean "porteus"or "boot' or "EFI" or "base" or etc and update the documentation to say that "/folder" doesn't mean those words.

And I am happy to hear you got your USB problem resolved Rava.

[Rava]

I don't recall Buurman saying the documentation needed to be changed.

I just quoted what he wrote.
And he is correct in stating the inconsistency as he did list what is written in the menu.lst or porteus.cfg and into what it is translated: that some parameters get extended, while others do not.
It would not hurt to be more specific in the documentation about that, now, would it?

And I am happy to hear you got your USB problem resolved Rava.

When it comes to booting 5.0rc2, yes, and I must say, it seems to be reacting quicker and acting smoother than 5.0rc1 or 5.0rc1-pre-rc2 ever did.

Which in itself is a nice thing.

(There used to be some hardware speed validation stuff for Linux, especially for what the X server and native driver is capable of doing, but not used any such things in many years, so not sure if there is new test suits out there, or if the old ones would still work with a never Linux OX / Linux kernel.)

On the other hand, the recovery of my crashed NTFS partition is still not that successful, I try to compile the 7.2WIP version of photorec.
The maintainer of it said it has extended capabilities compared to 7.1.

Added in 14 minutes 6 seconds:
Update
Just realized the maintainer of testdisk & photorec replied again to my post in his forum and provided the link for the pre-compiled x86-64 Linux binaries, so first I try to mold these into the same kind of module with the same file and folder hierarchy that donald used in his 7.1 version of the module.
And if it succeeds the I upload it and post it in "x86-64 modules".

Added in 34 minutes 6 seconds:
Done, the 7.2-WIP module is much larger than the 7.1 version due to the three binaries being static binaries. But it works, that is what counts the most, amiright?

[Ed_P]

urright

[Rava]

So, finally able to give some 5.0rc2 feedback. Yay!

Trying to run xzm2dir as non-root user ends with error messages and no xzm extracted into the target folder. I get asked about the root password, and after I gave it the env errors start:

Code: Select all

guest@porteus:/mnt/sdb/Porteus_5.0rc2/porteus/base$ xzm2dir ../992-rootcopy_5.0rc2_2020-12-07.xzm /tmp/992-rootcopy_5.0rc2_2020-12-07/
/usr/bin/env: ‘/opt/porteus-scripts/xzm2dir /mnt/sdb/Porteus_5.0rc2/porteus/992-rootcopy_5.0rc2_2020-12-07.xzm /tmp/992-rootcopy_5.0rc2_2020-12-07’: No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines

The only way to succeed with xzm2dir is to start it via a root terminal.
_____________________________________________

Also, this is a bother ever since the very first version of 5.0 XFCE - where does audacious store the info to use the GTK interface?

Every time I boot up Porteus, audacious again starts up with this tiny mini Winamp Classic interface that sucks when you use a full-HD-screen or even a larger one.

As soon as I told audacious to use the GTK interface it is able to remember that, but looking into the recently changed files I could not figure out where audacious saves that info.

~/.config/audacious/config is not the file with the info on the GTK interface: I always saved the most recent ~/.config/audacious/config to rootcopy/ or into rootcopy.xzm, still, at next Porteus startup audacious is back to the ugly tiny Winamp Classic interface. Whhhyyy?

[Rava]

ncmprhnsbl, any yet another browser-update issue or maybe a bug:

Two errors running update-browser -d -p when a palemoon tar.xz is in the current directory:

Code: Select all

root@porteus:/Porteus_modules/5.0/palemoon# update-browser -d -p
 Starting checks ... 
[OK] User is root.
[OK] Distro is Porteus
Downloading live script ...
Downloading: update-palemoon-live  DONE
Work will be done in: /Porteus_modules/5.0/palemoon 
 Checking if palemoon is installed ... 
[OK] palemoon is installed
[OK] installed palemoon version:  28.8.4 

 A palemoon tarball was found in /Porteus_modules/5.0/palemoon 
 We will use this archive to create palemoon.

Choose the palemoon file you want to process.


1) palemoon-28.16.0.linux-x86_64.tar.xz
#? 1
CHOICE:palemoon-28.16.0.linux-x86_64.tar.xz
 Checking for Porteus ... 
[PASS] Distro is Porteus
Getting latest version ...
Checking http://dl.porteus.org/x86_64/current/modules
 Set your home page. 
 Leave blank for: https://forum.porteus.org and press Enter to continue.
> 
[PASS] Homepage is available

Choose a locale from the list.

 1) palemoon-28.16.0.linux-x86_64.tar.xz
 2) bg
 3) cs
 4) de
 5) el
 6) en-GB
 7) en-US
 8) es-AR
 9) es-ES
10) es-MX
11) fr
12) hu
13) it
14) ko
15) pl
16) pt-BR
17) pt-PT
18) ru
19) sk
20) sv-SE
21) tl
22) tr
23) uk
24) vi
25) zh-CN
#? 

There are two errors here:
One, the installed and even running palemoon version is 28.16.0, not 28.8.4 .

And 1) palemoon-28.16.0.linux-x86_64.tar.xz is sure no valid locale.

[donald]

where does audacious store the info to use the GTK interface?

~/.config/audacious/plugin-registry

2 values are changing > enabled 1 or 0
see:

Code: Select all

..............................
name GTK Interface
domain audacious-plugins
priority 0
about 0
config 1
enabled 1  <-- this one and
...............................
name Winamp Classic Interface
domain audacious-plugins
priority 0
about 0
config 1
enabled 0  <-- that one

[ncmprhnsbl]

ncmprhnsbl, any yet another browser-update issue or maybe a bug:

should be fixed on the server now(and on mirrors sometime later)

[Rava]

~/.config/audacious/plugin-registry

2 values are changing > enabled 1 or 0

okay… but I think the file is called plugin-registry for a reason.

Can I only save the quoted parts? Do I need to delve into audacious readmes for the simple goal of getting my GTK interface?

I would like to have a saved setup that works for all my hardware and I fear some hardware related registered plugins might break that goal.

The question is: would a newly started audacious with a ~/.config/audacious/plugin-registry from a different hardware just ignore unavailable but mentioned in ~/.config/audacious/plugin-registry plugins?
While still loading other hardware related plugins available now but missing in ~/.config/audacious/plugin-registry ?

If so, good, if not…

In the end if no other solution is working, I could add a custom selection to /etc/rc.d/rc.local that knows about my known hardware and selects the correct plugin-registry to be copied to /home/guest/.config/audacious/plugin-registry - not to ~/.config/audacious/plugin-registry since it is root executing /etc/rc.d/rc.local using similar info my machine.sh uses:

Code: Select all

#!/bin/bash
#VERSION="0.5"
#MYNAME="machine.sh"

uname -p
echo /mnt/sd*/intHD*_[1-9]_*

exit 0

The /mnt/sd*/intHD*_[1-9] is part of how my script suite indexing output of ls and find of all internal and external partitions knows which drive and partition it is currently dealing with.

[Rava]

Sadly my working solution for having webp working for my image viewer viewnior and for the preview images in XFCE's thunar that worked flawlessly in 5.0rc1 is now broken.

I just made a module out of 032-webp-pixbuf-loader-20191003.fb04954-x86_64-1_slonly - and it contains this:

Code: Select all

guest@porteus:/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders$ l
total 310
drwxr-xr-x 2 root    46 2020-04-26 05:04 .
drwxr-xr-x 4 root    30 2020-04-26 05:04 ..
-rwxr-xr-x 1 root 22816 2019-10-08 20:28 libpixbufloader-ani.so
-rwxr-xr-x 1 root 18672 2019-10-08 20:28 libpixbufloader-bmp.so
-rwxr-xr-x 1 root 27040 2019-10-08 20:28 libpixbufloader-gif.so
-rwxr-xr-x 1 root 14544 2019-10-08 20:28 libpixbufloader-icns.so
-rwxr-xr-x 1 root 22872 2019-10-08 20:28 libpixbufloader-ico.so
-rwxr-xr-x 1 root 27104 2019-10-08 20:28 libpixbufloader-jpeg.so
-rwxr-xr-x 1 root 27200 2019-10-08 20:28 libpixbufloader-png.so
-rwxr-xr-x 1 root 18648 2019-10-08 20:28 libpixbufloader-pnm.so
-rwxr-xr-x 1 root 14536 2019-10-08 20:28 libpixbufloader-qtif.so
-rwxr-xr-x 1 root 14504 2020-07-04 20:42 libpixbufloader-svg.so
-rwxr-xr-x 1 root 18672 2019-10-08 20:28 libpixbufloader-tga.so
-rwxr-xr-x 1 root 22912 2019-10-08 20:28 libpixbufloader-tiff.so
-rwxr-xr-x 1 root 14632 2020-04-26 05:04 libpixbufloader-webp.so
-rwxr-xr-x 1 root 14560 2019-10-08 20:28 libpixbufloader-xbm.so
-rwxr-xr-x 1 root 35168 2019-10-08 20:28 libpixbufloader-xpm.so

See how all these sit in /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders not in /usr/lib64/
Why did that work in 5.0rc1 and is broken in 5.0rc2 ?