Ready for testing is a version of WDL_Void-xfce4 desktop boot-able ISO

[rockedge]

Ready for testing is a version of WDL_Void-xfce4 desktop boot-able ISO. The download link will be here shortly. The ISO file is 757 M.

At this time the project is in it's very early stages. Only the first boot selection without persistence works at this time. The system is built with wiak's build_firstrib_rootfs_400rc1.sh script with the f_00_Void_generic_XFCE_no-kernel_WDLteam-rc2.plug as the plug file recipe to create the XFCE4 desktop based on Void Linux.

The first step is to get something going so I borrowed the components from a Puppy Linux Bionic and Void Linux Live to make a boot capable ISO. As tests proceed this structure will be simplified and cleaned up.

Screenshot(8).png (48.04 KiB) Viewed 4829 times

So far I have only tested on VirtualBox. GParted needs to be included to create an sda1 in an ext2/3/4 format on the virtual hard drive, to be able to build and use /upper_changes for the persistence to function.

If a partition sda1 exists and is writable the second boot option will work and all changes will be saved in/mnt/sda1/live

Screenshot(13).png (166.38 KiB) Viewed 4821 times

________________________________________________________
UPDATED: 30 OCT 2021
Download Link -> WDL-Void-xfce4-rc4.iso 410 M

Also here -> https://rockedge.org/kernels/ under ISO

[rockedge]

In this post is a link to WDL-Void-xfce4-frugal-rc1.iso which comprises of the main components to set up a frugal installation of WDL-Void-xfce4. There are NO boot components included in the ISO.

This is the system I will start with in the construction of a boot-able ISO of the WDL-Void-xfce4 system (hopefully)....

Download Link -> WDL-Void-xfce4-frugal-rc1.iso 721.46944 M

Screenshot(9).png (34.35 KiB) Viewed 4748 times

Boot Stanza examples to boot the system. uuid number is for example purposes.

Code: Select all

title WDL-Void-xfce4-frugal (uuid)
  uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
  kernel /WDL-Void-xfce-2/vmlinuz-5.4.70-rt40 w_bootfrom=UUID=8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa=/WDL-Void-xfce-2 net.ifnames=0
  initrd /WDL-Void-xfce-2/initrd_v401rc1.gz

title WDL-Void-xfce4-frugal (label)
  root (hd1,0)
  kernel /WDL-Void-xfce4-frugal/vmlinuz-5.4.70-rt40  w_bootfrom=LABEL=psystem=/WDL-Void-xfce4-frugal
  initrd /WDL-Void-xfce-2/initrd_v401rc1.gz

title WDL-Void-xfce4-frugal (uuid)
  uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
  kernel /WDL-Void-xfce4-frugal/vmlinuz-5.4.70-rt40  w_bootfrom=/mnt/sdb1/WDL-Void-xfce4-frugal w_changes=RAM0 net.ifnames=0
  initrd /WDL-Void-xfce4-frugal/initrd_v401rc1.gz

[rockedge]

I have constructed a boot-able hybrid ISO of a WDL-Void-xfce4 built with @wiak's WeeDog builder scripts and a PLUG file, outfitted with a Puppy Linux huge real time kernel 5.4.70-rt40 and the XFCE4 desktop.
This is a bare bones operating system based on Void Linux, with the standard desktop components XFCE4 provides. The boot system is borrowed from a Puppy Linux Fossapup64 ISO with the actual ISO built from the command line with:

Code: Select all

mkisofs -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat -D -l -R -v -V "WDL_Void" -no-emul-boot -boot-load-size 4 -boot-info-table -o "WDL-Void-xfce4-rc3.iso" WDL-Void-xfce4-frugal-rc3

Code: Select all

isohybrid /mnt/sdb1/WDL-Void-xfce4-rc3.iso

@Clarity Please test again and @fredx181 perhaps a test to see if it can boot from the ISO directly. I did not test on a UEFI machine.
Improved version : Audio is not completely function ready and needs some components installed.

Screenshot(15).png (34.84 KiB) Viewed 4679 times

