Puppy Linux Discussion Forum

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

rockedge wrote: ↑Sat Jun 29, 2024 9:09 pm

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.

@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

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

# 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

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

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

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

Issue

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

Clarity wrote: ↑Mon Jul 01, 2024 1:03 am

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?

rockedge wrote: ↑Mon Jul 01, 2024 3:15 pm

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.

@rockedge

Clarity wrote: ↑Mon Jul 01, 2024 1:03 am

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.