KLV To-Do List

[wiak]

Tonight been mucking around reminding myself how to use Qemu. I don't use the likes of Aqemu; I prefer just using commandline (and taking appropriate notes in my cherrytree notebook).

Actually, I was also doing a Clarity type trick booting Ventoy physical usb stick via Qemu too; not really so much point to that for me though since can just instead boot the isos it contains directly.

My Ventoy stick does have a special third partition that I labelled "Persistence" as I documented elsewhere

viewtopic.php?p=101793#p101793

and so (with nothing to do with Ventoy) that proves useful to me in direct Qemu boot of the likes of KLA-XFCEpodman where I use boot -d to boot the KLA iso image but also attach the physical usb stick (as a -device format=raw) that has that "Persistence" partition, which immediately allows me to use the Qemu boot menu choice for RAM2 save on demand mode to Persistence partition. I'm also playing with Ctrl-Alt-2 to enter qemu monitor for experiments with usb pass-through techniques in already running Qemu vm.

Using the physical usb stick along with the iso image is pretty handy. Qemu is really nice to the extent that Ventoy is a bit irrelevant for me really. Still, nice to have that Ventoy usb stick that also has that Persistence partition for general RAM2 save on demand usage in Qemu (without using Ventoy itself - though using Ventoy as boot usb from Qemu also working fine though for that we do need the exFAT support and appropriate Ventoy-related grub.cfg and so on in iso/boot/grub).

[Clarity]

For me, I test the Ventoy stick to get a lead on what would/does happen when booting on bare-metal. Useful from that standpoint.

Your test pattern is great in that using the stick containing ISO files, you:

• can path to the ISO file directly on that USB in a QEMU stanza
  OR

• you can boot the bootable USB stick in a QEMU stanza

to validate behavior knowing what to expect or look-for when using the USB and/or on bare-metal. Faster results by using QEMU. And I can test multiple VMs simultaneously on the desktop while the host allow productive work as well.

Its win-win.

In my case, I handle my persistence differently as I want the VM to appear physically as close to bare-metal as possible. Since, on bare-metal, I keep Persistence on bare-metal's system drive versus on a USB (for very obvious reasons). So, on QEMU, I boot the USB and use a 2nd drive in the stanza. That 2nd drive is labeled "Persistence" with a Sessions folder used to mimic how I do things on bare-metal. All of my save-sessions for every distro that provides persistence is kept in that same Sessions folder...everywhere.

I have tested this arrangement on QEMU in its default BIOS VM as well as QEMU in a UEFI VM. This mimics a PC with a system drive booting from either of the 2 boot launchers; namely Ventoy or SG2D USB.

QEMU with "boot D" in its stanza is the same as booting a bare-metal with a DVD used to boot the PC.

This parallels what you are doing.

[Clarity]

This post just reminded me of a test case setup PC that I need to resurrect as it was useful.

I had a test PC that I had been using for several years. But is died around the beginning of the summer and I never replaced it.

This is the pertinent piece of that test machine.
I think it was @mistfire, IIRC, that helped me with the script (the script, too, was lost when I discarded that PC). The script was used to create a RAM disk. I had imaged that RAM disk from a bootable Ventoy USB.

I would download a ISO file, load it onto the Ventoy RAM disk and boot accessing it in a QEMU VM. This reduces the turn-around time for a given test ENORMOUSLY because the ram disk is SO MUCH FASTER than the physical USB sticks. This way, the wait to copy the downloaded ISO file in order to test using a physical USB was shortened by copying to the ram disk versus physical USB. I perceived (not measured) a faster boot of the ram-disk version than the USB as well. AND, most importantly, it gave a quick reasonable expectation of what would happen if a "real" Ventoy USB was used to boot a VM OR a bare-metal.

Just another effort on my part to keep up with what developers do in their efforts to test scenarios using QEMU. This effort made me a little more productive by reducing time and reducing efforts for testing. All of my stanzas are saved as they are basically standardize for my test cases.

