KLV-Airedale-beta+ Released, Ready for Download

[rockedge]

Code: Select all

root# cd /mnt
root# ls
home  layers  sda1  sdb1  sr0
root# cd layers
root# ls
00firmware_modules  01	07  10	RAM  merged  uc_ro
root# cd RAM
root# ls
upper_changes  work
root# 

So it seems upper_changes exists!

[Clarity]

QEMU FossaPUP64: Seems I have @666PhilB's QEMU v6+. NO ISSUES, here on older KLVs. I have not tested the most recent KLV, yet, on the Fossa PC.

I would prefer, if KLV has QEMU v6+ vs the older versions, if possible thru a installable app, package management, etc consistent with KLV.

QEMU from past studies, including such by me, is outstanding: In some cases, FATDOG has proven to perform better in both speed and response than it does on its desktop...for example.

This kind of performance on 64bit PCs can allow a KLV PC to host several KLV-specific virtual PCs (ie a KLV camera monitor vPC, a KLV internet transfer vPC, a KLV media streamer vPC, a KLV dedicated compiler/builder vPC, a KLV dedicated testing vPC, etc) ... all the while having the Host merely monitor overall PC behavior.

These could ALSO easily be linked in an intenal LAN on the Host where a virtual router/bridge-like function could offer separation from the home physical LAN with both LANs accessing broadband thru a common physical router.

Just ideas for anyone interested.

I think the QEMU aspect may benefit from its own separate forum subheading as the possibilities in its use with todays modern PC would be contributed to: aspects arising from video, sound, USB ,LAN, BT and other items could be shared. For over a year, for example, I have been booting the SG2D and the Ventoy USB sticks "DIRECTLY" in QEMU to compare behavior vs real PCs I have. If using the qemu_gui running in a PUP; instead on filling in the ISO file, I fill-in /dev/sdb and the vPC will boot it as if it is a 'real' PC with a USB.

FYI

[fredx181]

So it seems upper_changes exists!

Yes, in /mnt/layers/RAM , but the important thing is that /mnt/layers/uc_ro is connected to what is specified in w_changes=... (upper_changes)
EDIT: i think w_changes=/mnt/sdXX/.. doesn't work, should be LABEL or UUID, e.g. w_changes=LABEL=<label>=/...
EDIT2: look at mount | grep uc_ro

Code: Select all

root# mount | grep uc_ro
overlay_result on / type overlay (rw,relatime,lowerdir=uc_ro:10:07:01:00firmware_modules,upperdir=/mnt/layers/RAM/upper_changes,workdir=/mnt/layers/RAM/work)
/dev/sdb1 on /mnt/layers/uc_ro type ext4 (rw,relatime)

I booted with w_changes=LABEL=<label>=/... w_changes1=RAM2 and /dev/sdb1 (USB) contains my upper_changes (sdb1 connected to /mnt/layers/uc_ro)
Probably @wiak can explain better, I don't really understand all about this.

[rockedge]

@fredx181 I am in the middle of compiling QEMU 7.0.0-rc1 on a Fossapup64
I will make a PET or SFS out of it eventually if it works.

On the QEMU I have running at the moment (4.2.2) I am going to try the same method you did with the boot stanza

Code: Select all

title KLV-Airedale-beta10 (LABEL, RAM2,V-1)
 kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=/mnt/sda1/WDL-live w_changes1=RAM2 net.ifnames=0
 initrd /initrd.gz 

You are starting KLV as a ISO image (CD/DVD)?

I will try other variations of the stanzas

Code: Select all

title KLV-Airedale-beta10 (LABEL, RAM2,V-2)
 kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=RAM2 w_changes1=/mnt/sda1/WDL-live net.ifnames=0
 initrd /initrd.gz 

[fredx181]

You are starting KLV as a ISO image (CD/DVD)?

Yes, ISO.

For what it's worth.. I found that this works with qemu for me to save changes to USB ( you need to change path to ISO and -device ... and hostbus=.. and hostport.. accordingly).
But qemu is rather new for me, perhaps anyone has better options.

