Porteus-v5.0x86_64_bugs reports

[Rava]

With older kernel (needed for my NVidia driver, cause no one is able to compile one for newer kernel version than the one I am using) and older but quicker XFCE - 4.12 version - all together works like a charm:



Since I use the very same DE as previously, I also loaded all my standard programs and settings via 999-settings-xzm, the only difference towards the older base system is a newer palemoon, but overall I have the quite the subjective impression that the whole system has an overall shorter response time…

Added in 2 hours 5 minutes 54 seconds:
Might be I have much more random network disconnections. It happened ihn the past once in a while, but now it is a more regular occurance,

Sadly, Blaze's tip of

Code: Select all

# nmcli networking off
# nmcli networking on 

is not helping, after "on" the panel icon switches to "connected" and at the same time the popup

Code: Select all

Disconnected
The network connection has been disconnected

pops up and the icon shows its "disconnected" state.

Since I still did not manage to the the WLAN runnung, I use an Samsung S4 via USB tethering.

Maybe the disruption in my "extra antenna cable" that is fixed via a crocodile clamp to the USB cable where it sits at the S4 USB connector that I now restored to the old "antenna layout" was the reason… since it seems the network connection is back to its previous reliability.

[kultex]

@Rava
I have JS enabled

Code: Select all

javascript.enabled     	true

still

Code: Select all

500, View not found [name, type, prefix]: phocadocumentation, html, phocadocumentationView

but I think, it should not be, that I have to make handstands in the config of the browser to view a simple installation guide

EDIT: I have tested it on all versions of firefox I use (Linux, Mac Windows) - I only use firefox - and there is all the time View not found - also on Safari of my Ipad.....

EDIT-2: I installed palemoon 31 on windoes, because I did not find a slackware package - JS enabled - same situation

[beny]

http://www.porteus.org/info/tutorials.html or this:
http://www.porteus.org/component/conten ... guide.html

[Ed_P]

http://www.porteus.org/info/tutorials.html or this:
http://www.porteus.org/component/conten ... guide.html

Good links beny. So, basically the USB_INSTALLATION.txt file in the ISO needs to be updated. (another file for the Porteus-v5.0/updates/core/202207023 folder )

And unless the data in the links include coverage of UEFI systems the webpages should be updated also. Who's maintaining the porteus.org webpages?

[beny]

web master if nothing have changed is Hamza?

[Kulle]

xzm2dir is not working

I wanted to shrink a module (remove superfluous),
but xzm2dir doesn't work:

Code: Select all

guest@porteus:~/Downloads$ xzm2dir changes-2022-07-07.xzm folder/
Please enter root's password below:
Passwort: 
Parallel unsquashfs: Using 4 processors
391 inodes (515 blocks) to write


FATAL ERROR: write_file: failed to create file folder//.wh..wh.aufs, because Operation not permitted
guest@porteus:~/Downloads$ 

[kultex]

@Ed_P

so we are back to the problem, because the link I gave at the beginning, where you said, this is for Porteus 2.0 - both documents are the same regarding linux.....

http://www.porteus.org/tutorials/37-ins ... #USB-linux
http://www.porteus.org/component/conten ... #USB-linux

[kultex]

WORKAROUND to boot Porteus from USB-stick formatted with EXT4

Install any MX-Linux or Antix Version with https://gitlab.com/bztsrc/usbimager or any other image writing tool to the usb drive. Boot MX or Antix with the option "toram". Use the included "Live usb maker" to make the EXT4 Usb stick. Copy the porteus folder to /boot and vmlinuz and intrd.xz to /boot/syslinux - cange the syslinux.cfg with bootentries on Porteus and delete all the rest....... This is for leagacy booting - Uefi is also possible.....

[Ed_P]

so we are back to the problem,

Yes. I misunderstood it. Sorry.

[Rava]

WORKAROUND to boot Porteus from USB-stick formatted with EXT4

Due do the limited write cycles for and USB-Sticks (that is not valid for external hardrives ) I recommend not using any journaling filesystem on a USB stick. Use e.g. ext2. I do so for years and never got any issue because of data corruption, even when the system was unresponsive and I needed to do a hard reset cause not even REISUB would work.

As current example, this is my 2 GB SD-card, via an USB-cardreader, as my bootdevice. I had to do a hard reset prior this session:

Code: Select all

root@porteus:/tmp# fsck /dev/sdc1
fsck from util-linux 2.37.4
e2fsck 1.46.5 (30-Dec-2021)
extSD_2GB: clean, 520/120720 files, 431200/482799 blocks
root@porteus:/tmp# fdisk -l /dev/sdc
Disk /dev/sdc: 1.84 GiB, 1977614336 bytes, 3862528 sectors
Disk model: STORAGE DEVICE  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8110a210

Device     Boot Start     End Sectors  Size Id Type
/dev/sdc1  *      135 3862527 3862393  1.8G 83 Linux

fdisk says "STORAGE DEVICE" cause that is how the USB card reader names itself.
Whatever program manages the desktop icons for XFCE is clever enough to realize its an SD card and not an USB-thumbdrive, I have no clue how it manages that, but is does:


