KLV To-Do List

[rockedge]

This is a topic to post needed fixes and ideas for utilities and tools including improvements to system configuration.

• Really see a need for a utility program with GUI that will manage <filename>.ucimg file system images. Creating and resizing functions as well as full an images is. With perhaps a warning mechanism to notify if the .ucimg file system is close to memory capacity.

• finally finish the save.sh and merge.shscripts for use in RAM0 mode as a "save on demand" feature.

[rockedge]

Looking at the Rox options window and comparing the F96-CE version and the KLV version and there is a difference!

They are not the same version and the KLV Rox options box is the top one in the screenshot. The panel (obsolete) field had "default" entered which when removed also removed the entry in the the panel file

Screenshot(4).jpg (80.42 KiB) Viewed 13053 times

I altered the KLV (top) options to check radio button pinboard and deleted the default entry.

Question remains why is this option page selections taking place and how to get the newer version in to KLV?

Original topic and post -> viewtopic.php?p=74798#p74798

[wiak]

New Year over. Back to work!

As I said a few days ago I was reminding myself how to boot KLV-Airedale (indeed any FR initrd bootable distros really) using either SG2D or Ventoy.

I would be the first to admit that FirstRib initrd was never designed with iso booting in mind (its absolute main focus being for normal frugal installations). Despite being extremely flexible in terms of usage modes the initrd remains a relatively uncomplicated, fast and code-efficient design in the sense that it generally does not search for any boot files required; rather, the user is expected to manually configure grub (or whatever boot loader used) to tell the FR initrd exactly where the boot components are (e.g. via w_bootfrom UUID or LABEL and w_changes location and so on). Unlike many other distros, autosearch routines were purposively to a large extent avoided because the great flexibility of FR init/w_init would have needed a great deal of extra and complex autosearch code included to cater for all config possibilities. However, owing to demand for FR distros to boot via SG2D I did in the end bow to that pressure, but only to the extent of having an autosearch function for iso files.

A result of that limited autosearch code is that the likes of Ventoy need some special treatment (internal to iso grub configuration) to get the best out of them. Anyway, that is what I have been experimenting with and have both SG2D and Ventoy booting now with the most useful direct saves to persistence and RAM2 save on demand modes without any interaction from the user (they just need to put the iso in appropriate location per usual and select appropriate menu choice on boot).

In practice, per the way rockedge packages KLV-Airedale:

The iso config file boot/grub/menu.lst is used to boot from cdrom using that internal to iso provided menu.lst (i.e. he currently uses grub4dos for that purpose).
The iso config file boot/grub/loopback.cfg is used (per usual) to provide the boot menu for SG2D
The iso config file boot/grub/grub.cfg is used by Ventoy (but included no Ventoy-compatible entries until my alterations below)

I have made some modifications to all of the above (though have left previous entries in place for later experimentation and possible modification or deletion).
In particular I have provided the ability when booting via SG2D or Ventoy of using the FR modes:

a. RAM0 for session changes in RAM only (i.e. no save persistence)
b. RAM2 save on demand mode back to upper_changes folder (or ucimg savefile) in same directory iso is stored (or in subdirectory if symlink manually made to iso).
c. RAM2 save on demand mode back to upper_changes folder in, Clarity suggested, partition with LABEL 'Persistence' and directory 'Sessions'
d. Direct save (not in RAM) back to upper_changes folder (or ucimg savefile) in same directory iso is stored (or in subdirectory if symlink manually made to iso).
e. Direct save (not in RAM) back to upper_changes folder in, Clarity suggested, partition with LABEL 'Persistence' and directory 'Sessions'

No editing of the presented SG2D or Ventoy boot menus will be required to achieve these most useful FR initrd modes. User just needs to put the KLV iso in BOOTISOS (or wherever it is put usually) and boot...

