Porteus-v5.01 bug reports

[ncmprhnsbl]

OK, new thing...

yes, a bug, in the sense of a half implemented feature,
ie. using the porteus-5.*.cfg file for cheatcodes and then
relying on it in the make-changes script for something that wasn't supported.
generally my thought on it was that using it for changes= cheat(and some others)
could be problematic, because they are applied for all boot options
with no way to opt out of at boot time via the TAB key.
the obvious one is that "Aways Fresh" option, wouldn't be,
because it relies on the APPEND line not having changes= ..
ie. baseonly ..would be the modules in base plus your changes,
if you hadn't previously edited the porteus-5.*.cfg file before rebooting,
which seems a bit painful..
long story short:
so, the previous 'fix' was to not use the .cfg file for changes in the make-changes script,
which was ony done in the pygobject ported version, but wasn't, for no good reason
done in the older gtkdialog version which was retained because of some as yet unresolved
problem with the encryption parts.
now that you've presented this fix, i've reconsidered my opinion on it,
and tried to resolve the 'baseonly' issue within initrd.
basicly, to disable changes= if baseonly is invoked:
linuxrc:

Code: Select all

if param base_only; then
	unset $CHANGES
elif [ $(value changes) != "$CHANGES" ]; then
	CHANGES=$(value changes)
	echo $i"Using $CHANGES from config file"
fi

the problem here now is if a user actually wants baseonly with changes=, which
would then have to be worked around with noload=<list;of;dirs;and;or;modules>

the documentation also should specify which cheats are appropriate for where,
under various scenarios..
eg. multiple boot options with their own changes ..

another idea might be to have an "overide=" or "nocfg=" cheat that negates listed cheats in the porteus/porteus-5.*.cfg file..

[Ed_P]

Wow! I think this is getting overly complicated. If a user specifies an illogical combination of boot parms, changes= and baseonly, simply issue a warning that one, or both, are being disregarded when booting and disregard any further use of them. All these other concerns are illogical.

[pterid]

OK, new thing...

yes, a bug, in the sense of a half implemented feature,
ie. using the porteus-5.*.cfg file for cheatcodes and then
relying on it in the make-changes script for something that wasn't supported.

Ah I see - thank you for explaining the history of this!

generally my thought on it was that using it for changes= cheat(and some others)
could be problematic, because they are applied for all boot options
with no way to opt out of at boot time via the TAB key.

I know this would make things more complicated, but maybe to preserve this ability, you could introduce an ignorecfg boot param, which would mean "don't use the porteus-5.0...cfg file for anything"?

I can see why the decision was made to have make-changes edit porteus-5.0...cfg rather than the syslinux configs directly. Once you are in a session, it's not obvious where they are / where you booted from - it could have been another disk or partition, etc.

the obvious one is that "Aways Fresh" option, wouldn't be,
because it relies on the APPEND line not having changes= ..
ie. baseonly ..would be the modules in base plus your changes,
if you hadn't previously edited the porteus-5.*.cfg file before rebooting,
which seems a bit painful..

Agreed! I didn't consider this case. It seems bad to have no way to avoid the changes from the porteus-5.0...cfg in any profile!

long story short:
so, the previous 'fix' was to not use the .cfg file for changes in the make-changes script,

What did it use instead?

which was ony done in the pygobject ported version, but wasn't, for no good reason
done in the older gtkdialog version which was retained because of some as yet unresolved
problem with the encryption parts.

Aha! Is the attempted pygobject version in the porteus-scripts repo somewhere?

now that you've presented this fix, i've reconsidered my opinion on it,
and tried to resolve the 'baseonly' issue within initrd.
basicly, to disable changes= if baseonly is invoked:
linuxrc:

Code: Select all

if param base_only; then
	unset $CHANGES
elif [ $(value changes) != "$CHANGES" ]; then
	CHANGES=$(value changes)
	echo $i"Using $CHANGES from config file"
fi

the problem here now is if a user actually wants baseonly with changes=, which
would then have to be worked around with noload=<list;of;dirs;and;or;modules>

Thanks very much, I think this is a great compromise for now! The main thing is that it allows the "golden path" of (install to FAT USB partition, create savefile) go smoothly.

I suppose later we could introduce something like my ignorecfg idea above, so base_only would revert to meaning "no non-base modules". the Always Fresh profiles would need to have both baseonly and ignorecfg to ensure they really are fresh.

the documentation also should specify which cheats are appropriate for where,
under various scenarios..
eg. multiple boot options with their own changes ..

Yes! This idea (3 different profiles with 3 different changesets) is another thing that ignorecfg could allow; it'd stop you being locked into the changes from the post-boot porteus-5.0...cfg file. Or we just do documentation for advanced users and tell them "delete that post-boot file, it only exists to make persistent change creation easier for new users"

another idea might be to have an "overide=" or "nocfg=" cheat that negates listed cheats in the porteus/porteus-5.*.cfg file..

