Puppy Linux Discussion Forum

KLV-Airedale-rc7.2
Kennel Linux Void Airedale Release Candidate 7.2 776 MiB download size ↓
KLV-Airedale-rc7.2
SHA1-MD5.txt

Complete system update/upgrade and outfitted with a Void Linux kernel 6.1.4_1

Improved and rebuilt initrd.qz including expanded support for SD cards.

Routine system update/upgrade. And wallpapers from @Sofiya are included, replacing some of the stock xfce4 backgrounds.

@wiak has done work improving the boot system menus and further improvement to the initrd.gz boot mechanisms :

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

starting of the pulseaudio system for any user that is logged in has been fixed and improved. Thanks wiak, Sofiya and fredx181 for the exact steps.

Upgraded to a new version of @fredx181 's save2flash, and set LANG=en_US.UTF-8 in /etc/environment as default localization.

Thanks to @Sofiya for the poorercputemp and Display Control packages that also have been added to desktop.

• Grub4Dos is now included in the System menu. Making KLV-Airedale capable of setting up a boot-able device using GParted and Grub4Dos.

• CUPS starting as a service has been added and is working thanks to @rcrsn51 spotting missing components!

This is constructed from KLV-Airedale-beta27->rc1->rc2->rc3->rc4->rc4.1 and is equipped with a Void Linux kernel version 6.0.12_1 SMP PREEMPT_DYNAMIC constructed with @wiak 's scripts that will extract the Void Linux kernel for KLV. Also has had a system wide upgrade. Uses an initrd.gz based on the FirstRib skeleton initrd.gz constructed by the kernel/module creation script. Firmware SFS is from a woof-CE kernel-kit built huge 6.0.0-1 kernel.

KLV-Airedale-rc5 is just as at home on FAT32, NTFS prtitions as it is running from ext2/3/4 formatted partitions.

Also included is wiak's generate a set of boot stanzas script. fredx181's mksplash has a menu entry and the remaster script is installed.

With the addition of a xfce4 desktop tiling configuration. A tip from wiak for configuring Tiling windows done with the Super (Windows) key and an up, down, left, right, home, pgup, pgdown or end key.

gxmessage in the default rootfs.

save2flash has been expanded to handle persistence on FAT32 and NTFS partitions.
The mksplash GUI utility to create splash notification banners.

The latest initrd.gz brings vFat and NTFS formatted partition support to KLV, allowing persistence on NTFS/vFat systems as well as the usual /ext2/ext3/ext4/swap support.

• included htop, Grub4Dos, CUPS

• created a symlink /root/spot with the target /home/spot

• Auto login cleaned up.

• includes also the logout logic provided by fredx181 gives true mulit-user support.

• replaced loop.cfg to the most recent modifications.

• Debian kernel 6.0.0-3-KLV SMP PREEMPT DYNAMIC is used.

• added gtkhash

Plus the other important improvements contributed by the KLV team.

Added @fredx181's save2flash utility that can be used when KLV is started in RAM2 mode to perform session saves on demand for persistence.
This is similar to PUPMODE13 in Puppy Linux.

fredx181's swap partition enable script includes the latest revisions and also added are the packages

• mime-add-1.0_0.noarch.xbps

• edit-sfs-1.0_0.noarch.xbps

KLV-Airedale-beta25 is able to load squash SFS packages on the fly or during the boot sequence.
Squash files and ISO images can be opened from the file manager and the read the contents.

• can run with rootfs, 01fimware and 00module SFS files as uncompressed directories.

• Also able to load compressed and/or decompressed directories,
  once a 2 digit prefix is added to the file name.

• It is possible to mix using compressed squash files and uncompressed directories.

Also can be downloaded from https://rockedge.org/kernels in ISO->Kennel_Linux->Airedale

I'm kind of in a hurry, but it seemed to me that when I exited there was no request to save or not save the session.
check if possible

Sofiya wrote: ↑Sat Jan 14, 2023 7:27 pm

I'm kind of in a hurry, but it seemed to me that when I exited there was no request to save or not save the session.
check if possible

I am checking it and RAM2 mode is working well for me. RAM0 is working as expected. I do have 2 scripts that can save from RAM0 mode but are not included yet.

Also RAM(null) or "normal" mode is working in both QEMU and on bare metal. Please keep testing!

@wiak Fixed it! Almost ready to upload it. Need to get the wife ice cream......it's a priority

