Porteus-v5.0x86_64_bugs reports

[Ed_P]

.


Nice job ncmp.

Thank you.




A minor suggestion, making the alert indicating the user is booting from an ISO a Warning rather than an Error.

[Rava]

here is a module of an adjusted /opt/porteus-scripts/update-porteus
updater-test.xzm
to test it, just activate and run the updater from porteus settings centre.

downloaded it…

Code: Select all

64d39221ab482316e0c384ea76c68da2  updater-test.xzm

is my md5sum correct?

[ncmprhnsbl]

is my md5sum correct?

yep

[Rava]

to test it, just activate and run the updater from porteus settings centre.

As usual, it seems it is not able to work with my shared internet WLAN via LAN, as previously reported.

Code: Select all

 Starting checks ... 
[OK] Server: http://dl.porteus.org
[OK] Architecture: x86_64
[OK] User is root
[OK] Distro is Porteus
[OK] Base folder is writable
[ERROR] An internet connection is required.

As you can see, internet is working fine on my machine when pinging e.g. gøøgle, but trying the used LAN sharing address via 10.42.0.1 fails as usual. (I presume the code "ping -q -w 1 -c 1 `ip r | awk '/default/{print$3}'|head -n1`" is still the one used.)

Code: Select all

root@porteus:/# ping -q -w 1 -c 1 `ip r | awk '/default/{print$3}'|head -n1`
PING 10.42.0.1 (10.42.0.1) 56(84) bytes of data.

--- 10.42.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

root@porteus:/# ping -q -w 1 -c 1 www.google.com
PING forcesafesearch.google.com (216.239.38.120) 56(84) bytes of data.

--- forcesafesearch.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 26.358/26.358/26.358/0.000 ms

Is there a fix planned for folks using WLAN over LAN sharing via NetworkManager like I do?

Or is my only chance in getting it to run is having to hack the relevant code manually?

[ncmprhnsbl]

A minor suggestion, making the alert indicating the user is booting from an ISO a Warning rather than an Error.

Is there a fix planned for folks using WLAN over LAN sharing via NetworkManager like I do?

try this one:
updater-test-22-10-31.xzm md5sum: 7e84e2bda8a04e5cb0bd441bbbff7ef3
'red' function instead of 'sayerror'
is_online_url $SERVER (our server or configured mirror) instead of is_online

[Rava]

Using updater-test-22-10-31.xzm (my md5sum is the same as yours)

Code: Select all

 Starting checks ... 
[OK] Server: http://dl.porteus.org
[OK] Architecture: x86_64
[OK] User is root
[OK] Distro is Porteus
[OK] Base folder is writable
[OK] Internet connection confirmed

Downloading: update-porteus-live  DONE
Downloading: updates.txt  DONE

Checking base modules ...




Checking patch availability ...
 ######################### 
 Available core updates 

001-core.xzm
002-xorg.xzm

 Would you like to continue? [y/n]

Now it works.
Suggestion, is it possible for the script to tell the user what update that is?
E.g. by telling the user the YYYYMMDD folder the updates are in?
Just

Code: Select all

001-core.xzm
002-xorg.xzm

is giving no info at all, but I presume the script knows what YYYYMMDD folder the modules are in?

Would the script overwrite my files in base?
Would it make a backup first?

I prefer older versions that work than new versions that fail e.g. due to a download error and wrong md5sums.
The core modules are quite essential to a working system after all.

Added in 7 minutes 49 seconds:
Some mirror servers still seem not to have the updates.

This one does:
https://linux.rz.rub.de/porteus/x86_64/ ... /20220924/

Code: Select all

Index of /porteus/x86_64/Porteus-v5.0/updates/core/20220924

Icon  Name                                       Last modified      Size  [PARENTDIR] Parent Directory                                                -   
[   ] 001-core.xzm                               2022-10-09 12:48  121M  
[   ] 002-xorg.xzm                               2022-10-09 12:48  112M  

I presume that's the ones the above is referring to?

