Porteus v5.0rc1 problems

Please reproduce your error on a second machine before posting, and check the error by running without saved changes or extra modules (See FAQ No. 13, "How to report a bug"). For unstable Porteus versions (alpha, beta, rc) please use the relevant thread in our "Development" section.
beny
Full of knowledge
Full of knowledge
Posts: 2086
Joined: 02 Jan 2011, 11:33
Location: italy

Porteus v5.0rc1 problems

Post#91 by beny » 26 Aug 2019, 16:53

hi payoon,for virtual box you need the running kernel to build the module,so you can try with the crippled-source kernel if available.

Payoon
Black ninja
Black ninja
Posts: 88
Joined: 01 Mar 2013, 19:16
Distribution: Porteus 3.2 32 bit XFCE
Location: Duisburg, Germany

Porteus v5.0rc1 problems

Post#92 by Payoon » 26 Aug 2019, 21:14

Will try.
Thank You Beny.

Payoon
Black ninja
Black ninja
Posts: 88
Joined: 01 Mar 2013, 19:16
Distribution: Porteus 3.2 32 bit XFCE
Location: Duisburg, Germany

Porteus v5.0rc1 problems

Post#93 by Payoon » 27 Aug 2019, 00:43

Hi Beny
I have tried to compile the .run file with crippled sources activated, but the result is the same.
Thanks nevertheless.
Payoon

sams
Legendary
Legendary
Posts: 31
Joined: 05 Jan 2011, 18:53
Location: Alaska

Porteus v5.0rc1 problems

Post#94 by sams » 12 Sep 2019, 06:16

Hi porteus people, I have a feature request or 3.
When I travel my porteus environment often ends up running on a MacBook with broadcom wireless. I always end up building this driver myself from the slackbuilds. I have this working on porteus 3.x and 4.0, works ok most of the time but the connection is not completely reliable. I wanted to see if the latest porteus has more reliable broadcom wireless but I note that this driver is still not included. Is it possible you could package the appropriate broadcom driver with the next release? (Edit: and maybe macbook sound drivers? I can test these... Sorry if these are crazy requests but porteus works well on macbooks and is way more comfortable than OSX)

Minor note: the cheatcodes.txt is unchanged from 4.0. It includes something like:
cfgfile=xxx.sgn
This is not exactly incorrect but the sgn reference is from 3.0 and the cfg file works a bit different than the old sgn file

and finally this is not a big deal but I don't use the porteus installers, I copy the files manually to my own stick that can boot from bios or EFI, and my stick always contains multiple porteus versions, so the porteus folder is 1 level deeper than yours, down in a version folder. Same with the kernel/initrd. I don't think anything you do will substantially change what I do but maybe it would be cool if the default configuration supported multiple porteus versions on one stick. (EDIT: ignore this one, my install can't be automated since it uses grub-efi & grub-bios & syslinux. It's slick when done but not realistic for a script)

Anyway, latest porteus still works fine on a Mac (sans wireless so far). As always you guys are lifesavers.

biotec
White ninja
White ninja
Posts: 27
Joined: 23 Jan 2014, 23:50
Distribution: slackware
Location: Oviedo

Porteus v5.0rc1 problems

Post#95 by biotec » 08 Oct 2019, 20:25

Hello porteus people,

Stritcly speaking, what I am reporting is not a porteus5 problem, but people still using porteus4 with the default kernel will not have it, and in any case, I believe the solution should be devised with porteus5 in mind.

Tje problem is that using recently built kernels, porteussave.dat is not being properly umounted at shutdown. Not everybody will notice because the messages are very short, and self repairs works most of the times. However you will know that because you get this short-living message just before total shut-down, and because at startup you get a really hard-to-see message telling that porteussave.dat was not cleanly closed and is being repaired. Sooner or later, expect filesystem corruption, though.

After some of trials I found that the problem disapears when installing kernels from last year. And after quite some additional tests, I found the problem is that [with recent kernels] the busybox grep called fromthe "cleanup" script at shutdown, inside initrd.xz, is not able to process /proc/mounts properly. You may try to execute manually "grep /union/ /proc/mounts" from the test shell you obtain using the "debug" bootup cheatcode, to see that nothing is returned, so in further steps, the /union/ mout-points are not unmounted, and finally /memory/changes fails to be unmouted too. However, "cat /proc/mounts | grep /union/" works, and the actions thereafter will be properly executed.