UPDATE : All set and repackaged and ready to download. ISO size is 776 mb

@rockedge could you include 'kvm-check' in the upcoming iteration?

The KLV version of the upcoming guide will reflect its use to help insure easy setup for anyone.

rockedge wrote: ↑Sat Jan 14, 2023 10:46 pm

@wiak Fixed it! Almost ready to upload it. Need to get the wife ice cream......it's a priority

UPDATE : All set and repackaged and ready to download. ISO size is 776 mb

Yep, modules all seem to be there in initrd now, so should boot fine with those using sdcards and probably others that had difficult with older releases.

I've copied the iso to the BOOTISOS folder on my Ventoy usb disk (I don't have SG2D on it). Booted fine from Ventoy alone, so all looks great to me. Also booted from my favourite install, which is normal frugal - looks fine. Will test more and report issues if any. Currently posting from my Ventoy booted iso in fact.

Booted fine in a VM on my rig.

@wiak would you also check to insure that your ISO file boots work EXACTLY the same as your 'normal' frugal. The behavior should be exact no matter normal or SG2D/Ventoy ISO file operations.

Thanks for all the work of EVERYONE helping on KLV. Its polished and friendly.

P.S. I have 4 old 64bit PCs; 3 I use for testings and 1 is my main productive station. Thusly I have a very old BIOS, and 3 old UEFI PCs with the newest as my main which I rarely take down. Each of my PCs behave differently as 2 wont boot a GPT USB and 2 will. All natively boot the 'multi' version of SG2D. For SG2D, I have tested and use both its v2.04 as well as the latest v2.06. I see, its author is active with his attempts at a Youtube explanation of his latest incarnation.

I have a cheap, single 4 port kvm Switch. (This is a hardware box used to connect all 4 PCs to a single keyboard+mouse+video. It allows me to jump from one PC to any other via a keyboard sequence.) The switch has a Ventoy USB and a SG2G USB that I can choose either at boot-time to boot their ISO files.

This post is merely a note of my environment and progress to make testing and use simple for me.

Edit: For those who might decide that a kvm-siwtch is a choice for their use, this info may help

• They come in 2 configurations: 2-port and 4-port

• They units are designed for either VGA or HDMI depending which video monitor you have

• If a VGA model pay attention to your audio connections: eg, my unit is old so it breaks the audio out to the PCs on each leg via audio wires. Newer VGA units send it via USB cable with the keyboard and mouse.

• PAY ATTENTION as some HDMI models do not ship the needed HDMI cables while most do send the cables.

• HDMI unit pricing is all over the map, but capability is the same from cheap models to the business expensive models

Enjoy!

Clarity wrote: ↑Sun Jan 15, 2023 8:44 am

@wiak would you also check to insure that your ISO file boots work EXACTLY the same as your 'normal' frugal. The behavior should be exact no matter normal or SG2D/Ventoy ISO file operations.

KLV boots fine for all of normal frugal install, Ventoy, SG2D, and Qemu. However, since the FirstRIb initrd/init was never designed with any form of iso/image booting in mind (rather being for normal frugal installs), it would be nonsense for me to claim that iso/image booting (in any of its shapes or form) works identically in terms of flexible boot choices for all FR initrd-capable modes.

Definitely, KLV provides more flexibilty for normal frugal installs. Not identical at all under the hood anyway - a normal frugal install is from a read/write directory and hence by default savefolder goes there, but an iso stores the boot files/sfs and so on in read-only storage and so the default savefolder to same location doesn't work. Hence persistence workarounds required when booting from iso, and making that work most DEFINITELY complicated the initrd/init code and thus work load of the developer.

I don't know why the nonsense claim is made that Ventoy/SG2D just boots the same without any extra developer work - that is only true if the developer already did the work to allow the likes of Ventoy and SG2D to work; that was not any wish of original FR initrd/init design and remains very low priority - Qemu booting is much more important from KLV perspective than Ventoy or SG2D, but at least they have been made to work, via extra complex init search-related code and specially configured grub config files, to a useful extent now anyway - but not equal overall to normal frugal installation the FR-initrd-based distros were designed for.