@rockedge, to get these modes all working please make next iso to contain the new entries provided in boot/grub/loopback.cfg (for SG2D) and boot/grub/grub.cfg (for Ventoy) and also the slightly edited boot/grub/menu.lst file. I have attached all of these new versions that will achieve the above once provided in the iso.

Cheers and happy new year, wiak

NOTE: that is probably the best I can do for SG2D and Ventoy without adding lots of auto search code, which is unlikely to happen; however, above is probably sufficient for most usage and is actually pretty effective in my opinion.

[rockedge]

@wiak Happy New Year!

Good stuff, I will add these in today. I made for the how-to I started, an ISO called KLV-Airedale-rc4.2 and within a new rootfs SFS from a QEMU "pseudo full installed" rc4.1 squashed a new rootfs SFS from it's upper_changes. I was able to install cdrtools and with the mkiso and isohybrid copied from Fossapup64 I made the ISO directly in the QEMU virtual machine. Turns out this works really well and the process has somehow made the new rc4.2 work really well in QEMU.

I will call the latest version with the tuned boot components rc5. Yes Will, back to the grindstone!!!!

[wiak]

I will call the latest version with the tuned boot components rc5. Yes Will, back to the grindstone!!!!

Sorry to do this to you Erik, but since the mod to FR initrd to allow Ventoy to boot from iso in either its / directory or in /BOOTISOS on the Ventoy disk was so small I couldn't resist implementing it to get the matter out of the way and finished with.

I have therefore uploaded new Skeleton initrd-latest.gz to owncloud which can per usual be fetched along with matching w_init-latest using the (unchanged) attached get_WDLskelinitrd_latest.sh script

Code: Select all

# initrd/init: simple switch_root init with overlay filesystem set up.
# Copyright William McEwan (wiak) 26 July 2019+; Licence MIT (aka X11 license)
# version="6.0.1"; revision="-rc1" Date: 02 Jan 2023

Important for correct Ventoy operation in KLV is the name of the iso needs updated in boot/grub/grub.cfg. To save you the effort I have already done that in my tests - using name KLV-Airedale-rc6.iso. I have attached the thus fixed and needed grub.cfg, menu.lst and loopback.cfg files to this post for your next rebuild/release... Of course if you choose a different iso name you will need to replace the KLV-Airedale-rc6.iso name I have used in these attached files.

All going well, I don't expect to modify this Skeleton initrd-latest.gz for a long while... fingers crossed.

[Clarity]

In light of this thread's topic,namely "KLV To-Do List", I wonder if its time to add the GRUB2 Utility to the desktop Menu.

Benefit is obvious.

[Sofiya]

I am glad that in my laptop there are 2 boot in (BIOS / UEFI)
And I don't think about these things

[rockedge]

@wiak No worries, glad to get this in rc6.

I recommend changing the wget links in the download script to https.

Something similar to ->

Code: Select all

#!/bin/sh
# Creation Date: 20Jun2020; Revision Date: 02Jan2023
# Copyright wiak (William McEwan) 20Jun2020+; Licence MIT (aka X11 license)
progname="get_WDLskelinitrd.sh"; version="504"; revision="-rc2"
resource=${progname#get_}; resource=${resource%.sh}

case "$1" in
	'--help'|'-h'|'-?') printf "Simply execute this script with command:
./${progname}
to download $resource
to the current directory\n"; exit 0;;
	'--version') printf "$progname ${version}${revision}\n"; exit 0;;
esac

printf "\nPress Enter to download $resource\nor press Ctrl-C to abort download\n" 
read  # Stop here until the Enter key is pressed or Ctrl-C to abort
wget -c https://owncloud.rockedge.org/index.php/s/HRZhsnouSm3Gpf3/download -O modify_initrd_gz.sh && chmod +x modify_initrd_gz.sh
wget -c https://owncloud.rockedge.org/index.php/s/CXixDo8Dd2rtxSQ/download -O initrd-latest.gz
wget -c https://owncloud.rockedge.org/index.php/s/8aFjxy5QrjfyI8o/download -O w_init-latest

exit 0

[rockedge]

@wiak I am have trouble with a kernel panic trying to boot rc6 in QEMU and a runaway QEMU process.

I am trying out the different boot options and so far it appears all of them are failing with the same symptom that the initrd.gz isn't getting the right paths to find the root_fs.

Screenshot(8).jpg (97.32 KiB) Viewed 12893 times

[wiak]

Okay, sorry about that @rockedge. I didn't try qemu boot since only change I made inside initrd/init was to a function that (as far as I understood it) should only be used by Ventoy and SG2D. Perhaps I accidentally edited something else by leaning on keyboard or something... (quite possible). Could you tell me how you are using qemu since that is like booting on a different system, with various possible setups, altogether so might work for me if I use a different set up rather than the one(s) causing trouble?

The find_iso modifications I made should only be getting accessed when the w_bootfrom line being used ends in <name_of_iso>.iso, Hence I didn't feel many other tests were required since I 'thought' every other boot function/method was untouched and thus safe.

I'll try a few qemu tests of my own test iso and report back.

EDIT: @rockedge: with the test new initrd test iso I made myself, I quickly tried:

Code: Select all

qemu-system-x86_64 -boot d -m 2048 -enable-kvm -smp 2  -cdrom KLV-Airedale-rc6.iso

and it booted fine in first menu choice RAM0 mode (/dev/sr0 as w_bootfrom)

[rockedge]

@wiak I swapped in the rc5 initrd.gz and the system works well again.

Here is the QEMU line ->

Code: Select all

/usr/bin/qemu-system-x86_64  -soundhw ac97 -machine accel=kvm -m 4096 -cdrom "/mnt/home/KLV-rc6.iso" -hda "/root/.aqemu/KLV_rc6_HDA.img" -boot once=d,menu=off -net nic -net user -rtc base=localtime -name "KLV-rc6" -cpu host -vnc 192.168.254.13:0 $*

[wiak]

I've opened up my iso and extracted the init (from inside the initrd.gz), w_init, and grub components that I have inside it so that you can compare.

I'll also download latest (and fix the https links in the get script) and rebuild iso using that initrd-latest.gz I published to see if I published the right one!!!

Attachment is an actual tar file of the above components (not including initrd-latest.gz or iso's initrd.gz itself).

[rockedge]

It looks like the files I used match. I am trying out some more things but rc5 is easy to boot so it looks like something with rc6 is broken slightly.

Further testing. continues,,,,,

[wiak]

@wiak I swapped in the rc5 initrd.gz and the system works well again.

Here is the QEMU line ->

Code: Select all

/usr/bin/qemu-system-x86_64  -soundhw ac97 -machine accel=kvm -m 4096 -cdrom "/mnt/home/KLV-rc6.iso" -hda "/root/.aqemu/KLV_rc6_HDA.img" -boot once=d,menu=off -net nic -net user -rtc base=localtime -name "KLV-rc6" -cpu host -vnc 192.168.254.13:0 $*

Okay, I'll try that qemu arrangement best I can and track down the issue, but what is KLV_rc6_HDA.img?

EDIT: Also, do you get a grub4dos menu on booting and if so what menu selection are you using? I don't know your qemu line arrangement so can't test without duplicating whatever you use in that line.

[wiak]

I'm at a bit of a loss @rockedge that the previous initrd would work for you but not the new one when using qemu with -cdrom option.

Am I correct that that uses menu.lst (grub4dos)? There is nothing at all in that menu.lst that will result in the (EDIT) initrd/init function find_bootmnt being called up and the only change I have made to the initrd are very minor and all inside that find_bootmnt function. Qemu -cdrom finds the iso by itself - nothing to do with my initrd function, which is only used by Ventoy and SG2D. But I'd like to try your qemu line but don't know what you have in the .img file and so on so can't.

[rockedge]

@wiak the img file is the virtual HDD. The booted system sees /mnt/sda1. You could probably leave it off.

Let me redo the new /boot/grub files and test again.

[wiak]

@rockedge Okay, I understand you are using aqemu. I installed it and configured (but not using vnc) and the following worked fine for me for my KLV-Airedale-rc5.iso modified and remade as KLV-Airedale-rc6.iso to include the new v601rc1 initrd.gz:

Code: Select all

/usr/bin/qemu-system-x86_64  -soundhw ac97 -machine accel=kvm -m 4096 -cdrom "KLV-Airedale-rc6.iso" -hda "/root/.aqemu/KLV_rc6_HDA.img" -boot once=d,menu=off -net nic -net user -rtc base=localtime -name "KLV-rc6"

I went with menu.lst option RAM2 V-1 and booted fine.

Are you sure when you used FRmake_initrd scripts on the new skeleton initrd that the correct kernel modules were in your root filesystem? I can't think of anything else, the initrd-latest.gz skeleton seems fine to me still thus far.

Since just using the full initrd.gz from rc5 in my tests but modified to use the new internal init and w_init, my test isn't yet based on first downloading and modifying initrd-latest.gz skeleton via FRmake_initrd scripts. i.e. To test more thoroughly I'd have to make final initrd.gz via FRmake_initrd scripts so I'd have to decompress the 07KLV sfs and then build new full initrd.gz. I'm pretty sure the skeleton initrd-latest.gz is okay, but I'd need to do that full test to confirm, which will take me a while. Perhaps you could send me a copy of the new initrd.gz that you built out of the skeleton initrd-latest.gz using FRmake_initrd scripts or even a link to copy of the iso you made I could more reliably help test that?

[rockedge]

Something did not go right with the new initrd build with the script.

I am not sure why not. Something I am overlooking...
@wiak What are the best steps to take to build the new initrd.gz?

[wiak]

So starting with a frugal install of KLV-Airedale-rc5.iso into a folder named KLV, I did:

Code: Select all

unsquashfs 07KLV-airedale_rootfs.sfs

Used click via filemnt to open 00modules_6.0.12-void.sfs

From uncompressed 00modules_6.0.12-void.sfs copied the /usr/lib/modules/6.0.12_1 into squashfs-root/usr/lib/modules

Put copies of FRmake_initrd.sh and FRmake_initrd_dep.sh into KLV frugal install folder and made executable.

Then made new initrd via command:

Code: Select all

./FRmake_initrd.sh latest squashfs-root

which also auto-fetches initrd-latest.gz skeleton initrd.
Then:
Renamed the FRmake... resulting initrd-latestXXX.img to initrd.gz

Then I deleted squashfs-root since not needed in final iso and umounted the 00modules_6.0.12-void.sfs prior to building the iso with:

Code: Select all

cd ..
mkisofs -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat -D -l -R -v -V "KLV-Airedale" -no-emul-boot -boot-load-size 4 -boot-info-table -o "KLV-Airedale-rc4.1.iso" KLV-Airedale-rc6
isohybrid KLV-Airedale-rc6.iso

Finally booted via:

Code: Select all

/usr/bin/qemu-system-x86_64  -soundhw ac97 -machine accel=kvm -m 4096 -cdrom "KLV-Airedale-rc6.iso" -hda "/root/.aqemu/KLV_rc6_HDA.img" -boot once=d,menu=off -net nic -net user -rtc base=localtime -name "KLV-rc6"

and it booted fine.

I used the popped up grub4dos menu choice:

KLV-Airedale-rc6.iso RAM2,LABEL save on demand V-1

Are you sure you copied the appropriate modules for the Void kernel you are using into your root filesystem prior to running FRmake_initrd.sh?

EDIT: @rockedge missed step that I of course also copied the previously attached grub.cfg, menu.lst and loopback.cfg into the KLV/boot/grub folder prior to making the iso

[rockedge]

@wiak Okay! I found a mistake I made so I fixed it and the build went smoothly. All is good and rc6 starts in QEMU quickly.

It looks like I can package the rc6 ISO with the new initrd.gz.

UPDATE: Looking good! Here's the ISO -> viewtopic.php?p=77439#p77439

[wiak]

Though it will probably be a while before I am likely to release any new FR skeleton initrd-latest.gz, assuming no bugs found in current one, I can see issues related to booting of isos and image files that I wish/need to better address eventually. I'm primarily interested by the qemu image or iso boot-from scenario. The issue that remains needing to be addressed is the result of there being a fundamental difference between a 'normal' frugal install and the use of a bootable image (e.g. iso).

As I've said before, FR-based distros were not designed with image booting in mind, so that consideration was not part of the original as-simple-as-possible design, which was intended for normal frugal install only (distro savefolder separation being achieved via distro-names subdirectory). But now that we also wish to be able to boot from bootable image files (such as read-only iso) we get a logical inconsistency in the system arrangements required for both since in original design criteria/expectation the savefolder is put in the frugal install filesystem, but it is of course 'impossible' to write a savefolder into bootable frugal install filesystem image (for example, an iso, which you can think of as an already created, but read-only, frugal install filesystem).

More precisely, there are two factors and associated issues that result from that difference:

1. Normal frugal install is read-writable and can be used to hold the (upper_changes) savefolder. However, a bootable image such as an iso (which can be thought of as an already made frugal install), being read-only, can not be used to hold the (upper_changes) savefolder.
2. Normal FirstRib frugal install achieves distro savefolder (upper_changes) separation via unique per-distro subdirectory name to contain the frugal installation. Most users do not separate bootable image files at all, but instead store them in common directory (e.g. BOOTISOS) hence if you wish to boot one from several stored bootable images some other means of 'separation' (for the likes of their individual upper_changes savefolder) is required to be implemented.

These fundamental differences not only complicate the initrd coding requirement (since has to treat normal subdir-separated frugal installation with different, sometimes complex, code for the case of read-only non-separated bootable image frugal installation), but also has potentially similar effects on any system/user utility maintenance scripts (such as for savefolder maintenance, or management rollback session changes filesystems).

It is a nonsense to ever suggest that the likes of Ventoy or any other find and boot iso/image system in any way itself makes an 'iso-boot' identical in functionality/flexibility as 'normal' frugal install - as I say, there are in fact fundamental differences between normal frugal and bootable image frugal: the bootable image being a read-only filesystem, and having major difference also that users store isos in 'same' directory whereas normal frugal installs are separated into own subdirectories. FIxing these differences (when reasonably possible) involves considerable, often very complex, initrd coding work (and more, since can also effect many system utilities), so anyone who claims otherwise is clearly not appreciating the actual difference and complex/developer-time-consuming coding issues involved to appropriately re-code the initrd and many related system utilities to allow for both types of boot.

I.e. whilst both being forms of frugal install, they are fundamentally different in practice, and no, simple sticking of a single config file in the frugal install root directory (or wherever) that says where to find the save folder does not at all address these fundamental frugal install boot type differences. In fact there is no significant difference between using a grub kernel line argument to define savefolder location (i.e. w_changes=blahblahblah) and a text config file (containing the words w_changes=blahblahblahj) to do the same thing or take precedence. Certainly there is nothing wrong with having such a config file mechanism; it is neither innovative nor unusual to employ such a mechanism when it proves useful; for example to provide a default configuration or to take precedence over grub kernel line provided config arguments (indeed FR initrd has always had that savefolder-location config-savefilemarker/and-more ability via its w_plugin files). However, that is irrelevant really since it is actually internal to initrd/init code complexity that remains required to address the differences between normal frugal install and image-contained frugal install that takes a great deal of work - a config file alone is no more than a piece of information - the code to use that information is the issue - it has to take into account the existing FR initrd/init logic and not mess it up... but it is not the save location that is difficult - it is that fundamental difference between normal frugal install read-write nature and bootimage read-only nature that demands special treatment.

Anyway, I am still considering these fundamental differences and working on alternative ways to properly address them. Basically, if you want boot types of frugal install (normal and bootable image) it would be best to force consistency in structure. However, that is not going to be possible since it is inconvenient on the whole to store bootable images in their own separate (from other isos) subdirectories. The fact one type of frugal install media is read-write and the other read-only means the likes of runtime changeable files should not (in terms of operation consistency) be stored inside the frugal installation, but having to store upper_changes somewhere different would generally be a terrible inconvenience also thus not reasonably avoided. Overall, my priority will continue to be normal frugal install, since a bootable image can always easily be converted into that form (so that is best in my opinion actually), but yes, nice and convenient to be able to boot directly from image, but certainly has some limitations at present particularly if wanting to boot between several FR distro images.

If I thus accept read-only frugal installs (image files) as a special case then the easiest 'workaround' is that the special code needed (or extended) in the FR initrd/init treats boot-images as somewhat different than normal frugal installs in that the upper_changes savefolder will either need a per-distro savefolder name (which I don't like) or will be put into its own subdirectory for use only by its relevant separate FR-based distro. I actually don't like that much either since means boot isos getting handled differently in initrd/init code from normal frugal installs, which adds bloat and complexity to the initrd/init logic and also to utility maintenance scripts. The most recent initrd works fine, using one KLV distro iso, with for example qemu or Ventoy, but, assuming save persistence wanted for all, wouldn't work satisfactorily if two FR-based distros amongst the isos since no mechanism is currently provided to allow them convenient automatic access to their own separate upper_changes savefolders. Normal frugal installs always work fine, no matter how many FR-based distro installs are being used since they each all have their own unique upper_changes savefolder (in the separate frugal install subdirectory).

This is a thread for developers mainly of course, so users who are not also developers don't need to understand or bother about any of the above, though they will find some things that work with normal to-media frugal installations won't work with multiple bootable image boots. These rambles are just part of my thinking... being recorded for me to re-read and re-think later really so don't worry about them.

[wiak]

Per link below, I am currently experimenting with new boot/grub/menu.lst stanzas specially for more convenient qemu/KLV boot options, so had made a new test version of rc7.2 iso with the alterations inside it, and then rebooted that via qemu:

https://forum.puppylinux.com/viewtopic. ... 680#p78680

[wiak]

@rockedge:

Here are the boot/grub/{grub.cfg, loopback.cfg, and menu.lst} files for inclusion in next KLV-Airedale iso release (perhaps next release will be rc8?).

NOTE WELL: You now only have a small job to do for each new iso creation release with these files. In EACH of these three files, each time you make a new release you must remember to edit them and change line (near the top of each file):

set release=<release_number>

For example, for next release (possibly the last for a while?) probably will be:

Code: Select all

set release=rc8

or whatever you make it. NOTE: Nothing else in these files will need changed; no more search/replace required - it is all now done with simple grub config variables.

These work like a charm for me (albeit in minimum testing - was quite a bit of work putting them together and testing some of it - certainly ready for testing though and maybe all okay if lucky...).

That, for me would be end for now of needing to do further config work for using Ventoy, SG2D or Qemu; I believe the provision, via these files is now pretty good. I have little doubt more could be done using grub2 (especially) scripting, but that can be looked into later in the future.

NOTE ALSO: To understand what to expect using these grub config files for Ventoy, SG2D and Qemu, please read my explanation posts here:

https://forum.puppylinux.com/viewtopic. ... 680#p78680
https://forum.puppylinux.com/viewtopic. ... 691#p78691

[rockedge]

@wiak I am starting to assemble rc8!

maybe we can make a yad GUI for @Clarity 's KVM detector script It will go in as command line as it is. I think Grub4Dos could get some refinement as what it generates when it detects a KLV which it does (sees it as a full install). That will be in the future since it is most efficient and accurate to run wd_grubconfig and copy & paste the results into the Grub4Dos created menu.lst overwriting what is in it.

[wiak]

@wiak I am starting to assemble rc8!

maybe we can make a yad GUI for @Clarity 's KVM detector script It will go in as command line as it is. I think Grub4Dos could get some refinement as what it generates when it detects a KLV which it does (sees it as a full install). That will be in the future since it is most efficient and accurate to run wd_grubconfig and copy & paste the results into the Grub4Dos created menu.lst overwriting what is in it.

Just make sure to use the above attached menu.lst without any modification other than to change release version in (near top of each of menu.lst, grub.cfg and loopback.cfg):

Code: Select all

set release=rc8

It is specially configured to work well booting from iso with Qemu. To boot from normal frugal install made to a hda qemu disk is different of course and we should confer on that to see what is likely to be best.

Have you any suggestions for extra menu.lst item for Qemu to boot normal frugal installs to the likes of a qcow2 Linux partitioned image file? I actually hadn't been considering the normal frugal install in qemu image disk at time I modified menu.lst. I could look at any you think would be useful and suggest if alternative formats if any I think better.

You can of course add some extra menu.lst items for such purpose if you wish at this stage to test normal frugal installation configs - good to use grub variables similarly to what I have done for these boot from iso cases (i.e. where variable content is the likes of %release% when grub4dos, and in grub2 more like normal shell being $release or ${release}). I'm not sure what you mean when you say grub4dos sees it as a full install?

I'm not sure what is the point of Clarity's KVM detector script being put in KLV-AIredale (though I'm fine with it being there - its a tiny script) since KLV-AIredale comes with kvm loaded and ready so just testing something that will always be true there surely? Different in the likes of radky FP when kvm-intel and kvm-amd are not loaded by default?

[wiak]

I used to use zram a lot on my old laptop so worth thinking about its set up again.

@dancytron posted some useful set up scripts the debiandogs use: https://www.forum.puppylinux.com/viewto ... d1c#p78549

[wiak]

Still thinking about Qemu boot procedure for normal frugal install on qemu image disk. Am I correct in thinking I remember you posted something about how you do it in some earlier post @rockedge? I wouldn't know where to look to find that old post. Do you recall what you did or where you posted that info. I'd like to see how you configure it all so I can think of most useful extra menu.lst stanzas.

[rockedge]

@wiak I set up the virtual HDD (qcow2) using GParted once I have the ISO booted then run Grub4Dos on it.
After running wd_grubconfig I modify the menu.lst to this:

Code: Select all

# menu.lst produced by grub4dosconfig-v1.9.4
color white/blue black/cyan white/black cyan/black
#splashimage=/splash.xpm
timeout 10
default 0

#####menu.lst (note the LABEL or UUID options below):

title KLV-Airedale-rc7.2 (LABEL)
  find --set-root --ignore-floppies /KLV-AIredale-rc7.2/grub_config.txt
  kernel /KLV-Airedale-rc7.2/vmlinuz w_bootfrom=LABEL=klvsys=/KLV-Airedale-rc7.2 net.ifnames=0
  initrd /KLV-Airedale-rc7.2/initrd.gz

title KLV-Airedale-rc7.2 (LABEL,RAM2)
  find --set-root --ignore-floppies /KLV-AIredale-rc7.2/grub_config.txt
  kernel /KLV-Airedale-rc7.2/vmlinuz w_bootfrom=LABEL=klvsys=/KLV-Airedale-rc7.2 w_changes=RAM2 net.ifnames=0
  initrd /KLV-Airedale-rc7.2/initrd.gz

title KLV-Airedale-rc7.2 (LABEL,RAM0)
  find --set-root --ignore-floppies /KLV-AIredale-rc7.2/grub_config.txt
  kernel /KLV-Airedale-rc7.2/vmlinuz w_bootfrom=LABEL=klvsys=/KLV-Airedale-rc7.2 w_changes=RAM0 net.ifnames=0
  initrd /KLV-Airedale-rc7.2/initrd.gz

#############################OR uuid method:

title KLV-AIredale-rc7.2 (UUID)
  find --set-root uuid () c8dcb6c3-a6bb-44b1-a139-ed5283706b56
  kernel /KLV-Airedale-rc7.2/vmlinuz w_bootfrom=UUID=c8dcb6c3-a6bb-44b1-a139-ed5283706b56=/KLV-Airedale-rc7.2 net.ifnames=0
  initrd /KLV-Airedale-rc7.2/initrd.gz

title KLV-Airedale-rc7.2 (UUID,RAM2)
  find --set-root uuid () c8dcb6c3-a6bb-44b1-a139-ed5283706b56
  kernel /KLV-Airedale-rc7.2/vmlinuz w_bootfrom=UUID=c8dcb6c3-a6bb-44b1-a139-ed5283706b56=/KLV-Airedale-rc7.2 w_changes=RAM2 net.ifnames=0
  initrd /KLV-Airedale-rc7.2/initrd.gz

# Advanced Menu
title Advanced menu
  configfile /menu-advanced.lst
  commandline

I install on the VM HDD just like any bare metal HDD:

Virtual Hard Drive structure

Screenshot.png (30.71 KiB) Viewed 12371 times

Frugal installs work exactly the same on the VM as with the physical bare metal machines and I set it all up by booting KLV in RAM0 from the ISO. This also has the WDL-Live directory for session saves from ISO boots.

I will test out naming a partition as "Persistence" and give that a test next. We can leave the kvmcheck script out for now. It isn't really needed in KLV.

[wiak]

@wiak I set up the virtual HDD (qcow2) using GParted once I have the ISO booted then run Grub4Dos on it.

That's what I thought you'd be doing. I note that grub4dosconfig Shinobar script is included in KLV so I guess you use that (EDIT: oh, I see now from your menu.lst above that is what you use). When you think about it, users have to go to all the trouble of making the likes of Ventoy or SG2D bootable disks when it is no less technically difficult to simply make a bootable grub4dos or even grub2 disk (or qemu image), which is simpler, smaller, and more versatile altogether IMO. Yes, if you have already gone to the trouble of making a Ventory disk (and managed that) then the result isn't bad, but for the most part it is even easier to simply use Qemu to boot an iso albeit with more resource consumed. Normal frugal install is hard to beat really; second easiest for many distros is full install despite so many speaking against that despite it being by far the easiest to regularly upgrade kernel and glibc and so on. In many ways I actually prefer full install for my main distro (despite being the creator of FR initrd, which is great for making frugal installations) and run my experimental and very versatile frugal installed distros under the likes of Qemu (my computer has plenty resources nowadays).

Would be nice to have a simple utility for installing grub2 similarly, something like part of frugalpup that is available in Fossapup (and the newer radky FP).

I really like booting distros in Qemu using that kind of mechanism, though Qemu iso booting is certainly very easy for general users and newcomers.

I also think RAM0 mode is sufficient for all of this so I kind think of anything extra I'd want in the menu.lst stanza I sent you for inclusion in next iso boot/grub/menu.lst (or indeed for the grub.cfg and loopback.cfg).

Some users would probably benefit from brief tutorial on using grub4dos (or grub2 if we had utility) for creating bootable qemu qcow2 images of KLV (and any other frugal installed distros).

[Clarity]

... Would be nice to have a simple utility for installing grub2 similarly, something like part of frugalpup that is available in Fossapup (and the newer radky FP)...

Would @shinobar's GRUB2utility be what you'd want? or maybe add GRUB2 utils package.