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

[wiak]

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 I do find ability to run well under qemu more important by far than booting from an iso file via grub2 and so on, so I do plan to experiment with that more since not having been my focus it is likely that facility could be usefully improved. In fact I haven't been using qemu much at all (though did try it out once under WDL_Arch64), but, specially for development work, I do think it is a very important resource. 'Importance' is a very subjective concept of course and priorities and interests tend to change for all of us, so really main issue becomes the fact that there is never enough time in the day and a continual barrage of interesting avenues for exploration. I have a 'bad' and regular habit of quickly stashing links I've come across for something I wish to learn more about into my Cherrytree notepad (in very disorganised fashion). Later I come across the links, which I've often not even annotated to tell me what they are about. Main result is information overload to which I react by going out for a coffee... I think that's another reason I'm fond of 'plugins' for adding new stuff to core code - that way someone else can add new and interesting developments and creations of their own giving me time to drink more coffee. But I'm interested in using qemu too, and I haven't yet checked out what I think might be the best ways to install WDL systems for use with that (probably not iso).

Positive note, however, is that I'm ahead of what was my earlier 'planning'. I had temporarily withdrawn from WeeDog-related publications (though working on it in the background) and had intended not to release anything concerned with it till around Christmas... But then I played with WDL Manjaro at home and decided it was too interesting to hold onto; didn't have time or energy to publish the new build_weedog_initrd script, but decided a 'skeleton' initrd might be a useful instant publication. Booting from iso files and so on has caught me off-guard a bit, because that is concerned with heavier new development work than I feel like doing right now, so should remain left till Christmas

