Testing KLV-Airedale-sr14 for Save and Boot Performance

[rockedge]

@wiak, @fredx181, @Sofiya, @geo_c

I have repackaged the KLV-Airedale-sr14 ISO with the save2flash-1.9_0.noarch update included.

Also for existing KLV's save2flash-1.9_0.noarch.xbps is available to update the save2flash/snapmergepuppy scripts.

[geo_c]

Also for existing KLV's save2flash-1.9_0.noarch.xbps is available to update the save2flash/snapmergepuppy scripts.

Since this an xbps package, to install I would have to source it locally, and do a local install with rindex and all that, correct? Which I can do by the way. Just a little rusty on it, but it's probably time to brush up.

[rockedge]

@geo_c Installation of a local package can be done using OctoXBPS or even easier is download the .xbps open up the download directory with Thunar (can be done by clicking on the download in Firefox also) and click on it. Should install that way.

Or a right-click there is a an install xbps package option. Or use the install script directly /usr/local/bin/inst-xbps

[Clarity]

Preliminary - Bare-metal later.
All 3 VM environments launch SR14 to desktop ... rapidly. Can be replicated using these terminal commands:

Code: Select all

# qemu-system-x86_64 -name "KLVA vSR14 ISO file in VM" -enable-kvm -smp 2 -m 2048 -vga std -device AC97 -net nic -net user -rtc base=localtime -boot order=d -cdrom KLV-Airedale-sr14.iso 
# qemu-system-x86_64 -name "Ventoy launch KLVA vSR14 ISO file in VM" -enable-kvm -smp 2 -m 2048 -vga std -device AC97 -net nic -net user -rtc base=localtime -hda /dev/sdc
# qemu-system-x86_64 -name "SG2D launch KLVA vSR14 ISO file in VM" -enable-kvm -smp 2 -m 2048 -vga std -device AC97 -net nic -net user -rtc base=localtime  -hda /dev/sdc
===> where "/dev/sdc" is a USB

sdc1 for Ventoy USB OR sdc2 for SG2D's USB

Ventoy - SG2D USB disk.jpg (9.46 KiB) Viewed 741 times

Boots, runs, and shutdowns without any observed issues from either launch.

[Clarity]

Bare-Metal Results: SAME behavior as seen in the VM environments via Ventoy and SG2D launches.

[Clarity]

Total time to download to USB, shutdown the host BKWP64 PC and reboot to launch in bare-metal via the USB to desktop was 2min-37sec . with greatest amount of time spent downloading the ISO file.

This is even faster when booting in a VM as I do NOT need to wait for a shutdown, POST restart and SR14 Menu default to see a SR14 desktop.

Thanks for all of the contributions to this distro set that you developers are presenting for our benefit

BTW: At no time, did I touch the keyboard after ISO file selection. The KLVA did all the work on its own to arrive to its desktop. Thus, this is the default boot by the KLVA

[Clarity]

Issue

Code: Select all

root# mount -o username=root,password=woofwoof //192.168.1.21/BOOTISOS /root/TestPC
mount: /root/TestPC: unknown filesystem type 'cifs'.
       dmesg(1) may have more information after failed mount system call.

Any chance findsmb utility from BKWP64 is included in next release of KLVA?

Testing continues...

[rockedge]

Any chance findsmb utility from BKWP64 is included in next release of KLVA?

will need to check into this. I am not familiar with the findsmb utility.

For the issue mentioned, does the mount point on the Windows machine exist?

[Clarity]

For the issue mentioned, does the mount point on the Windows machine exist?

YES.

That is a central remote lib backup of ISO/IMG files I test next time I run.

'findsmb' is a tiny utilty from Tazoc-01Micko when they put together SAMBA services in PUPs back in their day. It list alll SMB servers on the local network. I use it extract the network-paths and their hostnames to update the PC's host file such that each server can be referenced by its hostname vs using its IP addresses. Or as a quick-reference from the terminal to see which SMBs are alive. It is also present in F96CE, IIRC along with WoofCE generates with SAMBA services from peebee.

[Clarity]

@rockedge

Issue

Code: Select all

root# mount -o username=root,password=woofwoof //192.168.1.21/BOOTISOS /root/TestPC
mount: /root/TestPC: unknown filesystem type 'cifs'.
       dmesg(1) may have more information after failed mount system call.

...

DISREGARD this issue

I rebooted on a different test PC and no issue exist. Command works as expected!

This time, I created the mount-point in the 'mnt' folder versus 'root'. But additional test shows it works on other mount-points in root folder.

Let's ignore this. If it resurfaces, I will pursue more extensively.