wiak wrote: ↑Wed Oct 20, 2021 12:14 am
My gut feeling on the above code addition, by the way, is that I'd have to pass the isopath (per grub2 loopback) to WDL initrd/init at boottime and loop mount it from WDL perspective so that init can access the WDL-needed files it contains whilst setting up layers. I'd also need to add a related very small change to the w_mountfrom selection code for that special boot from iso case. Perhaps I'll investigate that later.
wiak wrote: ↑Wed Oct 20, 2021 12:15 pm
I have taken a final look for now at SG2D booting via grub2 loopback mechanism.
An odd thing I note is that the SG2D autoiso.cfg script exports the directory where the isos are stored in variable iso_path, but it doesn't unfortunately also export the device where that directory is. Talk about a pain... Anyway, I want to keep WDL init simple per one of its design aims so I am not going to be adding all the scan device code that would apparently be required to find the device where that iso_path is (though may leave a position in the WDL initrd for that as a placeholder for an optional w_plugin later).
Nevertheless, it strikes me that I could provide limited grub2 (and SG2D) "boot from iso" support, where instead of scanning all devices for that bootisos location, WDL initrd/init can scan simply for a particular partition LABEL that contains the bootisos directory. What makes that relatively easy/short to implement is that WDL initrd/init already contains a simple function for searching for device partition via a designated LABEL.
fredx181 wrote:From a bootable usb with GRUB2, direct ISO booting, this stanza works too with WDL-Void-xfce4-rc3.iso (I placed in "isos" folder on second partition):
I find this more convenient than using SG2D frankly.
Yes, I prefer that direct grub2 loopback procedure too, though providing for Clarity and others who use SG2D is also good.
rockedge wrote: ↑Wed Oct 20, 2021 5:46 pm
@fredx181 Excellent! Would the init modifications work if put into the w_init file instead of modifying initrd_v401rc1.gz??
No, that is why I split WDL init into two parts, init and w_init. The (what was) small init part is required inside the initrd since its job is to find the boot partition/directory. Code that comes after that, which does most of the 'real' overlayfs-related work/functionality, can be stored external to the initrd; hence the optionally external w_init can prove very useful during development and for alternative implementations and user-contributions.
As I said a few posts above, a 'search for isos function(s)' was required to boot from iso file using grub2 (or SG2D), along with a minor if then selection code modification to include a boot from iso choice. So thanks Fred, for providing the Porteus boot variation of that functionality.
Nevertheless, as I said earlier, I will make the search for isos code a w_plugin for placement inside the initrd rather than incorporate that complex iso-search code into the small WDL init itself (i.e. as I've already indicated in earlier post, I'll make a minor change only to the existing WDL init to allow a plugin to be sourced for this kind of optional purpose along with minor modification to the if then selection code to include iso boot).
I won't include that Porteus code in official release per se because:
1. The main reason is licensing restrictions. Porteus code is under a GPL license and I can't ignore that in official publication. A simple for loop or if then selection would never be a problem since simple 'statements' are commonplace and not subject to license restrictions, but more complex code sections are certainly restricted for use by their author's assigned license. It is in any case particularly important to me that official WeeDog scripts have a non-restrictive license (MIT) such that WeeDog code can be used for both 'free/open-source'designs or for commercial implementations if someone wants it for that. When a developer wants to include a non-MIT licensed plugin, a good solution would be to have a simple associated plugin build script that auto-inserts it into the official WDL initrd (via the likes of a specially tailored modify_chroot_initrd script) - that's a well-known way of avoiding licensing issues (though overall work still can't be published when the licenses are 'incompatible' for any reason).
The unrestricted MIT-licensed WDL code can be freely used in GPL designs, but the opposite is not true; if a project uses GPL code as part of its scripts then the whole script would need to become that same restrictive GPL if it were to then be published, which is why I didn't use similar code from the DebianDogs. I knew of course that DebianDog's Porteus initrd must contain search for isos functionality (as does GPL-licensed Puppy) since grub2 loopback is known to work with it. I also knew such search code understandably involved quite complex blkid (and so on) manipulations involving many lines of code.
2. In practice, that search for isos code is not required at all for normal frugal install, which is the emphasis in WDL design. It is therefore an optional 'wish', but one that increases the complexity of init for that single boot from iso file search purpose. It was very much always my concern to keep WDL init as simple and easy to understand for others as possible - hence my adoption of the simple w_bootfrom kernel-line mechanism rather than adoption of an auto-search for boot files methodology, which is never simple... In main WDL initrd release, as I've already said, I will instead be providing inbuild limited grub2 loopback (and SG2D) support - the limitation being that the partition containing the isos must use the LABEL name SG2DISOS. That is very easy for me to implement as MIT licensed WDL code since the search for LABEL functionality, written by me, is already part of WDL init.
3. Not everyone will be booting WDL from iso files. It is my wish as part of overall WDL design philosophy that such optional facilities be satisfied via simple addon (optional) plugins. It is also a fact that I wish to encourage alternative optional implementations/WDL plugin development since WDL is intended to be a good system to learn Linux system development with. Those who build systems using WeeDog components can polish these builds up as much as they want of course, but the core of WeeDog is intended to remain small and expandable thereafter only via optional plugin build extras so that builders can alternatively build very minimal systems that purposively lack any un-wished-for extra functionalities. I see both types of system (full-on and minimal) as useful and good.
NOTE that using a 'sourced' script plugin does not get round any licensing restrictions (such as those of GPL), so official WDL initrd cannot be published containing a mix of MIT and GPL code. But a plugin does allow individuals to use a plugin of their own design and/or any license they wish for their own use. Of course a MIT licensed plugin is always going to be preferable since it could than be adopted inside the core MIT-licensed WeeDog scripts, but all contributions/ideas are good.
Fact is, I am no expert on licenses at all, but can't see that anyone could stop or object to forum members individually using any code of any license (be they plugins or otherwise). But publishing any complete work that mixes incompatible licenses, I am pretty sure, is a different matter, which I cannot officially sanction. As I said, being unrestricted for using it, MIT licensed code is compatible inside a GPL declared overall project, but GPL licensed code, on the other hand is not compatible inside MIT licensed project code (unfortunately). I doubt anyone would complain, but still, Porteus (and Puppy) assign a license to their work, so I can't ignore that.
However, as far as I understand it, plugins, individually published on their own, can be assigned to any license a user/creator/contributor wants them to be, and it is nothing to do with me what individuals use at home. However, they should check license restrictions (those of GPL in this case) before they ever publish any complete works made using WeeDog code. Furthermore, since WDL code is all MIT-licensed, users are free to use it mixed with GPL at home anyway, as long as they don't then publish the overall result as MIT-licensed (which they can't because of that GPL included code restriction). Such is life. That's the reason I myself didn't take such functions out of Porteus or Puppy code (despite knowing it was there) - I contemplated exactly that in fact, but since I couldn't publish that officially under MIT license I decided to use the less flexible LABEL search approach since I don't think many need to boot from iso files anyway, though that's just my opinion.
Anyway, big post, but I wanted to explain why I won't be publishing WDL isos myself that contain Porteus or Puppy code in their core scripts. Puppy can use WDL code (though acknowledgement of source is always good of course - MIT does provide for that). Nor will I be moving WDL to a GPL license. I do not like these GPL-related restrictions. Indeed, one reason I did not choose Linux live kit to implement WDL init is for license reasons (though Linux Live seems to be only under author name, which is even worse). Also, back then, two years ago since WDL overlayfs implemented, Linux Live was aufs only - though recently, in last 6 months I think, has provided optional overlay support, but its usage license remains unclear to me.
NOTE: I'm not inviting others opinions about licenses. Anyone who wishes to argue about that should open a different thread since this one is about rockege's WDL_Void_XFCE creation (including or not including boot from iso ability). However, I had to comment about WDL published works if they mixed MIT with GPL, which under the GPL is not allowed per se. i.e. Publish a plugin (any license) is encouraged and excellent, but be careful about online publishing scripts/complete-works that mixed in GPL when project is MIT - that is a problem (if I sanctioned that as official WeeDog publication - I certainly don't myself have permission from Porteus team to publish large chunks of their code under WeeDog chosen MIT license, and even if I did I'd want that to be an optional-only plugin). The code is useful though for Clarity's wishes anyway!!! 