The following patch applied to "cleanup" is a work-around that solves the problem for me:

Code: Select all

--- initrd-orig/cleanup 2019-09-30 10:58:51.901811369 +0200
+++ initrd-fix/cleanup  2019-10-02 22:22:41.819441863 +0200
@@ -23,7 +23,8 @@
 [ -b /dev/mapper/crypt ] && cp /memory/images/000-kernel.xzm/sbin/cryptsetup /bin
 
 # Determine if we booted from CD and copy 'eject' utility:
-CD=`grep /dev/sr /proc/mounts | cut -d" " -f1 | uniq`
+# RSC: workaround for "grep /dev/sr /proc/mounts" that fails on recent kernels
+CD=`cat /proc/mounts | grep /dev/sr | cut -d" " -f1 | uniq`
 [ -b "$CD" ] && cp -f /union/usr/bin/eject /bin
 
 # Remove doubled ntfs mount entries from mtab:
@@ -52,7 +53,9 @@
 
 echo "unmounting union"
 sync
-umount -nl `grep /union/ /proc/mounts | cut -d" " -f2 | tr "\n" " "` 2>/dev/null
+# RSC: workaround for "grep /union/ /proc/mounts" that fails on recent kernels
+UNION=`cat /proc/mounts | grep /union/ | cut -d" " -f2 | tr "\n" " "`
+umount -nl $UNION 2>/dev/null
 umount /union 2>/dev/null
 if [ $? -ne 0 ]; then
     x=10; free=no
@@ -69,7 +72,9 @@
 fi
 
 echo "unmounting everything else"
-umount -a 2>/dev/null
+# RSC: workaround for "umount -a" that fails on recent kernels
+ALL=`cat /proc/mounts | cut -d" " -f2 | egrep -v "(tmpfs|/dev)" | tr "\n" " "`
+umount $ALL 2>/dev/null
 if [ $? -ne 0 ]; then
     # Close encrypted container:
     if [ -b /dev/mapper/crypt ]; then
That's it. Im using initrd.xz wiht only this change and did not investigate further. I only can say that it happens with several recent kernels compiled kernels (some taken from Neko and others independently built by myself). Whether the culprit is some kernel code, some compilation options or the gcc compiler (I used gcc 9.2.0), I do not know. It also could be some bug in busybox that did not manifest with previous kernel versions, but I did not tryied that either. The rest of the startup and shutdown processes seem to go smoothly.

Ricardo.

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Porteus v5.0rc1 problems

Post#96 by Ed_P » 08 Oct 2019, 22:23

biotec earlier versions of Porteus would write the whole changes folder to the save.dat file, even if the changes folder was larger than the save.dat file which caused problems. Later versions, not sure when, got the ability to write only files in the changes folder that were new or updated to the save.dat file. And a script was added to the shutdown to display the size of the save.dat file and it's percentage used to help prevent catastrophic writes to the save.dat file. Whether neko's versions have those changes I don't know.

It's interesting that you check for booting from a CD, what about people booting from USB drives and from ISOs, which is what I do. And people using changes=EXIT so all the writing is done when shutting down, which is what I do.

BTW I'm not experiencing any save.dat problems shutting down or booting.
Ed

dutchkind
White ninja
White ninja
Posts: 11
Joined: 09 Jan 2017, 20:19
Distribution: Opensuse Tumbleweed
Location: Spain

Porteus v5.0rc1 problems

Post#97 by dutchkind » 19 Oct 2019, 15:19

I have been trying out Porteus 5 and I am impressed at how good and stable it is, well done!

Just a minor thing I came across: when I run update-libreoffice, this will on it's turn download update-libreoffice-live and execute it. But this latter one needs an argument for language, which is not passed on and so it fails and exits.

In my case adding a $1 to the sentence where update-libreoffice-live is called gave me at least the possibility to let it finish with the chosen language as argument to update-libreoffice

User avatar
AcnapyxoB
Samurai
Samurai
Posts: 191
Joined: 24 Dec 2014, 10:15
Distribution: Porteus 5.01
Location: Planet Earth

Porteus v5.0rc1 problems

Post#98 by AcnapyxoB » 19 Oct 2019, 16:44

After patch problem is slowed for me to. I had the same problem, but because of using ReiserFS save.dat it was corrupted after every reboot!
Porteus v5.01 KDE x86_64

