WeeDog ISO - An idea

[Clarity]

When first visiting the Ventoy website, one sees that it must download a Ventoy generator. Knowing how Ventoy presents its generator of its bootable, gave me the idea for use in Puppy Linux forum for WeeDog.

To use Ventoy, one must download a Ventoy generator and run the generator to complete a Ventoy.

WeeDog has its own 'generator' in a way of speaking: You must download and run it on a Linux distro for it to serve its purpose.

So I can foresee a WeeDog ISO as a self-contained utility affording the functionality in a standalone that affords what WeeDog does running within some distro...except without a need to go thru the effort.

Comparisons of WeeDog with other subsystems that manage multiple Linux distros: Namely (those used in this forum); Ventoy & SG2D: My Reason is based upon

• a the fact that Ventoy/SG2D supports the booting of multiple different distros. WeeDog supports the building of bootable different distros.

• Ventoy has utilities AND an ISO to create its bootable. WeeDog has merely a Linux utility

BUT ... WeeDog, like Ventoy, "could" be a single ISO that creates the bootable distro a user selects from its list of distros.

I MUST admit, that my limited scripting or programming ('C'/Python/Go...) does not afford actual programming of an app similar to Ventoy, yet I can foresee a WeeDog bootable ISO that does a single function:

• Boot the WeeDog ISO

• Auto-Open a screen for selection of supported distro

• Running WeeDog app to afford a WeeDog build of the selected distro

OR since Ventoy is open source, the Ventoy ISO could have an added function to Weedog distros: It seems that adding a WeeDog ability to a Ventoy ISO could also do what I describe above.

Was thinking of methods to make WeeDog too easy to get a WeeDog'ed distro.

Just some thoughts for some of the creative minds in this forum.

[wiak]

Comparisons of WeeDog with other subsystems that manage multiple Linux distros: Namely (those used in this forum); Ventoy & SG2D: My Reason is based upon

• a the fact that Ventoy/SG2D supports the booting of multiple different distros. WeeDog supports the building of bootable different distros.

• Ventoy has utilities AND an ISO to create its bootable. WeeDog has merely a Linux utility

BUT ... WeeDog, like Ventoy, "could" be a single ISO that creates the bootable distro a user selects from its list of distros.

Whilst I agree that weedogit could be provided and autorun via an iso variant (WDL_GO tiny weedog variant comes to mind), there is a fundamental difference with the like of SG2D and Ventoy. These latter two basically simply find and mount the selected iso and via grub2 trickery boot from that. They do not extract anything physically out of the iso so don't need to arrange storage for that.

The weedogit utility, on the otherhand, could also be crafted such that it found isos (or be told where they are), but the process of then creating a WeeDogged distro is basically to extract the main rootfilesystem components, and the kernel out of the iso and storing it in a frugal install configuration. That requires a suitably formatted and mounted partition and space for the extraction and knowledge of where the grub2 config files are. Currently, after running weedogit.sh, it is up to the user to use blkid to manually adjust the weedogit 'suggested' grub.conf, and up to the user to edit that appropriate grub.conf (or grub.d file) to match the particular system arrangement. Yes, weedogit, does in fact run blkid as a help to the user, but makes no attempt to select which partition UUID is the relevant one. So yes, weedogit.sh, at least, could be automated slightly more. Since it is run from the partition the frugal install is created in, it could auto-find the blkid for that partition, 'but' different systems arrange grub2 configuration differently and I think it would be difficult and potentially dangerous to try and get weedogit to do that last stage of configuring an unknown system's grub. Ventoy and SG2D have none of these problems - SG2D uses its own grub2 (though that is one of its limitations actually). WeeDog would almost have to have Artificial Intelligence to replace the current manual actions of the user that are required.