P.S. I run a VM on my production host that is used for all Internet browsing. File transfer for information gathered in the VM is via the OOTB samba to/from the host. Thus NO installations on any kind is necessary for this host-VM information pathway. Every major OS/distro comes with SMB (Linux/Unix uses SAMBA) built-in making this all-to-simple use available. This completes the integration requirement for info movement needed. I use a virtual desktop with the VM running full-screen in one of the host's virt-desktops. This allows the appearance ... rather ... 'use' of 2 PCs on the same display's access; one real and the other real-virtual. This production arrangement has NO CPU overhead...just the RAM designation in the QEMU stanza. "Idle utilization" remains the same with or without the VM running. VM desktop behavior is the same instantaneous as the host desktop.

In my past, another test case was running 2 different releases of a given distro to ascertain if a misbehavior I was witnessing was the same in a prior release. This is great to spin-up a VM with a current distro and a 2nd spin-up of a prior release to compare, side-by-side onscreen, a behavior.

In summary, I use this arrangement because I get the real allusion of having multiple PCs on the same desktop's display.

This is where use of my TV is now beneficial on these old eyes with so many things on the real estate it allows to presents.

[wiak]

I don't know much about Qemu really. I dabble with it too rarely, trying many things, but then after not using it for ages, I forget most everything all over again.

It would be nice if it were possible to boot an underlying Windows installation on Qemu whilst I am booted into Linux... Trouble would be, I imagine, that the virtual machine will not be recognised as the actual hardware machine by Windows so registration won't work(?). It would be so useful on dual boot machine like mine, not to bother separately having to dual-boot, but instead run the Windows system as a virtual machine. Well... I suppose I could use the likes of Virtual box, running it under booted Windows, and with my Linux system the one being run as a virtual machine... but I don't want to be directly booted into Windows.

One reason this is suddenly on my mind is that I'm getting a replacement new laptop (well, business is...) and though not fast in terms of the likes of gaming, it again has loads of RAM and tons of nvme SSD space so running virtual machines makes lots of sense with it (rather than my dual-booting and risking to mess up the actual business-related purpose of the machine...

However, I have zero time at the moment anyway (can type fast enough so this post doesn't hurt), but March will come sooner than I'll be ready for and sometime then I will be back doing FirstRib/KL work.

[rockedge]

@wiak I have several versions of Windows running in both QEMU and VirtualBox. Yes the registration mechanism for Windows works on both types of virtual machine.

It is really convenient to work with Windows in a QEMU machine using the VNC to display and see it with Tigervncviewer.

I use WinXP still mostly in the VM's that do not need any registration. Might be some Win7 models around these days that are opened but I do have a couple of valid Win7 versions with the keys that I could use but WinXP still runs what I use it for.

[rockedge]

Going to begin experimenting with JACK audio server on our KLV variants. This would be really top self stuff.

I also have been building in lots more support for sound cards and devices in the latest full real time kernels for Puppy Linux and KLV. This will need some testing though.

Also will try JACK on a wayland KLV especially on @Sofiya 's latest works of art.

[Clarity]

Hi @wiak , I have installed multiple Windows, at times, under QEMU for over a decade. So far, issues. The important thing to concern is how you structure your QEMU definition to mimic a "real" PC. There are several ways to do this.

If I can offer an insight that you and others might benefit in QEMU use, its that you keep a library of the definitions that you use with comments of both the type PC it is defined with each QEMU stanza. Remember, QEMU stanza merely is defining a mimic of a "real" PC. Thusly it contains everything from type of UEFI/BIOS, video card, audio card, LAN structure, and storage devices.

If this is for a home 'production' system for permanent development or other use, I would suggest Linux Virt-Mgr (aka 'libvirt') as this is the best screen GUI for KVM systems (QEMU). It is fabulous and makes plain what is happening on which virtual PC and each individual definitions of its hardware (virtual) layout. And it does a lot of the QEMU (cli) heavy lifting for user understanding and use.

It would probably be a mainstay in Puppyland, until recently, many members were not into virtual machines or use of such. (The KL community is currently the best and appears to be the most understanding of VMs and Linux's KVM benefit in its efficient use of the real PC's hardware.)

In fact, I would think that this year, 2024, is going to be a breakout year for KLs as it appears to be headed as the front-runner for the modern Linux technology with the several very good things it has going for it.

[Clarity]

Hi @rockedge I will follow your work as there has been discussions I've seen recently in this area of Pipewire use.

I ask, to be consistent with your efforts, that you install the QPWGraph package. Reason, it looks simple enough to make sense of what the PC is doing and what is connected. And it leads to an expanded knowledge for experienced and new users alike.

As a developer, it could be helpful in tests you (and others) would engage to readily see what you've attempted in real time.

Have you seen it? Anyone else in KLs community, please provide feedback on value of these kind of assisting technology and any other products like this. It has an advantage that we can visually see results toward speeding resolutions in a system's multimedia use. "Wireplumber", maybe, as RECOMMENDED by Arch in their Wiki.

Those reviewing this post, might appreciate this Arch Wiki Pipewire page...especially just the 1st 3 paragraphs-sentences.

[Clarity]

After seeing a few distros over the past months from Distrowatch and reviewing discussion of Linux in 2024, it seems to me there are 6 products that almost every major distro, OOTB, will achieve; as follows

• Pipewire

• Wayland

• WirePlumber

• QT6+

• GTK4+

• GRUB2 v12

Some speakers believe there will be no holdouts, while they feel the early adopters will have the least effortless implementations. They all predict X11 will be removed among many top 10 going forward to reduce their need to support X11 and its past.

AS I look over these directions, here, in various forum distros, I foresee a need for a functional graphical display program for Pipewire as it makes plain how the system and its apps are connected to deliver the multimedia experiences so common in today's world of electronics. Today, the leaders I see are Helvum and qpwgraph for this visualization task. Thus, for now, one or the other (developer's choice) should be included, built-in OOTB, in any forum distro(s) released for member use such that it allow them complete understanding of the NEW system interconnections for multimedia.