Hahaha, yes, you had my idea but first and better. Sorry, I started doing these inline replies without reading this bottom line. Exactly My idea was just one flag to blow off the whole file, rather than a granular solution. In truth, the two are equivalent, as I think after this code change, we will still only be checking for changes in the post-boot porteus-5.0...cfg now (no other cheats).

Edit: I think we may need the caveat / warning that all of this applies only if your partition containing the Porteus folder, the Porteus-5.0...cfg etc is editable. ISO booters will have to edit the changes cheatcode into their bootloader, and those who burned the Porteus ISO to a stick with Rufus are basically out of luck, etc. I can try to draft concise wording of this!

[Ed_P]

Edit: I think we may need the caveat / warning that all of this applies only if your partition containing the Porteus folder, the Porteus-5.0...cfg etc is editable. ISO booters will have to edit the changes cheatcode into their bootloader, and those who burned the Porteus ISO to a stick with Rufus are basically out of luck, etc. I can try to draft concise wording of this!

There are otherways to have edited cfg file boot changes present for ISO booters.

That's it. There a folder named ventoy containing ventoy.json and porteux.cfg. This leaves the original PorteuX iso file untouched.

[pterid]

ISO booters will have to edit the changes cheatcode into their bootloader...

There are otherways to have edited cfg file boot changes present for ISO booters.

That's it. There a folder named ventoy containing ventoy.json and porteux.cfg. This leaves the original PorteuX iso file untouched.

Ventoy is a bootloader...

[Ed_P]

Ventoy is a bootloader...

Not the same as BCD or Grub or Grub2 or Grub4Dos that use /boot/syslinux/vmlinuz Boot Parms. It can use a modfied porteus.cfg file when booting ISOs.

[pterid]

So my suggestion is to change the UI string in this modal in make-changes:



Of course, currently this doesn't work at all, but there's now a change coming, and editing the porteus-5.0...cfg will be effective in setting up persistence. (Yay!)

