I can only hope I didn't miss anything due to tiredness 
..... or worse affect something I shouldn't have ....
Nope. We have a winner. Everything works.
I started with a live CD session on the PIII, 512MB of RAM, using the last OpenBox Bonsai. This machine does not have a USB boot option in BIOS. I used your PLOP floppy image to boot from USB. Checked all boot options when creating the live USB. When I rebooted from the USB thumbdrive, the first thing I selected was Openbox with Copy to RAM. Worked flawlessly. I then rebooted to persistence mode. Setup wifi with password and copied the lusbc_0.9.7-1.sh to guest's ~/Downloads directory. Rebooted with persistence again and wireless came up automatically. Copied script was where I left it. Rebooted again and ran Memtest. That works, too.
I then switched to an AMD Duron, 1152MB of RAM, already running from its hard drive installed OS. Ran the lusbc_0.9.7-1.sh script and used the RAW iso to add to the USB's contents, naming the entry "RAW". Again, I checked all boot options. This machine also requires the PLOP floppy image to boot from USB. Just like on the PIII, the USB port booted from is on a PCI card. Rebooted from the USB. Guess what the new entries were named? If you guessed "RAW", you'd be correct. Tried the copy to RAM option first. At first, I thought there was a problem. Then I remembered Hootiegibbon's creation boots to an X-client script with no wallpaper or toolbars. Just a blackscreen running X. Right-clicked and got, I think, an FVWM menu. Rebooted again with persistence. Did a full Synaptic upgrade and installed the full IceWM. Rebooted once more with persistence and all updates were intact.
The last reboot was to check Memtest option again. Bear in mind, I chose to add Memtest both from the live CD session, and from the copy from iso session. As a result, there are two Memtest GRUB entries. The executable was only written once, to the /boot directory. I don't know whether to call that a flaw or not. I think not. It would be extra work to see if a previous Memtest entry already exists in the /boot/grub/menu.lst file, then deselect that option if it already exists. I think it's better to just tell the user to only select the Memtest option once.
I was hoping you wouldn't drop any of the extra options included in the script. True to form, you didn't. The loop files are /OpenBox0.sqfs and /RAW0.sqfs. Doesn't look "messy" to me. Looks very logical and easy to know what belongs to what, along with the folder names.
The thumbdrive is 16GB formatted with ext4 on a single partition. I had no problems with repeated reboots from the USB. I really like what you've done with this. Excellent work!
As comprehensive a test run as I have come to expect ..... really appreciate that.
I am aware of the time and effort it takes to do this.
Just for clarity, can I ask if you used the 'primary OS' install option for Openbox and the 'Add an OS' option for RAW, or did you have an OS already on that stick and use the 'ADD' option for both?
I think this is not important now, just want to clarify in case of any questions later.
Regarding Memtest ...... the memtest package is present on the install from a 'Primary OS' install, whether it is selected to be used or not, for that install.
This provides memtest as an option for additional installs, even if not selected for the first one.
It is a small package ~160K so has little effect on space consumed, and is, IMO, well worth having there by default.
I was hoping you wouldn't drop any of the extra options included in the script. True to form, you didn't. The loop files are /OpenBox0.sqfs and /RAW0.sqfs. Doesn't look "messy" to me. Looks very logical and easy to know what belongs to what, along with the folder names.
I chose the easiest way out of my dilemma in the end
I reverted to the previous method of storing the files, with the .sqfs files in the root of the device.
I did make a slight change to the naming convention, which distinguishes the files from those installed by the previous version - not needed, but for my testing it helps to know which is which. So the name now is the 'name' chosen by the user with a number appended which is the Grub partition number on which it is installed. Previously I had an underscore between name and number.
FYI, having the partition number appended allows the user to have the same named OS installed on multiple partitions of the one device, and yet ensures that the correct .sqfs file is used for each.
So, if you wished you could have an OS named KDE on several partitions of the device - say different releases like 06 & 09 - and the correct one will be used for booting for both. Without the number the first file found that matched the name would always be used .... so the 06 .sqfs file might be used when trying to boot 09, and throw up problems.
Also it is great to hear that the PLOP boot manager works in the situation you described.
A very useful package that ..... pity it is not released under the GPL.
Thanks again mate
*******
I will now withdraw the script from the download, as I believe testing is complete ..... or as complete as possible.
I want to thank all those who took the time and effort to check out that it would run and do as expected.
I really do appreciate the effort it takes, so a big
Thank You to all.
When the translations are complete this will be packaged and hopefully hit the repositories some time later.
regards.