Screenshot(17).png (220.23 KiB) Viewed 4639 times

UPDATED: 30 OCT 2021
Download Link ->WDL-Void-xfce4-rc4 410 M

[rockedge]

Starting on a VirtualBox machine and directly after booting in a terminal, ran wiakwifi then installing and using GParted to format and Thunar to create a /mnt/sda1/WDL-live

Code: Select all

xbps-install -Sy gparted

Then re-booted into the second boot option to read and write /mnt/sda1/WDL-live/upper_changes to use system persistence.

Screenshot(19).png (186.4 KiB) Viewed 4628 times

[wiak]

I have constructed a boot-able hybrid ISO of a WDL-Void-xfce4

Download Link -> WDL-Void-xfce4-rc4.iso 410 M

Downloading it now, and I'll burn it to CD to see if will boot on my machines. I will also look into UEFI and Clarity's isoboot needs to see if I can work that latter bit out if not already working - I'm presuming that just needs the loopback cfg files and EFI and puppy cert stuff as produced by FatDog jamesbond I believe (which DebianDogs also use). I never myself boot from iso, and would normally not bother providing these extras (nor the EFI stuff since only need one such install for EFI rather than every produced iso having that duplication, which swells the size of the iso somewhat). Generally speaking I am personally in favour of a system that has EFI booting already provided by host computer then only need new distro to provide the frugal install files and alter the menu.lst or grub.cfg, but I recognise not everyone agrees with that carbon/download-size-saving methodology... My view is that iso booting is great for new users who maybe don't know much about Linux (and they can use a Pup or DebianDog for their early adventures), but seasoned Pup/Dog users most all know how to manually make a frugal install anyway, so why boot straight from iso, despite its slight initial convenience (and ease of use for newcomers, who always have Puppy or DebianDogs to use in iso form anyway)?

EDIT: hmmm... I think quite a bit would need changed to achieve the boot from iso mechanism Clarity is looking from (I may be wrong there though...). I'm not sure since haven't looked into it sufficiently and don't have time sorry.

[rockedge]

@wiak I also am more for providing and ISO that looks like this:

Screenshot(9).png (34.35 KiB) Viewed 4541 times

and letting users set up frugal installs and the boot mechanism. This CD-ROM type WDL-Void-xfce4 ISO is purely an experiment.

Mostly I would recommend just running the scripts with the chosen plug file and build them from scratch, but the ISO does provide all the files that can be immediately installed frugally

[wiak]

@wiak I also am more for providing and ISO that looks like this:
Screenshot(9).png
and letting users set up frugal installs and the boot mechanism. This CD-ROM type WDL-Void-xfce4 ISO is purely an experiment.

Mostly I would recommend just running the scripts with the chosen plug file and build them from scratch, but the ISO does provide all the files that can be immediately installed frugally

Actually, I have been trying (yesterday) to get boot from iso (via loopback.cfg) to work, but I haven't managed. Some might think that should be easy for me since it probably isn't overly difficult to do. However, though I once spent a lot of time working with boot issues down at MBR even BIOS interrupt type scenarios that was long ago, and frankly I always hated it. So it's not really that I'm in any way against arranging for any WDL isos to also be able to boot in that way, I am simply too unfamiliar with the mechanism, somewhat lazy to learn about it since I don't need it myself, and prefer to concentrate on matters that interest me in developing WeeDogLinux core rather than worry about boot matters, which aren't really WDL specific at all. But yes, I would implement that if I had time, energy, and didn't hate that kind of stuff too much nowadays - but I find my mind goes numb when trying to read up on its operation, because I find it boring (which isn't to say it isn't useful), so my hope would be that someone else would work the details out (provide the loopback.cfg details/howto) and I'd happily add that in when appropriate... Yes, I accept that the mechanism could be very useful sometimes and certainly useful for some users as an alternative way to create frugal installs - this is probably one case of it being hard to teach an old dog a new trick (me) though partly because I have a list of other priorities that have been waiting years for me to complete...

[rockedge]