[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.

Regarding qemu... As a follow-up to the above, I can report just trying to boot rockedge's WDL-Void-xfce4-rc3.iso (I don't know if that's the most recent, but I had downloaded it sometime or other to my hard drive). It booted fine as soon as I ran the command:

Code: Select all

qemu-system-x86_64 -cdrom WDL-Void-xfce4-rc3.iso  -boot order=d  -m 1G -enable-kvm

From a quick look inside the iso, it seems to be getting booted via isolinux chain-loading grub4dos (and thus via a menu.lst). Is that correct @rockedge? There certainly seems to be nothing wrong with the iso in terms of booting it via qemu, though I've only tested it in w_changes=RAM0 w_copy2ram mode. It is the other WDL init modes that really need to be tested when it comes to best ways to use it via qemu. I'd still myself probably go for a frugal install to hard disk qemu image file approach rather than boot thus straight from cdrom (iso file), but until I test further I don't know off the top of my head whether the various other WDL w_changes, and so on, modes will work okay in qemu. I 'should' know just by thinking about it, but my brain is currently in lazy mode.

[Grey]

But I do find ability to run well under qemu

An interesting observation. WDL works in Qemu with virgl 3D driver (OpenGL accelerated rendering). What's so interesting about that ?

The point is that Qemu is "not very friendly" with xfce. ALL distros with xfce that I tried to run with the parameter -device virtio-vga-gl (Qemu>v6.0) or with the parameter -vga virtio (Qemu<v6.0) just hang at the xfce initialization stage. To run such distros - for example MX Linux - you need to use the -vga std parameter and then xfce will not hang.

WDL-Void-xfce4-rc3.iso is the first and only xfce distro to run with the -device virtio-vga-gl option. I don't know how or why yet. But fact is fact:

wdl_virgl.png (188.35 KiB) Viewed 2837 times

[rockedge]

it seems to be getting booted via isolinux chain-loading grub4dos (and thus via a menu.lst)

Yes it does. I am more familiar with GRUB4DOS syntax and I wanted at some point to have a successful boot for morale purposes.

This ISO began as an experiment and for testing out the results. I realize I "might have" mixed licenses when meshing the ISO together but I am not selling the ISO nor am I planning to 'officially' release such a Frankenstein distro. Although that may change as the WDL_Void-xfce4-rc3 improves. Though with the proper licensing that falls in line with the WeeDog(WDL) way.

Step 1 is I wanted to see if I could get the ISO to boot in VirtualBox and on the machine I made it on. The ISO did do that and now I am excited to see if we can get something to boot as an ISO or CD or USB or as my favorite, a "regular" frugal install all from the same ISO.

If I am about to break licensing rules please tell me before the Fed's arrive at my door.

Most important to me is a community making the thing, watch it work and make it a useful basic distro.

[wiak]

This ISO began as an experiment and for testing out the results. I realize I "might have" mixed licenses when meshing the ISO together but I am not selling the ISO nor am I planning to 'officially' release such a Frankenstein distro. Although that may change as the WDL_Void-xfce4-rc3 improves. Though with the proper licensing that falls in line with the WeeDog(WDL) way.

If I am about to break licensing rules please tell me before the Fed's arrive at my door.

I don't see how or where you mixed any incompatible licenses in your rc3 iso. My concern is with the Porteus search code Fred experimented with in WDL init - the search routines are fine and usefully solve that boot from iso issue (albeit with a lot of extra code complexity) but that can't be included in official WDL init directly since Porteus code is incompatible with WDL permissive MIT license (Porteus is restrictive GPL - can't mix GPL with MIT without the original WDL MIT code being re-licensed as GPL, which won't be happening). Certainly I like all these experiments too (despite the licensing issue) - very informative too. I do feel that making that Porteus search component a plugin at least keeps it separate from a publishing point of view (until used that is - but what individuals use is up to them of course - as long as they don't 'publish' final work or Porteus team would have a right to complain...). Porteus are welcome to use WDL code of course (not that they need it) - its use is non-restrictive (aside from acknowledgement), being MIT licensed, so can be used in the GPL licensed scripts of others (but not that other way round... sigh... not that the 'Feds' worry me either, but a serious project can't ignore licensing restrictions).

[rockedge]

Pressing on, I am going to add the audio components and see how it goes getting sound to work. Then add those lines to the WDL-team PLUG file that makes the distro from the build script.

In most all of my WDL_Void-jwm-rox desktop's I have been using ALSA with a Void Linux kernel and firmware built with the script and PLUG file. With WDL_Void-xfce4-rc3 I will try to see how pulseaudio goes.

@wiak How is the water supply/drainage situation looking over there? Make any headway? Connecticut is enjoying a few nice days of Fall here in October so it must be spring time in NZ.

[wiak]

@wiak How is the water supply/drainage situation looking over there? Make any headway?

I'm currently building a shed for new pump over rain water tank. Alas, still a while till completed and till I have any running water in the house again (I manually currently lug in around 100 litres of siphoned water per day in large plastic containers). Yes, that is restricting my Linux dev time severely right now.

By the way, I've been thinking further on your question regarding could that Porteus search code be put in the external w_init instead. On reflection I actually can't see why not, (nor do I understand the need for "findiso=${iso_path}" - where is variable findiso ever actually used I wonder?; I would have thought simply w_bootfrom=${iso_path} was sufficient) but I've never used grub loopback myself before so maybe I am misunderstanding something about it. It seems to me that for the initrd/init to mount the iso it first needs to mount the partition the iso is being stored on as a file - by that stage it can already therefore read an external w_init and no reason I can think of that that external w_init couldn't include the search code (or as a further external plugin) and iso loopback mounting. Doesn't change the overall issue that GPL script can't be directly sourced into MIT code script since the GPL doesn't allow such usage of its code. Nevertheless if 'experimentors' could use an experimental external w_init for their experiments at least the WDL team could publish the iso without that issue being inside it. It's late here and maybe I am dreaming and loopback stuff needs done inside the initrd; I'll explore the alternative tomorrow if I have time and report my findings. But in any case, I will only myself release an initrd with MIT init script code (but, if it works, including my own LABEL based search loopback implementation).

Regarding sound/audio... though slightly larger to install I personally would always use pulseaudio or similar nowadays - I have no doubt that would work without any effort out-of-the-box once installed via xbps package manager.

[Clarity]

One way of describing "findiso=${iso_path}" is that it identifies where-what the ISO file is for loop mounting for boot.

Ubuntu, Mint, MX have used that method for years. SG2D 'keys' on the loopback.cfg for preparing the list for user selection. When the user selects, the distro's GRUB merely follows the distro's instruction for booting the distro: SG2D is not involved.

Not sure if my description is helpful or provides an answer. But, as Ventoy shows; "there a many ways to skin the cat". In the modern PUP and DOG cases, SG2D is a proven boot method to get users to a desktop quickly eliminating hassles. And, it is a Frugal means without the effort.

So, as has been pointed out, it is great for any new forum users, inexperienced forum users, as well as working for all of us experience users, administrators, and developers.

WDL along with the DOGs have to be a little crafty in their methods for builds, whereas the WoofCE builder has it as a part of the generator. So far, WoofCE PUPs will also remaster an ISO that can be found when placed on the SG2D USB stick with the other PUP-DOG ISO files.

Just some thoughts and hope they are helpful understandings I have.

Lastly, MY ONLY interest in any of the booters is to present ways that aim at reducing the continual user problems in trying to do FRUGALs. They are just to be a method of booting from the ISO's contents. The aim, from my point of view, is what is the easiest way to get to desktop which is what all of user seek. I could care less about the boot tool as I only see that as a PC starter. The boot method offer NO system normal use operations, NO stability, NO subsystems in normal use, nothing....except to allow the distro to get to desktop.

I have been amazed at the many corollary discussions about which tool. All I want is to get to desktop as quickly as possible with little to no effort. This is all that I have been presenting with the community. "Get to desktop and run!"

So far, I have found nothing easier than these methods of download the ISO file and boot it.

[fredx181]

Hi wiak, well, I should have known better about the licence restrictions, I understand that you don't want to include complete chunks from porteus-boot in the init script.
Also, as you said, lots of unneeded code was in the previous init that I shared earlier, so here's a much more simple version (still experimental and contains some code from porteus-boot but pretty much "my way", as far as I understand how most of the code works (line 35-63 (functions), 139, 149 and 162-166)):
EDIT 2021-10-22: Re-attached, didn't find the ISO on ext4, fixed now.
EDIT2: Still, probably finding the ISO on NTFS filesystem won't work, (EDIT: but it does) see viewtopic.php?p=39768#p39768

init.txt

2021-10-22 fixed mistake

(8.73 KiB) Downloaded 67 times

So more compact and changed the function names, It works for me booting ISO with SG2D and from bootable disk with GRUB2 bootloader: viewtopic.php?p=39683#p39683 (IMO the latter is important to work too, not only with SG2D).
Hope it's useful somehow, perhaps as part of the w_init sourced script, as you seem to prefer, of course do as you like with it.

One way of describing "findiso=${iso_path}" is that it identifies where-what the ISO file is for loop mounting for boot.

I think also, it's probably needed for GRUB2 to find vmlinuz and initrd inside the ISO.

EDIT: @rockedge , as @Grey reported, the icon in the system-tray expects pulseaudio installed and won't work, not sure how to fix, perhaps include alsamixer ? ...

Fred

[wiak]

Hi wiak, well, I should have known better about the licence restrictions, I understand that you don't want to include complete chunks from porteus-boot in the init script.
Also, as you said, lots of unneeded code was in the previous init that I shared earlier, so here's a much more simple version (still experimental and contains some code from porteus-boot but pretty much "my way", as far as I understand how most of the code works (line 35-63 (functions), 139, 149 and 162-166)):
init.txt
So more compact and changed the function names, It works for me booting ISO with SG2D and from bootable disk with GRUB2 bootloader

Ok, thanks Fred. I'll examine and think further about how to best utilise your effort with this.

re: findiso argument

I think also, it's probably needed for GRUB2 to find vmlinuz and initrd inside the ISO.

I'll double-check that too. A few days ago, prior to your post using Porteus code, I did try loopback.cfg and got as far as vmlinuz being booted and the initrd/init being found (that was using Clarity's SG2D dd download image). But then it hung apparently unable to then find the main sfs files, so grub2 did find vmlinuz and initrd but then the initrd itself (i.e. by then running linux) was itself unable to see the underlying files in the iso. The initrd/init, by the way, got as far as sourcing the initrd's internal w_init, but could not do the w_copy2ram stuff, nor come to that 'see' the also provided external to initrd (but still inside the iso) w_init. My interpretation of that result was a realisation a linux search for the iso and loop mounting it was all that was still required, which is when I came up with my idea to use the search for LABEL method (since I was aware of blkid search methods and didn't want to bother with the added complexity for the simple gain of being able to loopback boot from an iso). Time will tell.

