Testcases of KLV and F96 forum distros

[Clarity]

Test: QEMU boot of the individual ISO files in a BIOS VM

Environment is a WoofCE "F96" forum distro on a 2012 Intel platform booted pristine with a Chrome PET (@ETP ) and QEMU (@Grey , IIRC; Apologies if named the wrong person)

Code: Select all

# echo "F96 WoofCE PUP"
F96 WoofCE PUP
# uname -r
6.0.12-FP
# echo "QEMU installed from a PET supplied on the forum for FossaPUP64"
QEMU installed from a PET supplied on the forum for FossaPUP64
# qemu-system-x86_64 --version
QEMU emulator version 7.1.50 (v7.1.0-1-g93fac696d2)
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers

QEMU v7.1.50 run with KVM loaded

Code: Select all

# echo "F96 initial test"
F96 initial test
# qemu-system-x86_64 -boot d -m 512 -enable-kvm  -cdrom F96_4-CE_radky6.iso -smp 2 -cpu host -device virtio-vga-gl -usb -device usb-tablet -display sdl,gl=on -device ac97
gl_version 42 - core profile enabled
GLSL feature level 420
#echo "F96 Boots ISO to pristine desktop, runs 'snappy', FirstRUN is setup, clock utility runs to set-time, and browser works without issues."
    o
    o
    o
# echo "KLV initial test"
KLV initial test
# qemu-system-x86_64 -boot d -m 512 -enable-kvm  -cdrom KLV-Airedale-rc6.iso -smp 2 -cpu host -device virtio-vga-gl -usb -device usb-tablet -display sdl,gl=on -device ac97
gl_version 42 - core profile enabled
GLSL feature level 420
#echo "KLV Boots ISO to pristine desktop, runs 'sluggish',, and browser works without issues."
    o
    o

Request for F96:

• Consider adding utilities supplied by @ETP and others from FossaPUP64 Contributions thread; particularly the "Conky Toggle" and others.

Request for KLV:

• Since there is no FirstRUN, should the "Settings" be opened to desktop approx 15-30 seconds after desktop wallpaper emerges?

For example:

KLV Pristine.jpg (71.46 KiB) Viewed 796 times

KLV is sluggish on opening desk programs as reported in the console list above.

[Clarity]

Change the video in QEMU to observe KLV behavior in system performance

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

   Code: Select all

   # qemu-system-x86_64 -enable-kvm -m 2G -vga cirrus -smp 2 -device AC97 -cdrom KLV-Airedale-rc6.iso
   # echo "NO messages from this command...CLEAN BOOT and operations. Desktop looks much better with this QEMU stanza"
   NO message...CLEAN BOOT and operations. Desktop looks much better with this QEMU stanza

   

   KLV Pristine with Cirrus VGA.jpg (21.98 KiB) Viewed 780 times

   .

2. qemu-system-x86_64 -enable-kvm -m 2G -vga virtio -smp 2 -device AC97 -cdrom KLV-Airedale-rc6.iso

   Code: Select all

   # qemu-system-x86_64 -enable-kvm -m 2G -vga virtio -smp 2 -device AC97 -cdrom KLV-Airedale-rc6.iso
   # echo "NO messages from this command...CLEAN BOOT and operations. BUT desktop booted to ONLY 640x480"
   NO messages from this command...CLEAN BOOT and operations. BUT desktop booted to ONLY 640x480

   

   KLV Pristine with VIRTIO video.jpg (58.75 KiB) Viewed 780 times

   .

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

   Code: Select all

   # qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -cdrom KLV-Airedale-rc6.iso
   # echo "NO messages from this command...CLEAN BOOT and operations. Desktop booted is better"
   NO messages from this command...CLEAN BOOT and operations. BUT desktop booted is better

   

   KLV Pristine with STD video.jpg (74.71 KiB) Viewed 780 times

The desktop performance improves to equal F96's behavior using these video options: Preference is 'Cirrus'

[dimkr]

-m 512

That's very low by today's standards, even if you don't use Xfce.

[Clarity]

Test: QEMU boot of the Ventoy USB stick with the ISO files in BOOTISOS in a BIOS VM

Booting the Ventoy USB in a VM exposes issues in booting both distros. The USB's ISO file contents

Folder with ISO files. SAVESPEC renamed to avoid distro handling attempts before USB use.

Ventoy Partition #1.jpg (27.28 KiB) Viewed 717 times

.
Booting each ISO directly from Ventoy screen fails EXCEPT "slacko64". Slacko64 boots without issue to desktop while all other fails either during INIT processing or during distro loading.

The QEMU stanza used is the following:qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -hda /dev/sdc

In QEMU VM, Ventoy file list page 1

Ventoy page 1.jpg (49.2 KiB) Viewed 717 times

In QEMU VM, Ventoy file list page 2

Ventoy page 2.jpg (55.94 KiB) Viewed 717 times

.

After testing each ISO file for boots directly from Ventoy, I then used the SG2D v2.06-b2 to list and boot the ISO files by 1st launching SG2D from the screen shown and then selecting the individual ISO file to review any boot issues. ALL of the distros booted to desktop EXCEPT KLV via SG2D. KLV stuggles via SG2d was a an unexpected surprise as in the past tests I've done on earlier version, this was not the case..

