Porteus USB live install

[robang74]

About choosing a default browser for the users

How to choose a browser for the user? Netsurf is extremely appealing with its 2MB size but it has no (or not complete) support for javascript which makes it unsuitable for every-day use of a common user. The next appealing size is Palemoon which is a reduced lightweight version of Firefox (half of its size). Nice, it seems that we have found the right candidate for including a default-chosen browser but then we can read the news and found out THE problem: "Firefox 137 fixes harmful bugs" - keeping updating a browser is a MUST and installing it as a module IS NOT the right choice. So another approach should be taken. At the moment v5.1 (alpha2) does not show any browser but probably it will do as soon as it is stable.

Under these circumstances, I would opt-in for Netsurf because 2MB more does not change the sensitivity of the picture and at least a man page or a document in HTML/CSS can be read. Like those can be generated using one of my scripts and leveraging the github.io platform with an extended markdown language (to add fancy PDF production) or just the standard one. At the same time Netsurf is not good enough to fulfill the users need to have a full-flagged browser. In that case, downloading a module is NOT the best way to go but an installation that can be upgraded (whatever it would be made in a specific loop file or docker or via an on-demand module creation) as soon as possible.

This is mandatory in keeping the users safe and alleviate the DEV from the need of track every browser update in order to make a new module and distribute it among the mirrors - even if the mirrors are automatically updated - the idea of keeping EVERY update is quite demanding but in case of a regression, users cannot return back to their previous version. So, as you can imagine while having basic browsers like yt, lynx, dillo, netsurf is a mere commodity all the others are going to pose a challenge in a way or another.

Many other software can have security issues BUT the browser is the most exposed in terms of frequency and as-per-daily basis use. Therefore - to some extent - it is a peculiarity. IMHO, it makes sense to add netsurf among basic packages (as long as the icon is cropped because it is hugly and wrongly displayed in many circumstances) but the idea of integrating a full-fledged browser is a little more complicated (and also delicate) than creating a set of optionals modules.

I hope this helps, R.

[robang74]

New v0.3.5 release

Mostly changed usb-install with the following:

• a more fine grain timings during installation (debug and develop purposes, mainly)

• added a script /home/guest/.xprofile that add a resolution for DVI-VGA adapters (as example, also)

• hopefully a more solid and stable Kiosk mode drawbacks mitigation (after mem-install tests)

• added a clean-sh scripts that make easier expert users to test the new version without interferences