At a quick glance, your new code looks small enough that I'm more encouraged to keep it in (or as user-optional w_init code if can be made to work there - just the license situation I'll concerned with now that the code addition is small).

[Grey]

Grub2 has essentially become the de facto standard. I believe all efforts should be devoted to solving boot problems with it.

Yes, the "add-ons" above it and the "light versions" are suitable for new users. But they slow down the realization that you will eventually have to use Grub. And this understanding will come. Because "simple" programs are only good as long as there is no difficulty in using them.

[wiak]

Grub2 has essentially become the de facto standard. I believe all efforts should be devoted to solving boot problems with it.

Yes, the "add-ons" above it and the "light versions" are suitable for new users. But they slow down the realization that you will eventually have to use Grub.

Well, there had never been any problem booting WDL using grub2 in its designed-for frugal install modes - most of my machines at home all boot via grub2 (just a couple of old ones have grub4dos bootloaders on them. The only issue being talked about recently is for that very special case of booting from an iso file (no problem booting from a cdrom once image made for that); it's really just an option that some seem to be interested in (particularly Clarity) so it is not really a WDL priority to put a lot of dev effort or time into that special case - still if it can be made to work without too much complexity (and within license restrictions of 'borrowed' search for iso code) then that is all well and good of course.

Fred's more recent version of that Porteus search is small enough that it is not difficult to work out the overall idea of how to search through the devices - lots of basic ways to do that so shouldn't be too difficult later to write a WDL version since really all such routines do is run blkid, mount devices and look for files - so its just a matter of looping through devices and parsing the outputs of commands like blkid, so I think we can write our own variant of that sometime - using sed, grep or maybe awk - whatever - the overall idea isn't anything to do with Porteus - most distros contain similar code for exactly that purpose I think.

Providing an iso that will boot via syslinux if written to cdrom (or via chainload of grub4dos) doesn't at all prevent a grub2 install being able to boot from the iso file itself. That just requires that the iso contains an appropriate loopback.cfg and the search for iso and loop mount it code in the initrd/init. However, it may be that it is indeed better longterm to actually use grub2 as the boot cdrom method too for the simple reason that grub2 is able to deal with modern EFI and even secure boot machines with appropriate certificate shim - but... no need to worry about that at all really if you already use grub2 on your machine or the usb you will be using - in that case its just a matter of making a normal frugal install, which is really what I do all the time at home. i.e. It is a matter of opinion if making isos is really important nowadays - for Clarity's SG2D type of boot it would be of course, but personally I just install grub2 on my machine (usually via a DebianDog install procedure) and then boot WDL frugal installs via that - I don't worry about including grub2 install routines with WDL itself (call me lazy)... But the boot from iso loopback thing is another matter since it needs support coded into the WDL initrd/init - so it comes down to the decision of whether I care for WDL to support that boot method or not; no problem if the addition is simple of course (and doesn't break anyone else's code's license restrictions).