Having said that, Ventoy boot currently provides the three definitely most useful boot modes RAM0 (no persistence), RAM2 (save on demand), and default mode which is direct immediate saves to media stored upper_changes save folder. The abiliity of Ventoy is a direct result of the iso's boot/grub/grub.cfg file being specially set up to provide these modes (Ventoy reads and relies on these grub.cfg stanzas), plus some extra (search-iso-partition) code added to the initrd/init to accommodate/support the likes of Ventoy and SG2D.

I have not finished setting up an optimum boot/grub/loopback.cfg, which is the file SG2D relies on to boot correctly. It will currently boot KLV, but not so conveniently as Ventoy already can - but in future KLV releases I will endeavour to give it equivalent ability to boot in RAM0, RAM2, and direct to media savefolder as already done for Ventoy (including to Persistence/Sessions folder).

SImilarly I have not finished setting up the boot menu config for optimum Qemu needs - that relies on a different grub-related config file the way KLV iso booting has been arranged by rockedge. It is the menu.lst (grub4dos) config file. Currently that is set up with a couple of Qemu-related KLV boot modes (for example, RAM0 mode and also saves to /dev/sda1 qemu image disk) but not yet convenient RAM2 save on demand back to the likes of Persistence/Sessions on a qemu image disk. Can be done at boot time by editing grub menu stanza of course, but that is a pain - better to just have the options provided in the menu.lst that will work without further user input. I will arrange that additional Qemu boot choice support for future KLV releases. I should add however, that if KLV is arranged to be a normal frugal install inside a Qemu disk image then it just works like a normal frugal install, which is how I personally prefer overall to use it with Qemu (not as a cdrom iso image).

Note that other forum distros, such as Puppy and Debian Dogs, contain various auto-search routines that make booting from iso easier, but that adds a lot of extra and complex code to their initrd/init. Whilst FR initrd/init provides at least as much flexibility and functionality in terms of its layered filesystem arrangement abilities (and sfs or uncompressed addon layer filesystem types) and various RAM savefolder modes, and where these can be stored, it remains very important to me that the FR initrd/init remains generic for use with most any distro and contains relatively simple, efficient and easy to read code, primarily intended for normal frugal boot. Certainly, as is being demonstrated, it 'can' absolutely boot isos, but needs to be told where to find them via these grub-related files stored in the iso.

wiak wrote: ↑Sun Jan 15, 2023 10:55 am

KLV boots fine for all of normal frugal install, Ventoy, SG2D, and Qemu.

Yes, I agree that attention has been paid, thus far. And my experience ( and yours too) demonstrate that as you say.

I was only asking as over the past months, couple members and I have seen KLV hit couple of boot snags as it matures from release to release. I do, though, believe that the behavior of the ISO should behave with the same elements as one see in the 'normal' use such that no matter how a member chooses to boot, they/we will achieve the same behavior in all of its glory.

Having followed the workings it is great that we have these varied ways as they support developmenters, testers, users new and experienced no matter which boot methods suits them for the achievements we need and use.

Thanks again as I, personally,know the superhuman effort you have given! Your explanations are appreciated.

Note that aside from my comments in above post, I don't plan to do more concerning Ventoy and SG2D. They work well enough for my needs - good for a quick iso boot test. I doubt I'd use them for anything else. Just as simple for me to make a normal frugal install really. Qemu is a bit of a different matter. As I say, that is very useful to me too. Actually my own history is that I used virtual machines in a big way in the (more than ten years ago) past for work and research - networks of them - albeit usually using mix of vmware and user-mode-linux. So expect nothing further to be added to FRinitrd/init by myself concerned with Ventoy or SG2D - that matter is concluded aside from the grub config files I'll recommend to rockedge for their use.

Hopefully what results will be found useful by everybody no matter their usual boot practices. And of course FR initrd/init plus w_init combination allows for user contributed special-purpose code anyway - w_init, in particular, is a basically a user-modifiable boot plugin that includes code to call up other plugins as and when designed and wanted.

Here is KLV-Airedale-rc7.2 running on QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6) in F96_4-radky6-CE.
I also ran @Clarity KVM detector script before starting qemu which loaded the KVM-intel module allowing the use of a virtual 8 core CPU.

qemu-system-x86_64  -smp 8 -soundhw ac97 -vga std -machine accel=kvm -m 4096 -full-screen -cdrom "/mnt/home/KLV-Airedale-rc7.2.iso" -hda "/root/.aqemu/KLV_rc7_HDA.img" -boot once=d,menu=off -net nic -net user -rtc base=localtime -name "KLV-rc7.2" -vnc 192.168.254.13:0 -cpu host $*

