Page 7 of 15

Porteus v5.0rc1 problems

Posted: 26 Aug 2019, 16:53
by beny
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.

Porteus v5.0rc1 problems

Posted: 26 Aug 2019, 21:14
by Payoon
Will try.
Thank You Beny.

Porteus v5.0rc1 problems

Posted: 27 Aug 2019, 00:43
by Payoon
Hi Beny
I have tried to compile the .run file with crippled sources activated, but the result is the same.
Thanks nevertheless.
Payoon

Porteus v5.0rc1 problems

Posted: 12 Sep 2019, 06:16
by sams
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.

Porteus v5.0rc1 problems

Posted: 08 Oct 2019, 20:25
by biotec
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.

Porteus v5.0rc1 problems

Posted: 08 Oct 2019, 22:23
by Ed_P
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.

Porteus v5.0rc1 problems

Posted: 19 Oct 2019, 15:19
by dutchkind
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

Porteus v5.0rc1 problems

Posted: 19 Oct 2019, 16:44
by AcnapyxoB
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.0rc1 problems

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

Porteus v5.0rc1 problems

Posted: 26 Oct 2019, 14:37
by AcnapyxoB
Blaze repacked initrd.xz is working fine for me.

Porteus v5.0rc1 problems

Posted: 26 Oct 2019, 14:52
by Blaze
AcnapyxoB, thanks for your report :)

Porteus v5.0rc1 problems

Posted: 28 Oct 2019, 18:06
by Buurman
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:

Porteus v5.0rc1 problems

Posted: 29 Oct 2019, 03:13
by fulalas
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! :)

Porteus v5.0rc1 problems

Posted: 29 Oct 2019, 18:58
by Ed_P
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. :(

Porteus v5.0rc1 problems

Posted: 03 Nov 2019, 17:32
by maia
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 :)