porteus-v4.0-x86_64.cfg ignores changes
Posted: 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!
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!