Probably worth mentioning that KLV-Airedale comes with qemu installed and also with klv enabled by default (according to lsmod | grep kvm on my system at least).

As for FP radky distro. I booted that this morning (after download to my Ventoy usb) and note that qemu not installed on it and even once installed kvm module needed to be modprobe loaded. I have to say, on this my first attempt, I haven't been successful at getting qemu (ver 4.2 from package manager) to work per my expectations. It says "vncserver loaded" or some such but no virtual machine pops up (I was trying to load KLV-Airedale in qemu). I didn't want to use vncclient to view the result - I just want it to pop up on my desktop without vncclient being needed. How to accomplish that?

I remember Clarity posting a couple of qemu commands recently - one including vga cirrus and the other vga std with different wallpaper backgrounds appearing. I was looking for the post but can't find it.

I'm worried in case I somehow deleted it yesterday, but surely not...? I deleted a very small post of my own that was no longer relevant (not to do with qemu) since KLV iso had since been fixed. Then I got a message (via PM surprisingly) that asked "Are you sure" with a 'yes' button. I just pressed the button since I was sure I wanted my small post deleted. Hopefully nothing to do with me not finding Clarity test report post today (though I can't remember which KLV release Clarity post was in...).

By the way, in reqard to my above post I have to say I find it frustrating not getting qemu to work in FP radky - I think that process needs to be made simple for new users. I am not a new user. Qemu is certainly very easy to use from KLV-Airedale and with kvm accel available out-of-the-box.

@wiak That's the wierd thing....I noticed also that still during last October, that when I started KLV with a qemu gui it would open directly a window on the desktop. Now I can't seem to get that feature to return. I read somewhere that there is a dependency on a package not installed because now QEMU always starts in a VNC server mode. But I am using the same set up almost exactly as before and I do not understand what changed. I know I did not purposely turn off the display of the virtual machine opening automatically on the desktop using an internal vnc client.

But it is. It would be interesting to find out what suddenly changed or what lib's need to be installed to use it again. The options are there on AQEMU but I notice that I can not select from desktop to VNC and that it defaults to VNC.
maybe it's an electron application or QT5.

The KLV team believes that a real world usage strong point of KLV-Airedale is it's abilities as a virtual machine host platform.

Also the security aspects of distro running itself in a virtual machine environment has its use as an Internet gateway .

Getting QEMU to work on F96_4-radyXX is tricky. I did it a few times now using the PPM and or Pkg2.

Pkg did the better job of getting the dependencies. Not one of those few had the same results. But I found out the kernel has a lot to do with success running qemu.

You may have noticed that I attempt to post the QEMU stanzas so that anyone can merely type the stanza in a terminal of a PC that has QEMU installed and "should" experience the exact results I see. In other words, the VM should be exactly the same no matter the processor (Intel/AMD). These are the 2 primary stanzas I test; they differ in their video cards.

qemu-system-x86_64 -enable-kvm -m 2G -vga cirrus -smp 2 -device AC97 -cdrom KLV-Airedale-rc7.iso
qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -cdrom KLV-Airedale-rc7.iso

which yields 2 different desktops.

If one of these runs into getting to the forum distro's desktop, I try the other. If both fail, I know that the distro will NOT boot baremnetal on any of my PCs.

For testing the VEntoy OR the SG2D USB sticks in the VM, I use

qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -device AC97 -hda /dev/sdg
qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -device AC97 -hda /dev/sdb

One of these is the Ventoy USB while the other is the SG2D USB stick. These are pretty good indicators of what to expect when booting either USBs baremetal.

All methods yield sound via the host.

Interesting, @dimkr 'wayland' Vanilla v10..138 requires the cirrus stanza to get to desktop with all of its glory; namely video and audio working without issues. For me this is a recent improvement as this distro matures.

Hope you might find these methods useful.

I can't figure out what is required of me?

> qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -cdrom KLV-Airedale-rc6.1.iso
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize kvm: No such file or directory

Sofiya wrote: ↑Mon Jan 16, 2023 7:10 am

I can't figure out what is required of me?

> qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -cdrom KLV-Airedale-rc6.1.iso
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize kvm: No such file or directory

