Multiple versions of Porteus

[francois]

rara:
Somehow these days I always use Syslinux.

Great, at last we will have a syslinux expert.

[datruche]

Hi, found some good information in this post --thanks to françois, Rara, Rava and Ed_P

I began to test Porteus v3.1 yesterday. Hope I can include it in my test of some distros usability on flash memory devices and small PCs.

Using the doc and your examples above in this thread below, installing Porteus single proved to be a fast, relatively easy job.
Adding another Porteus version is more complicated.

Adding persistence:
I used dd for creating a '.dat' file per Porteus version.

Code: Select all

dd if=/dev/zero of=/media/KINGSTON4G/porteus/64/changes.dat bs=1M seek=512 count=0  
mkfs.xfs -L LABEL /dev/USB_STICK_PARTITION

Not so used to formating files with a filesystems, I searched a bit as I couldn't find the way on porteus.org (http://www.porteus.org/component/conten ... tainer-and has no word on fallocate, dd and mkfs.xfs)

Going Multiboot
I went with Syslinux bootloader since I've always found GRUB2 overkill when Syslinux's simplicity reminds me ofgood ol' Grub (legacy). FS is FAT32. File structure on my key look like this:

Code: Select all

USBSTICK/
|_boot/syslinux/
|_porteus/
  |_32/
    |__boot/{initrd.xz,vmlinuz}
    |__porteus/{base/  make_iso.sh  modules/  optional/  i486.sgn  rootcopy/}
  |_64/
    |__boot/{initrd.xz,vmlinuz}
    |__porteus/{base/  make_iso.sh  modules/  optional/  x86_64.sgn  rootcopy/}
|_[other folders]

From what I understant, 'LABEL' tell the OS which environment to start. As for the cheatcode 'from= ' it should tell the path to the root Porteus-version-N folder (the one with 'boot/' and 'porteus/'). Is that correct?

A few trials and errors after, all entries work but the XFCE 64-bit: It boot till after loading all the modules and display something like "Started the Live system", then hang up and freeze complaining about '/union/etc/mtab' then '/union/dev/console' nonexistent.

Code: Select all

# 32bit (the #64bit problematic entry is just below)
 
LABEL XFCE
MENU LABEL XFCE 32bit
KERNEL /porteus/32/boot/vmlinuz
APPEND /porteus/32/boot/initrd.xz from=LABEL:KINGSTON4G/porteus/32 sgnfile=porteus-v3.1-i486.sgn changes=/porteus/32/save.dat [timezone... utc volume kmap]

(...)  

# 64-bit  

LABEL XFCE
MENU LABEL XFCE 64bit
KERNEL /porteus/64/boot/vmlinuz
APPEND initrd=/porteus/64/boot/initrd.xz from=LABEL:KINGSTON4G/porteus/64 sgnfile=porteus-v3.1-x86_64.sgn changes=/porteus/64/changes.dat  [timezone... utc volume kmap]
(...)

LABEL fresh
MENU LABEL Always Fresh 64bit 
KERNEL /porteus/64/boot/vmlinuz
APPEND initrd=/porteus/64/boot/initrd.xz from=LABEL:KINGSTON4G/porteus/64 sgnfile=porteus-v3.1-x86_64.sgn nomagic base_only norootcopy [timezone... utc volume kmap]

Please can you advise on the XFCE 64bit issue?

The Porteus refs I'm using for this:

• [HOWTO] run multiple versions of Porteus from one partition
• Add Porteus entry~ies to (another distro installed GRUB2)
  viewtopic.php?f=48&t=1790
• Add Porteus to Debian GRUB2, GPT partition
  viewtopic.php?f=39&t=3993
• Boot from any number of Porteus versions with Syslinux or Grub4DOS
  viewtopic.php?f=81&t=4953[/quote]

EDIT: Corrected typos on on name (sorry about that) and on the UBS stick Porteus files' tree.

[francois]

welcom datruche.

1. For persistence in porteus .dat containers are only necessary if you want to work on windows for system. And there is a porteus tool to create them. With xfs, you just need to specify the folder in which you want your changes to be saved. The cheatcode for change or persistence has to be specific to the boot loader:
http://www.porteus.org/tutorials/26-gen ... -them.html
changes="path-to-folder" #an existing one of one that you will have to create.

2. For dd use have a look at this thread for newcomers, use find function dd:
http://forum.porteus.org/viewtopic.php?f=81&t=3318