[fredx181]

Tested some more ISO booting with my init mod, and found that it failed to find the ISO on a Linux filesystem e.g. ext4 (previously tested on FAT32 only).
Re-attached init.txt, fixed mistake on line 52, see :
viewtopic.php?p=39735#p39735

[Grey]

Tested some more ISO booting with my init mod, and found that it failed to find the ISO on a Linux filesystem e.g. ext4 (previously tested on FAT32 only).
Re-attached init.txt, fixed mistake on line 52, see :
viewtopic.php?p=39735#p39735

Good. I just have ext4 only

[wiak]

Tested some more ISO booting with my init mod, and found that it failed to find the ISO on a Linux filesystem e.g. ext4 (previously tested on FAT32 only).
Re-attached init.txt, fixed mistake on line 52, see :
viewtopic.php?p=39735#p39735

Thanks Fred. By the way:

One way of describing "findiso=${iso_path}" is that it identifies where-what the ISO file is for loop mounting for boot.

I think also, it's probably needed for GRUB2 to find vmlinuz and initrd inside the ISO.

I tried your new slimmed down init.txt as the initrd/init by editing your version of the WDL-Void-xfce4-rc3.iso. Just as a test, at the same time I modified its boot/grub/loopback.cfg to:

Code: Select all

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

i.e. I took out: fromiso=${iso_path}

It still booted fine from Clarity's provided SG2D usb stick dd'd image. Haven't tried directly from GRUB2 yet (currently on my old grub4dos machine).

[fredx181]

I took out: fromiso=${iso_path}

Ah, ok, good that it works without it.

Another thing, I see just now, in init mod line 50, probably mounting ntfs won't work that way (no ntfs-3g exist in the initrd AFAIK).

[wiak]

Another thing, I see just now, in init mod line 50, probably mounting ntfs won't work that way (no ntfs-3g exist in the initrd AFAIK).

That's correct. I didn't put it in. Next kernel version is going to include improved ntfs support I've heard? - but yes, could modprobe ntfs-3g also in the init for this boot from iso situation. EDIT: Oh... it's a package not a module isn't it? - uses fuse. So that would need some libs. No it isn't in the initrd then - don't see me doing that one - maybe.

[fredx181]

Another thing, I see just now, in init mod line 50, probably mounting ntfs won't work that way (no ntfs-3g exist in the initrd AFAIK).

That's correct. I didn't put it in. Next kernel version is going to include improved ntfs support I've heard? - but yes, could modprobe ntfs-3g also in the init for this boot from iso situation. EDIT: Oh... it's a package not a module isn't it? - uses fuse. So that would need some libs. No it isn't in the initrd then - don't see me doing that one - maybe.

Yes a binary/package. I tested now booting the ISO from ntfs, with GRUB2 bootloader and it booted fine, can't understand why, since ntfs-3g is not in the initrd (mystery ).
Only thing, the USB (ntfs formatted) couldn't be opened with Thunar, but could fix that with xbps-install ntfs-3g

EDIT: After done some debugging , it seems to me that the ntfs-3g .... command is ignored and at some point switched to else... mount ... (which apparently woks mounting ntfs, but probably read-only) still don't fully understand, I guess because it's part of a loop (scanning devices that are possibly not ready), although it works ok, I'm a bit concerned if the code is correct.

[wiak]

EDIT: After done some debugging , it seems to me that the ntfs-3g .... command is ignored and at some point switched to else... mount ... (which apparently woks mounting ntfs, but probably read-only) still don't fully understand, I guess because it's part of a loop (scanning devices that are possibly not ready), although it works ok, I'm a bit concerned if the code is correct.

NOTE: I'm actually just out of my bed, so haven't actually tested any of the following myself - just glanced at your most recent init.txt code, so my surmises below may be total rubbish...
--------------------------------------

Well, kernel does include basic ntfs support (mainly read-only) of course, so the mount dev command likely just works without ntfs-3g. Regarding:

Code: Select all

	elif [ $fs = ntfs ]; then
	    ntfs-3g /dev/$x /mnt/$x -o noatime,nodiratime,suid,dev,exec,async 2>/dev/null || rmdir /mnt/$x;
	else

seems to me, since ntfs-3g not in the initrd the first part of the command should fail and thus /mnt/$x would get removed, so it shouldn't working??? I'm just wondering if fs is not being found to be type ntfs. If that was the case then the command:

Code: Select all

				else
					mount -n /dev/$x /mnt/$x -o noatime,nodiratime,suid,dev,exec,async 2>/dev/null || { modprobe $fs 2>/dev/null && mount -n /dev/$x /mnt/$x -o noatime,nodiratime,suid,dev,exec,async 2>/dev/null || rmdir /mnt/$x; }

would come into play, and busybox mount is clever enough to mount the filesystem without needing filesystem type and would use standard kernel limited ntfs support.

The mystery to me is why rmdir /mnt/$x didn't occur in the $fs = ntfs choice part, which seems to me would have broken the search. Are you sure ntfs boot wasn't working prior to you adding in that elif [ $fs = ntfs ] choice? And is the 'ntfs' actually being returned as the fs type by:

Code: Select all

fs=`grep -w /dev/$x /tmp/devices | egrep -o ' TYPE=[^ ]+' | cut -d'"' -f2`

You've probably checked it out and fixed it all by now anyway...

[Clarity]

Will drop the next version's ISO file onto the /BOOTISOS folder and test with both ISO file boot solutions presented on the forum. Now that if works, its one issue that can be put in the rear-view mirror. Looking at this WDL as another of the forum's distros whose ISO File boots OOTB for users using the file boot methods for full distro operations.

On the other idea shared (NTFS), YES, as I understand it, Tovalds has embraced the NTFS into the kernal beginning v..15.+. Not sure if it is the full implementation or one modified specific for LInux's security model. I assume the later and I assume MS's own implementation will match such that NTFS will have a universal behavior no matter which OS is using it. (that is more of "a guess" based upon the efforts I have seen over the past 2 years in both camps)

Thanks to each of you as this project's progress. The cooperation and the enlightenment you are sharing is uncanny.

[wiak]

Hi again @fredx181

Further per my above post: viewtopic.php?p=39819#p39819

I have now tested the thoughts I expressed there.
Turns out I have ntfs on this old computer in sda2. Don't have grub2 on the hard drive, but used Clarity's image on a usb stick to test having the WDL iso on ntfs partition in /BOOTISOS there.

So, as I said, since indeed WDL init does not include ntfs-3g I did not see how the following could work, since without ntfs-3g the rmdir /mnt/$x will come into play and boot will not find /mnt/isoloop.

I thus tried it and sure enough the boot failed. I then simply commented out the two lines:

Code: Select all

#	elif [ $fs = ntfs ]; then
#	    ntfs-3g /dev/$x /mnt/$x -o noatime,nodiratime,suid,dev,exec,async 2>/dev/null || rmdir /mnt/$x;

and that means the following will come into play:

Code: Select all

else
  mount -n /dev/$x /mnt/$x -o noatime,nodiratime,suid,dev,exec,async 2>/dev/null || { modprobe $fs 2>/dev/null && mount -n /dev/$x /mnt/$x -o noatime,nodiratime,suid,dev,exec,async 2>/dev/null || rmdir /mnt/$x; }

and, as I thought, that does successfully boot the iso file from ntfs location (via the limited kernel's own ntfs support (busybox mount able to detect fs type so no -t ntfs necessary).

I think that is fine. No need for ntfs-3g in the WDL initrd/init itself. Of course once the OS is running the user quite likely wants access to the ntfs partition and, as you say, should install ntfs-3g with xbps-install ntfs-3g (though won't need that in future kernels, which will have superior ntfs support anyway).

[fredx181]

I thus tried it and sure enough the boot failed. I then simply commented out the two lines:

Code: Select all

# elif [ $fs = ntfs ]; then
# ntfs-3g /dev/$x /mnt/$x -o noatime,nodiratime,suid,dev,exec,async 2>/dev/null || rmdir /mnt/$x;

and that means the following will come into play:
.....

Ok, that's fine then.
Still strange that it booted for me without that change, but must say that I didn't test with SG2D on ntfs (just on ntfs formatted USB with GRUB2).

[wiak]

I thus tried it and sure enough the boot failed. I then simply commented out the two lines:

Code: Select all

# elif [ $fs = ntfs ]; then
# ntfs-3g /dev/$x /mnt/$x -o noatime,nodiratime,suid,dev,exec,async 2>/dev/null || rmdir /mnt/$x;

and that means the following will come into play:
.....

Ok, that's fine then.
Still strange that it booted for me without that change, but must say that I didn't test with SG2D on ntfs (just on ntfs formatted USB with GRUB2).

I'll test again some time, because other things seem a bit strange on reflection and perhaps I made an error in my test. I've had a closer look at the search code and to be honest some of it is a complete mystery to me so I'll have to put in a few debug echo statements to help me understand what exactly it's doing.

any idea why 'locate -e'? I don't see anything about option -e, or is that just a dummy argument in the cut down code? That's the main kind of thing I'm unsure about: what are the values of $1, $2 and the whole $* in the search functions? It certainly boots, but I'm not happy unless I know exactly where the DEV and LPTH values are being generated (and LPATH doesn't even seem to get used).

Oh well, maybe my brain is just in slow mode, but I don't like any mysteries in the code.

In terms of licenses and copyright, truth is, all blkid type search code is pretty similar - just the loop details differ depending on the choice of the scripter really. For example, the following shows similar blkid parsing used in Puppy initrd/init compared to that Porteus main code lines so obviously any re-write ends up pretty similar in these critical lines, along with the loop mounting of course - a loop mount is a loop mount no matter the variable names etc used:

Code: Select all

Porteus initrd/init
dev=`egrep -v 'TYPE="sw|TYPE="LVM|TYPE=".*_raid_member"' /tmp/devices 2>/dev/null | cut -d: -f1 | cut -d/ -f3 | sort | uniq`
fs=`grep -w /dev/$x /tmp/devices | egrep -o ' TYPE=[^ ]+' | cut -d'"' -f2`

Puppy initrd/init
   id) PART="$(blkid | grep "$1" | grep -E "^/dev/$1| LABEL=.$1| UUID=.$1" | cut -f1 -d':' | cut -f3 -d'/')" ;;
   fs) PART="$(blkid | grep -E " TYPE=.${1}" | cut -f1 -d':' | cut -f3 -d'/')" ;;
ONE_FS="$(blkid /dev/${1} | grep -o ' TYPE=.*' | cut -f 2 -d '"')"

It is annoying (tricky and slow) to test code like this since have to keep building an iso!!! Also, it is true that I would be better just testing directly via grub2 than using that SG2D usb. but my old machine itself just boots via grub4dos. However, I can alter SG2D main.cfg to include a few 'normal' grub2 stanza's (I think).

[Clarity]

FYI ONLY
The SG2D author is on GIT. And he 'appears' responsive to posts there. Should there be a need, you might post anything that can help on his GIT for SG2D.

For Ventoy, that author has a forum where post can be made for attention and response.

Hope those resources can also help minimize work and understanding, if needed.

In my travels with these over the past couple years,

• Booting from an SG2D's has a very, very, very high probability that nothing will go wrong booting a modern PUP-DOG ISO file from it.

• Ventoy's methods do work, but sometimes, it fails with some PUPs having questionable failures attempting to boot the ISO file.

Repeating the benefit for the investigations, here, over the past few days:

• Ease to get a test boot in, by merely download and boot

• Reducing user errors if they have built the one-time USB stick, where all future ISO files will be added

• Reliable boot methods to desktop for the PUP-DOGs

• PUP-DOGs booted do behave exactly the same as direct CD/DVD/USB distro builds, with persistence, from ISO/IMG files.

• Frugal is a file structure supporting PUP-DOG operation. The booting directly from ISO file is a Frugal merely using the ISO file as its base: With added security protections because the base layer is an impossible read-only layer protected from user errs.

The file-boot methods intends developer, admin, user productivity.

[fredx181]

....
It certainly boots, but I'm not happy unless I know exactly where the DEV and LPTH values are being generated (and LPATH doesn't even seem to get used).
....

Yes, I have the same feeling, that's the disadvantage of using someone else's code lines.
Sometimes I took code from Stackoverflow, containing complicated e.g. awk or sed commands without understanding, tried to, but got very frustrated.

The LPATH=.... line can be removed, it was part of the code where searching for UUID and LABEL (which is (probably ?)not needed for locating the ISO).
The "-e" (exist) is used as $1 in the srch function so $2 is the ISO name and as far as I understand the $* is in fact "$1 $2".
The code is not very intuitive, I agree. Btw, found another small mistake I made rmdir /mnt/$1 in the vfat fs check part, should be rmdir /mnt/$x

Fred

[Grey]

The SG2D author is on GIT. And he 'appears' responsive to posts there. Should there be a need, you might post anything that can help on his GIT for SG2D.
For Ventoy, that author has a forum where post can be made for attention and response.

This is a fundamentally wrong approach. Puppy Linux developers should not and are not obliged to provide support for some "left-wing" programs and resources. Vice versa. It is the authors of the aforementioned programs who should add new distros to their products.

[wiak]

....
It certainly boots, but I'm not happy unless I know exactly where the DEV and LPTH values are being generated (and LPATH doesn't even seem to get used).
....

Yes, I have the same feeling, that's the disadvantage of using someone else's code lines.
Sometimes I took code from Stackoverflow, containing complicated e.g. awk or sed commands without understanding, tried to, but got very frustrated.

The LPATH=.... line can be removed, it was part of the code where searching for UUID and LABEL (which is (probably ?)not needed for locating the ISO).
The "-e" (exist) is used as $1 in the srch function so $2 is the ISO name and as far as I understand the $* is in fact "$1 $2".
The code is not very intuitive, I agree. Btw, found another small mistake I made rmdir /mnt/$1 in the vfat fs check part, should be rmdir /mnt/$x

Yes, any kind of parsing code can be far from intuitive - even for the person working out the parsing (at least, with complex sed constructions, for example, I often need to hack around for ages till I get it right - bash quoting issues compound the issues of course, and I tend to forget the quoting complexities even after I think I've mastered them...). Yes I do understand $* being all the arguments (and realised that -e was being passed as $1), so it's more I don't know what arguments to expect really (for $2 particularly - meaning where is that originally coming from and does it contain paths and so on, but I'll just use debug echo statements to clear my understanding up). But thanks anyway for all the thus far effort you've put in hacking the code down - that's not easy to do either - we'll get a good solution out of it all in the end I'm sure.

I will also eventually satisfy myself with how it is all working - basically I just need to retry with some debugging statements to find what all the args are received as. I'm in no hurry for final decisions (re: license/copyright issues and whether I'll put in init or maybe can end up in w_init I think) since it is out there in your posts for others to try, and known to basically work.

Like you say, the Porteus functions are designed for a bigger purpose - using blkid parsing to find UUID and LABEL and more too - the need here is much simpler and just that blkid parse, device loop search and mount looking for the iso, followed by its loop mount - and for the moment if the code has some unknown faults it doesn't matter overall since only called up for this special boot from ISO file case in the if then selection.

[rockedge]

homing in on the audio working....

[wiak]

The SG2D author is on GIT. And he 'appears' responsive to posts there. Should there be a need, you might post anything that can help on his GIT for SG2D.
For Ventoy, that author has a forum where post can be made for attention and response.

This is a fundamentally wrong approach. Puppy Linux developers should not and are not obliged to provide support for some "left-wing" programs and resources. Vice versa. It is the authors of the aforementioned programs who should add new distros to their products.

Well actually everything done by everyone in open source published works like all of these are purely voluntary, so there are absolutely no rules about when to contribute or collaborate or otherwise. It really more about available time and interest, and everyone can become a 'developer' depending on their interest and developing skill level. I make no secret of the fact that nowadays, I develop WeeDog Linux primarily because my family uses it for all our in-house computing (personal and business use). That means I definitely include/develop the functionality my family need and use, but no guarantee for the wishes of others. Having said that, I like developing sometimes, and so when I have plenty time available I am happy to develop extra bits and pieces that I don't myself otherwise need. Also, rockedge, for example, is a longtime WDL plugin developer for building Void Linux variants, so I support his efforts best I can (and use his forum facilities).

Actually, because of my above mindset I purposively develop WDL build scripts with as much plugin capability as I can, and particularly with the capability of w_init usually being able to be stored externally from the initrd (iso is a special case though). That way I try to make it easier for others to modify the main components for their own special wishes/needs though of course they also need the Linux skills to implement any such changes. Obviously I also help when I can, since even though I may not have the same needs it is always good to have optional other ways of doing things.

Problem I have at the moment is the issue at home where we have had no running water for weeks. My family are waiting on me to finally remedy that situation so I'm I in danger of getting 'into trouble' suddenly working on WDL dev matters when the taps in the house don't yet work...

Main important WDL-related matter needing continued at the moment is really the development of this new and exciting WeeDog XFCE Void build by rockedge - the boot variants is just a side matter and rockedge fixing up his plugin build is far more important overall right now (the audio he's working on and so on) I think.

[rockedge]

managed to get audio working, pretty much straight forward using

Code: Select all

xbps-install -y alsa-utils ffmpeg apulse pulseaudio

then opened alsamixer in a terminal, increased the master volume setting and for now I am starting pulseaudio manually with:

Code: Select all

pulseaudio --daemonize=yes

Other than getting the volume controls to appear and functions, I have not yet gotten pulseaudio to work by itself.

I added the xbps commands to the plug file.

Also I managed to download and install Clarity's USB image and then booted successfully using fredx181 and wiak's modified WDL-Void-xfce4-rc3 ISO from that USB drive.