I couldn't myself get qemu to work properly when using radky Fossapup host. Works great using KLV-Airedale host (and can use radky FP as a guest). If you are using radky FP as the host system though, maybe someone knows how to set up qemu without needing to use vnc to access the qemu boot? Qemu support on radky FP really needs to work flawlessly and easily, especially since Pups attract newcomers to Linux too.

Clarity wrote: ↑Sun Jan 15, 2023 11:28 pm

You may have noticed that I attempt to post the QEMU stanzas so that anyone can merely type the stanza in a terminal of a PC that has QEMU installed and "should" experience the exact results I see. In other words, the VM should be exactly the same no matter the processor (Intel/AMD). These are the 2 primary stanzas I test; they differ in their video cards.

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2G -vga cirrus -smp 2 -device AC97 -cdrom KLV-Airedale-rc7.iso
qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -cdrom KLV-Airedale-rc7.iso

which yields 2 different desktops.

Thanks, Clarity. Do you happen to have any good tips for making hard disk images which can also be used via -hda option? For example qcow2 and so on. Is it just a matter of using qemu-img command?
Partial answer to my own question; this worked for me: https://serverfault.com/questions/73141 ... nux-server
I was able to load it with -hda filename.qcow2 and then use gparted on it as /mnt/sda. I am (planning to) give it a Linux ext4 format and a label 'Persistence' and then creating a 'Sessions' folder in it for my boot experiments. EDIT: That worked great for my purposes. I'll discuss in next post and document more fully at a later stage.

qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -cdrom KLV-Airedale-rc7.iso
-vga std --- is a standard video card that does not support large screen resolutions

Follow on from my almost immediately above post...

Having created qcow2 image file (I made it 1GB in size) using command:

qemu-img create -f qcow2 KLV-Airedale.qcow2 1G

