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: 782
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: 74
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: 74
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: 28
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: 25
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: 5074
Joined: 06 Feb 2013, 22:12
Distribution: 4.0 Cinnamon 64-bit 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

Post Reply