There seems to be some 'filler" on nvidia, nouveau, and the kernel changes. The push seems to be moving the timetable on this, early in 2024 to be consistent with minor Wayland needs.

This thread, probably should be posted elsewhere as KL distros are not the only forward thinking distros in the Puppyland kennel.

[wiak]

I don't know... I'm now on the big move so maybe just thinking 'ambitiously'... but...

I'm tempted to work on a build of Puppy - similar to traditional, but different. Not using FirstRib initrd, so not KL-approach, but using Puppy system scripts with a new design of initrd that learns a lot from FR. However, maybe best I don't, and leave Puppy to those that want to stick with 'as is', but slowly developed however they wish from there. But maybe at home or in-house will make something just for my own personal fun. So much to do though, so little time; I'd certainly be sorry to see Puppy grow so old and gnarled it becomes irrelevant eventually.

[rockedge]

I'm tempted to work on a build of Puppy - similar to traditional, but different. Not using FirstRib initrd, so not KL-approach, but using Puppy system scripts with a new design of initrd that learns a lot from FR

I agree and would be onboard with this type of project.

However, maybe best I don't, and leave Puppy to those that want to stick with 'as is', but slowly developed however they wish from there.

Those days have to be left behind. Only way is redesign with all this good tech at it's core. It is the Puppy Linux philosophy we want to preserve. Look at automobiles.....the basic thing is the same...engine on a frame with 4 wheels and a steering wheel outfitted with brakes. But huge difference between a 1920 model and a 2024 model......in performance and materials used to build.

[wiak]

Actually first priority, once I get back into KL more deeply again will be to accumulate all the new/latest developments and get them onto FirstRib gitlab so easier to make consistent KL releases via the build system plugins. I have nothing against any and all users supplementing what becomes standardised/tested KL-utilities and so on, but nice to collect the latest and greatest and keep that resource up to date to optionally allow KL distro builders to include the most popular whilst knowing they can trust they are well tested and latest releases.

The other matter I see happening more this coming year is that we also take a closer interest in Puppy Linux distro development too with the idea that many of the techniques/scripts/methodologies we develop could also be useful in Puppy. We already have wd_multi as an example of that; I consider it very wasteful of dev time and talent to make utilities such that they cannot be used in other distros here without re-inventing the wheel. It is fine for members to have their favourite distros and use only those they prefer, but as a developer/build perspective I've always considered that a very narrow and wasteful way of improving distros featured on this forum. This is not a big organisation, hence KL happily uses whatever proves useful from any area of this forum and equally looks to provide utilities and ideas that will definitely at times prove useful elsewhere - the more compatible we can build such components the better so reducing/removing system-level barriers to such compatibility is IMO something to always consider and aim for.