3. but the XFCE 64-bit:
porteus-v3.1-i486.sgn* is in the 64bit path tree you need the 64bi .sgn

[datruche]

3. the i485.sgn comes with the Porteus XFCE 32bit entry, and the x86_64.sgn for the XFCE 64bit's. Seems right to me. Now the 64bit is not booting. Does someone has a clue why?

the XFCE 64-bit: It boot till after loading all the modules and display something like "Started the Live system", then hang up and freeze complaining about '/union/etc/mtab' then '/union/dev/console' nonexistent.

2. While I'm glad these forums are active and information rich, they're for the users and hobbyists. Which I'm not yet. Brand newcomers to a distro with no fellow using it like me, look for the information in the doc, FAQ or chat first when they exist and look well (the case). Digging in every forums is way more time consuming, that is, unless knowledgeable guy like you is kind enough to give somedirection Thanks for the link (it didn't came out when I did my searching at each step).

1. persistance or Changes.dat file can be created from the live yes (btw I'm writing these messages from Porteus). Now I like to do and possibly automatize as much as possible in the original step, from the existing OS. Eases the workflow. The cheatcode that made me scratch my head a bit last night is 'from= ': As the information for that one is a bit scaterred along http://www.porteus.org/tutorials/26-gen ... -them.html I wasn't sure to where it should give the path to, eg {LABEL:xxx,UUID:xxx}/porteus/{version}{/}{porteus} Guessing it must be obvious when you know but eh.

[francois]

Sorry that linux computing could be so rebarbative.
1. Personnally I do not use the LABEL, I use a) /dev/sdax/"your path" and/or b) better for usb keys UUID. Thus for you:
a) from=/dev/sdxy/porteus/32
But as your usb could be assigned a different /dev/sdxy from one bootup to another, I use uuid. There might be a label strategy, but I do not know it.
What is the output of blkid for your /dev/sdxy usb key?
b) from=/dev/disk/by-uuid/UUID:cb81a316-66b7-4a04-9760-43357614fc06/porteus/32 (is for my usb key)

2. This forum is the right place. We just need to communicate and find the level of explanation that you need.

3. porteus 64bit .sgn should be porteus-v3.1-x86_64.sgn. I do not see that in your folder tree.

[Rava]

Hi, found some good information in this post --thanks to françois, Rara, Rana and Ed_P

(Highlighting by me)

WHut? I do not recall a user Rana here; I checked via "Nach einem Mitglied suchen" (Search for a member), and indeed, we have no user Rana. (STill, Rana is a cool username, same with Rara and Rava. [Duh] </own trumpet and such> <-- lame joke is lame>]

Me presumes it was a typo? By random luck or such, could you have meant to say it was yours truly that was able to help you with that?

[Ed_P]

Adding persistence:
I used dd for creating a '.dat' file per Porteus version.

Code: Select all

dd if=/dev/zero of=/media/KINGSTON4G/porteus/64/changes.dat bs=1M seek=512 count=0  
mkfs.xfs -L LABEL /dev/USB_STICK_PARTITION

Not so used to formating files with a filesystems, I searched a bit as I couldn't find the way on porteus.org (http://www.porteus.org/component/conten ... tainer-and has no word on fallocate, dd and mkfs.xfs)

Wow!! Not sure where you found the DD command for creating a save.dat file but the way I always use is the menu > System Tools > Porteus Save File manager. A GUI and reasonably straight forward.

File structure on my key look like this:

Code: Select all

USBSTICK/
|_boot/syslinux/
|_porteus/
  |_32/
    |__boot/{initrd.xz,vmlinuz}
    |__porteus/{base/  make_iso.sh*  modules/  optional/  porteus-v3.1-i486.sgn*  rootcopy/}
  |_64/
    |__boot/{initrd.xz,vmlinuz}
    |__porteus/{base/  make_iso.sh*  modules/  optional/  porteus-v3.1-i486.sgn*  rootcopy/}
|_[other folders]

That 64/ porteus line shows an i486 .sgn file reference not a x86-64 one.

3. the i485.sgn comes with the Porteus XFCE 32bit entry, and the x86_64.sgn for the XFCE 64bit's. Seems right to me.

May be but that's not what you posted.

oops

[Rava]

Question towards admins and fellow moderators:
The 1st part of this post is quite off topic here. Would be the best when I create a new thread, use rara's quoted below post as the initial post of that thread and then copy my below reply as new reply to his post in there the best solution to untangle the off topic issue?
(I refer to the "gmail / GMX and alpine matter" rara asked me about. Not the "who the frog is Rana matter" at the very end)