@wiak The first priority was to see if I could boot into a brand new VirtualBox machine. I haven't otherwise tested the ISO, to see if in fact I could get it to boot straight from ISO.

I was hoping smarter people than I would play around with it.

[Clarity]

Hello @wiak and @rockedge

I DO UNDERSTAND the need for an ISO ability as it would be consistent with the current PUP-DOGs that users now see.

AND, I 'understand' and agree that this low-level ability is a departure from the mission of WDL.

This forum community has several resources that might make this ability easy with little need for a departure from the efforts you are doing in WDL desktop operations.

I will consider opening an appeal for some guidance in how to either replicate what is done in WoofCE to create the boot mechanism they employ OR to request how to replicate what the DOGs do to create the boot mechanism they are employing which BOTH of those approaches generate successful means for a bootable ISO via GRUB2 (with grub.cfg<=>loopback.cfg). Those approaches were done, it appears, in 2019 and has been rock-solid ever since with NO development efforts required.

The objective is to make it easy for any user to acquire and boot a WDL with little to no effort beyond a mere ISO file download. I AGREE!

Let me think a little to how to word it "intelligently" with some level of understanding.

[rockedge]

@Clarity I did borrow the entire boot mechanism from a Fossapup64-CE (a woof-CE community edition build, run by me). The only things changed from the Puppy Linux set up is the menu titles and kernel boot commands.

I will add the loop.cfg lines to what I have and lets see if it will work. But I hav not yet even tried to boot WDL from an ISO directly yet

[Clarity]

Hold on. Borrowing may not be the solution.

I think something else is needed in how the boot mechanism is deployed in the ISO. And, have already reached out for some feedback to rectify.

I dont have the answer just yet, but am looking into the ISO itself.

I hope to have some idea soon as I can get back here.

[Clarity]

There is something wrong with the ISO as it is released. If you run a simple KVM virtual machine, you'll see the boot problem. Not sure how to help.

I'm sure you know how to run a Linux Virtual Machine. For the QEMU, I use this:

Code: Select all

qemu-system-x86_64 -boot d -m 1024 -enable-kvm -smp 2  -cdrom WDL-Void-xfce4-frugal-rc1.iso

I get the same error with or without attempts to try a version of GRUB2 PUP setup. The problem is in the files on the ISO. Is this ISO prepared to be a bootable for creating a USB/DVD/CD?

Hope this is helpful.

P.S. You can exchange any modern DOG/PUP ISO in that command to see the difference as they boot to desktop. Also, you can use the qemu_gui program if you have fossaPUP64 running to visually know what is being setup to run a virtual PC.

[wiak]

There is something wrong with the ISO as it is released. If you run a simple KVM virtual machine, you'll see the boot problem. Not sure how to help.

I'm sure you know how to run a Linux Virtual Machine. For the QEMU, I use this:

Code: Select all

qemu-system-x86_64 -boot d -m 1024 -enable-kvm -smp 2  -cdrom WDL-Void-xfce4-frugal-rc1.iso

I get the same error with or without attempts to try a version of GRUB2 PUP setup. The problem is in the files on the ISO. Is this ISO prepared to be a bootable for creating a USB/DVD/CD?

Hope this is helpful.

P.S. You can exchange any modern DOG/PUP ISO in that command to see the difference as they boot to desktop. Also, you can use the qemu_gui program if you have fossaPUP64 running to visually know what is being setup to run a virtual PC.