and partitioned it into two equal halves (so to become qemu sda1 and sda2) I then booted KLV in qemu with option -hda KLV-Airedale.qcow2 and, using gparted (in the qemu booted KLV), formatted the resultant sda1 with ext4 format and gave the partition the LABEL 'Persistence'. Then I mounted the result using wd_mount sda1 and made a directory named 'Sessions' in it (that latter step isn't actually necessary - the directory Sessions would be made automatically in the Persistence partition when qemu re-booted into, for example, save on demand RAM2 mode).

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 (from my Zorin lite OS host system) using command:

EDIT:

qemu-system-x86_64 -enable-kvm -m 2G -vga cirrus -smp 2 -device AC97 -cdrom KLV-Airedale-rc7.2.iso -hda KLV-Airedale.qcow2 -boot once=d

Not sure of these command options as yet, but worked anyway.

When the boot NEW-to-come boot menu appeared I had new option:

KLV-Airedale-rc7.2 (RAM2 save on demand to Persistence/Sessions)

which I used.

Once booted, I made a new test file:

touch just_a_test_file

and being in RAM2 save on demand mode, saved that to persistence using command, in qemu-booted KLV:

save2flash

which worked fine. i.e. The changes were save to Persistence partition, directory Sessions. Actually I arranged things slightly better. Since I didn't want upper_changes to appear in 'Sessions' directory directly, but instead in a KLV-Airedale subdirectory of that (since will be booting more than one FR-based distro and so need to keep their different upper_changes savefolders separate) in the menu.lst I had purposively used construct:

w_changes=LABEL=Persistence=/Sessions/KLV-Airedale-<revision_number> w_changes1=RAM2

EDIT: In the final release this will be replaced using grub variables, for convenience, to take the form:
(EDIT2: Actually opted to use grub variables for savepart=Persistence and savedir=Sessions too, so easier for developer to quickly change location if desired).

w_changes=LABEL=Persistence=/Sessions/${distroname}-${release} w_changes1=RAM2

where at top of each grub config file I simply have:

set distname=KLV-Airedale
set revision=rc7.2

which, in my tests seems to be working well. In practice, I'll probably use grub variables for partition name and save location directory too. There is a lot that could be done further using grub (specially grub2 programming constructs, which is much like shell scripting).

The result of that was that FR initrd/init automatically made the folder /Sessions/KLV-Airedale/upper_changes inside that 'Persistence' partition! That is an important consideration for developers like @rockedge to keep in mind since it is probably going to be best to always place upper_changes in a subdirectory named after the iso in order to effect separation - not essential per se for normal frugal installs since they are usually placed into the whole frugal install is generally in its own subdir, but when we write utilities to process upper_changes folders it is best they will also work in iso-booted installs, such as Ventoy, SG2D and Qemu; i.e. best to be consistent in utility approach to upper_changes location so will work in all these boot types. Main FR initrd works fine with either arrangement.

All good. The save on demand mechanism worked out-of-the-box.

Similarly, I have new menu.lst options for direct save to Persistence/Sessions/KLV-Airedale, and more besides.

These new user-friendly menu options for Ventoy, SG2D and qemu, will be available for next iso release.

My view is that general users, and even new users are likely to only need the following main KLV boot mode options:

RAM0, which provides no persistence
RAM2, which provides save on demand persistence (similar to Pupmode 13), and
direct (immediate) to/from savefolder reads/writes

Thus I am planning to provide all of these most useful likeliest to be useful modes by default to those booting via Ventoy, SG2D, or Qemu. That provision involves no alterations at all to the FR initrd - they are simply arranged via these iso-included boot/grub/{grub.cfg, loopback.cfg, menu.lst files}. Once all working (which they already are in my new test iso) that is likely to be all I will automate for Ventoy, SG2D and Qemu booting, but any other mode are only very rarely used anyway and generally only by developers or expert users who have no difficulty making normal frugal installations, and/or opening up iso and modifying the boot/grub scripts themselves. Of course all such grub config files can also be manually edited at boot time, but I am trying to make that unnecessary for most use-cases.

Once of the great things about using Qemu like this is that you can even test latest KLV releases inside the older one you are using without needing to commit to it, yet still be able to test most all the newer facilities inside the VM booted version.

I see a lot of value in what you are doing. It 'should' make KLV simple in both concept and use to any user.

I take note, also, to your HOUSEKEEPING approach as this creates a tidy and easy to locate and understand for new and experienced users of KLV.

Very insightful information provided in your post, above.

Thanks for the clear explanation.

I ask:

• When time is permitting, could you also post results of the 'tree' command of the drive labeled "Persistence"?

Not urgent, just curious

Hi @rockedge
As I understand that "kvmcheck" will be a part of the upcoming version, I ask if you would consider (not required, though) a small addition demo'd earlier; namely the "tldr" command-package as it accents the "man" command providing worthy examples of commands and products used in KLV.

Looking forward to the next version-release.

Clarity wrote: ↑Mon Jan 16, 2023 10:11 am

• When time is permitting, could you also post results of the 'tree' command of the drive labeled "Persistence"?

Not urgent, just curious

No need for 'tree' command report.
The Persistence partition, per above use, simply contains the directory structure:

/Sessions/KLV-Airedale-<revision_number>/upper_changes

Should a different FirstRib-based distro be booted similarly - e.g. a different iso such as Kennel Linux Arch (named, say, KLA), then its upper_changes savefolder would be found under /Sessions/KLA/ subdirectory of the Persistence partition, and so on for other such FR-based distros.

The user actually only needs to create the Persistence LABEL on the partition they want their KLV-Airedale to automatically store its savefolders. The /Sessions/KLV-Airedale/upper_changes subdirectories would all be created automatically by KLV's FR initrd as soon as the system boots in either RAM2 save on demand mode (when the new grub configs I'm testing are later used), or in direct writes to drive mode (this latter direct saves to upper_changes savefolder mode being the default when no w_changes option is specified on grub config kernel line). I designed that part of the FR initrd/w_init code specially for that convenience to automatically be available without the user needing to know how to do it (they do need to know how to label a partition with name 'Persistence' though, but if you are going to use gparted, that is a simple matter anyway).

The Persistence/Sessions house-keeping choice was a mirror of what you posted you were using Clarity. DIdn't really matter what they were called, but good to be consistent and especially important from developer's point of view also when writing utilities that manage the system structure in any way.

EDIT: Please note that above facility is currently under test so not in current iso, but will be available for next release. As I said, it is a minimal addition involving only the grub configs provided in the iso - the FR initrd isn't itself affected nor the overall distro rootfilesystem or other parts of the build. Also, there isn't isn't any reason against other partition/folder names being used for savefolder storage except that to use alternatives you would have to manually edit the grub boot stanzas appropriately during boot, or uncompress the iso, make the change you want to the directory names in the grub stanzas, and then re-make the iso. In fact the latter isn't actually difficult to do - a simple script utility could be easily created to provide that facility. However, as I said, consistency in naming is itself important for other reasons - particularly since it makes writing other utility scripts that manage savefolders easier to write and maintain.
I expect to send @rockedge a copy of the new grub configs within the next day or two for inclusion in next release. Would be tomorrow, but I want to experiment with grub2 variables in case that helps simplify the build work rockedge needs to do each time new iso is build (each iso having different rc release number in their name).

