How to create a Multi-Porteus Boot USB flash drive?

[Ed_P]

but I'd like to know a solution for automatically assigning this optional folder with a cheatcode, but which one ?

OPTIONAL modules are manually loaded/activated after you boot. To load an optional module when you boot there are 2 easy options imho:
1. Copy the module to the /modules folder.
2. Use the extramod= cheatcode to either: a. replace the /modules folder name with the /optionals folder name, or b. add the optional folder to the extramod= cheatcode after the module folder's name. extramod=/path/folder_with_modules;/path/folder_with_optional modules.

the Porteus modules activation panel

[Rapha_]

1. Copy the module to the /modules folder.

I'm going to try this method too...

2. Use the extramod= cheatcode to either:

a. replace the /modules folder name with the /optionals folder name,
or
b. add the optional folder to the extramod= cheatcode after the module folder's name. extramod=/path/folder_with_modules;/path/folder_with_optional modules.

No, this method is no good, because in this case the modules in the 'optional' folder are activated* automatically (which I don't want).

* Activated doesn't necessarily mean loaded into ram memory, doesn't it? or am I mistaken???

Porteus modules activation panel

le panneau d'activation des modules Porteus in French
The translation is not good ?

The true name is Porteus module activation status made with the script lsmodules by jssouza and it works very well ! Thanks to him!
See : Porteus module activation status

[Ed_P]

No, this method is no good, because in this case the modules in the 'optional' folder are activated* automatically (which I don't want).

I thought that's what you asked for.

I'd like to know a solution for automatically assigning this optional folder with a cheatcode, but which one ?

* Activated doesn't necessarily mean loaded into ram memory, doesn't it? or am I mistaken???

Yup, activated means loaded into RAM.

So, you want to automatically assign a drive to the optional folder which I assume is on the USB drive your booting? After you boot you could run a script to do that. Something like this could work for you.

DRV.sh

Code: Select all

#!/bin/bash

# https://forum.porteus.org/viewtopic.php?p=86943#p86943
# but, yeah, to set an env variable, add a file to /etc/profile.d:
# my_env_var.sh

#set -x;
# http://forum.porteus.org/viewtopic.php?f=53&t=3801&start=30#p28472
BOOT=`grep -A1 "Booting" /var/log/porteus-livedbg|tail -n1|sed 's^//^/^g'`
SYSTM=
DRV=${BOOT:5:4}
if [ "${BOOT:0:12}" == "/mnt/isoloop" ]; then
   ISOBOOT=`grep -A1 "//porteus" /var/log/porteus-livedbg|tail -n1|sed 's^//^/^g'`
   SYSTM="${ISOBOOT:14:10}/"
   DRV=${ISOBOOT:9:4}
fi
if [ "$DRV" == "nvme" ]; then
   SYSTM="${ISOBOOT:19:10}/"
   DRV=${ISOBOOT:9:9}
fi 
export DRV

Optional=/mnt/$DRV/porteus/optional

[Rapha_]

Apparently all sub-folders of the 'module' folder are loaded automatically: so it's not a good method for optional too ...

* Activated doesn't necessarily mean loaded into ram memory, doesn't it? or am I mistaken???

Yup, activated means loaded into RAM.

it seem not really :

[My Firefox is automatically activated]

But when I use The task Manager there is a difference before and after being executed

• Before, Mem 23 % used ( 891 MiB / 3.7 GiB )
  With show all process activated --> Firefox is not visible

• After Firefox execution, 34 % used ( 1.3GiB / 3.7 GiB ) Firefox is visible in process (it uses 360 MiB of memory at startup)

So, you want to automatically assign a drive to the optional folder which I assume is on the USB drive your booting? After you boot you could run a script to do that. Something like this could work for you.

I'll try that later

[Rava]

* Activated doesn't necessarily mean loaded into ram memory, doesn't it? or am I mistaken???

Yup, activated means loaded into RAM.

it seem not really :

[My Firefox is automatically activated]

But when I use The task Manager there is a difference before and after being executed

• Before, Mem 23 % used ( 891 MiB / 3.7 GiB )
  With show all process activated --> Firefox is not visible

• After Firefox execution, 34 % used ( 1.3GiB / 3.7 GiB ) Firefox is visible in process (it uses 360 MiB of memory at startup)

Rapha_ you are correct.
When copy2ram cheatcode is not used (and the quoted post by Rapha_ did not mention copy2ram; nor does the one by Ed_P) an activated module hardly uses any RAM resources.
I only have 4 GB of RAM on my main PC, hardly a lot by today's standard, so I refrain from using copy2ram cheatcode.

Example:

Code: Select all

root@rava:/Porteus_modules# ls -o 005-chromium-ungoogled-118.0.5993.70-x86_64-en-GB-1alien.xzm
-rw-r--r-- 1 root 110735360 2023-10-16 16:35 005-chromium-ungoogled-118.0.5993.70-x86_64-en-GB-1alien.xzm
root@rava:/Porteus_modules# 1024calc 110735360
105.605 MB
105.61 MB

My 005-chromium-ungoogled-118.0.5993.70 module is approx 105.61 MB of size, so when activated it should use at least that kind of RAM without even being started according to Ed_P.
I use my alias fx to not only display "free -m" but also add an time/date stamp line for better comparisons:

Code: Select all

root@rava:/Porteus_modules# type fx
fx is aliased to `echo $(date +%d.%m.%Y\ %H:%M:%S) ____________________________________________________________;/bin/free -m'

Now for the test itself, be aware that three much RAM using programs are already running: palemoon, interlink and Telegram. (Aside from others using much RAM like Xorg)

Code: Select all

root@rava:/Porteus_modules# fx
18.10.2023 05:20:59 ____________________________________________________________
               total        used        free      shared  buff/cache   available
Mem:            3873        3010         312         106         551         348
Swap:          15157         959       14198
root@rava:/Porteus_modules# activate 005-chromium-ungoogled-118.0.5993.70-x86_64-en-GB-1alien.xzm 
Updating shared library links:  /sbin/ldconfig
root@rava:/Porteus_modules# fx
18.10.2023 05:21:45 ____________________________________________________________
               total        used        free      shared  buff/cache   available
Mem:            3873        2995         284         106         593         360
Swap:          15157         958       14199
root@rava:/Porteus_modules# deactivate 005-chromium-ungoogled-118.0.5993.70-x86_64-en-GB-1alien.xzm 
Updating shared library links:  /sbin/ldconfig
root@rava:/Porteus_modules# fx
18.10.2023 05:22:42 ____________________________________________________________
               total        used        free      shared  buff/cache   available
Mem:            3873        3004         276         107         593         352
Swap:          15157         958       14199
root@rava:/Porteus_modules# 

As you see, activating the 105.61 MB sized module did not cost me 105.61 MB of RAM.
Swap have been not really been affected, the swap value changes by just a mere one MB, so we ignore swap for now. (Swap use even decreased by 1 MB, not increased!)

When activating the module meant its compressed size is fully loaded into RAM, then my free value should have gone down from 312 prior activation minus (rounded) 106 MB is: 206 MB.

But it is not, the free RAM after activation is 284. That is only minus 28 MB, not minus 106 MB.

And we cannot disregard the buff/cache and available values.

The free RAM decreased by a mere 28 MB, but buff/cache increased by 42 (meaning 42 more MB is used for buffering and/or caching - and since buff/cache can and will be freed when the system needs RAM elsewhere) - the available RAM even increased by 12 MB.

Available is RAM available including RAM currently used for buff/cache since that can be freed, like I wrote above.

And deactivating the module seems to decrease the free RAM, and even seems to decrease available RAM: from 360 MB during module activation to 352 MB after activation. Quite bizarre, eh?

Better even, comparing the available RAM prior the module activation an after the module deactivation shows this:
available RAM prior the module activation: 348 MB
available RAM after the module deactivation: 352 MB

Be aware that the entry of free is not that important due to the fact that a standard Linux system will try using much available RAM for buffering and/or caching. More important is the available RAM entry.

HTH.

[Ed_P]

But when I use The task Manager there is a difference before and after being executed

Before, Mem 23 % used ( 891 MiB / 3.7 GiB )
With show all process activated --> Firefox is not visible

After Firefox execution, 34 % used ( 1.3GiB / 3.7 GiB ) Firefox is visible in process (it uses 360 MiB of memory at startup)

Rapha_ you are correct.

Do this command:

Code: Select all

ls -ski /mnt/live/memory/images

before you activate Firefox then do it again after you activate Firefox,
and note the name of the 2nd folder is live and the name of the 3rd folder is memory.

Activating a module is not the same as executing the module.

[Rava]

Activating a module is not the same as executing the module.

What is "executing the module"?
You not meant executing a binary from an activated module?

Added in 5 minutes 30 seconds:
man ls

Code: Select all

-k, --kibibytes
     default to 1024-byte blocks for file  system  usage;  used  only with -s and per directory totals

-s, --size
     print the allocated size of each file, in blocks

Allocated size of each file (in this case: folder) not means it is loaded into RAM. ls is only concerned about file system information. It doesn't know anything about live systems and such.

If it were the case, please explain my above quoted experiment showing that activating a module doesn't use that many RAM as the compressed module is of size.

[rych]

I'm trying to install different versions of Porteus (3.1, 4.0 and 5.01) so that they can be booted from the same USB key. My boot USB drive (created with Porteus Installer from the 5.01 XFCE cdrom) works wonderfully well to boot 5.01, and now the challenge is to find a way to also boot the other versions from the same stick. I have tried putting separate directories (Por3.1, Por4.0, etc.) containing the "boot" and "porteus" folders in the USB key's root directory and playing with the porteus.cfg file in a number of ways, to no avail

I run both Porteus 5 and PorteuX from the same USB. I don't use .iso booting and I save my changes into a folder which had better be on a proper linux filesystem.

The 'msdos' partition table allows 4 partitions, so after creating a small 50MB FAT32 for EFI boot, I made an ext4 partition with porteus&changes folders, and the 3rd partition is also ext4 with porteux&changes folders, the last partition is NTFS for data.

It doesn't have to be different partitions of course: you can have one ext4 partitions with porteus, porteux, changes, and ... let's say changex -- where the changes= cheatcode should be pointing to for porteux!

As for the boot&EFI folders on the FAT32 partition, just 2 files from each distribution should be (renamed and) added into (normally) /boot/syslinux: vmlinuz and initrd. For example, I have in there vmlinuz and vmlinuzX; initrd501.zst and initrdX.zst and so on.

My boot&EFI also have grub installed into them. I had to use grub which is a signed boot loader allowing to load unsigned kernels to be able to boot on some (DELL has made it more difficult/impossible with recent BIOS updates on their new machines) Secure Boot enabled UEFI systems. So instead of adding new boot entries into /boot/syslinux/porteux.cfg I add them into /boot/grub/grub.cfg. But again, grub isn't necessary either. If you can have Secure Boot disabled on your systems, I don't see why one would use grub instead of the included syslinux?

[Ed_P]

What is "executing the module"?

Running the app / Invoking the app / Starting the app? What do you call it when your chrome module initially displays a window on your screen?

is only concerned about file system information. It doesn't know anything about live systems and such.

I'm pretty sure when the folder the file system information is being reported from is labeled /live/memory it's not from the /mnt/sdxx/module drive.

please explain my above quoted experiment showing that activating a module doesn't use that many RAM as the compressed module is of size.

A module may be compressed and contain a variety of words in different languages but when executed/run/invoked/started the code in the module is decompressed and only the words in the language the user selected are loaded and viewed. If the app reads and writes other files the RAM used will include the buffers needed/used/required to perform the process being executed.

Added in 23 minutes 2 seconds:

Code: Select all

guest@porteus:/mnt/live/memory/images$ ls -ski
total 0
 5035 0 000-kernel.xzm/
22880 0 001-core.xzm/
17156 0 002-xorg.xzm/
  319 0 002-xtra.xzm/
 5582 0 003-cinnamon.xzm/
 8374 0 07-printing-x86_64-2023-02-04.xzm/
    6 0 DellBlueTooth.xzm/
   56 0 Dellautonet.xzm/
    4 0 Dellsound.xzm/
    5 0 Dellwifi2.xzm/
   91 0 firefox-118.0.2-x86_64-en-US.xzm/
  327 0 mychanges.xzm/
   19 0 mynemochanges.xzm/
guest@porteus:/mnt/live/memory/images$ 

Code: Select all

guest@porteus:/mnt/isoloop/porteus/base$ ls -ski
total 378796
2118  95332 000-kernel.xzm  
2123 125848 001-core.xzm      
2127 114784 002-xorg.xzm
2132  18064 002-xtra.xzm    
2136  24768 003-cinnamon.xzm
guest@porteus:/mnt/isoloop/porteus/base$ 

Code: Select all

guest@porteus:/mnt/sda6/porteus5.0/Modules$ ls -ski | grep '.xzm'
187898  85564 07-printing-x86_64-2023-02-04.xzm*
187901    472 DellBlueTooth.xzm*
187900      8 Dellautonet.xzm*
187902      4 Dellsound.xzm*
187903    908 Dellwifi2.xzm*
  6726  70876 firefox-118.0.2-x86_64-en-US.xzm*
 49315  14860 mychanges.xzm*
187966      8 mynemochanges.xzm*
guest@porteus:/mnt/sda6/porteus5.0/Modules$ 

[Rapha_]

@ Rava , Ed_P

The free - m command is missing some information (there's no active and inactive memory...)

I did a complete memory test with the Firefox module: before/after activation, after execution, exit and deactivation .

I used the command :

Code: Select all

vmstat -sSM > before.txt

After that, I made a table with a graphic to better see the evolution of this memory

For your information, the compressed module is 64.5 Mio, which corresponds to the inactive memory, but since the active and swap cache are also growing strongly, I can't say where exactly the module's memory is distributed !

[Rava]

Thanks Rapha_ for that testing.

Code: Select all

vmstat -sSM > before.txt

I shall try that as well. I ran

Code: Select all

vmstat -sSM

several times and it seems it makes no difference when ran as root or when ran as guest. Rapha_, can you confirm that?

Which program did you use for creation of Activation-module.png ?

For your information, the compressed [Firefox] module is 64.5 Mio

That's amazingly small. Is it a recent version hardened against the critival vulnerabilities CVE-2023-4863 & CVE-2023-5217 ?

If so, then i want that as well.

[camtaf]

These solutions seem rather complicated.....I just use Ventoy.

[Rapha_]

@ Rava

Which program did you use for creation of Activation-module.png ?

For the table with the graphic, I used LibreOffice

That's amazingly small. Is it a recent version hardened against the critival vulnerabilities CVE-2023-4863 & CVE-2023-5217 ?

If so, then i want that as well.

I've chosen speed (with this old version of Firefox) but I've disabled webp and webm.



@ camtaf

These solutions seem rather complicated.....I just use Ventoy.

No, it's not complicated...

And Ventoy also needs configuration if Porteus is to be used to its full potential :
Ventoy, Porteus et Syslinux...

[Rava]

I've chosen speed (with this old version of Firefox) but I've disabled webp and webm.

I would not be surprised when folks bore up old versions of browsers and add the fix for CVE-2023-4863 & CVE-2023-5217 to the source code, thus creating older but slim and faster versions hardened against these vulnerabilities.
*knocks on wood*

[Rava]

Realised this detail via the other thread PorteuX 0.7 has been released (Post by rych #96914) but deemed to ask about that is more appropriate in here than in the PorteuX 0.7 thread.

I run both Porteus 5 and PorteuX from the same USB.

Is it a USB thumbdrive or an external USB harddisk?
The thread title is How to create a Multi-Porteus Boot USB flash drive? so I presume with your "the same USB" you refer to a USB thumbdrive aka a USB flash drive?
If so, then why do you use as the last partition NTFS for data?

When it's a USB thumbdrive Windoze can only see the 1st partition, so any Windoze could not access any data on that sdX4, unlike when it's an external harddrive then Windoze can access all partitions if it knows these kind of partitions (e.g. FAT, VFAT. NTFS)

Or did this behaviour of Windoze change in the newest Windoze versions, e.g. in W10 or W11?

Added in 16 minutes 43 seconds:
Update
I try setting up a USB thumbdrive for both Porteus and Porteux and report back in here how that went; including as many details so tat anyone can replicate how I did it fro themselves.
For backup and security reasons, I will neither use the 8GB thumbdrive that already has Porteus 5.01 on it, nor the 8GB thumbdrive that has Porteux V0.7 on it, but look for yet another 4GB or 8GB with either enough free space, or I move its data elsewhere and use its entirety (in case of a 4GB thumbdrive) or the sufficient free space (in case of a 8GB thumbdrive) for setting up a drive for both Porteus and Porteux.
And I already have the boot image for that one:


CAVE! This drawing and this character is copyrighted material! Use it on your own peril. Therefore I reduced the original size of 640x480 px to a mere sample size of 200x150 px.

The "extUSB-XW" in its top right corner uniquely identifies one drive.

My own parlance on that (also used by my lsfind databases thingy)
ext is for any kind of external drives (USB thumbdrives, USB harddrives, SD cards)
(int is the equivalent for internal drives)
USB is my short for a USB thumbdrive (always external, unless I buy a Raspberry Pi)
HD is my short for an external or internal harddrive
and finally the XW uniquely identifies that one external USB thumbdrive.

Added in 7 minutes 2 seconds:
Meaning, since "extUSB-XW" is already in use, the new drive will get a different unique identifier editing the non-changed (only cropped) porteus.png that has no text in its top right corner.

When it's e.g. USB thumbdrive "05" it would be "extUSB-05" or "extUSB_05".
When it's e.g. USB thumbdrive "XX" it would be "extUSB-XX" or "extUSB_XX".

I use the divider of "-" or "_" to make it more obvious what is the description about the type (external USB thumbdrive) and what is the unique identifier (e.g. 05 or 21 or XX)