So, yes, a small WDL distro iso could be produced that autostarted weedogit utility, and weedogit utility, but there would be an awful lot of information required thereafter by weedogit utility to know where the frugal install was to be created, and more besides to know where grub.conf (or sometimes grub.d files - an added complication) were situated - and since normal user wouldn't probably know these answers, then weedogit would have to analyse the system and try and work out all such complexities itself. Really that would be asking too much of it, and truly dangerous since it could mess up not only partitions but also grub2 such that system could thereafter fail to boot at all! I don't want to write off the idea, but really weedogit is a frugal install creator that substitutes in the use of WeeDog's special generic initrd to boot that frugal install, it is not an iso booter... that's the difference. The utility itself could certainly be improved but not fully automated, I feel, in the way Ventoy or SG2D are. But fact is, I wouldn't claim weedogit utility is for a new user or even a non-technical user - some level of experience of making frugal installs manually is almost a pre-requisite; weedogit.sh simply removes a lot of the hard work (being really a scripted version of someone like myself doing it manually - in fact that's how the script was written: first I did the steps manually, and then, line by line copied what I did in a script, so simple really and no Artificial Intelligence involved...

[wiak]

But no sooner than I had made the above post, I had a second thought, which may be more what you mean.

It may be possible (need to think more on it) to create a 'special' WeeDog initrd that included support for finding the rootfilesystem inside an iso and then mounting that as its own main rootfilesystem (and used via the appropriate overlayfs layer). That could likely be made to work, though there are other things required; similar to weedogit utility, the relevant kernel and modules would need to be auto-located and used. I think this is possible though (thanks to Keef, there is already some functionality built into existing weedogit to semi-automate some of that). WeeDog initrd is not only generic in terms of being able to boot many other distro root filesystems, it is also fundamentally designed for ease of modification via its external to initrd w_init component. That w_init optional addon component of WeeDog initrd is actually a modifiable plugin that lies external to the compressed main initrd, and what I am describing is the incorporation of weedogit.sh functionality, as an option, into that generic WDL initrd itself, via w_init alterations. In theory it should thus be possible to include selection of different iso distros at boot time during w_init execution (i.e. that 'special' WDL initrd, incorporating weedogit functionality, effectively providing console menu of available isos stored somewhere on the system), so I think the end result would be what you describe. The grub2 would be the one provided by the WeeDog iso - but I have to think how its grub.conf could in practice be modified as required at boot time, or perhaps at a reboot or iso pre-written to usb stick for booting in a way that leaves it read-writable; certainly some such mechanism should be possible...

EDIT: Actually, it is easier; the grub.conf doesn't need to be altered at all so could simply boot (from iso, or usb stick, or hard drive) into that weedogit w_init functionality and the then being used 'special' WDL initrd would take over, finding, mounting and using the appropriate rootfilesystem and modules from selected distro iso (such as, for example, Zorin or EndeavourOS or even KLV-Airedale or even a to be weedogged Puppy) and all grub2 needs to do is boot the WDL initrd in the first case after which it takes over.

EDIT2: Yes it's an exciting idea with lots going for it, but don't hold your breath - personally I have a lot going on in my life right now. But I do think the above paragraphs is a pretty complete recipe for exactly that auto-weedogit system - just needs scripted; much of that simply being the modification of existing w_init to include weedogit functions, so in that sense may be less work than one might imagine. Certainly, I expect some road-blocks would be encountered on the way to working implementation, but I can already visualise the bulk of the code required - not that any system design is easy.... Overall I feel that the work involved would be much much less than what was needed to create the existing main WDL initrd itself; most of the required code is already in there, and the bulk of the rest is already in weedogit utility. So food for further thought certainly - in many ways the resulting system could be much more powerful than what SG2D or Ventoy offer since it automatically brings with it full frugal install functionality provided in all WDL initrd based distributions (via overlayfs and all the related tools also being developed for KLV-Airedale use), but via mounting the distro iso rather than having to physically extract its components.

[wiak]

One major 'roadblock' is that the first thing that grub boots is the kernel, so that wouldn't by default be the desired distro kernel.

One way of handling that would be to accept a different kernel/modules/firmware combination than the default distro versions. That would be usable though obviously not as upstream intended, but often that doesn't matter.

To use actual distro kernel/modules/firmware; that could be arranged via a reboot, which is a nuisance, but no way I can think of out of that - and it is a complication since the distro kernel, and modules, would need to be physically extracted prior to the reboot - that's not so good/convenient, though could arrange a temporary storage location for exactly these components. Such is life.

