Page 1 of 1

porteus-v4.0-x86_64.cfg ignores changes

Posted: 18 Apr 2019, 02:39
by nanZor
Here's what I'm running - uname -a

Linux porteus 4.16.3-porteus #1 SMP PREEMPT Sat Apr 21 12:42:52 Local time zone must be set-- x86_64 Intel(R) Celeron(R) CPU J3455 @ 1.50GHz GenuineIntel GNU/Linux

Using a FAT32 stick mounted as /dev/sdXn, where that means for me /mnt/sdb1. I have a savefile, which has proven to be successful with other techniques, but wanted to provide more feedback.

System will recognize all cheatcodes in

*EXCEPT* for the changes cheatcode. It WILL pick up my timezone, delay etc, indicating that the file is getting read, but not the changes line. In fact, upon reboot it does not even complain or seem to test for posix compatability with a savefile of my own

NOTE: This test was performed by REMOVING (commenting out actually), the APPEND line in
so as not to confuse the system with two append lines containing the same info in two different config files.

The fix is to put my changes in the APPEND lines in the usual place

And the system dutifully recognizes the changes cheatcode pointing to my porteussave.dat

What I find interesting (and possibly a fix pointer to) is that the 64 bit specific [ porteus-v4.0-x86_64.cfg ] *IS* being read, applying any cheatcodes there (try a delay cheatcode of a few more seconds for proof or whatever that it works...)

This doesn't seem to be an issue of spell-checking either. :) I'm watching the reboot and just simple seeing that values in porteus-v4.0-x86_64.cfg is being read, but apparently for some reason "changes" is being ignored.

The lack of a complaint makes me think that the savefile is being *acknowledged*, but just not *applied* ?? Beyond my ken.

Not a showstopper
Just feedback which you probably know. I just find it interesting that porteus-v4.0-x86_64.cfg isn't being totally ignored, just the changes line even when the APPEND line is commented out in the other config.

Rock on devs!

porteus-v4.0-x86_64.cfg ignores changes

Posted: 18 Apr 2019, 02:54
by Ed_P
The new porteus-v4.0-x86_64.cfg file was a bad idea. It complicates cheatcode changes. Adding a cheatcode to it may require removing a cheatcode from the porteus.cfg file, so instead of making one change you have to make two changes. Not a good idea for newbies.


porteus-v4.0-x86_64.cfg ignores changes

Posted: 18 Apr 2019, 03:39
by nanZor
Yeah, I'm not hip to the design strategy - but I can certainly deal with it, considering all the REST that totally rocks out of the box!

I'm going to keep digging to maybe find some clues ... is it better with UUID's only? Do 3rd-party flash utilities muck with syslinux making them ignore the changes mode in 64 bit? Dunno', but I'll play until I get tired.

Heh, we're all in this together. Let's help the devs find this bug and kill it!

porteus-v4.0-x86_64.cfg ignores changes

Posted: 18 Apr 2019, 03:55
by jssouza
In linuxrc, the changes= is searched for in the CFG file before the location of the CFG file is determined. Hence changes= is not found.

Offending line in linuxrc:

Code: Select all

CHANGES=`value changes`
value() function itself searches for CFG file existence as

Code: Select all

if [ -e $CFGDEV/$FOLDER/$CFG ]; then
But the $CFGDEV and $FOLDER, where CFG file resides, are determined after this, in the section "# Find *.cfg file:" of linuxrc.

In fact, none of the below cheatcodes, if added in CFG file would be found, since all these are searched for before the $CFGDEV and $FOLDER are determined.

Code: Select all

FROM=`value from`; ISO=`echo $FROM | egrep ".*\.iso( |\$)"`
IP=`value ip | cut -d: -f2`
MOPT=`value mopt`; [ $MOPT ] || MOPT="noatime,nodiratime,suid,dev,exec,async"
CHANGES=`value changes`
RAMSIZE=`value ramsize`; [ $RAMSIZE ] || RAMSIZE=60%
LOAD=`value load | sed 's/;/|/g'`; [ $LOAD ] || LOAD=._null
NOLOAD=`value noload | sed 's/;/|/g'`; [ $NOLOAD ] || NOLOAD=._null
EXTRAMOD=`value extramod | sed 's/;/ /g'`
RAMMOD=`value rammod | sed 's/;/|/g'`
ROOTCOPY=`value rootcopy`

porteus-v4.0-x86_64.cfg ignores changes

Posted: 18 Apr 2019, 06:38
by nanZor

Whaddya' know - I was wondering if by chance that the "changes" cheatcode was somehow not happy changing from the parent config file, and started playing around in syslinux replacing the parent porteus.cfg append line with:

CONFIG /mnt/sdb1/porteus/porteus-v4.0-x86_64.cfg

but I was either doing it wrong, or maybe that has nothing to do with what you've shown above.

Interesting stuff. My hope is that devs don't get discouraged. We can deal. A system this flexible means a user has to read, and get their hands dirty once in awhile. Like a fine classic sports-car.

porteus-v4.0-x86_64.cfg ignores changes