[rockedge]

@wiak With some tweaks and new additions a KLV-Airedale and KLV-Spectr PLUG files can be ready, and using the ideas from @Sofiya's scripts that build a complete KLV distro scripts we should be able to begin to add to the GitLab collection. I have a GitHub repo, but it does not have the latest versions.

The ability to add in configurations and polish using .xbps packages has proven to be a good method. By varying the choice of those types of .xbps packages can then in a pin-point fashion build the different specialized variants like those designed for audio workstations for example.

[wiak]

I'm still in very cramped temporary accommodation, but move to slightly better arrangement next week and should have reasonably reliable internet there.

Have a backlog of non-forum-related work keeping me busy for some time into the future, but in-between times I at least want to do a bit organising regarding above couple of posts.

Could you guys post known KL facilities (such as, of course, save2flash) that are being employed in different, but not yet all, KL distro offerings. I plan to make a shared spreadsheet we can keep updated with which KL distro offerings exists and with checkmarks showing which in-common utilities they contain (or might want to contain once we have time to implement further additions). Some of the more system-oriented utilities probably best offered, at latest release versions, in all KL distros for consistency of experience, so the spreadsheet will provide a quick glance view of everything in current state KL offerings. I know some people resist all things google, but in practice we use google sheets here a lot in business, so that's what I'll be using since I'm more familiar/efficient with that as an easily shareable editable cloud resource.

My view is that the likes of gitlab/github are best for keeping distro dev work up to date, but really nothing is more familiar and useful as a spreadsheet for flexible, easy to modify, very simple information sheet such as I describe. A fully-fledged database is good at other times, but not so accessible to most people; for me therefore I prefer simple spreadsheets for this purpose. In business we use large cloud accounting packages, which include sophisticated invoicing and more databases, but we nevertheless also supplement that with simple spreadsheet templates for quick information sharing purposes.

Anyway, main point of this post is to make a request for list of such primarily system-type utilities/facilities that KL distros now can provide; so many bits and pieces I can't myself reliably remember...

NOTE: Hard to work here though. Hot. Currently 29C (6pm) - high humidity so weather forecast says feels like 33 - they are not kidding; highest today 31C and was 26C just prior to sunrise... Do have in-room airconditioning, but that means like being in a refrigerator so the constant change of hot to freezing plays havoc with the respiratory system of my body... I try to keep temp at around 24C in the room so going in and out doesn't feel quite so significant.

[fredx181]

@wiak
Latest save2flash for KLV is here: viewtopic.php?p=103651#p103651
For systems with systemd, e.g. KLA or KLU it's different as it needs also a systemd service file (and small other modification, if I remember well), (perhaps @Sofiya knows more).

[Sofiya]

@wiak
Latest save2flash for KLV is here: viewtopic.php?p=103651#p103651
For systems with systemd, e.g. KLA or KLU it's different as it needs also a systemd service file (and small other modification, if I remember well), (perhaps @Sofiya knows more).

for KLA I have this

[rockedge]

save2flash used in KLV-Airedale and KLV-Spectr used by the PLUG script

Current version -> save2flash-1.7_1.noarch.xbps

previous version -> save2flash-1.6_1.noarch.xbps

GitHub repo for PLUG collection -> https://github.com/techrockedge/KLV-PLUGS

[Sofiya]

save2flash used in KLV-Airedale and KLV-Spectr used by the PLUG script

Current version -> save2flash-1.7_1.noarch.xbps

previous version -> save2flash-1.6_1.noarch.xbps

GitHub repo for PLUG collection -> https://github.com/techrockedge/KLV-PLUGS

save2flash-1.8_1.noarch.xbps latest version viewtopic.php?p=103651#p103651

[rockedge]

I checked and it is currently save2flash-1.8_1

Current version -> save2flash-1.8_1.noarch.xbps

previous version -> save2flash-1.7_1.noarch.xbps

old version -> save2flash-1.6_1.noarch.xbps

GitHub repo for PLUG collection -> https://github.com/techrockedge/KLV-PLUGS

[wiak]

