Porteus

@ Gooplusplus

Gooplusplus wrote:I don't want "my" own personal post-first-run settings saved when they may be entirely different and inappropriate for others.

So the Question is: Why do you have to run it first?
(imo you could unpack the iso, make your configurations and repack.)
and the Point is: If you need to do so, you are not forced to save your Settings.

The "main-owner" of this collection may or may not save his changes (e.g.using a save-file)
you can boot porteus in "allways fresh mode" what will ignore the changes and boot up the defaults.If you make and want to save the changes you can make a "module" containing them.This modul you can store wherever you want and activate it next Time.

I should add that my comment was assuming that the user boots with the changes:EXIT cheatcode. I am also an 'always fresh' user. I think we agreed early on in the evolution of Porteus that a 'first run wizard' of any kind would not work well with Porteus for many reasons.

Once up and running, the Porteus SAVE FILE MANAGEMENT menu seemed simple enough. However, the SAVEFILE creation aspect never really worked for me. It seemed to create the file in RAM without writing to the USB flash drive.

I did find a workaround by CREATING (EXT4 option) and then choosing the REPAIR OPTION simply to grab the listed porteus.dat file (from RAM?) in order to copy via the FILE MANAGER to my bootup USB flash drive. After that, the changes=/multiboot/porteus/porteus.dat parameter in my /multiboot/menu/porteus-rw.cfg worked fine after reboot.

This is not a very user-friendly method to add persistence but I'm not fond of digging through documentation to find the "right way" to do it. I doubt many Windows users new to Linux would be inclined to do so either.

At least after this process, I can now compress this clean porteus.dat file for inclusion with a few new USB multiboot "persistent" collections. With automatic Porteus persistence available for less tech-savvy users, I will now replace Puppy-Racy with Porteus KDE 2.1 for my next YUMI-compatible USB multiboot collection (example shown below, likely to be available in a few days via bittorrent download).



http://www.gooplusplus.com/multiboot-collections/

Once up and running, the Porteus SAVE FILE MANAGEMENT menu seemed simple enough. However, the SAVEFILE creation aspect never really worked for me. It seemed to create the file in RAM without writing to the USB flash drive.

could be due to an 'async' mount flag used in Porteus by default. most Porteus installations are done on the flash media so we need this flag to reduce number of writes and extend life of the sticks.

solution to the 'delayed writes' problem is very simple: one must run 'sync' command after creating the .dat container to flush the buffers.

@brokenman
please add this command to the 'save file manager' tool.

thanks for reporting.

Done. Added sync after all dd actions.

Hi Gooplusplus,

Correct me if I'm wrong but you want to have a feature that allow anyone to choose the path of changes before even downloading the ISO ? About .dat container ... I don't think this will be possible for only one reason ... someone will not downloads an ISO of 1.5Gb with a container of 1Gb included inside.

Thanks!

^
...and a preset path makes no sense if you just want to burn a live-cd...for use on different machines...

Hamza wrote:Hi Gooplusplus,
Correct me if I'm wrong but you want to have a feature that allow anyone to choose the path of changes before even downloading the ISO ? About .dat container ... I don't think this will be possible for only one reason ... someone will not downloads an ISO of 1.5Gb with a container of 1Gb included inside.

That is not how it will work. A clean 1GB EXT4 *.dat file can be compressed to under 400KB.

donald wrote:^
...and a preset path makes no sense if you just want to burn a live-cd...for use on different machines...

Before you speculate on what "makes sense", perhaps you might wait a few days and try it yourself. I will post a bittorrent link.

Assuming that everything works, this first "all persistent" USB multiboot collection will include Zorin OS lite, Porteus KDE 2.1, OpenElec 3.2.2 XBMC, Hirens Boot CD lite, and AVG rescue CD with a total download size of about 1.6GB (requires installing to a 4GB or larger USB flash drive.)

@Gooplusplus
You are talking about a USB multiboot
I'm talking about a live-CD
must I explain the difference?

My YUMI-compatible USB multiboot collections are made up of several "live-cd" distros on a single USB flash drive rather than on CD-ROM media,

This one, for instance, is under 800MB and contains utilities collections and four selectable Linux "live-cd" distros. (Only Puppy has persistence.)

http://www.gooplusplus.com/multiboot-2013-mini-v2/ --- http://www.tuxdistro.com/torrents-details.php?id=1752

A clean 1GB EXT4 *.dat file can be compressed to under 400KB.

Can you extend this answer to a more technical answer with details like compression method, algorithm used, advantages, disadvantages ?

Hamza wrote:

A clean 1GB EXT4 *.dat file can be compressed to under 400KB.

Can you extend this answer to a more technical answer with details like compression method, algorithm used, advantages, disadvantages ?

I simply used 7-zip to create a self-extracting EXE file. I created PERSISTENCE.exe which compressed two "clean" files: (1) /casper-rw (1GB used for persistence for any Ubuntu derivative) and (2) /multiboot/porteus/porteus.dat (512MB EXT4 persistence file). The archive format is *.7z (required to create SFX archive). Since I found there was little difference in the compressed file size on clean persistence files, I chose the 7-zip defaults: fastest, LZMA compression, etc.

PERSISTENCE.exe will be run and uncompressed almost immediately after formatting the USB flash drive, likely eliminating any potential fragmentation.

Here is what I could get when trying from one of build servers.

Pull apart a slax-6x ISO and take a look at the save.dat files that are all compressed into one (zip?) file.

I don't understand, sorry.