Porteus

On a USB stick booting multiple flavours of Porteus, I am experiencing severe slowdowns and balks in all the OSses.

Porteus with DEs openbox, Mate, XFCE, and LXQT are in subdirs targeted using the from= parameter in the syslinux boot instructions. All flavours experience slowdowns that they did not when on a solo-boot stick written as default by the Porteus installer. The subdir contents were copied directly from those original solo-boot sticks.

To test whether it is a fault with the USB stick itself, I placed an identical copy of the LXDE ~/porteus folder in the top level of the same disk, mimicking the default installation directory structure.
When booted from this folder, Porteus runs fine.
When booted from the lower-level folder using the from= parameter, porteus is horribly and uncharacteristically slow and balky, pausing for long times in the middle of routine operations. File copies from place-to-place on the USB stick run at speeds as low as 44 Kbps with frequent 'stalls'.

Please see the syslinux code below:
This occurs identically on several different machines.

Code for the 3 other flavours is identical except for the subdir name/path.

Does anyone have suggestions how to correct the slowdowns?

Amaya

A couple of thoughts:

1. Use the same vmlinuz and initrd.xz files for each menu. Not copies, the same /boot/syslinux/vmlinuz and /boot/syslinux/initrd.xz.
1.a. Personally I would use a INITRD /boot/syslinux/initrd.xz line like the /boot/syslinux/porteus.cfg file uses.

2. Put all the 003- de files in the same /porteus/base folder then in each menu's APPEND line add an noload= cheatcode for all the des you don't want loaded.
2.a. For openbox you would use: noload=mate;xfce;lxqt For Mate you would use noload=openbox;xfce;lxqt etc.

Basically have one OS, 4 DEs and 4 /pxyz/changes folders.

One of my menu's options for Cinnamon:

Added in 9 hours 52 minutes 13 seconds:
Another 2. thought. Install the main distribution on the USB drive then copy the alternate systems' 003- files into the /porteus/modules folder rather than the /portues/base folder. The noload= works for them also.

Ed_P...
Thanks for this very interesting suggestion and approach.
I had no idea about the noload= parameter existing or offering this possibility.

This implementation will have very convenient consequences for my attempts to resolve the disparate behaviours of Porteus with different DEs loaded.
1) By re-using all the same other (non-DE) system modules for each booted OS instance, it eliminates any possible inconsistencies in anything except the DE itself.
2) By all booted OS instances using exactly the same home directory and contents, I don't have to keep notes on an offside partition or folder that all OS instances can access.
3) Huge amounts of disk space are saved and directory complexity eliminated by getting rid of all the bulky duplicate subdirectory contents.
4) If I compile a new module, I do it once and its available in the same modules folder for all DEs. If I find one somewhere else I don't have to copy it to 4 different modules folders. I don't accidentally/carelessly end up comparing the performance of different modules in different DEs (at one point I somehow had FFox 128 in one OS/DE and FFox 130 in another.)

. . . . . . . . . . . NICE !

I think this solution might rightly be called 'elegant'.
I will get back with results when I have worked with it a bit.

I am curious to see if I will still be able to set up a different desktop wallpaper for each DE reminding me which DE I am in.

..................................................... Amaya

I am returning belatedly (over 2 months later) to this topic to mark it as "solved".
Thanks for your patience!

Although I am marking it as "Solved", I never did figure out WHY Porteus seemed to run so much more slowly in some configurations, but managed to find configurations (most) where performance matches that of a solo-boot LIVE stick.

Multi-booting several live Porteus flavours became a huge though enjoyable distraction because it was so interesting to see how many different configurations of multibooting worked. Besides the variations in ways of specifying boot params (aka cheat codes) and init specs that surprised Ed_P, I tried a lot of other different configurations using various cheatcodes for loading or not-loading DE-modules, different directory structures (including the ?most frugal? one of a single shared copy of everthing, and the most wasteful of duplicating everything for each system). I tried parking DEs in another folder and calling them specifically by path/name, you name it - almost everything I tried could be made to work after puzzling out why it did not do so on the first try.

For any other inexperts who want to try this, I encourage you to give it a go. Almost all the work can be done with the text editor as root on the /boot/syslinux/porteus.cfg file, and also using the filemanager as root to move things around in the disk you booted from - I don't think I needed to use the terminal at all.
I don't consider myself a Linux expert, but the porteus.cfg file is much more understandable to work with than say, Grub2 config files with all the devvy curly-bracket stuff that I don't have the patience to learn. Its more like an old DOS batch file or the simple menu files Grub4DOS uses. DOable.

Thanks for the help getting me going on this.