I'm not myself planning to add anything further for a while; the initrd seems to be pretty rock solid and efficient and no new features for that are planned since it is doing all I really want it to do at present.

Clarity wrote: ↑Mon Jan 16, 2023 10:20 am

Hi @rockedge
As I understand that "kvmcheck" will be a part of the upcoming version, I ask if you would consider (not required, though) a small addition demo'd earlier; namely the "tldr" command-package as it accents the "man" command providing worthy examples of commands and products used in KLV.

I would have thought that is pretty large addition since it covers all languages? I may be wrong, but if a large extra would be best user installs themselves if they want it. Fact is anyone using any kind of 'man' page, even simplified tldr, is likely only using commands like that if relatively experienced with commandline usage and thus can easily install their own extras(?).
Important therefore to indicate the size of the extra tldr package once installed so it can be considered carefully.

wiak wrote: ↑Mon Jan 16, 2023 10:52 pm

Important therefore to indicate the size of the extra tldr package once installed so it can be considered carefully.

Good point. I am not sure how best to measure a terminal command size for any x86 use. But, 'tldr' is a terminal command that members may/may-not know of it and it benefit in a Linux terminal where everyone knows the 'man' terminal command.

How does one measure the man command, for example? And if reasonable, how to measure its value to community users?

I am not sure, but is it worth consideration?I leave that decision to you developers.

thanks

Clarity wrote: ↑Sun Jan 15, 2023 11:28 pm

For testing the VEntoy OR the SG2D USB sticks in the VM, I use

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -device AC97 -hda /dev/sdg

Important to note, Clarity, whilst above method will basically work for testing SG2D booting via Qemu with KLV-Airedale releases, it does NOT work with Ventoy booting (Ventoy physical usb stick will boot from Qemu, but the resulting Ventoy in Qemu will not successfully boot KLV-Airedale) for complicated reasons concerned with how Ventoy and KLV work together.

HOWEVER, actually booting KLV from a physical Ventoy usb stick booting from bare metal does work, which is the real point of course. Moral of the story is, do not use Qemu booting of Ventoy to test Ventoy booting of KLV - that won't work. Instead test Ventoy booting of KLV-Airedale from actual boot of physical computer with Ventoy usb stick, which has worked for several releases now. In fact you may find some other distros you do not think can be booted via Ventoy directly, in fact can be - but not if you use Qemu to first boot Ventoy (which is basically a simulation of physical computer boot).

For example latest FP radky also boots fine from actual Ventoy boot, as does old FossaDog64, but neither boot successfully from Ventoy first being run under Qemu - I'd avoid that kind of Qemu test use in future in other words - boot the actual computer with Ventoy usbstick instead to get correct successful boot in Ventoy result.

hell yeah, it works for me! The one who doesn't give up wins
Launched KLV_airedale 6.1 on KLV-Airedale. Yes Yes

You all forgot to mention the most important thing. For a virtual machine to work on your PC, you need to enable virtualization in BIOS.
Intel Virtualization Technology

The "Intel Virtualization Technology" technology in the BIOS is already enabled by default (this happens rarely);

qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -M pc -device AC97 -cdrom KLV-Airedale-rc6.1.iso

Sofiya wrote: ↑Tue Jan 17, 2023 9:19 am

You all forgot to mention the most important thing. For a virtual machine to work on your PC, you need to enable virtualization in BIOS.
Intel Virtualization Technology

hell, yeah, very true!

Yes Yes Yes works great
works better with this one, I mean with " -vga cirrus "
there is sound, there is a network

https://forum.puppylinux.com/viewtopic. ... 781#p78781

qemu-system-x86_64 -enable-kvm -m 2G -vga cirrus -smp 2 -M pc -device AC97 -cdrom F96_4-CE_radky6.iso

Thanks for posting that stanza!

You now have 2 PCs working on a single box! Both running at PC's native speed. And you can run more, should you choose.

Enjoy!