Posted: 18 Apr 2019, 07:47
by ncmprhnsbl
curiously, this topic: Followed the Save.dat Manager tutorial and It's Still Not Working? seems to suggest otherwise..
even though jssouzas reasoning appears sound..
this one: cannot save changes [solved] may also be related, with nemesis config folder/files a little different..

porteus-v4.0-x86_64.cfg ignores changes

Posted: 18 Apr 2019, 10:00
by nanZor
I went over those threads a few times with a fine toothed comb.

For the purpose of the bug report, I reduced all variables by not including such cool options like EXIT: or the use of UUID's. Proper partition numbering double-check. Spellchecked to make sure I didnt fat-finger proteus for porteus, missing s's and the like. :)

Why it works for that op and not for me made me smash an empty energy drink into my forehead looking for any PEBCAKS.

Just in case, instead of commenting out the append line in the porteus.cfg file, I deleted it completely. Still no go.

Made sure there was nothing wrong in the porteus-v4.0-x86_64.cfg file, like leading spaces. Line triple checked. Nope.

*MAYBE* because my Intel NUC is configured solely for UEFI boot? Enabled legacy-boot as well and tried again. Nope - system does not recognize savefile, so resorted to just using porteus.cfg again.

I understand the desire to do this now. Simple - the objective is NOT to use one long APPEND line that might go on forever, but to put each cheatcode by itself on a single line. I get it. Just seems for some reason the changes line is being ignored.

The good part is I have a suggestion for resizing the savefile, which won't appear in the bug reports here...

porteus-v4.0-x86_64.cfg ignores changes

Posted: 18 Apr 2019, 18:00
by nanZor
And forgot - thanks jssouza!

My suggestion to prevent anything from being a release blocker:

Since we know that using the original <usb path>/porteus/porteus.cfg works regardless, along with any other cheatcodes, perhaps the simplest solution is to just provide additional comments in the porteus-v4.0-x86_64.cfg file like

## If for some reason any of your cheatcodes do not appear to be working, you can STILL append them in a single line in the <usb path>/porteus/porteus.cfg file.

AND possibly when the savefile util writes the changefile line for you, put it back into the old porteus.cfg file instead for those just starting out...

Heh, me and my peanut-gallery comments. What do they say about he who touched it last? Oh no, not me! :)

porteus-v4.0-x86_64.cfg ignores changes

Posted: 14 Aug 2019, 11:55
by zahtar
Ed_P wrote:
18 Apr 2019, 02:54
The new porteus-v4.0-x86_64.cfg file was a bad idea. It complicates cheatcode changes. Adding a cheatcode to it may require removing a cheatcode from the porteus.cfg file, so instead of making one change you have to make two changes. Not a good idea for newbies.

I agree with that one and thanks for the comment. I've been struggling with the savefile for the past few days, until I read some posts with you and nanZor discussing the matter in a few threads. What I did was edit the /boot/syslinux/porteus.cfg file adding the following:

Code: Select all

LABEL Zahtar
MENU LABEL Zahtar mode
KERNEL /boot/syslinux/vmlinuz
INITRD /boot/syslinux/initrd.xz
APPEND changes=EXIT:/mnt/sdb1/port4sav.dat
    Run Porteus the way I prefer.
    Autoconfigure gfx card
    use max allowed res
    copy2ram +2 rammods
and setting this mode as default. Additionaly the /porteus/porteus-v4.0-x86_64.cfg file has the following settings:

Code: Select all

APPEND /EFI/BOOT copy2ram rammod=palemoon;flashplayer-plugin
So the changes are now saved at the savefile and my questions are two:

1) Is there a way to make sure that copy2ram worked indeed and the two modules were copied there? I didn't manage to read anything during boot... - By opening system tools - Porteus Modules, I get a window that mentions containing directory /mnt/live/memory/copy2ram, so I guess it worked ok, just by editing the /boot/syslinux/porteus.cfg file. Ok noticed the os and the modules being copied to RAM during bootup so it works ok :)

2) Can I make changes just at the /boot/syslinux/porteus.cfg and forget about the /porteus/porteus-v4.0-x86_64.cfg file? I mean to put # in everything at the second file so I can work with a single one. - Yes, I just tried and it is possible. As of now, I'll stop making changes to /porteus/porteus-v4.0-x86_64.cfg

Thanks in advance.

EDIT: I updated the questions, both answered

porteus-v4.0-x86_64.cfg ignores changes

Posted: 15 Aug 2019, 08:22
by nanZor
zahtar - in another thread indicated solved, that was done by following the most recent instructions in the iso (basically copying the entire contents of the mounted iso, which includes copying the EFI directory to the usb stick prior to running the porteus installer utility ..

Now you won't need the /EFI/BOOT in your append line. Try it.

porteus-v4.0-x86_64.cfg ignores changes

Posted: 17 Aug 2019, 16:23
by zahtar
nanZor, that's true, I removed it from the append line, it works ok, thanks. so that means we only need to copy the folders included in the iso, run the exe and we are good to go.

Now I need to find why the mouse scrolls 23 lines instead of 3 as set in the preferences... but that's off topic here

PS: thanks for explaining about rufus at the other thread :good: