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

[wiak]

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

That's good, but no way do you need both apulse AND pulseaudio (which is actual full pulseaudio - apulse is just a way to allow a pseudo pulseaudio interface for apps that otherwise need pulseaudio). If you go for full pulseaudio (which I would recommend), its possible you are also needing to install alsa-plugins-pulseaudio:

https://docs.voidlinux.org/config/media/pulseaudio.html

For applications which use ALSA directly and don't support PulseAudio, the alsa-plugins-pulseaudio package can make them use PulseAudio through ALSA.

Also, I would install pavucontrol for all the stream selection (inputs/outputs/record/playback) and volume setting facilities that nicely provides. The combination of full pulseaudio with pavucontrol certainly works beautifully for me in WDL_Arch64 and even most Pups have finally moved to using pulseaudio rather than trying to fudge it via apulse.

Not sure if 'troubleshooters' link is up-to-date, but might prove useful still (though you definitely don't need sox application): http://www.troubleshooters.com/linux/vo ... .htm#audio

Though not required for reference at this point, the following seems like quite a nice detailed description/explanation of all the possibilities surrounding Linux Audio Stack more generally: https://venam.nixers.net/blog/unix/2021 ... stack.html

By the way, regarding boot from iso file - I have done nothing myself in that effort up till now aside from testing fredx181 Porteus search mod variants. I'll later think about how best to merge that work into the main builds, once I fully understand/work-out all aspects of how the code is working and to address any possible mix-license issues (the blkid search and parse methodology isn't itself a license issue itself though, since that is what blkid is designed for and every distro using it pretty much similarly). But for now anyone can just use the results of Fred's efforts - a few mysteries about operation of some of it, but certainly works - doesn't effect other boot modes than for those wishing to boot from iso file anyway.

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

But I do kind of agree with your comment Grey. Fact is, I could get grub2 (without SG2D, for example) to successfully boot from an iso file without needing any search for iso function code inside WDL initrd/init. Indeed were it not for Clarity promoting his need for SG2D support, I would have avoided complex blkid parsing altogether. Rather I would have used normal grub2 UUID search that WDL already handles in a different way to fine the device and I would simply have looked for a separate grub2 exported iso_path argument (i.e. set iso_path=/whatever/name_of_iso; export ISO) and on kernel line had something like boot_iso=${iso_part}. In that way both device and path would be found WDL init (the device from the UUID) and so the iso could be loop mounted without needing all that blkid output/mounting/parsing complexity...

Unfortunately, SG2D wouldn't work with that since it expects the OS initrd/init to internally search for the iso - but the daft thing about that is that SG2D autoiso.cfg includes code doing that same search(!) and in loopback section gets the result in variable "device". But it only does an export iso_path and not an export device (seems daft to me)! Seems to me that one line change in SG2D autoiso.cfg (being that export device line) would allow 'device' to be passed to OS initrd/init as a kernel argument (i.e. ${device}, same as ${iso_path}) - maybe I am missing something but seems to me that would work and not need all this extra code in WDL initrd/init anyway!!! Oh well, SG2D has had no dev work on its github site for two years...

I note that Clarity had long discussions with SG2D author two years ago and basically took on task of promoting it... But is it worth the effort here? (I'm not really convinced). As for Ventoy, well that is certainly currently being actively developed (and seems to have mechanism for passing device and path info) so looks far better in practice to me even though Clarity has had less success with it - less success is just a matter of finding why and fixing rather than preferring SG2D.

At least I now do understand the fred-minimised Porteus search code now (I used some debug echos to satisfy my slow brain) and will consider how to merge same or similar blkid search into WDL initrd (despite grub2 booting from iso not actually needing ANY of that). I don't personally believe for a second SG2D will become a dominant boot methodology (nor probably Ventoy, and others will no doubt design similar boot from iso arrangements) - and grub2 can boot from iso file anyway without such complexity. But of course, the likes of SG2D and Ventoy grub2 frontends is for a special put many isos onto one storage device situation and autodetect them all (but pity SG2D doesn't successfully export the autodetected device location after going to the trouble of autodetecting it).

Anyway, this SG2D stuff is somewhat off-topic - we do not really need rockedge's WDL_Void_xfce to boot from isofile - that's a more generic WDL matter and we basically have that sorted out now (though not yet implemented in final decided form). It is useful, for sure, just a pity the likes of SG2D didn't do a better job of providing both the iso path and device info - that's a weakness of SG2D design that WDL (and other distros) are having to address to make it work. I definitely myself prefer a pure grub2 boot solution even though that requires some minor manual configuration prior to the boot being successful - I actually made a decision way back NOT to use blkid parsing to detect WDL boot files since a purpose of WDL design is to keep it as simple to read and understand as possible - no blkid parsing is ever simple to read! Instead, I used a very simple wee command called findfs (which busybox can have) that can find the fs via UUID or LABEL, and that perfectly matched my needs for normal (non-boot-from-isofile) frugal install.

[rockedge]

@wiak I installed both at this stage to compare. I was trying out just pulseaudio and on this old Dell laptop I dug out of the attic, which booted the WDL-Void and runs fantastically, but the sound wouldn't work until I added the ALSA package. As I am playing around with it I am managing to get sound with just pulseaudio (I think!).

Test machine for this round is a:
DELL VOSTRO 1500 build year circa 2008, CELERON M M540 1.8gHz, 1 G RAM, on board analog audio snd_hda_intel

I have tried out several different audio configurations and was at midnight happy that I was playing some YouTube and hearing it. So today I will look to see if I can get the pulseaudio to standalone and start at boot as a --system.

I am running into permissions problems very easily with pulseaudio, user weedog and user root. Works more or less as expected when I start pulseaudio as a daemon manually. I'm looking for the correct spot to start it as a service, but at midnight I was happy any sound was coming out of this machine.

I decided to add all the audio components after repeated failure (perhaps the old machine) to see if I could get sound at all. No worries....I am looking to make it as compact as I can and if pulseaudio continues to cooperate and the plug file recipe works then I'll treat myself to a nice cup of coffee of some good beans roasted by my step daughter in Colorado.

Once the audio is OK and I have the correct init.gz to reflect all the modifications, I'll package it up.

[Clarity]

I think this is misunderstood.

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.

The intent of this post by me was "if WE have problems and need explanation or bug resolution for either of those, it is an option to help US, same as we would if it was a DOG/PUP-only project or any other open-source products. It is NOT a directive, not a request; merely informational.

I agree as @wiak points to, this ISO file booting is 'solved" for the moment. And other important advances are now, current.

[fredx181]

Fact is, I could get grub2 (without SG2D, for example) to successfully boot from an iso file without needing any search for iso function code inside WDL initrd/init. Indeed were it not for Clarity promoting his need for SG2D support, I would have avoided complex blkid parsing altogether. Rather I would have used normal grub2 UUID search that WDL already handles in a different way to fine the device and I would simply have looked for a separate grub2 exported iso_path argument (i.e. set iso_path=/whatever/name_of_iso; export ISO) and on kernel line had something like boot_iso=${iso_part}. In that way both device and path would be found WDL init (the device from the UUID) and so the iso could be loop mounted without needing all that blkid output/mounting/parsing complexity...

Mmm.. that's news to me, I couldn't make WDL ISO booting work with just GRUB2, that's partly the reason I investigated the way with blkid search, I don't understand, how you do exactly ISO boot with GRUB2 ?

[rockedge]

Pretty amazed on how well WDL-Void-xfce4-rc3 runs on this DELL VOSTRO 1500 and it's single core CELERON M M540 1.8gHz and 1 G of RAM (really 818 M available!). @wiak I enable a swap partition with swapon UUID=<uuid of swap partition> and enable pulseaudio --start and can run Firefox's latest version with ease. Do need to be careful though, not opening too many tabs with any weight to them or the RAM goes poof! and the machine locks up needing a hard power off.

weird thing is the 2007-08 VOSTRO 1500 needs alsa-utils to have audio. pulseaudio daemon is running and pavucontrol is working but without alsamixer selecting the audio device pulseaudio will not make any sound. Regardless of setting the default device using ->

Code: Select all

pactl list sink
pactl set-default-sink 0

[Grey]

Now I have 4 sound cards (pci-e, usb, hdmi and built into the motherboard). How do I select the current sound card when using Pulse? ALSA sound Wizard out of business?

[wiak]

Mmm.. that's news to me, I couldn't make WDL ISO booting work with just GRUB2, that's partly the reason I investigated the way with blkid search, I don't understand, how you do exactly ISO boot with GRUB2 ?

@fredx181Okay, just cos I think I can, I will test my idea today, though since just in my head thus far I could definitely be wrong...

Didn't take long - see my immediately next post.

[wiak]

Are you allowed to bet on rockedge Puppy forum? If so I'm collecting payment oh ye of little faith. I'm going to be rich at last!

So: Booting using Grub2 directly (not SG2D) without Porteus search code per what I reckoned I could do in my own brain thoughts:

So I put my variant of rockedge iso onto usbstick that has grub2 for booting - this has alternative WDL initrd/init, which I'll attach for convenience (but remember this is just an experiment to show it can be done directly from grub2 without any Porteus search code).

I put the created iso in folder /BOOTISOS on the usb stick (second partition as it happens), though directory name isn't important. Just used that since already had it from Clarity's image (but I'm not using SG2D for the booting, just grub2). Here is the grub2 config stanza used to boot (substitute in your own UUID of course where the iso file is - will also work with appropriate LABEL rather than UUID - i.e. like normal WDL frugal boot but just that extra w_isopath kernel line addition for boot from iso file):

Code: Select all

menuentry "WDL-Void-xfce4-rc3.iso in isos" {
insmod part_msdos
insmod ext2
set root=(hd1,2)                                              
set isofile="/BOOTISOS/WDL-Void-xfce4-rc3.iso"
search --no-floppy --file --set=root $isofile
loopback loop $isofile
linux (loop)/vmlinuz-5.4.70-rt40 w_isopath=${isofile} w_bootfrom=UUID=5c332b83-1bc5-409b-bf2c-ea1d5f3c28a2=/BOOTISOS w_changes=RAM0 net.ifnames=0
initrd (loop)/initrd_v401rc1.gz
}

All I needed to add to the original WDL initrd/init (just before calling w_init, or actually the same code could be put in w_init instead) is as follows:

Code: Select all

# grub2 boot from iso file (could alternatively be put in w_init)
if [ ! $w_isopath = "" ]; then
	mkdir -p /mnt/iso
	mount -o loop ${bootmnt}${w_isopath} /mnt/iso
	w_bootfrom=/mnt/iso
	mountfrom="${w_bootfrom}"
fi

Simple as pie, as you can see... This was the way I was planning to do it, prior to Fred posting that Porteus search code:
viewtopic.php?p=39619#p39619

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

But this method was for grub2 boot only (since doesn't work with SG2D unless SG2D itself has one mod made to its autoiso.cfg, which is to put in export device immediately prior to export iso_path).

[Grey]

After experimenting with WDL, I installed Pulseaudio in Fossapup. It happens sometimes
viewtopic.php?p=39942#p39942

[wiak]

Now I have 4 sound cards (pci-e, usb, hdmi and built into the motherboard). How do I select the current sound card when using Pulse? ALSA sound Wizard out of business?

I always also install alsa-utils (or whatever distro calls that). Doesn't "alsactl init" allow you to select sound cards? - just wondering, I haven't tried since only have one sound card on my machine.

In fact, for my WDL_Arch64 build plugin, I use pacman to install all of: alsa-utils pulseaudio pavucontrol and pulseaudio-alsa, but some of them may have different package names for other distros of course.

[fredx181]

@fredx181Okay, just cos I think I can, I will test my idea today, though since just in my head thus far I could definitely be wrong...

Didn't take long - see my immediately next post.

Should say that I misunderstood, thought you could boot the ISO somehow without modification of the init.
Anyway, I tested with your init mod with grub2 on ntfs formatted USB and boots fine !
I have WDL-Void-xfce4-rc3.iso on the root of the partition, so used:
.... w_isopath=${isofile} w_bootfrom=UUID=7B7DFBFD27726FA6=/ ....

[wiak]

@fredx181Okay, just cos I think I can, I will test my idea today, though since just in my head thus far I could definitely be wrong...

Didn't take long - see my immediately next post.

Should say that I misunderstood, thought you could boot the ISO somehow without modification of the init.
...

Drat... I don't get paid then.

[wiak]

So I've ended up merging both boot from iso file methods into the new WDL skeleton initrd (i.e. the blkid search for iso file code, and also the more direct grub2 method that can find the iso directly via specified UUID or LABEL). That way both direct grub2 booting will work without any search slowdown, but SG2D and similar will also work without SG2D autoiso.cfg modification. New skeleton initrd under testing now (just finished coding the overall modded init) - will upload it once I'm satisfied it seems to still be working okay for all current designed boot types.

[Grey]

A bunch of sound cards work great in Pulse:
viewtopic.php?p=40003#p40003

[rockedge]

@wiak That is excellent progress.

[wiak]

So I've ended up merging both boot from iso file methods into the new WDL skeleton initrd (i.e. the blkid search for iso file code, and also the more direct grub2 method that can find the iso directly via specified UUID or LABEL). That way both direct grub2 booting will work without any search slowdown, but SG2D and similar will also work without SG2D autoiso.cfg modification. New skeleton initrd under testing now (just finished coding the overall modded init) - will upload it once I'm satisfied it seems to still be working okay for all current designed boot types.

Sorry for the delay. During the merge and testing of the the two boot from iso file methods (using SG2D with blkid partition search or alternative using grub2 directly via UUID or LABEL partition detection) I thought up a slightly better (more consistent) method for direct grub2 kernel line options. Had a bit trouble getting all partition search methods I employed working to my satisfaction (and made many stupid mistakes that lengthened my debug testing - the overall selection logic was doing my head in). Just finished a successful test of main modes. Getting save persistence with SG2D method isn't easy to arrange in code so still to double-check what I can manage with that (no guarantee about that at this stage).
(EDIT) NOTE that WDL initrd/init has always had some very flexible alternative storage location capabilities for changes and/or for sfs addons. That includes various w_changes UUID and LABEL selection methods that 'might' work inside loopback.cfg (for SG2D) - I have not tested these alternative possibilities at all just now (or put them just now in my test loopback.cfg), but time will tell and i wouldn't be surprised if they will work under SG2D boot (nor surprised if they don't since weren't designed with SG2D boot in mind... but were designed with flexibility in mind so may prove useful).
EDIT2: Well, I just tried SG2D boot from WDL iso stored on my hard drive (/mnt/sda2) partition but with kernel w_changes telling it to use save persistence upper_changes on my usb stick /mnt/sdb2 in /WDL/upper_changes, and it worked. So at very least SG2D users will indeed have save persistence mechanism working - plenty other WDL save persistence possibilities - many may work with SG2D too... But some or even many may not - I have doubts about some when bootfrom ends up being a loop mounted iso - also w_changes via UUID or LABEL (though code into the initrd/init) has hardly been tested thus far, if at all (I can't remember). Fact is, there is so much designed in flexibility in the WDL initrd/init that I can't myself work out the logic complexity off the top of my head as to what will work with SG2D (I'm not actually a computer), but the design was pretty robust so I just accept what works when it does... looks promising). In any case, WDL initrd/init is a very open design that encourages tinkering so even if some aspects don't work (that do under normal frugal install) there is always the likelihood that someone particularly interested in the likes of SG2D booting from iso file, who develops or has the developement skills, will provide update code later.

Please make sure that, as far as possible, any contributed code can be used under the WDL initrd/init liberal MIT license (though GPL code remains very useful as exemplar) - alas, that's the GPL restriction effect (for example) that I have to work around. Having said that, blkid parse and search for file in partitions code is used in most all distros and tends to be very similar (with much absolutely in common)... there are only so many ways to:
Run blkid and parse the result to find a list of partitions.
To loop through the resultant partitions list looking for the searched-for file (in bash, inevitably that will usually be done via a for loop 'in partitions list', the parsing will involve cut and grep or maybe sed or maybe awk (no real difference there), and the search will involve:
mounting all the partitions and checking if the searched file exists on any of them. I'm now using my own variant to the fredx181 kindly provided hacked Porteus initrd GPL exemplar anyway (which is somewhat different on purpose in overall detailed loop logic) so I'm happy with that.

Going out just now, but I expect to publish the new skeleton initrd within the next few hours.

[wiak]

Further small delay to upload sorry. No fault to fix yet, per say, but I'm working on loopback.cfg possibilities for SG2D type boot. It is not correct to say or claim that SG2D itself allows save persistence mechanisms to all work without issue - not at all... rather, the initrd/init has to have mechanisms that allow that to work when using SG2D boot mechanism even though the boot location is the read-only loopmount /mnt/iso. Since that is read-only (being an iso file) clearly the initrd/init has to provide special means to indicate changes must go somewhere else. Fortunately, I had already built into the init the mechanism of specifying w_changes location via LABEL or UUID, and that works fine for actual media upper_changes save persistence, or in RAM-only persistence (w_changes=RAM0), but issue is if using w_changes=RAM1 or RAM2 mode:

Both RAM1 and RAM2 modes do put session upper_changes in RAM. However, RAM1 needs access to the previous on media upper_changes because the contents of that get physically copied into that RAM upper_changes during boot. Similarly for RAM2 mode, but there the media stored upper_changes simply gets mounted (read-only) as a layer of the overlayfs. Problem is since w_changes kernel line argument is being used to specify RAM1 or RAM2 it is unable to be used on these occasions to also specify where that previous media upper_changes directory is to be found... All other modes seem to work fine with SG2D but looked like RAM1 and RAM2 modes therefore wouldn't without extra code in the initrd/init and probably a new separate kernel line parameter for specifying the media upper_changes location - i.e. a lot more work... However, despite not knowing anything about SG2D needs and no plans for it, for other reasons I had already made provision for specifying w_changes media location when RAM modes being used... I had forgotten I had done that, and think might work without further coding... But now I need to rebuild the iso again quickly and try with suitable new loopback.cfg, which will take me a while and it is midnight here so may be tomorrow till I know if that mechanism will infact work with SG2D boots (I certainly think it might).

[wiak]

Anyway, the loopback.cfg file I'm currently testing (which does not contain all possible modes) is quite a lengthy one. Looks difficult at first glance, but if you understand WDL w_bootfrom parameters it is actually quite easy to understand the same w_changes boot format strings that can also be used in the SG2D loopback.cfg. Most all of this is tested as in fact working - but not yet rebuilt the iso to check these w_changes plus w_changes1 RAM1 and RAM2 modes, but I'm hopeful the initrd/init code 'seems' to have code lines to handle that (I probably tested them way back, but never used since so don't know how well tested it was - if at all...).

Note that I included UUID search out of interest - that's only usable with SG2D if loopback.cfg in iso specially created for known uuid device. LABEL (given to partition) however is a perfectly easy to apply and useful search mechanism (which in WDL initrd/init does not use the blkid search code function at all). Below will only work with the newest initrd that I'm currently testing. Of course the alternative blkid search mechanism is also now available in the initrd/init and also works.

The 'trick' for RAM1 and RAM2 save persistence modes is the special variable w_changes1 (which, fortunately, was already handled by the earlier initrd/init code - I must have known SG2D issues without even thinking about it - didn't know before that I had the ability to tell the future Just an illustration of WDL init inherent designed-in flexibility really). Anyone working on similar matters for other distros should take these issues into consideration at initrd/init design stage - you will not be sorry. Save persistence direct to original boot media location is the simplest case so no issues likely with that one anyway. Of course, all these init mechanisms are pretty complex logic and I'll be lucky indeed if they do indeed all work used together like this... Else I'll need to fix RAM1 and RAM2 modes at a later stage - at least I know the issue. Back later and with initrd upload.

Code: Select all

loadfont /boot/grub/font.pf2

# https://help.ubuntu.com/community/Grub2/Displays
color_normal=cyan/black
#menu_color_highlight=black/light-gray
menu_color_highlight=yellow/red
menu_color_normal=light-gray/black

menuentry "WDL-Void-xfce4-rc3 - changes RAM0 mode" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes=RAM0 net.ifnames=0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - changes RAM0 mode w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes=RAM0 net.ifnames=0 w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - changes on media/BOOTISOS" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes=LABEL=SG2DISOS=/BOOTISOS net.ifnames=0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes on media/BOOTISOS" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/WDL-Void-xfce4-rc3.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes on media/BOOTISOS w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/WDL-Void-xfce4-rc3.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - changes via named partition (location unreliable)" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes=/mnt/sdb2/WDL net.ifnames=0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - changes via named partition (location unreliable) w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes=/mnt/sda2/WDL net.ifnames=0 w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM0 mode" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/WDL-Void-xfce4-rc3.iso net.ifnames=0 w_changes=RAM0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM0 mode w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/WDL-Void-xfce4-rc3.iso net.ifnames=0 w_changes=RAM0 w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM2 mode" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/WDL-Void-xfce4-rc3.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM2
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM2 mode w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/WDL-Void-xfce4-rc3.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM2 w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM1 mode" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/WDL-Void-xfce4-rc3.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM1
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - LABEL bootfrom - changes RAM1 mode w_copy2ram" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=LABEL=SG2DISOS=/BOOTISOS/WDL-Void-xfce4-rc3.iso net.ifnames=0 w_changes=LABEL=SG2DISOS=/BOOTISOS w_changes1=RAM1 w_copy2ram
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - changes on media/BOOTISOS" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=${iso_path} w_changes==UUID=C836EF5836EF45D2=/BOOTISOS net.ifnames=0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - UUID bootfrom - changes on media/BOOTISOS" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=UUID=5c332b83-1bc5-409b-bf2c-ea1d5f3c28a2=/BOOTISOS/WDL-Void-xfce4-rc3.iso w_changes=UUID=5c332b83-1bc5-409b-bf2c-ea1d5f3c28a2=/BOOTISOS net.ifnames=0
	initrd /initrd_v501rc1.gz
}

menuentry "WDL-Void-xfce4-rc3 - UUID bootfrom - RAM2 changes with ro media/BOOTISOS changes" {
	linux /vmlinuz-5.4.70-rt40 w_bootfrom=UUID=5c332b83-1bc5-409b-bf2c-ea1d5f3c28a2=/BOOTISOS/WDL-Void-xfce4-rc3.iso net.ifnames=0 w_changes=UUID=5c332b83-1bc5-409b-bf2c-ea1d5f3c28a2=/BOOTISOS w_changes1=RAM2
	initrd /initrd_v501rc1.gz
}

menuentry "Shutdown" {
	halt
}

menuentry "Reboot" {
	reboot
}

EDIT: Couldn't resist rebuilding iso and testing above. That w_changes1 facility for alternative location of w_changes was all present right enough, but annoyingly the only part of that code I had never tested was that exact bit for RAM1 and RAM2 operation...

Code: Select all

"altmedia" for upper_changes on other than bootfrom partition

There was a bug in that bit of code (inside the w_init) - simple wrong variable name, but luckily (again) I spotted the bug at once on looking at the code. Rebuilt the iso and have tested above - all modes seem to be working (including now RAM1 and RAM2 w_changes save persistence modes with SG2D booting)... So will take a final look at the code tomorrow and upload once satisfied working. So much to test there may well be other issues but, maybe not...

[wiak]

New skeleton initrd.gz version 501rc1 has now been released. It includes new support (including re-written blkid search for iso code) for booting from any created iso file (either directly via grub2 or via the likes of SG2D). The associated fetch/download script, along with an exemplar loopback.cfg file for testing and more, is available on WeeDogLinux forum here:

https://weedoglinux.rockedge.org/viewto ... p=355#p355

Note that a lot of development time and testing was involved but I haven't had time to test that all remains well with normal frugal install, though should be fine. More testing would certainly be useful overall anyway.

[rockedge]

@wiak I have updated the ISO to include initrd_v501-rc1.gz and the matching w_init. The links in the post to the ISO are updated.

So far my limited boot tests have worked well in QEMU and VirtualBox. Both also worked with persistence once I created a sda1 partition on the virtual hard drives on both virtual machine systems.

Frugal Installs (my favored method) are being tested now and any more testing with different boot methods is appreciated.

[wiak]

@wiak I have updated the ISO to include initrd_v501-rc1.gz and the matching w_init. The links in the post to the ISO are updated.

So far my limited boot tests have worked well in QEMU and VirtualBox. Both also worked with persistence once I created a sda1 partition on the virtual hard drives on both virtual machine systems.

Frugal Installs (my favored method) are being tested now and any more testing with different boot methods is appreciated.

When you say this is working in QEMU or VirtualBox, is that booting it as an iso (using isolinux or what?). Do you know if it is successfully booting from cdrom?

Reason I'm asking is, as you know, I have SG2D booting from isofile on Clarity's set up - just needs that specially configured loopback.cfg included on the iso in /boot/grub/loopback.cfg. But also, I've been looking at Ventoy since some are using that to boot from iso files instead. Trouble is, I have no idea how Ventoy works - in particular I don't see how it passes the iso name up so WDL init can use it... However, despite not understanding its operation (even tho I've tried reading its technical docs) I can get WDL to boot in Ventoy (and even with save persistence) as long as I modify your isolinux.cfg file. Problem with that is, normal iso boot from actual cdrom would not work with what I do for Ventoy - what a conundrum... Anyway, I thought of easy work around: simply create your normal boot from iso entries as you already do, and then add a few similar extra entries with 'Ventoy' in the label (and see below for special Ventoy w_bootfrom format), and they will work for Ventoy case... simple, but works.

So prior to sending you suitable entries could you please let me know what you are now using - be it some grub4dos menu.lst or a isolinux.cfg and I'll then post back with same but appended with the additional entries to for working with Ventoy. SG2D is no problem since that loopback.cfg I posted previously handles that independently.

Oh, just to remind you that there are two ways we know of to boot WDL from a cdrom - one, as you used recently being w_bootfrom=/mnt/sr0 approach, the other being to give the isofile a LABEL and use this form: w_bootfrom=LABEL=WD_SLITAZ32=/

I'm not sure which is best. Probably the /mnt/sr0 is probably okay as long as system always knows the cdrom as /dev/sr0; otherwise the LABEL approach will be more reliable since will determine actual cdrom device name.

Just to let you know anyway, I was able to boot via Ventoy by using an isolinux.cfg entry like this (no cdrom being used here of course since boot being from iso file):

w_bootfrom=/WDL-Void-xfce4-rc3.iso

the initrd/init notices the .iso and then searches for it and works accordingly (but that entry no good for actual cdrom booting - hence my suggesting extra entries particularly for Ventoy).

Truth to tell, I know next to nothing about iso booting. I understand how /mnt/sr0 case works via WDL initrd/init and similarly for that LABEL method above, but that's about it. I simply never use cdrom booting in practice nor boot from iso file myself till recent tests - however, being able to boot from qemu and similar is very important - so nice is can be done as if a cdrom (alternative is to make a normal frugal install build image for qemu, but still cdrom emulation nice too and not requiring additional hard drive imagefile).

Note we previously discussed the boot from iso methods /mnt/sr0 and LABEL around here: viewtopic.php?p=13685#p13685

[rockedge]

@wiak I use LABEL mostly now. I found this to be reliable when experimenting with how to define w_bootfrom= when booting from the ISO as CD-ROM. I had a machine that /mnt/sr0 was /mnt/sr1 so how can I make this system find itself? Using the LABEL was the answer. Right now for the sake of speed while testing I tend to skip defining the LABEL when creating the ISO's, but for any real production release I think using the partition/ISO LABEL will be the best method for the boot stanza to be the most generic.

I will begin to modify the WDL ISO's to have a LABEL name on the next gen of possible releases.

[wiak]

@wiak I use LABEL mostly now. I found this to be reliable when experimenting with how to define w_bootfrom= when booting from the ISO as CD-ROM. I had a machine that /mnt/sr0 was /mnt/sr1 so how can I make this system find itself? Using the LABEL was the answer. Right now for the sake of speed while testing I tend to skip defining the LABEL when creating the ISO's, but for any real production release I think using the partition/ISO LABEL will be the best method for the boot stanza to be the most generic.

I will begin to modify the WDL ISO's to have a LABEL name on the next gen of possible releases.

So also good if you can put a few extra cdrom boot labels that contain entries for Ventoy booting. That just means as well as the LABEL entries, some that simply use the likes of: w_bootfrom=/WDL-Void-xfce4-rc3.iso

and also the loopback.cfg entries of the sort I put in the loopback.cfg download on the skeleton initrd Releases page. Note that the w_changes entries can also use LABEL for Ventoy use for different RAM modes as in loopback.cfg (though loopback.cfg seems to only be used by SG2D so for Ventoy I'm talking about the likes of special extra isolinux.cfg entries for it).

[Clarity]

@rockedge My latest test with RC4 shows it boots identically to desktop on SG2D & QEMU including same status warning messages at ISO start.

• SG2D, merely added the ISO file to /BOOTISOS on the USB and booted the USB on a BIOS PC.

• QEMU via the following terminal command

  Code: Select all

  $ qemu-system-x86_64 -boot d -m 2048 -enable-kvm -hda /mnt/sdg1/KVMstorage/vHDD2.img -hdb /mnt/sdg1/KVMstorage/vPAGEorSWAP.img -cdrom /mnt/sdg1/BOOTISOS/WDL-Void-xfce4-rc4.iso -smp 2 -boot menu=on -cpu host -vga virtio -display sdl,gl=on

Hope this is helpful into to successful booting the RC4

For those who want to use the terminal command 'qemu_gui' to manage your QEMU boot, here's my reference

QEMU WDL via SG2D-within.jpg (16.12 KiB) Viewed 1636 times

[Clarity]

Looking forward to a future WDL release that contains SAMBA OOTB.

Camera footage is maintained on system drive and shared.