[wiak]

Interesting tests results Clarity. It wasn't a test I expected though. Why would someone use a virtual machine to first boot Ventoy and then use Ventoy to boot KLV? Is that a likely use?

My own test of Ventoy does not involve that extra Ventoy on virtual machine case. Rather I simply boot an actual usb that has Ventoy partition working on it. KLV is put into either the / directory of that ventoy disk or into /BOOTISOS on it. That is what KLV is designed to boot (via Ventoy) with. I haven't thought about what might happen when you effectively simulate that process via virtual machine, but from what you say it doesn't work, but as long as works from normal Ventoy install I am fine with it.

Also I don't know about SG2D via virtual machine. It sounds strange that KLV used to work via that combination but doesn't now. The change made to the initrd for this rc6 release was tiny, but I'll check myself later to see if I can confirm the issue and see what is going on.

EDIT: On reflection, I suppose you use Ventoy and SG2D via virtual machine like qemu because convenient rather than using actual physical Ventoy (or SG2D) usb? Yes I can see that would be a pretty useful combination.

Anyway, definitely interesting to know what works on that configuration too. Pity KLV doesn't like it!

KLV rc6 definitely boots fine from my physical usb Ventoy stick though. I have recently found that the current rc6 initrd is missing some kernel modules needed for some types of boot, perhaps the issue you have come across is to do with that too. If so the issue should vanish once I track down the modules bug, which I am working on right now.

[Clarity]

... Why would someone use a virtual machine to first boot Ventoy and ...

To test the VM behavior of the USB sticks. In the past, they usually (always) mimic bare-metal and sets a level of expectation when booting bare-metal.

Been a VM guy for 4 decades so I have a good understanding of both expectations and behaviors. It give me a chance to compare if the same behaviors exist in bare-metal use of ISO booting. If there is a discrepancy it can lead to some base understanding that needs pursuit.

Expect the results of bare-metal testing to compare; as was noted in my listing of the test cases I've intended for review.

[Clarity]

OK, skipped the SG2D test case for the moment to concentrate on the Ventoy USB stick tested in the QEMU VM and its ISO filess booting on a bare-metal Intel system; circa 2012, IIRC.

The results on bare-metal are basically identical to findings reported. Thus same USB, same ISO files, same results.

Below is the KLV...RC6 screens captured in bare-metal abend during boot. The same patterns found in both Ventoy as well as the SG2D ISO booted from the same USB to launch KLV.
Edit: Having issues with the camera captures. Will upload soon as I can move them from this new camera..

I hope to get time to run the SG2D only USB testcases later, today,

[wiak]

Just to show current KLV rc6 is working well, per se, with Ventoy, I'll demonstrate my booting it. Video I took with my camera is huge so I'll just paste key frames taken from video as it runs and attached below in order.

My set up is that I have Ventoy installed to usb stick (Linux ext4 partition as it happens) and current KLV-Airedale-rc6.iso copied onto that usb stick /BOOTISOS directory. To test save persistence I have a second ext4 formatted usb stick plugged in with LABEL 'Persistence' and that contains directory named 'Sessions'.

Other than that I just boot the machine and it boots per the attached series of images via Ventoy usb stick. Once it reaches the void login and X server screen, KLV-Airedale appears to desktop (I didn't bother attaching image since we know what KLV desktop looks like already!). The demonstration shows that KLV-AIredale-rc6 certainly has no problem booting from Ventoy. That implies your machine has a different issue with KLV-AIredale, not to do with Ventoy, but maybe some module or firmware missing in KLV-Airedale that your machine needs as part of the boot process. Further reports from yourself may reveal what the problem actually is, but from attached test result it appears there is no issue with KLV and Ventoy.

I have another KLV iso in a different location which is why two Ventoy KLV rc6 menu choices appear. As it turns out, I booted the from the iso stored on nvme hard disk by accident, but same images result if taking the other choice except the bootfrom directory is then the usb stick... sorry about that error (can't be bothered making new video to show that).

The save on demand RAM2 to Persistence partition directory Sessions works fine by the way. :Anything I save2flash at this stage is available on next boot and I can also see the Sessions/upper_changes savefolder (in that second usb stick of mine) contains the saved work.

[wiak]

forgot the last image before KLV desktop appears. Not that it matters. Not very clear image, sorry, but you might notice the rdinit=vtoy/vtoy at end of Kernel commandline (if you manage to focus on the tiny text...) indicating Ventoy running this.
Also shows the w_bootfrom being from KLV-Airedale-rc6.iso (the iso location is given as / but /BOOTISOS is auto-searched too then), w_changes=LABEL=Persistence=/Sessions location, and w_changes1=RAM2 mode being used.

[wiak]

Since you say SG2D was working with older releases of KLV, I suspect the current kernel/modules, probably the modules in the current rc6 initrd.gz, are not sufficient for your system whereas previous release that used a different kernel/modules worked for you. I have just built a new initrd.gz for the current Void Linux kernel/modules used in KLV rc6 - perhaps that will end up fixing things for you too. Maybe next major release will be fine for your machine in other words. Time will tell. Certainly I don't think KLV with Ventoy is the problem - that as I demonstrated works fine (on machine that has appropriate modules/firmware/kernel combination for its hardware).