Added in 5 minutes 27 seconds:
Update
It seems silly me manually downloaded the updates via wget recursive… but I forgot to change the symlinks in my $PORTDIR/base/ accordingly.

I now changed that, making the new md5sums appear like so:

Code: Select all

root@porteus:~# md5sum  $PORTDIR/base/001-core.xzm $PORTDIR/base/002-xorg.xzm 
087e196ed3e7a8750b32031e3221fc2b  /mnt/sda1/Porteus_5.0/porteus/base/001-core.xzm
9a1afb69141822791d5a114909725431  /mnt/sda1/Porteus_5.0/porteus/base/002-xorg.xzm

According to https://linux.rz.rub.de/porteus/x86_64/ ... pdates.txt both md5sums are accurate.

Added in 6 minutes 41 seconds:
Now all there is to do figure out how to accurately update my palemoon settings module to reflect the most recent changes how I want it to behave prior me rebooting the system…

Code: Select all

cd /home/guest/.moonchild productions/pale moon/*.default
# the above won't work, replace "*.default" with the real folder name of your setup
grep -E '"browser.sessionstore.cache_behavior", |"browser.startup.page", ' prefs.js
# should be:
#user_pref("browser.sessionstore.cache_behavior", 2);
#user_pref("browser.startup.page", 3);

The last manually updated settings module did have some kinks left, while it at least has the two settings as quoted above correct.

Added in 2 minutes 56 seconds:
So, working on that and then when I rebooted using the manually downloaded newest updates of core I will report back after again activating updater-test-22-10-31.xzm how that goes then. (It should report no updates available for me then… I presume it checks the updates via the md5sums of the modules in the base/ folder ?)

[Ed_P]

try this one:
updater-test-22-10-31.xzm md5sum: 7e84e2bda8a04e5cb0bd441bbbff7ef3

This looks better. Thank you.

Suggestion, is it possible for the script to tell the user what update that is?
E.g. by telling the user the YYYYMMDD folder the updates are in?
Just

Code: Select all

001-core.xzm
002-xorg.xzm

is giving no info at all

I agree, some kind of info about an update would be helpful. Does 001-'s update require 002-'s update? What if there are 2 updates for the same modules but at different dates, can the user choose one or does the new one require the prior one be implimented. etc.

Would the script overwrite my files in base?
Would it make a backup first?

Unless the user has booted an ISO the answer to the 1st question I would say is yes.
As for the backup question I think the script could issue a statement that the user should backup the files before running the update. But renaming the existing files with a date and new extension would work. 001-core.xzm-103022.old for example would work.

[Rava]

As for the backup question I think the script could issue a statement that the user should backup the files before running the update.

I agree, while one could argue it is up to the user to safeguard that stuff, Porteus should be helpful in that regard and "think for the user" a bit so to speak, or in this case:
Either do a backup itself (and make sure there can not be an error… like the downloaded files md5sums are all valid, the renaming or moving of the original files is also without error, but then copying the downloaded files to $PORTDIR/base fails because now the partition where $PORTDIR/base sits has no longer enough free space (due to the original files being moved / renamed and thus taking the same space as before while the new ones need additional space - in the case of what I quoted above that's 223 MB [not that much but still could be too much when there is not that much free space to begin with])

… or tell the user to do so himself. Then the script would not have to bother with a scenario as described above.

[Ed_P]

To be picky I think the "You appear to be booting from an ISO" statement should be green not red and the "extramod=/path/to/folder/of/updated-modules" line should be bold white not green. Red usually implies a warning and bold white stands out from the green narrative. Just mho.

[Rava]

To be picky I think the "You appear to be booting from an ISO" statement should be green not red

I think it should appear red not green.

Like you said, red implies a warning and the updater cannot update files in base/ when you booted from an ISO… so in my book having that text in red is appropriate.

[Rava]

Manually updated my system to

Code: Select all

root@porteus:/# cat /etc/porteus/00*
001-core.xzm:20221006
002-xorg.xzm:20221006
002-xtra.xzm:20220630
003-xfce.xzm:20220925

Updater updater-test-22-10-31.xzm fails because I ran fastest-mirror previously:

Code: Select all

/porteus/
[OK] Architecture: x86_64
[OK] User is root
[OK] Distro is Porteus
[OK] Base folder is writable
[OK] Internet connection confirmed

Downloading: update-porteus-live  DONE
Downloading: updates.txt  DONE

[ERROR] Could not download updates.txt file
[ERROR] http://ftp.nluug.nl/os/Linux/distr/porteus//x86_64/Porteus-v5.0/updates/core/updates.txt
 You may now close this window. 

Seems ftp.nluug.nl is one of these mirrors that would not work due to them having not the needed updates.

Is there a way to exclude the mirrors such as ftp.nluug.nl in fastest-mirror - e.g. use a local http://porteus.org/porteus-mirrors.txt version that excludes all mirrors without porteus/x86_64/Porteus-v5.0/updates/core/updates.txt ?

Added in 2 minutes 40 seconds:
manually edited my /etc/porteus.conf

Code: Select all

root@porteus:~# grep SERVER /etc/porteus.conf
SERVER=http://linux.rz.rub.de/porteus/

result:

Code: Select all

 Starting checks ... 
[OK] Server: http://linux.rz.rub.de/porteus/
[OK] Architecture: x86_64
[OK] User is root
[OK] Distro is Porteus
[OK] Base folder is writable
[OK] Internet connection confirmed

Downloading: update-porteus-live  DONE
Downloading: updates.txt  DONE

Checking base modules ...




Checking patch availability ...

 #################################### 
 Porteus update report 

 You are up to date. 

 You may now close this window. 

[Ed_P]

Like you said, red implies a warning and the updater cannot update files in base/ when you booted from an ISO… so in my book having that text in red is appropriate.

I can assure you us ISO booters know we are booting ISOs and know ISOs can't be updated (without some effort) so we don't need "warning"s. "Reminder"s are sufficient.

Added in 3 minutes 28 seconds:
And we don't need to rebuild ISOs to apply all updates. Simply putting them in the extramods folder works.

[askman]

https://postimg.cc/PLdZRS5P
"PORTEUS PXE SERVER" not booting on lan ..... chek structure PXE foldres
first release work correct

[Ed_P]

Code: Select all

guest@porteus:~$ locate ntfs-3g
locate: unexpected EOF reading `/var/lib/mlocate/mlocate.db'

The 1st and last characters don't match, is that the problem?

"PORTEUS PXE SERVER" not booting on lan ..... chek structure PXE foldres
first release work correct

Sounds like a Porteus Kiosk problem.

[Rava]

The 1st and last characters don't match, is that the problem?

you mean these characters?

Code: Select all

locate: unexpected EOF reading `/var/lib/mlocate/mlocate.db'
                               ^                           ^

That's normal for some programs when they refer to stuff, that is not the issue.

What I also got on my system is this:

Code: Select all

root@porteus:~# locate ntfs-3g
locate: unexpected EOF reading `/var/lib/mlocate/mlocate.db'

and then I ran this:

Code: Select all

root@porteus:~# updatedb
root@porteus:~# echo $?
0

resulting in this:

Code: Select all

root@porteus:~# locate ntfs-3g
/bin/lowntfs-3g
/bin/ntfs-3g
/bin/ntfs-3g.probe
/lib64/libntfs-3g.so
/lib64/libntfs-3g.so.89
/lib64/libntfs-3g.so.89.0.0
/sbin/mount.lowntfs-3g
/sbin/mount.ntfs-3g
/usr/lib64/libntfs-3g.so
/usr/lib64/ntfs-3g
/usr/man/man8/mount.lowntfs-3g.8
/usr/man/man8/mount.ntfs-3g.8
/usr/man/man8/ntfs-3g.8
/usr/man/man8/ntfs-3g.probe.8
/var/lib/pkgtools/packages/ntfs-3g-2021.8.22-x86_64-1

I wish all problems would have such an easy solution.