I don't currently have qemu on my system so haven't had time to try the above. I did however take another 'quick' look at SG2D booting - I got as far as SG2D menu finding the iso loopback.cfg (which is probably wrongly set up by me). From there, it did find and boot the kernel, and the initrd was also loaded and init run. But that's as far as it got and the switch_root to the actual rootfilesystem didn't work. I have not studied how SG2D works so I'm only guessing. It seems to me that all SG2D does is to automate a grub2 grub.cfg for booting the selected iso (which SG2D also detects of course). In terms of trying to see if iso booting can work with WDL, it seems reasonable to me that it would be better to first concentrate on trying to do so with grub2 alone (rather than complicate matters via the automating SG2D scripts). But... fact is, whether 'modern' or not... WDL was at no stage designed with a view towards booting from an iso file (though it certainly can be booted from a CD - I've done so with WDL_LGO_focal release and also with WDL_Slitaz release. Rather, WDL was designed for normal frugal installation. It may well be the case that it would not be able to boot from an isofile, since that has never been considered as part of its design, so it is erroneous to imagine that it 'should' be able to just because some other distros include that feature. I didn't need or want the feature personally, so haven't thought about it at all, so it may well need extra code in the init should that function be required - nothing to do with being 'modern' or not. If booting from an iso file turns out to be the way everyone wants to boot their Linux, then maybe they just shouldn't use WeeDogLinux (or modify it to allow for that boot method I suppose).

I'm not saying it can't... but I suspect it can't so maybe we are wasting our time on that boot method, sorry. The reason I think it might not work is that WDL does not auto-find where its sfs files are located, but rather needs to be told where they are via the w_bootfrom kernel line option. That works perfectly well for UUID, or LABEL, or even the somewhat simplistic w_bootfrom=/mnt/sdX type of entry (and even the likes of /mnt/sr0 for cdrom), but I don't know about inside an iso file instead. So, maybe that simply won't work - I'd be surprised if it did actually, but I say that with almost zero knowledge about how grub2 arranges booting from iso files anyway...

Perhaps I'll try that boot method again sometime, but don't hold your breath, and if you can't get it to work, don't waste your time, that may be because it was not designed for that method. However, if you find it can be done, please let us know for the record. I continue to have water supply and drainage issues at home - pretty big issues alas, so I'm unlikely myself to look into this again for a while, and if it turns out WDL can't boot iso files anyway (design-wise) then that's just how it is, in which case WDL is not for those who need to boot from iso files... but you can boot it in a virtual machine as a normal frugal install or as /dev/sr0 (cdrom) anyway.

[Clarity]

Hi @wiak

Your share on SG2D
SG2D does NOTHING with an ISO file. It is merely a discoverer; nothing more. It list the ISOs if finds at system boot. The user selects from the list, and it turns the system over to the distro selected.

So, when it turns the system over, SG2D is out of the way. And the distro (aka PUP/DOG/etc) is now in control.

QEMU
Next, my post, above, is not a something that has anything to do with SG2D. QEMU merely creates a PC (virtual) and will boot as any 'real' PC would, the distro you throw at it. I cannot get the WDL-VOID distro to boot in the PC. There is NO SG2D involved at all in booting in QEMU; its ONLY the WDL ISO file. The QEMU stanza I shared, above, is about as simple as one can get for a test; Quick, easy, and immediate visual answers.

QEMU WDL failure.jpg (12.34 KiB) Viewed 4043 times

My current concern is that if I cannot boot it in a PC, it needs attention on why. If it boots, even in a virtual PC, then I can go to the next step and get the ISO adjusted so that it can be discovered in the same way the current PUPs and DOGs are discovered.

Disregarding the methods, I am trying to find clues in why it has the virtual PC boot problem while all other ISO files do not and merely boot to the distro's desktop?

[wiak]

Hi @wiak

Your share on SG2D
SG2D does NOTHING with an ISO file. It is merely a discoverer; nothing more. It list the ISOs if finds at system boot. The user selects from the list, and it turns the system over to the distro selected.

Yes, I understand that SG2D is simply a 'discover' frontend for grub2, which is why I said that it is best to try booting from iso file directly using grub2 to decide if WDL can boot via grub2 loopback or not. It was as I said not designed to boot with that method so I'd be surprised if it would do so without additional code.

Also, yes I know your later post was not about SGD2 booting but instead about booting the iso via qemu. As I said, I do not have qemu currently installed so I haven't tried that, but I certainly know that can be made to work. I have also not tried booting rockedge's latest iso from cdrom, so do not know if the boot method he is employed is working so I can't comment on that.