Aside from that all important save2flash, I think there are various other 'utility apps' being used in different KL distro releases aren't there? For example, some have samba, others grub2config and I'm sure there are several other such that may be in Airedale or Hyperland but I haven't as yet included as fixed or optional in, for example, KLF, KLU, or KLA?

Also, is there any rollback utility (I think maybe @fredx181 made one?) being used somewhere? Maybe some other stuff I've forgotten about.

We also have @fredx181 symlink sfsload on fly utility, or the possibly to be preferred chroot mechanism he devised. I can't remember where these threads are.

Maybe there are also some audio or audio/video utilities or related that I've forgotten about altogether.

All these are things I'd like in shareable spreadsheet to show what is available to KL and which KL distros already have them.

[fredx181]

@wiak
I think rockedge has added almost all custom made xbps packages here: https://rockedge.org/kernels/data/XBPS_packages/

Some others:

• Pipewire (included now in KLV (and probably in other KL's too)): viewtopic.php?p=98374#p98374

• Alternative SFS-load: viewtopic.php?t=8004

• GoogleDrive-Filemanager: viewtopic.php?t=10219

• Remaster: viewtopic.php?p=71341#p71341

• Simple python3 http server: viewtopic.php?t=7867

• Conkyclock: viewtopic.php?t=8536

• Pulse Capture Gui: viewtopic.php?t=9518

• Experiment with screener: viewtopic.php?t=9013

These are mostly my contributions, probably there should be more, also from others I think.
EDIT;

Also, is there any rollback utility (I think maybe @fredx181 made one?) being used somewhere?

I think you mean restore-sys script: viewtopic.php?p=103935#p103935

[wiak]

Thanks Fred, you have been making a lot of KL stuff during the year.

[wiak]

I still don't have much time for experimenting/dev work. But I am 'kind of' getting back into it. In particular, I'm ignoring my todo list, because I want to remind myself how my KL_full2fr mechanism works. Whilst I don't take any drugs, apart from my single dose of morning expresso coffee, it sometimes almost seems to myself that my brain must have been on drugs when I created KL_full2fr or at least I'm almost shocked that it works... However, I just tried it again, with my latest full install of Linux Mint, and, apart from a minor glitch (in the documentation) I am currently booted into my Linux Mint but as that very special full2frugal creation where the actual full install of Linux Mint remains exactly as it was (and thus remains bootable per normal full install) but also is bootable as frugal install, which is how I am using it right now... I really love this since has full KL power in this state. Note that unlike earlier weedogit-type creations, KL_full2fr does not at all involve installation iso of the likes of Linux Mint - i.e. it does not involve using the internal sfs rootfs of such distros - rather it uses the actual uncompressed full installed Linux Mint filesystem itself; that's why it is so useful (to me at least).

I have to re-study my own script though to get my head around how I managed this from the point of view of how the overlay filesystem is working with it. I know I later also managed to get this full2frugal working with KL/wd_multi arrangement, which is what I also want to do now (again) for my daily driver situation, but first I want to remind my brain how KL_full2frugal itself is actually managing to work...!... Anyway, it does. Of course, as I said back then, KL_full2fr should work on pretty much ANY already full-installed Linux distro; that could include a full install of a normal KL distro for example, though I've never actually yet tried running a KL distro in a full installed configuration, but no reason why not.

Without thinking of all the ramifications, I tend to suspect that a full-installed KL distro then run as a KL_full2frugal might be the most useful overall arrangement for the simple reason that it is trivial to upgrade a full installed distro, but KL_full2frugal then gives the result the full FR initrd frugal install advantages (except that in the special way I'm doing things a separate partition is then used for upper_changes work). Oh well, early days in my re-examination of KL_full2frugal, which I believe contains a lot of useful end information regarding how to make frugal installed distros work in the most powerful way, and even more so in conjunction with wd_multi configurations. Weird I suppose that I sometimes myself get lost in the complexity and power emanating from my own earlier work, but I do; like I say, though I wasn't at the time on drugs, the results even amaze myself such that I have to now re-understand how it all works... I think more useful implementations may well come out of that earlier KL_full2frugal (KL_full2fr) result and the theories behind it all that made it work.

The new 'trick' I wan't for KL_full2fr arrangement is that when using the result as a frugal install an upper_changes is of course created so I want to be able to later merge that back into the underlying actual full install root filesystem, which is effectively a re-master of the underlying full install itself. Weird idea I suppose, but once arranged in a user friendly seamless way the result would definitely be best of frugal combined with best of full install arrangements, being the best for anyone who likes to expeiment/do_dev_work whilst also keeping their distro fully up-to-date in all ways (new updated kernels and so on).

Of course, KL_full2fr methodology is very much related to how I made Pseudo Full Install with FirstRib/KL; KL_full2fr just took that a bit further to involve a full installed distro and all its parts in that one complete root filesystem. Actually the new Puppy experiments using a sort of PFI remind me, at least in simple description I read, very much of KL_full2fr, but using Puppy almost as the full install (rather than the likes of full Linux Mint or Zorin that I described), but I haven't studied that latest Puppy work so I don't really know if that is what is being done now in that new Pup initrd expermental arrangement; certainly sounds a bit like it to me.

EDIT: In case anyone else (and to remind myself of the issue) has the likes of a full installed Linux Mint (or Zorin or whatever) and tried a KL_full2fr per the instructions and script I provided, the one glitch was that the kernel didn't end up getting copied out of /boot of the full installed distro (in my case Linux Mint). Actually you don't need a copy of the kernel so you can easily fix the KL_full2fr simply by doing one of the following:

1. Copy the actual kernel out of /boot of the full installed Linux Mint to the /KL_full2fr directory and name it simply as vmlinuz
OR
2. Simply make a symlink from /KL_full2fr directory named 'vmlinuz' to the actual full install vmlinuz that is stored in /boot (of Linux Mint): That is:

Code: Select all

cd /KL_full2fr
ln -s /boot/vmlinuz-whatever_version_it_is vmlinuz

I used 2. above just to prove to myself a symlink to the actual Linux Mint kernel would work fine in the KL_full2fr arrangement.

[wiak]

By the way, regarding my above post, if you do build a KL_full2fr, the latest initrd that includes the w_config save folder re-direction capability will be automatically installed.

It is important to understand the single limitation of KL_full2fr in comparison to normal KL distro installs that the savefolder must be held on a different partition to the underlying full installed distro and thus if using w_config to redirect where the save folder is located that caveat/limitation must still be borne in mind for KL_full2fr use.

Note also that a special/customised w_init is used for KL_full2fr (which is automatically installed by the KL_full2fr build/install script). I may one day/later merge the full2fr special arrangement into the default FR initrd, but for the moment I just use the normal (latest) FR initrd plus the special custom w_init to achieve the final KL_full2fr ability.

[wiak]

Well KL_full2fr has an issue when using with other than RAM0 mode. Yes, w_initconfig works to redirect upper_changes to other partition anywhere you want it (or can alternatively be done using w_changes/w_changes1 grub kernel line arguments), but issue is that upper_changes will include the swap file that, for example, Linux Mint full install uses by default - of course I don't want that!

Well, obviously need to either turn off swapfile usage in underneath full install (that's probably best actually) or perhaps can be made to work if any such swapfile was not the one used on main Linux Mint partition (I think? - still thinking about it - but, really, RAM2 should work fine as long as main Linux Mint full install is configured not to use swapfile - now I just need to see where that is done; probably obvious, but I'm not used to caring about swap files...).

Okay, I'll just disable it entirely in my main Linux Mint full install before using RAM2 mode in KL_full2fr variant. To do that, on running full install of Linux Mint (or whatever full installed distro you are working with) as root user just open /etc/fstab and comment out the line that includes /swap info (i.e. starts with /swapfile in Linux Mint case). Then it won't be used on boot either in Linux Mint full install or in KL_full2fr version... YES, that works fine. I'll refer to this post from main KL_full2fr main thread first post...

[Clarity]

I was thinking that members in the KL arena 'might' want to have a "KL Theme" for its GRUB2 Menu.

Further, is it time to consider moving to just GRUB2 versus dev time to support multiple boot menu services? One less product to constantly maintain as we known the world constantly upgrades GRUB2 with timely needs in support of booting systems; this include security needs.

Not a request, rather this post is for dev consideration as KLs continue movement into its future.