_______________________________

TL;DR: Off Topic issues with gmail

What specific problem are you having with Gmail. Sorry I couldn't comprehend what issue are you having for so long. If I could understand I could possibly help.

Sorry rara, I have issues with alpine / Gmail and with alpine & GMX.

GMX is my main email provider, I just created a gmail account to test if the old howto use alpine and gmail still works, and if the same approach can be used for my issue with GMX.

My gmx issue, I can use alpine only for searching, reading, listing and deleting emails. It is quick as a falkon and works like a charm, quite unlike my older approach, that was Mozilla Thunderbird. Which is a nice software, that's not the issue, but for a text based communication as email, why not use a text/console based slim and highly customable I cannot send any emails.

And with gmail: When I use the setup from the howto "config alpine with gmail", all that happens is that gmail sends me an email, telling me an unsecure software / method was just used to try to access my gmail account and that google blocked that.
Which is NOT what I want google to do.
Sadly, I tried posting a question on the gmail forum, but for some reasomn, I could log into my google account, but the button for posting on gmail forum was missing (I did allow all pages to use their own colours, so that the icon was not missing in the same black hole that swallows the Porteus Forum [Edit article] or [reply with quote] or [delete article] icons.
____________________________________

Check the poster of this link

I don't copy.... The poster of that link was rara, and he mentioned me among others in the post you linked, but I am not sure what you try to tell me, sorry...

(Also, you seem to have deleted that very part about me wondering who could be meant with Rana in datruche's quoted part from my post above, seems you deleted that part from your post post while I was writing this very reply. )

[datruche]

@françois was that first sentence assuming?

3. porteus 64bit .sgn should be porteus-v3.1-x86_64.sgn. I do not see that in your folder tree.

In the folder tree yes (thanks I corrected it). But not in the included porteus.cfg code, which is what is used to boot rather than my "artistic creation" attempt to display the file structure on the USB stick

@Rava Yes your Multiboot syslinux shared above helped me go and try Porteus! Sorry about the typo. I do know a Rana, but had never meet with a Rava. ANd people tend to see what they know already. But I did care to differenciate between Rara and you while digging with the multiple new cheatcodes and documents, did you notice?

@Ed_P well, I installed the Porteus versions from a linux box and tried to do that job without powering my box off line. Seems I got a bit presomptuous :} 'fallocate' seems to be the way to go but, as it did not work for some reason on that USB key I used dd. Also command-line allows for better control, precision, in-line workflow, easy reproduction as well as automatisation when needed, at least in my experience


So I'd like to hearing your advices on these questions that I certainly have mal-formulated:

1. In Syslinux's porteus.cfg does LABEL tell the OS which DM to start (eg xfce, Maté)?.

1.1 The cheatcode 'from= ' tells the exact path to the Porteus-version-N folder (aka root folder), the one with 'boot/' and 'porteus/'). Is that correct?

2. After some trials and errors for booting multiple Porteus versions from an USB stick (FAT formated), all entries work but the XFCE 64-bit: It boot till after loading all the modules and display something like "Started the Live system", then hang up and freeze complaining about '/union/etc/mtab' then '/union/dev/console' nonexistent. Where to go for correcting this? The non-booting XFCE 64bit entry looks the replica of the XFCE 32bit which boots fine. Other 64bit entries also boot top noch.

[francois]

porteus-v3.1-x86_64.sgn (this is a tag) is not needed in the syslinux syntax, except if you have many versions of the same architecture. What is important is that you have the file porteus-v3.1-x86_64.sgn file in the /porteus folder. The initrd.xz will look at it an find it automatically. In your example, you have only one copy of a 64 bit and only one copy of the 32 bit architecture. There is no need for the porteus sgnfile=blabla in your bootloader syntax.

However, if you want many 64 bit installations of the same porteus version, then you will need to rename the porteus-v3.1-x86_64.sgn in your folder tree with different tag names. For example, for three porteus identical versions: 1_porteus-v3.1-x86_64.sgn, 2_porteus-v3.1-x86_64.sgn and 3_porteus-v3.1-x86_64.sgn, in each of the needing /porteus folders of these three installation. Then in your bootloader syntax you will need the sgnfile=1_porteus-v3.1-x86_64.sgn for the first installation, the sgnfile=1_porteus-v3.1-x86_64.sgn for the second installation ...