User avatar
Blaze
DEV Team
DEV Team
Posts: 3869
Joined: 28 Dec 2010, 11:31
Distribution: ⟰ Porteus current ☯ all DEs ☯
Location: ☭ Russian Federation, Lipetsk region, Dankov
Contact:

Porteus v5.0rc1 problems

Post#99 by Blaze » 26 Oct 2019, 10:45

I repacked and apply patch from biotec - thanks for the patch.
Can anybody test initrd.xz with biotec fix?
Linux 6.6.11-porteus #1 SMP PREEMPT_DYNAMIC Sun Jan 14 12:07:37 MSK 2024 x86_64 Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz GenuineIntel GNU/Linux
MS-7A12 » [AMD/ATI] Navi 23 [Radeon RX 6600] [1002:73ff] (rev c7) » Vengeance LPX 16GB DDR4 K2 3200MHz C16

User avatar
AcnapyxoB
Samurai
Samurai
Posts: 191
Joined: 24 Dec 2014, 10:15
Distribution: Porteus 5.01
Location: Planet Earth

Porteus v5.0rc1 problems

Post#100 by AcnapyxoB » 26 Oct 2019, 14:37

Blaze repacked initrd.xz is working fine for me.
Porteus v5.01 KDE x86_64

User avatar
Blaze
DEV Team
DEV Team
Posts: 3869
Joined: 28 Dec 2010, 11:31
Distribution: ⟰ Porteus current ☯ all DEs ☯
Location: ☭ Russian Federation, Lipetsk region, Dankov
Contact:

Porteus v5.0rc1 problems

Post#101 by Blaze » 26 Oct 2019, 14:52

AcnapyxoB, thanks for your report :)
Linux 6.6.11-porteus #1 SMP PREEMPT_DYNAMIC Sun Jan 14 12:07:37 MSK 2024 x86_64 Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz GenuineIntel GNU/Linux
MS-7A12 » [AMD/ATI] Navi 23 [Radeon RX 6600] [1002:73ff] (rev c7) » Vengeance LPX 16GB DDR4 K2 3200MHz C16

Buurman
White ninja
White ninja
Posts: 25
Joined: 28 Oct 2019, 18:00
Distribution: ver5

Porteus v5.0rc1 problems

Post#102 by Buurman » 28 Oct 2019, 18:06

system is going into powersafemode (sleep/hibernate/halt?, no screen, no sound) even though stuff is running (game or listening to music - no mouse or keyboard input at that time)

edit-- seems to not be an error but a "feature" - it indeed only seems to look at keyboard and mouse input .. not cpu-usage or other inputs (eg. gamepads) :hmmm: :no:
Last edited by Buurman on 06 Nov 2019, 20:15, edited 10 times in total.

fulalas
DEV Team
DEV Team
Posts: 2050
Joined: 26 Oct 2016, 15:34
Distribution: Porteus
Location: Brazil

Porteus v5.0rc1 problems

Post#103 by fulalas » 29 Oct 2019, 03:13

Blaze wrote:
26 Oct 2019, 10:45
I repacked and apply patch from biotec - thanks for the patch.
Can anybody test initrd.xz with biotec fix?
After using this initrd.xz file I have the impression that the reboot/shutdown process is now way faster! :)

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Porteus v5.0rc1 problems

Post#104 by Ed_P » 29 Oct 2019, 18:58

Blaze wrote:
26 Oct 2019, 10:45
I repacked and apply patch from biotec - thanks for the patch.
Can anybody test initrd.xz with biotec fix?
It works with my system also. But booting is not faster. :(
Ed

User avatar
maia
Samurai
Samurai
Posts: 116
Joined: 08 Aug 2019, 16:56
Distribution: Porteus-5 64b Openbox
Location: Brasil

Porteus v5.0rc1 problems

Post#105 by maia » 03 Nov 2019, 17:32

Blaze wrote: ↑
26 Oct 2019, 07:45
I repacked and apply patch from biotec - thanks for the patch.
Can anybody test initrd.xz with biotec fix?

I do not use porteussave.dat but rootcopy.

Compiling recent kernels with the Neko tool, I had no problems on shutdown.

Using recently Neko pack kernels received messages on shutdown:
Make use "fsck" cheatcode during nex boot.
make sure that all your filesystems are consistent...

Test with new initrd.xz and recently Neko built kernels received messages:
Union ummounted successfully
Ummonting everything else :)
Sorry my english is really, g##gle-tr4nsl4t0r

Post Reply