• alien binaries in /boot/*.{exe,com} removed because I do not how they behave with Moonwalker's edition

Enjoy, R-

[francois]

Nice contribution. I will try it.

[robang74]

Nice contribution. I will try it.

In the meantime, I am also considering other ways to use Porteus EXT4/INST on Thinkpads without an internal device (or without using it for that). Still theoretical as an approach, by now.

• https://github.com/robang74/porteus-usb ... busesports

An alternative to using a USB pendrive, is leveraging the internal u/SD reader, if it exists to save a USB port. In this case, it is useful to keep in mind that such embedded readers, like the one included into the Thinkpad X201, is limited by the USB version bus bandwidth. In that case the keywords for choosing a u/SD card are: U3 and A2 as mandatory, while v30 and XCI as desirable.

[...]

Instead, the X220's u/SD card reader is on the PCIe bus, so it is faster than USB 2.0 but is not among the bootable devices, unfortunately. However, there are two ways to overcome this issue: 1. using Coreboot (aka LinuxBIOS) which is out of the chance of many; 2. boot from an USB device (or internal SATA) and then switch on u/SD to run the system, and clear the USB port from the temporary boot device.

[M. Eerie]

is not among the bootable devices

I don't know the BIOS/UEFI compatibility specifications of your X220, but it seems a key point is that the card must be identified as an mmcblk device for the Linux kernel to detect it. In this case, a USB dongle might be useful.

Take a look here just in case.

[robang74]

it. In this case, a USB dongle might be useful.

and

Solution: Just temporarily use a USB <> SD-card adapter to do the burn.

Correct, as long as the u/SD is connected to the USB bus in whatever manner, it can be written (*) and it can boot as usual. The problem arises when the adaptor in whatever manner is connected to the PCIe bus on which the boot option is not allowed for X220 bios, AFAIK. This is the reason because a boot stage should be provided on USB or S/ATA buses and then jump on the u/SD as per the (root) system disk drive. Possibly, it is enough to create a bootable with kernel and initrd image ONLY and when 9...8...7.. the Porteus script is searching the correct drive as per its system device let it find on the internal u/SD reader. If a Porteus is installed on internal SATA the USB bootable jumps on it - instead of continuing on the USB stick. This makes me think that it would work as long as the kernel initialises the PCIe devices.

UPDATE #1

Boot from an USB device and with the u/SD into the internal reader, and the USB port can be freed ASAP the kernel + initrd image are loaded into the RAM, or later. Noticeably, the USB boot can be replaced by the network boot initiated by the BIOS. -- Tried and it works! - I have the USB port free and the system running on the u/SD using the internal adapter from X220 (**). Is it fast? Well, the u/SD is just a v10 - Read 20Mb/s, Write:10MB/s - but a better one certified v30, is arriving.

UPDATE #2

The most convenient way to boot from a non-USB u/SD embedded card reader is to install a specific boot option into your grub/windows for a multi-boot system, or create the u/SD as an Moonwalker's Porteous EXT4/INST and the other one as VFAT/LIVE. In that way the usbstick will serve as repair, maintenance and booting device while the other as a main installed Porteus. Alternatively, both devices in EXT4/INST and on the USB the 2nd partition can be formatted or removed (e.g. by gparted), to gain more free space.

Note

(*) apart, that eject -t does not work and smartctl has trouble in dealing with it because see it as sleeping device.

(**) there are two adapters: 1. the uSD to SD adapter which is a 3rd party piece and the internal adapter embedded into the SD slot of the X220. The u/SD adapter, I have two but just one works correctly (SanDIsk OK, Transcend KO). The same happens with the s/SD to USB adapters, one works the other not. Fortunately `sudo dmesg -w` immediately tells about.

[robang74]

Extra modules as default

I am planning to ask the users to download the followings modules:

Code: Select all

 428	man-lite-porteus-$lastversion-$arch-alldesktops.xzm
4820	remmina-$lastversion-$arch-$rel-alldesktops.xzm
1648	netsurf-$lastversion-$arch-alldesktops.xzm

Because all together are about 6M, a relatively small footprint, but two of them are quite useful (man, html/css viewer) while remmina which is the biggest of three is probably not so widely used but strategically to use the Moonwalker's edition as a thin client for a server. A server that might also be the one that provide networking and boot from network expecially when booting from an u/SD is not viable but it would convenient to bypass USB 2.0 bandwidth limitation about W/R like in Thinkpad X220.

Request for comments

It seems that choosing the default MATE desktop, all the GTK+ libraries are in place. Possibly, that libraries are also included in remmina as all desktops suggest.

Code: Select all

2088 gtk2-$lastversion-$arch-$rel-alldesktops.xzm

If this is confirmed, then the specific footprint for remmina is just 2732 Kb because the rest of its size is about providing GTK+ 2 for supporting every application when MATE or another GTK desktop environment is not selected. What's about this approach/integration?

UPDATE

The first release of the script to download the suggested set of the modules:

• https://raw.githubusercontent.com/roban ... ownload.sh

It is not integrated, yet. However, the last version of usb-install in the HEAD of the main branch install all the *.xzm that find alongside the ISO file.

[robang74]

Possibly, that libraries are also included in remmina as all desktops suggest.

I did my own home work about this point. Here below the commands that I used on a Porteus with remmina module installed

Code: Select all

df -h 

find /mnt/live/memory/images -name libgstgio.so

diff, ll (date) 

remmina 2021/09/21

003-mate 2025/03/25

diff, ll

find /usr/lib64 -name libgstgio.so

diff, ll

Let me briefly explain the rationale behind and the results. The remmina module brings in some libraries and these libraries can be present in the system, already. Is that bad or good?

• From a point of view of usability and end-user friendness, it is a good choice because who install the module - whatever desktop choosed - can use immediately the tool, as expected.

• From a point of view of system stability, debug and concept is a HUGE flaw that remmina module replaces some system library (003-mate) with stuff 4 years older.

Let me put this in perspective - usually nobody notice, because GTK+ v2 are very stable and therefore compatibility is granted despite a time gap of 4 years. But in terms of debug-ability is quite a nightmare and also in terms of security. Extending this concept to all the possible packages, the whole picture becomes even darker. If a system exist, it should be run on ALL the possible configurations (system, desktop, modules).

An alternative is to separate libraries from environment and module, creating dependencies. So, who chooses MATE will receive in the same ISO the GTK libraries package. On the opposite who chooses KDE the QT libraries package. But what's going to happen if someone chooses KDE and install remmina without GTK libraries package? It does not work. Hence, the installation app for Porteus should knows the dependencies three.

A text file on the mirror about dependencies and a correct segmentation of the components and modules. It seems the most straightforward way to go. Even better if that file - limited to a specific package - it is included into the package itself. Even better if that file contains information about HOW links the stuff inside (version/date). In such a way the root would be populated accordingly.

For example, remmina is date 2021/09/21 while 003-mate from v5.1 (alpha2) is dated 2025/03/25, so it was released the day next, the day of my birthday. I have appreciated very much the gesture and I am here to play nice/fair back, in fact. When the linker knows that remmina is older DO NOT link stuff that exist in root (/) from remmina module even if it is mounted after the 003-mate.

Another quick & dirty way to do that is to use a different nomenclature about components and modules. For example, 20210921-remmina-blabla.xzm and 20250325-mate.xzm. Does it work? I did not tested yet, let me give a try to this way to deal with the "issue". However, it is a mere workaround, the REAL solution is to create a dependency three and act upon that. Curiously, a dependency three - with the relative path of the components like bundles/remmina-blabla.xzm would be ALSO useful for a network installer.

Or, alternatively said, the catalog of every component/module and for each of them the dependencies, it is the ingredients menu from which create a recipe and assemble a personalised image. Because the mem-installer, it is not supposed to provide and installation even if it has been initially tested for that but to create a custom image for QEMU in tmpfs that the user can also save on disk - as per his/her wish - but in general for testing purposes a VT-d IOMMU passthrough virtual machine with a system R/O disk on RAMFS is the best choice in terms of performances while the persistence could be stored into a qemu-friendly COW format file.

Did you got the point? With this approach we can cast a "fast as furious" virtual machine running on a R/O system image today-updated and starting with a pre-configured COW persistence. A file that can EASILY created by running by hands a VM, do by hands the changes we like to have, make a R/O copy of its COW persistence file and starting from that point our VM server can cast a freshly new correctly configured VM every time a user requires with an authenticated thin-client which can run with a specifically tailored Porteus image/ISO.

Guess what? The usb-install in kiosk mode, complete the scenario. A guest arrives, put his/her own usbkey into the Kiosk which install quickly the thin-client variant, boot by the usb (unless the boot from network is not available or as alternative) and then s/he can also run a VM on the server. Complete the picture with cloud as SaaS and BAM!

=== UPDATE ===

Another quick & dirty way to do that is to use a different nomenclature about components and modules.

This is a drastic way to test the "quick & dirty" workaround and, yes, it works - le libraries are kept at their most updated version.

Code: Select all

roberto@x280[0]:/media/roberto/porteus/porteus/base$ ll
total 492816
dr-xr-xr-x 2 root root      4096 Apr  7 08:17 ./
dr-xr-xr-x 7 root root      4096 Apr  6 14:18 ../
-rw-r--r-- 1 root root 164126720 Mar 25 08:56 000-kernel.xzm
-rw-rw-r-- 1 root root    438272 Sep 25  2023 000-z-man-lite-porteus-20220607-x86_64-alldesktops.xzm
-rw-rw-r-- 1 root root   1687552 Aug 19  2024 000-z-netsurf-3.11-x86_64-alldesktops.xzm
-rw-rw-r-- 1 root root   4935680 Sep 24  2023 000-z-remmina-1.4.33-x86_64-1-alldesktops.xzm
-rw-r--r-- 1 root root 140128256 Mar 25 07:19 001-core.xzm
-rw-r--r-- 1 root root 147910656 Mar 25 07:19 002-xorg.xzm
-rw-r--r-- 1 root root  24666112 Mar 25 07:19 002-xtra.xzm
-rw-r--r-- 1 root root  20742144 Mar 25 09:35 003-mate.xzm

So, the general solution is using yyyy-mm-dd-component-name-version-arch.xzm and add them whatever the path /base or /modules in that order. However, what's happen when an optional module is added? File that exist should not be replaced? Based on which criteria? What's about a file exist but left void or unconfigured? Well... that for DEV, right? Good, everyone their own duty.

Another "issue" that it is worth to be mentioned: the kernel base component is above 160MB, why? Firmwares! Are those firmware necessary? Usually yes but not always. Some users might like to increase their boot speed sacrificing those firmware that they DO NOT need, for sure. Like? Let see together:

• 254 MB (uncompressed) for Nvidia GPUs firmwares

• 97 MB (uncompressed) for AMD GPUs firmwares

• 56 MB (uncompressed) for Intel GPUs firmwares

Considering that my Thinkpad has a motherboard integrated GPU, I think that I do not need anyone of these because i915 firmwares are just 11 MB while the Broadcom are 12MB.

Therefore the best choice is to have a separated squash file for each Nvidia, AMD and Intel GPUs firmware folder. Another one for the rest of the firmware - because some people wish to NOT load any proprietary firmware and live on the bare metal as much as possible and finally the all the rest into kernel (drivers). One component, split in 5 pieces, all of them provided into the ISO but not necessarily added into net-install recipe OR removed by users after USB drive has been created.

Is loading 5 pieces instead of one, slower. A little bit but not so much. A good configured TinyCores loads a HUGE number of squash modules compared with Porteus, so we can live with that.

[robang74]

in general for testing purposes a VT-d IOMMU passthrough virtual machine with a system R/O disk on RAMFS is the best choice in terms of performances while the persistence could be stored into a qemu-friendly COW format file

In case you wonder why I am interested/oriented to this approach:

• https://robang74.github.io/chatbots-for ... ns-to-face

The real-hardware server that I am preparing, has 32GB of DDR4 RAM with 4x dual-channel 68 GB/s bandwidth while the SSD NVMe M.2 on PCIe 4x, can read at steady 2.5GB/s. As you can imagine store a 1/2 GB xz compressed stuff in RAMFS as system disk takes a finger-snap (1/5 sec.) to be read from SSD and after that, it becomes "fast as light". Which makes a real-hardware GPU server behaving like a virtual machine in terms of service. The advantages of the worlds together, hopefully. Among others optimisations that can be implemented or experimented like having a dedicated CPU thread (1 of 8) for the kernel, IRQ and xz on-the-fly decompression (which is way faster than compression).



This is how it appears on my desktop among other hardware.

[ncmprhnsbl]

I am planning to ask the users to download the followings modules:

be aware that those modules are specific to v5.01, and in particular there's been a report that the netsurf module is incompatible with 5.1alpha.
internally in 5.1 there's and update script that is a frontend/downloader for various 'live-scripts' that provide modules for browsers and other software (remmina being one of those)

[robang74]

be aware that those modules are specific to v5.01

Thanks for the suggestion: I will put imported software form v5.01 under test. Can you more specific about issues reported?

and in particular there's been a report that the netsurf module is incompatible with 5.1alpha.

The root cause might be because of overwriting the system libraries, as I reported?

in 5.1 there's and update script

I am a clearly an enthusiast of shell scripts, but a script is not the proper "expressive form" to write a catalog / recipe.

POST SCRIPTUM

After all, these kind of problems appear recurrent and systemically rooted, to me:

• viewtopic.php?f=81&t=11362

at least compared with the TinyCore components installation/update.

UPDATE #1

Netsurf and Remmina v5.01 modules installed into v5.1 lacks of libssl.so.1.1 and libcrypto.so.1.1, both. While remmina can starts (not necessary works) using so.3 version linked to so.1, Netsurf is sticky to 1.1 or 1.1.1 and the backcompatibility in so.3 is missing. This underline the importance of keep a kind of separation between apps and libraries, a catalog of components with their dependencies. IMHO, obviously.

[robang74]

DEVELOPMENT UPDATE

With these commits, I am moving further on the idea of "transitionally" integrated the v5.01 apps into v5.1 and I think that it is worth to give a look at xzm/ folder

Code: Select all

+ 6b87eba - 2025-04-10 - porteus-usb-install.sh: more info + v5.x transitioning support, p.1  (HEAD -> main, origin/main, origin/HEAD)
+ 4a03041 - 2025-04-10 - xzm/transition-v5.01-to-v5.1-20250409.*: stuff for transitioning apps
+ 0f79e85 - 2025-04-10 - dconf/user.gz: added new (guest desktop)
+ 5ffe150 - 2025-04-10 - netsurf/Choices: added new (guest config)

What is the rationale behind? Some stuff that is needed to support v5.01 apps are missing in v5.1, adding a new squashfs package fulfills this lack AND the apps are put into the base/ immediately after the kernel package because I do not want that older stuff overwriting the newer. It is a work-around, obviously. A transitioning way to go, not a long-term solution.

The package is 24MB in its xzm format. Way too big for my specific needs: adding remmina and netsurf (+ javascript). I think that a better way to go was to use the script (where is it?) that converts packages into a module. In that case, I would focus on applications directly rather than older stuff they require. Probably, I will go for this path also and probably I will shrink the transitional package just for support remmina and netsurf.

In its fundamentals, the idea is to experiment leveraging what is plainly available to anyone with a little or none know-how about Porteus/X internals. By the way the PorteuX 2.0 has been recently released and probably that release will fulfill my needs without customising Porteus.

Finally, I found a lot of stuff duplicated - in terms of versions, quite a lot - in terms of redundancy a lot less but something. Which made me think that the whole process of creating and integrating modules in base/ is not fully automated, yet. Opinion, did not investigate in depth about this.

[robang74]

VERSION UPGRADE

• 3ed6e98 - 2025-04-11 - README.md: v0.3.6 supports 5.x transitional (tag: v0.3.6)

Transition 5.x:

• Currently the v5.1 is in alpha2 stage but old applications can still working adding a transitional modules

• Since v0.3.6 the scripts support the addition of this module (as example, not granted supports all apps)

• Among applications, two in particular are included into suggested extra modules: remmina and netsurf.

This is the folder which contains the 24MB transitional modules in squash xzm format, sha256sun, list of file, links, etc.

• https://tinyurl.com/22r4jnf5

The module contains file from core, extras and xorg from v5.01 and it goes before the v5.1 kernel module. The files inside can be check against those in v5.01: save in the writable partition the transitional module and after the boot, mount with -t squashfs -o loop in a folder. The use `find` in /mount/porteus/memory do match the files and `diff` to compare them.

In order to support remmina and netsurf, the size would have been much smaller but I did something that may fit with others apps, as well. It should be considered as an untested example of a transitional/temporary approach before v5.1 will be stable and apps will be released for it. Untested because I did not used remmina and netsurf but just started. Despite this, it is reasonably that those two applications will work. In case they won't, open an issue here with log:

• https://github.com/robang74/porteus-usb ... ler/issues

Spoiler: next version will support also PorteuX.

[robang74]

Spoiler: next version will support also PorteuX.

At this point, it seems to me that supporting two different distributions with the same script is not worth the effort. Therefore I created a branch for porteus for the time in which the v5.1 will be stable:

• https://github.com/robang74/porteus-usb ... ee/porteus

I will move forward on that branch to support transitional support for apps only if necessary. In the meantime I will test porteux. However, at this time it is pretty clear that the correct approach is the first that I have written about: leverage TinyCore to create an Dillo/HTML installation by network bootable tool or USB bootable key.

This is how the porteux boot screen looks like:



Why change the boot screen background and the desktop wallpaper? Am I trying to "steal" some credit from Porteus DEVs? Nope, exactly the opposite: I do not want to put on their shoulders the burden of my own choices. You are using my script? You have a visual customisation which clearly states who you have to contact, in the first place, if something is not as expected compared to your previous Porteus user experience. Is it a problem with my script? Well, I'll take care of it. It is a problem of Porteus that you did not see before? Move the issue here.

Hence, it is a best practice in how to handle the feedback among interconnected projects.

• Visual Customization and Responsibility: The deliberate change in boot screen and wallpaper for the PorteuX version of the installer is a smart move. It clearly distinguishes installations done with their script and directs users to the appropriate support channel for issues related to the installer itself. This avoids confusion with official Porteus builds.

• Promoting Clear Feedback Channels: The rationale behind the visual customization emphasizes the importance of clear communication and feedback loops between interconnected projects. This is a mature and responsible approach to open-source collaboration.

Above how this best practice is evaluated by Google Gemini. I did not invent anything new here. It always happens when a DEV is independent from a specific project to not mess-up the original project with his/own activities but take care of it. Which is also the reason because there is a short link on the desktop background: go to the 1st CS line, before bothering DEVs.