Code: Select all

/usr/bin/qemu-system-x86_64 \
    -machine accel=kvm \
    -m 512 \
    -cdrom /mnt/sda7/KLV-Airedale-beta10.iso \
    -boot once=d,menu=off \
    -usb \
    -device usb-ehci,id=ehci \
    -device usb-host,bus=ehci.0,hostbus=2,hostport=3

Running lsusb -t got me this for my USB stick (I use for the changes) (hostbus=2, hostport=3)

Code: Select all

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M

My USB is labeled "aire" so at the grub4dos stanza "KLV-Airedale-beta10 (LABEL, RAM2)" I changed w_changes=/mnt/sda1/WDL-live to w_changes=LABEL=aire=/
But... at shutdown the Save/NoSave dialog is NOT displaying, and will save anyway (as save is default).

I have been investigating this issue of not showing the Save/NoSave dialog (as @wiak reported earlier) , I have an idea to solve this, but get back on that later.

[rockedge]

@fredx181 I will try out your QEMU configuration to boot!

[Clarity]

But... at shutdown the Save/NoSave dialog is NOT displaying, and will save anyway (as save is default).

YES, I too am experiencing this on my last KLV beta run on a real PC. I was curious 'why' and should have reported it.

ALSO, iff you have an SG2D USB that you test with on real PCs, use it as the entry to boot /dev/sdc (or your USB entry) instead of the ISO file. Adjust any stanza at KLV Menu time to compare what 'real' users will see.

Hope this info is helpful.

[rockedge]

@Clarity Frugal install, started in RAM2 mode?

[wiak]

On another matter (/boot/grub/menu.lst):

Code: Select all

 title KLV-Airedale-beta10 (LABEL, RAM2)
 kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=RAM2 net.ifnames=0
 initrd /initrd.gz

That won't work for RAM2 booting from an iso since would try and mkdir upper_changes on readonly /mnt/sr0. I think the following should work though (I'll test this in a short while):

Code: Select all

 title KLV-Airedale-beta10 (LABEL, RAM2)
 kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=/mnt/sda1/WDL-live w_changes1=RAM2 net.ifnames=0
 initrd /initrd.gz

EDIT: Yes... that second one worked (I rebuilt my test iso with that change) - using qemu and save2flash worked back to /mnt/sda1/WDL-live/upper_changes (which correctly mounted to /mny/layers/uc_ro)
So that is one success at least!

I continue to be busy on new machine install. Interestingly, Zorin full install works fine on this over-the-top secure boot machine, but weedogit Zorin doesn't - must be checking flipping every component involved in the boot chain!