And I am using XFCE 4.12 - 003-xfce-4.12-20220218.xzm

[kultex]

@Rava

Use e.g. ext2. I do so for years and never got any issue

I use my old stick (Sandisk ultra fit 64 GB USB 3.0) since 2016 with ext4 and no issues - before a slim Lexar JumpDrive USB 2.0 and etx4 for 10 years and no issues and now the new Sandisk ultra fit USB 3.2 will hopfully last the same time....... But I will follow your recommandation.......

And maybe it is my stick with USB 3.2, that has this bootproblems - as soon as everything works on the new stick, I will format the old one and try if this problem still exists....

[roadie]

xzm2dir is not working

I wanted to shrink a module (remove superfluous),
but xzm2dir doesn't work:

Code: Select all

guest@porteus:~/Downloads$ xzm2dir changes-2022-07-07.xzm folder/
Please enter root's password below:
Passwort: 
Parallel unsquashfs: Using 4 processors
391 inodes (515 blocks) to write


FATAL ERROR: write_file: failed to create file folder//.wh..wh.aufs, because Operation not permitted
guest@porteus:~/Downloads$ 

Kulle,

There are ways around this:

1....If the changes module is in use, it's mounted @ /mnt/live/memory/images and you can copy from there to your folder....or

2....You can mount the module and copy from there:

Code: Select all

su
toor
mloop (your module)
cp -pr /mnt/loop /your-folder-name
uloop

Or:

3.....You can edit the /opt/porteus-scripts/xzm2dir script to make unsquashfs ignore the errors.....add the "-ig" option at the end of the file, though it probably shouldn't be made permanent. The issue comes from unsquashfs aborting on errors.

Code: Select all

unsquashfs -f -ig -dest "$destination" "$1"

[Rava]

The issue comes from unsquashfs aborting on errors.

Since he wants to change his changes-2022-07-07.xzm … and its about the permission issue with /.wh..wh.aufs … I presume the created module would malfunction since a changes-module would need that folder?
Or is that a manually saved module - not via the changes functionality of porteus?
I never used changes so I am not knowledgable about that issue (I prefer my system to forget everything unless I explicitly tell him to remember things)

Added in 1 minute 58 seconds:

And maybe it is my stick with USB 3.2, that has this bootproblems - as soon as everything works on the new stick, I will format the old one and try if this problem still exists....

Maybe, but tell us anyway how it turns out, okay?

[Rava]

Trying to get this to run Haruna - mpv QT-based GUI Front-end - obviouly it needs Qt, so I got me the new qt5-base-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm

But even after activating it there are still Qt dependencies missing:

Code: Select all

guest@porteus:~$ ldd /usr/bin/haruna |grep not|grep Qt
	libQt5QuickControls2.so.5 => not found
	libQt5Quick.so.5 => not found
	libQt5Qml.so.5 => not found

Why is that?

Are these Qt dependencies in qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm ?

Or are they missing from qt5-base-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm by mistake?

Added in 31 minutes 37 seconds:
lsxzmgrep (which is not part of your default Port setup, I think, search the forum for it) comes in handy once again:

Code: Select all

guest@porteus:/Porteus_modules$ lsxzmgrep qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm libQt5QuickControls2.so.5
lsxzmgrep V2020-12-19
>qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm
/usr/lib64/libQt5QuickControls2.so.5
>qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm
/usr/lib64/libQt5QuickControls2.so.5.15
>qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm
/usr/lib64/libQt5QuickControls2.so.5.15.3
guest@porteus:/Porteus_modules$ lsxzmgrep qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm libQt5Quick.so.5
lsxzmgrep V2020-12-19
>qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm
/usr/lib64/libQt5Quick.so.5
>qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm
/usr/lib64/libQt5Quick.so.5.15
>qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm
/usr/lib64/libQt5Quick.so.5.15.3
guest@porteus:/Porteus_modules$ lsxzmgrep qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm libQt5Qml.so.5
lsxzmgrep V2020-12-19
>qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm
/usr/lib64/libQt5Qml.so.5
>qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm
/usr/lib64/libQt5Qml.so.5.15
>qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm
/usr/lib64/libQt5Qml.so.5.15.3

So, my suspicion was spot on, all 3 modules are part of qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm

Added in 10 minutes 37 seconds:
Out of extracted qt5-dev-5.15.3_20220318-x86_64-xfce-cinnamon-openbox-lxde-mate-gnome.xzm I made me a qt5-base-5.15.3_20220318-x86_64-QuickControls2+Quick+Qml.xzm which is only 2.73 MB…

[roadie]

The issue comes from unsquashfs aborting on errors.

Since he wants to change his changes-2022-07-07.xzm … and its about the permission issue with /.wh..wh.aufs … I presume the created module would malfunction since a changes-module would need that folder?
Or is that a manually saved module - not via the changes functionality of porteus?
I never used changes so I am not knowledgable about that issue (I prefer my system to forget everything unless I explicitly tell him to remember things)

I don't use a changes module either, but I built one with the steps that I posted and all settings were there after rebooting in Always Fresh.