I mentioned both your SG2D method and also you qemu matter, which may have confused you into imagining I didn't realise they were separate raised issues, but I do know that. The main reason I posted was to notify you that I had quickly tested SG2D boot from iso and it didn't work for me with WDL and I am not surprised about that since no specific grub2-related code in WDL for any boot from iso case.

I do know that the WDL_VoidXFCE4 WeeDogLinux rockedge has built does boot correctly in normal frugal install mode (which I did test), so nothing wrong with its use in its designed-for normal frugal install mode at all.

Without having time yet to look into either grub2 boot from iso method, or that alternative qemu virtual machine booting, I cannot confirm any concern about either. I am not as I say concerned per se about the grub2 (or related SG2D) boot from iso possibility since it is not expected by me to work per WDL design - as I said, it might, but that would just be by good fortune rather than design and I think it likely won't without my adding some extra code to the initrd/init specially for a boot from iso scenario (which may turn out to be a simple addition, but may not). That's why I don't want anyone wasting WDL_Void_XFCE4 system development time on booting methodologies, unless they particularly want to possibly waste their time - main thing I feel is to develop/polish the Void XFCE system itself to the extent the developer (rockedge) wishes, and as far as boot from iso possibility is concerned simply notify that that mode has been tested as not working and ask for future inclusion (which is not guaranteed, but might end up being also offered depending on time and complexity).

Yes, thanks for pointing out that the way you normally boot a Puppy in qemu isn't working with WDL - whether that is a bug or not in rockedge's iso creation I cannot say at this stage, but if the iso boots from an actual cdrom then it will also boot from qemu so best to burn to a CD and simply try it and report back. Whether the qemu command used for Puppy and various other Dogs you gave is appropriate for WDL booting I don't myself know at this time.

[wiak]

I am not as I say concerned per se about the grub2 (or related SG2D) boot from iso possibility since it is not expected by me to work per WDL design - as I said, it might, but that would just be by good fortune rather than design and I think it likely won't without my adding some extra code to the initrd/init specially for a boot from iso scenario (which may turn out to be a simple addition, but may not).

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]

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. The limitation is that, for simplicity, a particular LABEL must be used for the partition containing the isos to be booted from in this fashion. Since forum member @Clarity already provided a downloadable SG2D (dd) image for booting various SG2D-compatible distro isos placed on usb stick, which I have tested, I plan to support the LABEL name used in that, which is "SG2DISOS". I believe I can add that much "boot from iso file" compatibility in a few lines of code, but I won't know for sure till I do it of course, so no promises (!) and this is not for rockedge's current WDL_Void-xfce4 release since I don't have time to implement these changes at this moment.

I hasten to add, that WDL remains primarily designed for 'normal' frugal installation, which is what I personally prefer rather than booting straight from an iso file, but hopefully that minor, albeit limited, addition will prove useful to some.

[rockedge]

I think the ISO I supplied for easy frugal install is the the way to go. I experimented with booting. I am not interested in an WDL ISO that will boot as an ISO that much.

I am more about the plug file system and or using the skeleton to make almost any distro into a frugal install-able one

[Grey]

I have run WDL iso in Qemu. Without SG2D, just launched. Works. Well, how does it work... Only the first option with loading into RAM. The second point of course does not work, because w_changes=/mnt/sda1/WDL-live in menu.lst, and there is no sda in Qemu by default.

But something is wrong with the sound. Pulseaudio? For comparison, the sound works in the new indripup.

[rockedge]

@Grey I just heard the Russian government is contemplating giving every one a week off from work to slow down COVID.....I hope all is well and you guys stay OK.

I never added any of the main pulseaudio components...yet........ I did a version with ALSA and the alsa-pulseaudio lib's which worked. The sound doesn't work because it it really isn't installed yet.

I guess today I should try to get it going.....I developed this WDL-Void-xfce4 on a DELL PowerEdge R210 II blade server...there is NO audio devices in it at all and a really simple graphics card (MATOX) so any graphics are only basic and with no sound at all....well the R 210 II is a commercial machine with 2 separate network cards and 9 fans.......I will have to switch over to the Optiplex 990 to see if I can get some sound!