As for using qemu. I had no trouble using RAM2 at all per the above LABEL stanza I posted about back then. (except snap-ex was causing snapmergepuppy on shutdown even when I didn't want it to). Fortunately I didn't need to use any special qemu parameters and this was boot from iso by the way. Perhaps Clarity is right - depends on your version of qemu - I was working on WDL_Arch64 so, being Arch Linux based would probably be latest and greatest qemu. I know nothing about qemu myself, but runs fine for me just used:

Code: Select all

qemu-system-x86_64 -cdrom isos/KLV-Airedale.iso -boot order=d -drive file=img1.raw,format=raw -m 1G -enable-kvm

having previously created img1.raw with:

Code: Select all

qemu-img create -f raw img1.raw 2G

As far as I remember (not using KLV ri ght now), that working LABEL grub.cfg stanza above is the one already provided in beta10 KLV iso.

EDIT: NOTE that it is important to realize that img1.raw above is /dev/sda1 as far as qemu is concerned in this configuration - i.e. do not confuse with underlying physical machine /dev/sda1, which is a different thing. i.e. the media upper_changes folder that gets mounted to /mnt/layers/uc_ro is the one stored inside img1.raw. Note also that the KLV distro itself is being booted from iso as if it were a cdrom here.
EDIT2: For completeness, I should mention that I used fdisk img1.raw and partitioned that img1.raw so has an sda1, and then formatted that 'sda1' as ext4 once I was inside a RAM0 booted qemu-booted KLV-Airedale. Then I rebooted with above grub.cfg stanza into LABEL RAM2 mode.

[esos]

Booting beta10 direct from ISO in realmachine RAM1 mode.
It works as expected.

RAM2 10 seconds time to save or not tosave
RAM1 load upper changes but nosave

[fredx181]

EDIT: NOTE that it is important to realize that img1.raw above is /dev/sda1 as far as qemu is concerned in this configuration - i.e. do not confuse with underlying physical machine /dev/sda1, which is a different thing.

For me it's /dev/sda not /dev/sda1
And read earlier in this thread that it needs formatting, so I did mkfs.ext4 img1.raw
Then booting with w_changes=/mnt/sda/ w_changes=RAM2 (note: edited to: sda) worked for me saving changes to img1.raw (btw, changes saved without showing the Save/NoSave dialog but that's another thing)
But perhaps I'm missing something ?

[wiak]

EDIT: NOTE that it is important to realize that img1.raw above is /dev/sda1 as far as qemu is concerned in this configuration - i.e. do not confuse with underlying physical machine /dev/sda1, which is a different thing.

For me it's /dev/sda not /dev/sda1
And read earlier in this thread that it needs formatting, so I did mkfs.ext4 img1.raw

Now that you mention it, I have a distant memory that I partitioned it with:

Code: Select all

fdisk img1.raw

Not sure I should have done that, but it worked. I 'think' what I then did was used qemu to boot but chose RAM0 mode and once into KLV I did:

Code: Select all

mkfs.ext4 /dev/sda1

and then I rebooted again choosing RAM2 mode. Made sense to me at the time, but maybe not sensible after all
Basically I wanted it to look like a normal sda drive, so needed partitioned to act like that.

Then booting with w_changes=/mnt/sda/ w_changes=RAM2 (note: edited to: sda) worked for me saving changes to img1.raw (btw, changes saved without showing the Save/NoSave dialog but that's another thing)
But perhaps I'm missing something ?

Well, that was the issue discovered that needs fault finding done on it. I did a quick debug and noticed that if snap-ex was disabled (temporarily renamed) then in RAM2 mode the session doesn't get saved, but otherwise snap-ex seems to go ahead and use snapmergepuppy even when clicked not to save session (and no dialog box pops up). I've been too busy installing Zorin on partners business machine (and still am), but if you don't discover what is causing that I'll have a look once I have some free time again. I also want to do a bit more research into the recent secure boot UEFI issues I've been fighting on pretty new HP laptop (slightly older HP models work fine with Puppy even with secure boot). I'm increasingly worried that new future computers simply aren't going to play ball with small distros like ours (puppy.cer or not - whole boot chain and firmware and maybe more seem to be getting involved in the signing process on 'very secure' setups, not just the grub2 bootloader maybe).

Zorin 16 lite is pretty nice to use - really reminds me of KLV-Airedale except based on apt/Ubuntu that is. I now have filemnt and gtkdialog and some of my own utilities (such as simple wd_mount) installed into Zorin's /usr/local/bin. I do miss overlayfs for RAM2 mode though - only managed to get a full install to work; more research/experiments required before I know if I can get any distros to boot frugal from internal hard disk (only managing from usb stick thus far for them - they simply can't 'see' the internal hard drive partitions as if signed out of seeing it... official Ubuntu and also Zorin work though, but only as full installs - they don't work weedogged on this particular HP laptop, which is a real pain). Possibly would be fine if I could remove Windows Pro, and anything to do with 'secure anything in the UEFI bios' (maybe... this machine is really locked down though) but Windows is wanted by my partner for now.

[fredx181]

Well, that was the issue discovered that needs fault finding done on it. I did a quick debug and noticed that if snap-ex was disabled (temporarily renamed) then in RAM2 mode the session doesn't get saved, but otherwise snap-ex seems to go ahead and use snapmergepuppy

I found that from virtual machine boot (e.g. Virtualbox and Qemu) that there's no output shown at all at shutdown, so also not the Save/NoSave dialog.
So as the default is "Save", it will save after the 10 sec timeout.

Changing "startx" to "exec startx" in /etc/profile.d/autologin.sh fixes that for me when running with Virtualbox (output at shutdown and the Save/NoSave dialog will show):

Code: Select all

# autologin on tty1
if [ -z "$DISPLAY" ] && [ "$(fgconsole)" -eq 1 ]; then
exec startx  # remove the exec if you want back to tty1 on exit X
# startx  # remove the exec if you want back to tty1 on exit X
fi

Reboot with save required to apply after this change, I guess.

What the comment says is that you get back to tty1 on exit X is true in both cases, but without the "exec" you stay logged in and with 'exec' you need to login with password again (which is okay IMO, it's a true 'logout' then).

So, as I said, for me in case of RAM2 booting with Virtualbox, it's fixed that way to be able to choose Save or not, but NOT when booting with Qemu (although it will show the Save/NoSave dialog, I couldn't choose 'NoSave' (keyboard not connected anymore ??, not sure why).

@rockedge Perhaps you can test this too, and it's your choice IMO how far you'd like to go in supporting boot with RAM2 from Iso/Virtual machine (from 'normal' frugal install RAM2 mode, Save/NoSave works fine AFAIK, but correct me if I'm wrong).

[rockedge]

frugal install Save/NoSave works fine

Yes. So far I have had no problems with Save/NoSave in frugal HDD installs.

I have been thinking of switching back to this form. I changed it early on as I experimented with login/logout:

Code: Select all

# autologin on tty1
if [ -z "$DISPLAY" ] && [ "$(fgconsole)" -eq 1 ]; then
exec startx  # remove the exec if you want back to tty1 on exit X
# startx  # remove the exec if you want back to tty1 on exit X
fi

If the login/logout works with the revision I'll but into a beta11

I was successful in compiling QEMU 7.0.0-rc1 and getting it working. Though I'll have to see how to package it if I make a PET out of it. I will be trying to get KLV's RAM2 mode to work on a very new QEMU.

[Grey]

I was successful in compiling QEMU 7.0.0-rc1 and getting it working.

Is the seventh one out already? Well, how is it, is there something unusual there? 6.2.0 suits me so far, but still.

[rockedge]

@Grey Version 7.0.0-rc1 actually reports as VERSION 6.2.91. I am cloning from the git repo

I don't see any difference in performance. Both QEMU 4+ and 6+ run well on a Fossapup64. I run 4 core virtual CPU, 2 Gb of RAM, frugal install on a virtual internal hard drive.

[Clarity]

I think it would be helpful to include either the qemu_gui that is used in FossaPUP64 or some gui facility (libvirt??) to make it easy for members to clearly launch virtual PCs (vPC) on the desktop.

In my past use, I tend to run a vPC in one of the virtual desktops giving me the 'feeling' of jumping from one PC to another.

64bit PCs with the RAM that many now have easily handle running these multiple PCs on the same desktop at the same time. Conky is also helpful.

WoofCE PUPs have been doing something interesting where it QEMU is initial run, it 'toast' a pop on the desktop with instructions on the user need to install to add it to the current system.

There is one WoofCE PUP (I cant remember which) that is missing/did-not have modprobe module ability needed to insure KVM presence (kernel) is set ready. So, a PET may want to consider running the modprobe on behalf of the user to insure the vPC performance is native-like.

Just some thoughts

[rockedge]

@wiak , @fredx181

I don't know what I did exactly but one time on QEMU I got a session saved only on demand and a save=Yes:No prompt on shutdown/reboot. I can't seem to be able to repeat it though.

I actually am pleased with the fact that KLV-Airedale will boot and perform well in both VirtualBox and QEMU, especially when there is a formatted virtual hard drive for the booted ISO (CD/DVD) to be able to create a ../WDL-Live/upper_changes for persistence.

Recommended is to create a virtual HDD, format it to ext3/4 and set the boot flag. Here I eject the KLV CD-ROM (iso) and mount a VoidPup64 ISO and boot into a Puppy Linux where I then run Grub4Dos on the virtual drive.I use the VoidPup64 to then mount and copy the KLV-Airedale ISO contents to a frugal install directory on the virtual HDD. I manually add the boot stanza's for starting KLV-Airedale from hard drive.

Now eject the VoidPup CD-ROM (iso) and reboot into the Grub4Dos menu.lst and select the frugally installed KLV-Airedale.

From this running state I am experimenting with boot stanza's and looking at why or what can be done.

I don't think it's a priority to have RAM2 work on the virtual machines.

Also trying to write /upper_changes to a USB drive (stick) that I have passed through as a valid device.
using the information from lsusb
The string added into extra parameters in qemu_gui ->

Code: Select all

-usb -device usb-ehci,id=ehci -device usb-host,bus=ehci.0,hostbus=2,hostaddr=9

Bottom line is I modified this and fiddled with that and suddenly it worked....but I can't exactly pinpoint what out of all of the modifications and attempts made, what it was that made it work.

[Grey]

@Grey Version 7.0.0-rc1 actually reports as VERSION 6.2.91. I am cloning from the git repo
I don't see any difference in performance. Both QEMU 4+ and 6+ run well on a Fossapup64. I run 4 core virtual CPU, 2 Gb of RAM, frugal install on a virtual internal hard drive.

Thanks I'll probably wait for the real seventh version and I won't compile anything yet.

[rockedge]

it would be helpful to include either the qemu_gui that is used in FossaPUP64 or some gui facility

I did exactly that. I copied the qemu_gui from the 4.4.2 version in Fossapup64 and I changed one line to use the newly compiled 7.0.0-rc1 QEMU.

It just makes it easier to work with many attempts with different configurations using the GUI. It's not complicated but once one gets involved using the extra parameters field the fun begins.

KLV-Airedale runs well enough in both VirtualBox and QEMU that I can go full screen and work only in the virtual machine and see good responsiveness and stability.

I am posting from KLV running on QEMU with Fossapup64-9.5 as the host operating system.

[fredx181]

Also nice is aqemu , a GUI for qemu. About availability I know only that it's in Debian repos (didn't check more distros so far).
As I like Virtualbox, specially because of easy to handle options with GUI, aqemu comes at a (good) second place for me.
(perhaps this qemu discussion is a little off-topic, but excuse me, just a bit obsessed atm, it will pass.. )

[Clarity]

This is a mere update for FYI.

LibVirt give KVM-QEMU ALL (and more) of the same feature as Virtualbox. It just that no-one is found on this forum who has share their experieces of it use, particularly its ease of use. The package is certainly a worthy match. And should you have multiple PCs on your LAN which can/do also run vPCs, as well, it would be suitable for both local as well as LAN vPCs management.

Again, this is mere knowledge as it appears more of us recognize the benefit of hardware (ie firmware KVM) provides us with vPCs that run as fast as the host they are on, where a single PC can be simultaneously multiple PCs without sacrificing primary host operations.

AND, for those new to use of vPCs, they, each, need unshared RAM that the host provides.Thus, many users, today, have used-new PCs with 8GB+ RAM where an allocation for a PUP ,even those we just test, does not have ANY impact of the host while the vPC runs at Native host PC speeds.

FYI

[rockedge]

@fredx181

I set up a QEMU machine running a KLV-Airedale-beta10 installed frugally on a virtual hard drive called /mnt/sda1. I have been able to use RAM2 mode and save2flash reliably and the save=yes:no prompt at shutdown/reboot works saving and not saving.

I have mounted a physical USB stick. But still working on getting save2flash to work when booting as CD-ROM from the iso

[Clarity]

I have not tried this, BUT, I have to ask in hopes it helps: Are you using a BIOS boot of the ISO file directly in QEMU? If so, is your PC set as a non-UEFI, non-secure-boot hardware setup such that the DVD drive matches what you see in QEMU? For an apples-apples comparison, these 2 must match. If not, your vPC looks one way to the CD booting the ISO file in QEMU while the real PC will be different with the ISO created real CD.

Otherwise, you will need to use UEFI boot parm in QEMU to match your PC for an apples (PC) to apples (QEMU) tests comparison.

I hope this makes sense, as I think you are wanting to compare what happens in the vPC vs the real PC.

[fredx181]

@fredx181

I set up a QEMU machine running a KLV-Airedale-beta10 installed frugally on a virtual hard drive called /mnt/sda1. I have been able to use RAM2 mode and save2flash reliably and the save=yes:no prompt at shutdown/reboot works saving and not saving.

I have mounted a physical USB stick. But still working on getting save2flash to work when booting as CD-ROM from the iso

If you try to do similar as I suggested here (boot directly from ISO and use USB for changes):
viewtopic.php?p=53094#p53094
I think it's important to use LABEL at editing the RAM2 grub4dos stanza for w_changes=.

My USB is labeled "aire" so at the grub4dos stanza "KLV-Airedale-beta10 (LABEL, RAM2)" I changed w_changes=/mnt/sda1/WDL-live to w_changes=LABEL=aire=/

[wiak]

Finally finished setting up the business laptops (two) - at least the Linux side of it (and in the end I doubt Windows will be used especially since my partner has now become addicted to Zorin xfce). I'll thus be experimenting further with qemu/KLV-Airedale again soon. One thing playing with Zorin has informed me of is just how good xfce can be. All sorts of 'tricks' can be set up using Windows (Super) key - e.g. getting windows to tile to left and right taking up half the screen; really well worth doing (we needed that for the business on a wide screen monitor). I've also noticed that most xfce distros are using xfce-whisker menu rather than the more basic Applications menu that KLV-Airedale is currently set up with. But whisker menu is installed in KLV-Airedale so I really recommend using it if there is no good reason not to - it is much nicer and simply better. KLV stilll a beta so understandable that setting up of xfce isn't near complete as yet - good idea to install something like Zorin and play around with it to see what is possible - and then use similar xfce configs in KLV-Airedale I feel. That's what I'll be doing anyway.

[fredx181]

New package save2flash (v1.2_0)

save2flash-1.2_0.noarch.xbps

save2flash v1.2_0 with small fix

(4.03 KiB) Downloaded 40 times

Fix is that it does a check now if /mnt/layers/uc_ro is really connected to the given w_changes= path (upper_changes) and only save if that is the case.
Previously, if the w_changes=... was wrong somehow, it could seem like the changes were getting saved (e.g. at shutdown) but in reality it was not happening.

And also, as I said earlier, I'd recommend changing "startx" to "exec startx" in /etc/profile.d/autologin.sh as this gives a better chance that the Save/NoSave dialog will appear at shutdown in case running from a Virtual machine.

[rockedge]

@fredx181, @wiak

I am going to issue a beta11 that reverts back to using exec startx which I left until now so I could drop to console without the Xserver using logout. Plus add in the save2flash update.

I have not at all tried out the Whisker menus and looking forward to having some cool keyboard shortcuts to tile windows around the desktop. Beta10 is working well enough to go forward and test out a Whisker menu setup.

I just added some LABEL's to few 8 Gb USB sticks to try out the same boot stanza as fredx181 is having success in with RAM2 mode.

[rockedge]

Beta11 is ready for down loading and testing!

Link in the first post or find the ISO in the usual place -> https://rockedge.org/kernels

gtkhash is included along with fredx181's improvements on save2flash. I did not switch the wallpaper from beta10 to 11 yet,

Also beginning to test the Whisker menu as main menu on a test platform running beta11

[Clarity]

Since most members have multiple PCs, is it time to add SAMBA and its utils to the Beta so that it can be tested as a part of the system before GA?