***************************************
1. In Syslinux's porteus.cfg does LABEL tell the OS which DM to start (eg xfce, Mate)?.
No. This is only the title you want to see at bootup. Though if this is the mate desktop and helps you as a mnemonic, just put it in there.

1.1 The cheatcode 'from= ' tells the exact path to the Porteus-version-N folder (aka root folder), the one with 'boot/' and 'porteus/'). Is that correct?
Exactly.

For the 64 bit edition, try to download another copy and verify the md5sums. It might be simply corrupted.

[Rava]

However, if you want many 64 bit installations of the same porteus version, then you will need to rename the porteus-v3.1-x86_64.sgn in your folder tree with different tag names. For example, for three porteus identical versions: 1_porteus-v3.1-x86_64.sgn, 2_porteus-v3.1-x86_64.sgn and 3_porteus-v3.1-x86_64.sgn, in each of the needing /porteus folders of these three installation. Then in your bootloader syntax you will need the sgnfile=1_porteus-v3.1-x86_64.sgn for the first installation, the sgnfile=1_porteus-v3.1-x86_64.sgn for the second installation ...

Could it be you meant with the last sentence this:
"Then in your bootloader syntax you will need the sgnfile=1_porteus-v3.1-x86_64.sgn for the first installation, the sgnfile=2_porteus-v3.1-x86_64.sgn for the second installation ..." ???

For the 64 bit edition, try to download another copy and verify the md5sums. It might be simply corrupted.

Can it happen, that with a custom made ISO, that it's corrupted, the iso builder not realizes that and computes the md5sum, which is then the same of the downloaded version, but the ISO is still corrupted?

//OffTopic
Answered (francois)

[datruche]

Thanks for the clarification on *.sgn in case of multiple Porteus-32/64 versions. Why I bothered to add it? After failed boot telling:

Code: Select all

^ Searching for porteus-v3.1-i486.sgn file                                  
^ 'from= cheatcode is incorrect, ...                                        
^ using Porteus data from /mnt/sdb1/porteus                                 
^ creating live filesystem and inserting modules                            
sh: 7: uknown operand
(...)

It worked fine without the 'sgnfile=' after I edited 'from=' APPEND cheatcode, so error may have been caused by my miscomprehension of 'from= ' in the first place.

1. In Syslinux's porteus.cfg does LABEL tell the OS which DM to start (eg xfce, Mate)?.
No. This is only the title you want to see at bootup. Though if this is the mate desktop and helps you as a mnemonic, just put it in there.

For the 64 bit edition, try to download another copy and verify the md5sums. It might be simply corrupted.

Aha so which DM Porteus will load is hardcoded in the version. Could have understand that by myself sorry.
No, to my knowledge its 'MENU LABEL' that names the syslinux boot menu entry. 'LABEL' is the syslinux name, the one we can type to load the appropriate kernel (like in Slitaz). Also beware, as it's mangled as DOS name.

As for the issue with XFCE 64-bit 1st boot entry not booting: The Porteus ISO md5sum was OK. Now my Kingston USB stick has suddently become unreadable (device is still seen and led on but no tool is able to read a partition or filesystem on it ) Makes a perfect "culprit" for the issue I had. Easy to check (and too bad for the little key).

Could it be you meant with the last sentence this:
"Then in your bootloader syntax you will need the sgnfile=1_porteus-v3.1-x86_64.sgn for the first installation, the sgnfile=2_porteus-v3.1-x86_64.sgn for the second installation ..." ???

Can it happen, that with a custom made ISO, that it's corrupted, the iso builder not realizes that and computes the md5sum, which is then the same of the downloaded version, but the ISO is still corrupted?

Hi Ran.. err, Rava
As for the sgnfile I understand it just like you.

[francois]

which DM Porteus will load is hardcoded in the version
More simple than that you cannot have two desktop modules, kde and xfce loaded at the same time. Look into your /porteus/base folder there is only one DE module depending on the edition that you choose. The DE module could be alternatively placed in the /porteus/modules folder. There are methods involving syntax of the bootloader that will permit loading from the same porteus installation one of the DE modules. Personnally, I use the extramod= cheatcode to do so. See:
viewtopic.php?f=48&t=4360

You really ask pertinent questions. I hope this does not make your experience with porteus traumatic.

So the topic is moving from multiple versions to multiple versions with multiple desktops.

[brokenman]

dd if=/dev/zero of=/media/KINGSTON4G/porteus/64/changes.dat bs=1M seek=512 count=0
mkfs.xfs -L LABEL /dev/USB_STICK_PARTITION