To its credit, make-changes does check whether porteus-5.0...cfg is writeable - my screenshot covers the case where the file is writeable (it's a VM with Porteus on the virtual hard drive).

If the porteus-5.0...cfg file is seen as not writeable, the message you get is:

$PORTCFG is not writable so you will need to manually add changes=$TARG/$NAME.dat to your $PORTCFG file."

Why it would be non-writeable? I think the main reasons are

• It is on an ISO, or
• the user is not running as root for some reason, or
• the user managed to make the file read-only with Linux permissions.

Of those, I'd guess the ISO is most likely. The "manually edit the file" advice probably leads to frustration for these people. You can't just edit the file, you will need to edit / re-make the ISO file. Or, if you are booting an ISO but via a 3rd-party bootloader on a disk you can edit, then you can find a way to inject the changes= cheatcode into your bootloader. (Methods for this may vary, as you say.) Or if you're booting off an ISO burned directly to a stick... you are kind of stuck. Booting from a CD? Very stuck.

Anyway my point is, I think the UI strings could be improved to give new users more of a clue.

One could perhaps do a check for ISO file system via [ "$(df "$(dirname "$PORTCFG")" --output=fstype | tail -1)" = "iso9660" ], and give a full and honest message to ISO users like:

"It looks like your Porteus config file is on an ISO file system. These are generally read-only. If your ISO is stored as a file on a writeable drive, you may be able to either edit or re-create the ISO with specialised ISO editor tools. If you are booting the ISO via an external bootloader (e.g. Grub2win, Ventoy...) consult your bootloader documentation for how to add the following boot parameter to your boot: changes=$TARG/$NAME.dat". If you burned the ISO directly to a USB drive or a CD, then unfortunately you cannot set up persistence; you will need to load Porteus another way."

Not the same as BCD or Grub or Grub2 or Grub4Dos that use /boot/syslinux/vmlinuz Boot Parms. It can use a modfied porteus.cfg file when booting ISOs.

That's great, but hopefully described in the relevant documentation (or a forum post). I'm not convinced the UI strings I'm asking about here have space to run through the mechanics of those 3rd-party tools. Maintaining such advice as the tools change with time would be pretty onerous too. The forum is a good archive of people who succeeded to set up Porteus through various such tools.

[Ed_P]

On your VM system, boot the Porteus ISO, as an ISO, with a copy of the porteus.cfg file, modified with a unique or bad code, on the system next to the ISO, does Porteus see it or the one in the ISO? Somehow, with Ventoy, Porteus is reading the cfg file outside the ISO file! No special code, according to jk9. This scenario is completely new to me.

[pterid]

On your VM system, boot the Porteus ISO, as an ISO, with a copy of the porteus.cfg file, modified with a unique or bad code, on the system next to the ISO, does Porteus see it or the one in the ISO? Somehow, with Ventoy, Porteus is reading the cfg file outside the ISO file! No special code, according to jk9. This scenario is completely new to me.

Looks like this feature / plugin of Ventoy: https://www.ventoy.net/en/plugin_bootconf_replace.html

which is great, but again, don't think it needs mentioning in official docs. External bootloaders come and go, and have their own documentation, and people post about them here. Ventoy is a bit controversial.

[Ed_P]

Not mentioning or using a Ventoy plugin, just doing what jk9 has found works. And if he has I am sure other new Porteus users will try. I just tried booting my Porteus 5.01 ISO, with a modified .cfg file next to it, in AF mode, with my grub2 system bootloader and the change did not happen.

If you want to mention it fine, if not that's fine also. But it is something that can occur and has occurred, by a Porteus user.

External bootloaders come and go, and have their own documentation, and people post about them here.

True. Years ago we booted CDs, then ISOs, then USBs, with the DOS boot manager then grub4DOS then grub4WIN and for me now just grub2. On the CDs there were single OSs. Same with the ISOs. On USBs initally single OSs, then USBs got larger and using them for a single OS got to seem wasteful, useless, expensive. etc, etc.

[ncmprhnsbl]

Aha! Is the attempted pygobject version in the porteus-scripts repo somewhere?

you should see it in you live 5.01 /opt/porteus-scripts/make-changes.py ..otherwise, on bitbucket porteus-scripts repo in the v5.1 branch or the pygobject3_ports branch (this repo is has gotten a bit messy)

What did it use instead?

it simply opened (if possible?) the /boot/syslinux/porteus.cfg file in an editor and gave the savefile path to be manually added to the APPEND line ..

One could perhaps do a check for ISO file system via [ "$(df "$(dirname "$PORTCFG")" --output=fstype | tail -1)" = "iso9660" ], and give a full and honest message to ISO users like:

certainly

generally, about alternative booting/install options, i think there should be some expansion of the docs (even if it's only links to the various howtos on the forum) to cover some of these, and their pro and cons..
"the docs" being the online and the onboard USB_INSTALLATION.txt and /boot/docs/install.txt..

Hahaha, yes, you had my idea but first and better.

.. well actually, probably both (blanket and granular) are worth having, i think.. but yes, for the moment just excluding for baseonly is enough so that 'always fresh' continues to work as intended.
btw, i updated the git repo with these and other changes (master branch)

[Ed_P]

the git repo

URL

[pterid]

you should see it in you live 5.01 /opt/porteus-scripts/make-changes.py ..otherwise, on bitbucket porteus-scripts repo in the v5.1 branch or the pygobject3_ports branch (this repo is has gotten a bit messy)

Ah, excuse me - it was right under my nose!

it simply opened (if possible?) the /boot/syslinux/porteus.cfg file in an editor and gave the savefile path to be manually added to the APPEND line ..

Ah, that makes sense... if and only if Porteus knows where the boot stuff is...

generally, about alternative booting/install options, i think there should be some expansion of the docs (even if it's only links to the various howtos on the forum) to cover some of these, and their pro and cons..
"the docs" being the online and the onboard USB_INSTALLATION.txt and /boot/docs/install.txt..

I have made a thread! Install guide discussion

.. well actually, probably both (blanket and granular) are worth having, i think.. but yes, for the moment just excluding for baseonly is enough so that 'always fresh' continues to work as intended.
btw, i updated the git repo with these and other changes (master branch)

Awesome, thank you as ever!!

the git repo

URL

ncm posted here: Porteus source repos (build scripts)

[Ed_P]

ncm posted here: Porteus source repos (build scripts)

Thank you. I wasn't aware "git repo" equaled "bitbucket.org".

[Ed_P]

03/11 update

Code: Select all

~#  uname -a
Linux porteus.example.net 6.18.16-porteus #1 SMP PREEMPT_DYNAMIC Mon Mar  9 10:49:33 Local time zone must  x86_64 13th Gen Intel(R) Core(TM) i5-13420H GenuineIntel GNU/Linux

~#  cat /etc/porteus/*
001-core.xzm:20260309
002-xorg.xzm:20260309
002-xtra.xzm:20250622
003-cinnamon.xzm:20240924
initrd.xz:20260309

~#  ls -l /mnt/live/memory/images
000-kernel.xzm : Mar 9 06:54
001-core.xzm : Mar 9 01:50
002-xorg.xzm : Mar 9 02:31
002-xtra.xzm : Jun 22 2025
003-cinnamon.xzm : Dec 29 2023
firefox-147.0.4-x86_64-en-US.xzm : Feb 19 01:10

The updates are working so far.
Surprised to see the ISOs updated too. You've been busy ncmp.

Added in 3 hours 12 minutes 35 seconds:



Porteus-CINNAMON-v5.01-x86_64.iso 3/11/2026

USB_INSTALLATION.txt 3/5/2024
/boot/docs/install.txt 8/12/2023

I thought some of the install documentation was being updated.