The following are thoughts at this time and not written in stone. They are open to correction and change as better understanding of the processes at play are achieved (by me particularly).
As some reading will be aware, I have an interest in using removable media for booting the various versions of the PCLOS releases. This has been ongoing for the past few years.
At this time, the liveusb creator project covers most of the options that might be needed, including storing lots of different versions on one device or partition on a device, to allow choice of booting whichever suits a particular situation.
The "livecd=" boot option has allowed us to rename the OS files and just edit this boot option to reflect that change, and thus boot whichever version we wish. So livecd=kde or livecd=lxde are valid options where the original livecd.sqfs file has been renamed to kde.sqfs or lxde.sqfs.
When it comes to the 'copy2ram' boot code, it appears that such variation in the name used for the livecd do not transfer to this boot option.
This results in a renamed .sqfs file not being recognised or used by the 'copy2ram' boot option.
The copy2ram boot option always wants to find a file named 'livecd.sqfs' and not one which has been renamed.
My suggestion to overcome this limitation of the present 'copy2ram' boot option would be to change it so that it is tied to the file name used for 'livecd=' boot option, or alternatively, to change the option to allow specifying the .sqfs by name in the boot stanza.
Whichever of those options is easier to implement would have, I think, the desired effect.
For future-proofing, it might be best to have the .sqfs specified when calling the 'copy2ram' boot option. Just because I cannot presently imagine a situation where one might want to call a different .sqfs file to that used for standard booting in a particular boot stanza does not mean there might not be a reason ..... now or in the future.
So maybe changing the 'copy2ram' boot code to 'copy2ram=' would be the better option. Default options would then be
Those could then be easily changed in a situation where the OS files have been renamed.
Now it may be that using copy to ram when booting from a fast device is not much of a gain ..... and this will likely be even more prevelant when we have USB 3 devices and connections attached to our PCs.
For a lot of us that time is a few years hence, so I believe there is still value in attempting this change.
How to do it?
This is where I am on really unsafe ground
but I do have some thoughts to share .....
It seems that all this part of the boot process is controlled by the 'linuxrc' file.
The copy2ram boot option is specified in that file (actually it is the same as 'toram=yes' ).
Where the decision is taken to copy to ram, based on the presence of 'copy2ram' in the boot line, the "livecd.sqfs" is copied to ram.
I am hopeful that changing this "livecd.sqfs" hardcoded name to some variable that can hold whatever name the user determines, would achieve the goal.
This is what I am referring to ....
# copy the livecd.sqfs image to a tmpfs directory to be used as the new MNTCDROM
echo -n " Copying to memory, please stand by..."
cp -R $MNTCDROM/livecd.sqfs $RAMDIR
If that specified file (livecd.sqfs) was some variable which held the name of the .sqfs file the user wished to use, then any renamed .sqfs file could be used for 'copy2ram'.
OK, there are likely other locations in the script where it would need to be changed also etc etc .... the above is just by way of explanation.
That variable could be either tied to the same name as the 'livecd' variable, or it could be given another variable for even more potential options in the future, as mentioned above. The default of course would always be "livecd.sqfs" so that nothing that uses that at present would get upset by the change.
This has gone on way too long.
Those are my thoughts presently.
All I ask is that the reader accept that although they may not use such things as different boot media and different boot options, there are quite a number of users who do and probably more who would like to, if the application of those options was simpler to achieve.
I guess the main point of this discussion should be any negative effects this might have on other parts of the booting system.
A secondary discussion point might be if it is easily achievable as I obviously think it is at present.
If the results from the above two are positive we then come to the question ...... is there someone who would like to get involved in looking at this with a view to implementing it?
It would be my wish/hope that this might be achievable and tested in preparation for the next quarterly releases of the PCLOS ISOs.
Over to you folks ....... comments, views etc etc ......