P.S. and the PowerEdge's BIOS/UEFI will not allow booting from any of it's USB ports.

[fredx181]

For who is interested (perhaps @Clarity only ):
It works for me to make direct ISO booting by using SG2D, edited the "init" script in initrd_v401rc1.gz.
Booting ISO with SG2D is the only thing I've tested though, so not sure if it will boot okay when burnt to cd, is "hybrid" ISO and it should also support UEFI boot (which I cannot test btw, too old hardware).
Modified latest share from @rockedge : WDL-Void-xfce4-rc3.iso, size: 423MB
https://drive.google.com/uc?export=down ... eSdyZWcd4g
EDIT: To boot ISO directly with just GRUB2: viewtopic.php?p=39683#p39683

Content of loopback.cfg (which is needed for direct ISO booting) :

Code: Select all

    menuentry "WDL-Void-xfce4-rc3 (X86_64) (RAM)" {
     linux /vmlinuz-5.4.70-rt40 findiso=${iso_path} w_bootfrom=${iso_path} w_changes=RAM0 net.ifnames=0
     initrd /initrd_v401rc1.gz
}

ISO created with xorriso, commands (assuming that the files are in folder "isosource") are:
Required is also package "isolinux" (contains /usr/lib/ISOLINUX/isohdpfx.bin)

Code: Select all

xorriso -dev WDL-Void-xfce4-rc3.iso \
-compliance "iso_9660_level=3:iso_9660_1999" \
-map isosource / \
-boot_image isolinux dir=/  \
-boot_image isolinux system_area=/usr/lib/ISOLINUX/isohdpfx.bin \
-boot_image isolinux partition_table=on \
-boot_image isolinux next \
-boot_image any efi_path=efiboot.img \
-boot_image isolinux partition_entry=gpt_basdat

Modified init (from initrd_v401rc1.gz): init.txt:

init.txt

(10.48 KiB) Downloaded 83 times

Here and there I've added comment "fredx181 - from porteus-boot" (taken some functions from porteus-boot as used in DebianDog)
How it's done is that it locates the full path of the ISO and mount it on /mnt/isoloop, which is finally used as "w_bootfrom" variable.

Fred

[rockedge]

@fredx181 Excellent! Would the init modifications work if put into the w_init file instead of modifying initrd_v401rc1.gz??

That would be really cool. I will give your modified init a test run. Good work Fred.

[fredx181]

Would the init modifications work if put into the w_init file instead of modifying initrd_v401rc1.gz??

Not sure, but quickly looking at it, I don't think so.

[rockedge]

Thanks @fredx181, I also looked and I agree it most likely will not work that way. Looking forward to trying out the ISO you modified which I just finished downloading!

[fredx181]

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.
(set "(hd0,2)" to what it is for you)

Code: Select all

menuentry "WDL-Void-xfce4-rc3.iso in isos" {
insmod part_msdos
insmod ext2
set root=(hd0,2)                                              
set isofile="/isos/WDL-Void-xfce4-rc3.iso"
search --no-floppy --file --set=root $isofile
loopback loop $isofile
linux (loop)/vmlinuz-5.4.70-rt40 w_bootfrom=$isofile w_changes=RAM0 net.ifnames=0
initrd (loop)/initrd_v401rc1.gz
}

[Grey]

a week off from work to slow down COVID.....I hope all is well and you guys stay OK.

Thanks. The people trust only one "medicine" - alcohol. I was already invited to the mentioned week at three places for drinking spirits, but I refused, honestly
The best illustration is on my ZX Spectrum, which was painted by a Polish ZX-artist from Krakow.

The Best Friend of man (and this is not a dog):

[fredx181]

@rockedge Small thing, on line 120 in modified init, there's a "sleep 5" that doesn't belong there (forgot to remove it).

[wiak]

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.

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.

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.

@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!!!

[Clarity]

Nice work from all, here.