You are creating a 0Mb save file here.

## Create a 5Mb container.
dd if=/dev/zero of=/tmp/container.dat bs=512K count=10 <---- 5Mb is very small. This is just to demonstrate the mathematics.

## Format the container
mkfs.xfs /tmp/container.dat

Please read the document /mnt/sdXy/boot/docs/cheatcodes.txt for more information about cheatcodes.

Code: Select all

SPECIAL NOTE FOR USING CHEATCODES WITH 'LABEL' AND 'UUID':
If you specify a LABEL or UUID with a cheatcode, remember that all
portions of these commands are case sensitive.  You should use a
unique label for each of your partitions if you wish to use device
labels with your cheatcodes. Use the 'blkid' command to view your
device's UUID and LABEL. Using UUID and LABEL can be quite handy
because they are unique to your device, and your data will be found
and properly mapped on different hardware configurations.
Every cheatcode which contains a /path can take advantage of 'UUID:'
and 'LABEL:' extensions.

Examples:
changes=UUID:STrING-0F-ChARACtERS/path/file.dat
extramod=LABEL:YourLabelName/path/to_folder/with_modules
from=UUID:STrING-0F-ChARACtERS/path/folder
rootcopy=LABEL:YourLabelName/path/to_folder/with_files

So LABEL is used to identify the LABEL of a partition. Using UUID will give more accuracy.
For your case:
from=/dev/sdXy/porteus/64
from=UUID:STrING-0F-ChARACtERS/porteus/64

DESKTOPS:
Porteus will boot to the desktop of whatever 003 module is loaded last. There should only be one. It resides in the porteus/base folder. If you want to choose between desktops at boot time you can download the extra 003-desktop.xzm modules from http://dl.porteus.org and place them in the porteus/optional folder. So (for example) if you have 003-xfce.xzm in the base folder and all the others in the optional folder you can use a cheatcode at boot time to choose. To do this hit TAB at the bootloader screen and type: noload=003-xfce load=003-kde

This will tell porteus not to load the 003-xfce module that is in the base folder, and to load any module from the optional folder that has the name "003-kde" in it. In this way you can decide on the desktop at boot. Be warned that any changes file that once saved 003-xfce related stuff will still be loaded (if you are using the changes= cheat) along with the 003-kde desktop which may or may not screw something up.

[datruche]

Hi I'm back with some new fast usb sticks from SanDisk to replace the dead one). And maybe some stuff on multiboot Porteus with syslinux (chainload), but let's answer you first.

DESKTOPS:

into your /porteus/base folder there is only one DE module depending on the edition that you choose. The DE module could be alternatively placed in the /porteus/modules folder. There are methods involving syntax of the bootloader that will permit loading from the same porteus installation one of the DE modules. Personnally, I use the extramod= cheatcode to do so. See:
viewtopic.php?f=48&t=4360

Porteus will boot to the desktop of whatever 003 module is loaded last. There should only be one. It resides in the porteus/base folder. If you want to choose between desktops at boot time you can download the extra 003-desktop.xzm modules from http://dl.porteus.org and place them in the porteus/optional folder. So (for example) if you have 003-xfce.xzm in the base folder and all the others in the optional folder you can use a cheatcode at boot time to choose. To do this hit TAB at the bootloader screen and type: noload=003-xfce load=003-kde
This will tell porteus not to load the 003-xfce module that is in the base folder, and to load any module from the optional folder that has the name "003-kde" in it. In this way you can decide on the desktop at boot. Be warned that any changes file that once saved 003-xfce related stuff will still be loaded (if you are using the changes= cheat) along with the 003-kde desktop which may or may not screw something up.

Thanks for that!

Changes file command line creation:

## Create a 5Mb container.
dd if=/dev/zero of=/tmp/container.dat bs=512K count=10 <---- 5Mb is very small. This is just to demonstrate the mathematics.

## Format the container
mkfs.xfs /tmp/container.dat

Got it, and the maths, thanks.

'from=' cheatcode and multiboot:

Please read the document /mnt/sdXy/boot/docs/cheatcodes.txt for more information about cheatcodes.

Yeah they're easy to find on both site and USB stick. I had them with me when writing the syslinux, and notice how the 'from=' cheatcode doc has the boot from OS images perspective --not from folderS?

> So LABEL is used to identify the LABEL of a partition. Using UUID will give more accuracy.

Actualy we were talking of syslinux' LABEL. And yeah, accuracy for the system and only for it. I'm used to label partitions with uniques labels.