[Clarity]

...To use actual distro kernel/modules/firmware; that could be arranged via a reboot, which is a nuisance, but no way I can think of out of that - and it is a complication since the distro kernel, and modules, would need to be physically extracted prior to the reboot - that's not so good/convenient, though could arrange a temporary storage location for exactly these components

Humm...Seems @rufwoof or @stemsee (cant remember which) suggested a distro/distro-addition which boots with an active QEMU feature built-in.

This kind of WeeDog ISO would have what you suggest is needed. Upon desktop, a pre-process 'kicker' for the Virtual Machine you indicate that WeeDog would build in. Upon WeeDog build completion, a mere post-process update to the local drives would complete the user's build.

Of course, if an ISO file is generated, the post-process would not be required as the generated ISO is self contained & bootable without disturbing the local drive.

Again, just an idea for anyone reviewing. And again, its been many years ago that I programmed subsystems before moving to a planner; so I am just throwing ideas out about taking greater advantage of the wonderful thing that WeeDog offers this community, as I lack the skills to building a packaging that we are discussing on this thread. This thread is NOT a request, rather, its a discussion of an idea that, if implemented, could spark a greater use of this builder.

WeeDog is a great builder approach! And is a wonderful understanding as I have watched this go from concept to its current product state.

JUST an idea.

[wiak]

...To use actual distro kernel/modules/firmware; that could be arranged via a reboot, which is a nuisance, but no way I can think of out of that - and it is a complication since the distro kernel, and modules, would need to be physically extracted prior to the reboot - that's not so good/convenient, though could arrange a temporary storage location for exactly these components

Humm...Seems @rufwoof or @stemsee (cant remember which) suggested a distro/distro-addition which boots with an active QEMU feature built-in.

Yes, that's another way of doing things, but nice to avoid the QEMU overhead I feel; ideally it shouldn't be necessary for what you suggest.

[wiak]

In terms of CPU resource overheads involved in running QEMU sessions I do not myself know, so in my immediately above post comment I was referring primarily to RAM resource usage. Not only does booted WeeDog system use RAM, even when idle (at which time it uses hardly any CPU resource), but so does each virtual machine (who also consume negligible CPU when idle). Unless a person actually wants the two machines (the host and the guest) available at the same time I'd want to be able to use a weedogit distro directly rather than via a virtual machine. However there are of course many times/scenarios when running a weedogit distros in virtual machines could be very useful indeed.

[Clarity]

+1
For single purposed WeeDog distro, the amount of RAM including what might be allocated for running the VPC for building, should be of no consequence on any 64bit PC manufactured since the 2006 Manufacturing Standard ("1GB-RAM f/64bit PCs"). And, it appears most users today of both old and new 64bit PCs have much RAM to throw at any of the Linux distros seen in the wild.

But, as you suggest (and I concur) if there is a way to have the requirements set for the WeeDog to do its builds without resorting to creating a VPC that has the machine requirements, it would address results, too.

Thanks @wiak for the insights you expose to us via WeeDogIT!

[wiak]

+1
For single purposed WeeDog distro, the amount of RAM including what might be allocated for running the VPC for building, should be of no consequence on any 64bit PC manufactured since the 2006 Manufacturing Standard ("1GB-RAM f/64bit PCs"). And, it appears most users today of both old and new 64bit PCs have much RAM to throw at any of the Linux distros seen in the wild.

But, as you suggest (and I concur) if there is a way to have the requirements set for the WeeDog to do its builds without resorting to creating a VPC that has the machine requirements, it would address results, too.

Thanks @wiak for the insights you expose to us via WeeDogIT!

Well, this discussion with yourself Clarity certainly has me thinking about later making an implementation of the method I would adopt. I won't actually know if my approach will work until I actually, at least roughly/basically, try it, but at the moment it seems to me I could even take a standard KLV-Airedale release and simply produce a customised w_init file that would take over the boot process and include weedogit functionality; by the way, I like your clever way of writing that weedogit term: WeeDogIT!.