Questions is the paragraph following
@fredx181 if SG2D only mission is to find ISOs and present them, as long as they conform to its criterion of folder names he searches, does it matter if his search folder is on the 2nd partition or not? As I understand, SG2D has a range of folders he looks for; namely "BOOTISOS" or "boot-isos" and several others. Am I missing something?

And, for example, in the case of the other boot ISO file helper I have published on the forum (example using Ventoy) where the /BOOTISOS folder is on the 1st Ventoy USB partition, if the SG2D ISO file is selected by the user, when SG2D boots, he will find the /BOOTISOS on the 1st parttion and list the ISOs to the users in exactly the same way he does as if the user booted an SG2D USB. So, this merely shows the flexibility of SG2D to find and present the ISO files, regardless.

Also, if a SG2D CD/DVD version is booted, it will find the ISO files in those mentioned folders on any root drives connected to the system and list for user selection as well.

So, I am merely trying to understand why placement of the boot stanza is important if SG2D is only going to present what is found to the user as long as it meets the requirements that PUPs and DOGS are presenting in their ISO files.

I am sure I am missing something, but, cant quite see it. Maybe the different foldername is suggested for test purposes on the SG2D USB or ...

[wiak]

Clarity,
SG2D does indeed look for a range of possible boot-isos folder names and then exports the name of the folder where it finds them, no matter what partition it is on as far as I could see. SG2D exports the result of its search in variable iso_path. I have no idea what 'findiso' is for. I did a grep for it's use by SG2D a few days ago (since I also saw it sometimes being used) and also in grub2 and found no mention of it in any of their scripts - I thus imagined it must be a variable used in the init script of some distros (but I didn't see where it was actually internally used at all in Porteus initrd either by the way). Anyway, I may be wrong and findiso variable may be needed for WDL using Porteus iso file search, and won't cause any harm whether really needed or not.

What really annoys me when it comes to SG2D is that it only exports the iso_path (e.g. /BOOTISOS/name_of_iso.iso). For some daft reason it does not also export the device (e.g. /mnt/sdb2) it found it on (yet SG2D must have found that info too - just didn't export it!!!!). Had SG2D also have exported the device name there would have been no need for the complex search device code of the sort also used in both Porteus init and in Puppy init, because once the device/path location of the iso is known it is a simple matter of loop mounting it for use - that much is really simple to implement, as I said already.

Anyway, I will only be including search by partition LABEL method in main WDL initrd release - short and simple partition LABEL search code has been in WDL init for a long time. As long as you give the partition the special LABEL name of SG2DISOS (which is what I noted you used in your dd SG2D image download) and put the future WDL iso in any of the many optional SG2D folder name locations (e.g. BOOTISOS, boot-isos, and so on) it will be found and loop mounted for use as I said some pages back. I can implement that in half a dozen simple lines of code inside WDL initrd/init. Grub2 (with or without SG2D) will also be able to boot from iso files stored similarly. Hopefully that simple 'solution' will be all you actually need. Of course you can use Porteus boot search code if you really want to, and I'll also make that available but as a standalone plugin only for individual use - it won't be published in any official WDL iso release of my own since that would break license conditions as I commented. Also I hope no one publishes WDL isos containing Porteus or Puppy GPL code mixed in with MIT-licensed WDL script code since as I said GPL licensing does not allow that (it's not WeeDog that has the restriction, it is the GPL, which is why I hate GPL generally).

So at least I wash my hands of responsibility should anyone publish mixed MIT/GPL code. WeeDog is MIT-licensed, which is a very permissive license. GPL licensed code is not permissive so publish such combined works at your own risk! I have no intention of making WeeDog license less permissive and will thus not formally incorporate less permissive code directly into it. You can publish plugins of any license you wish as long as the plugin itself does not mix code that has incompatible licences - however, it is more than dubious if you include such plugins inside a published MIT-licensed WeeDog. I don't make the rules of licenses.

Of course, being unrestricted, my understanding is that no-one can prevent you from forking MIT-licensed code under a less permissive license (such as the GPL). However, I won't be supporting any such fork myself. My WeeDog Linux build system and scripts will remain MIT-licensed.