porteus-v4.0-x86_64.cfg ignores changes

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.
Post Reply
nanZor
Samurai
Samurai
Posts: 185
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

porteus-v4.0-x86_64.cfg ignores changes

Post#1 by nanZor » 18 Apr 2019, 02:39

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.

Problem:
System will recognize all cheatcodes in
/mnt/sdb1/porteus/porteus-v4.0-x86_64.cfg

*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
changes=/mnt/sdb1/porteussave.dat

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

Semi-Solution
The fix is to put my changes in the APPEND lines in the usual place
/mnt/sdb1/boot/syslinux/porteus.cfg

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!
That's a UNIX book - cool. -Garth

User avatar
Ed_P
Contributor
Contributor
Posts: 5134
Joined: 06 Feb 2013, 22:12
Distribution: 4.0 Cinnamon 64-bit ISO
Location: Western NY, USA

porteus-v4.0-x86_64.cfg ignores changes

Post#2 by Ed_P » 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.

IMO
Ed

nanZor
Samurai
Samurai
Posts: 185
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

porteus-v4.0-x86_64.cfg ignores changes

Post#3 by nanZor » 18 Apr 2019, 03:39

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!
That's a UNIX book - cool. -Garth

jssouza
DEV Team
DEV Team
Posts: 1047
Joined: 09 Jul 2015, 14:17
Distribution: Porteus x86 arm
Location: Liechtenstein

porteus-v4.0-x86_64.cfg ignores changes

Post#4 by jssouza » 18 Apr 2019, 03:55

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`

nanZor
Samurai
Samurai
Posts: 185
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

porteus-v4.0-x86_64.cfg ignores changes

Post#5 by nanZor » 18 Apr 2019, 06:38

Wow!

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.
That's a UNIX book - cool. -Garth

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2254
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

porteus-v4.0-x86_64.cfg ignores changes

Post#6 by ncmprhnsbl » 18 Apr 2019, 07:47

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..
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

nanZor
Samurai
Samurai
Posts: 185
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

porteus-v4.0-x86_64.cfg ignores changes

Post#7 by nanZor » 18 Apr 2019, 10:00

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...
That's a UNIX book - cool. -Garth

nanZor
Samurai
Samurai
Posts: 185
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

porteus-v4.0-x86_64.cfg ignores changes

Post#8 by nanZor » 18 Apr 2019, 18:00

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! :)
That's a UNIX book - cool. -Garth

zahtar
White ninja
White ninja
Posts: 6
Joined: 06 Aug 2019, 13:24
Distribution: Porteus v4.0 x64 LXQT
Location: Greece

porteus-v4.0-x86_64.cfg ignores changes

Post#9 by zahtar » 14 Aug 2019, 11:55

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.

IMO
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
TEXT HELP
    Run Porteus the way I prefer.
    Autoconfigure gfx card
    use max allowed res
    copy2ram +2 rammods
ENDTEXT
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
Last edited by zahtar on 17 Aug 2019, 16:20, edited 1 time in total.

nanZor
Samurai
Samurai
Posts: 185
Joined: 09 Apr 2019, 03:27
Distribution: Porteus 5.0 RC1 XFCE
Location: Los Angeles

porteus-v4.0-x86_64.cfg ignores changes

Post#10 by nanZor » 15 Aug 2019, 08:22

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.
That's a UNIX book - cool. -Garth

zahtar
White ninja
White ninja
Posts: 6
Joined: 06 Aug 2019, 13:24
Distribution: Porteus v4.0 x64 LXQT
Location: Greece

porteus-v4.0-x86_64.cfg ignores changes

Post#11 by zahtar » 17 Aug 2019, 16:23

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:

Post Reply