KLV-Airedale-beta+ Released, Ready for Download

[wiak]

We have many many options though that work and that PLUG that makes the lighter JWM - Rox combo Void system still cranks those out so there is light at the end of the tunnel

Yes, I also still have simple openbox variant draft plug-in that was basically rewrite of WDL_Arch64 but to use Void xbps instead. That built successfully when I tried it long time back but didn't of course contain the tons of nice stuff and utilities/features you have since added to KLV-Airedale so a lot I'd need to add to that plug-in to.

I'm also eventually going to need your zoneminder extras since in around 18 months time we plan to move country but keep our existing house here, so will use zoneminder to keep an eye on it if not always rented out. Plan to spend half of each year away from then on. 18 months is a long time in terms of klv rapid developments though... Will be traveling light - just suitcase with nice laptop and android phone ... maybe like nomads.

[Clarity]

I, too, vote for a ZM distro (aka "WatchPUP" or some similar name) in the future.

I look forward to a possibility of a PUP that OOTB will connect to RTSP cameras on the home LAN. This means we could have an OOTB solution to visually see, hear, and talk to the camera speakers.

Ha, it could also be called a "SeeingEyeDog"

[mikewalsh]

@wiak :-

Will, I've got an issue that I'm guessing you may be able to help with, since you understand the scripting, etc, better than anyone else.

I've currently got "Airedale" on an 'external' SSD - it's the IDE/PATA SSD out of the old Dell lappie, to which I've added a USB 3.0 SATA interface and made up an enclosure for. Presently, I plug it into a USB 3.0 port when I want to run it, then select it via an entry in the main Grub4DOS boot menu, OK?

I'm trying to move it to my new, main, internal Crucial SSD inside the HP itself, alongside the rest of the 'kennels'. I move the entire sub-directory to that drive, edit the boot entry to suit, but it won't boot. Insists it can't "find" it, or even "see" it.

Now, this thing is pretty heavily-modified by now, and I really don't want to have to set it all up again from scratch. I got to thinking; is there something inside the 'upper_changes' directory that would need to be modified to suit, in order to "point it" at its new location.....a file, somewhere, that needs to be edited to match? I know the advice would be to start again with a clean install, but I really can't be arsed to go through all that again.....plus, I simply don't have that amount of time to spare at present.

I want to replace the IDE SSD back in the old Dell lappie again, but I need to be able to "move" Airedale in order to do so. So....any thoughts? Advice? Pointers?

Mike.

[mikewalsh]

@wiak :-

Ignore my previous post. I've just tried the transfer again, and this time it's booted fine. I'm posting from Chrome in "Airedale" ATM, on the internal 1TB Crucial SSD.

I know now where I went wrong. Although I modified the UUID in the boot entry to suit (along with what I thought was everything else!), I forgot to modify the "w_boot_from" stanza to match. The UUID was pointing to the new location - sda2, the main "kennels" - but I'd left "w_boot_from" still pointing to the old location.....sdc1.

D'oh!!

(Half of my problem is that I will attempt so much of this kind of thing just before I turn in for the night. By that point, I'm usually yawning hard enough to crack a jaw; doesn't make for very good concentration, I tell you...)

Mike.

[Clarity]

@mikewalsh Could a mere cloning do all for you to reduce the complication? If you think that is what you want, I could recommend many solution options for moving from one place to another with much safety.

Hope that helps...if that's your desire.

[rockedge]

@mikewalsh If I had a gold piece for every time I forgot to change ALL of the boot stanza correctly to reflect the new location I would be able to afford a yacht to come on over and have a beer together at your local pub.

I just did it now DESPITE reading how you just did it! Forgot to change a beta12 to beta13 in this case.

[mikewalsh]

@Clarity :-

@mikewalsh Could a mere cloning do all for you to reduce the complication? If you think that is what you want, I could recommend many solution options for moving from one place to another with much safety.

Hope that helps...if that's your desire.

Nah, it's not that, Clarity.....although the offer is appreciated. My trouble is that I will try doing things that need concentration when I'm too tired to think straight.

It's self-inflicted, and no piece of software can help me with that!

@rockedge :-. Heh. Well, it's good to know I'm not the only one that makes daft mistakes! The moral of the story is, of course, that no matter how many times you've checked through something, and have convinced yourself you've "fixed it", it NEVER hurts to check again. Especially with Linux being so case-sensitive, AND intolerant of the tiniest mis-spelling or mis-punctuation, etc....

(*shrug*)

I'm convinced "word-blindness" affects everyone to some degree, the older you get. I think it's an unadvertised part of the aging process....

<snip>...I would be able to afford a yacht to come on over and have a beer together at your local pub...</snip>

Any time, Erik, any time..!

Mike.

[wiak]

I haven't had much time of late for doing much in the way of computing so installing beta13 the other day was the first for a while. But had a bad night and this morning tested positive for Covid so I am hiding in my room now to not spread to the rest of the family - computer with me of course! My eldest son caught it first a few days ago. Pretty nasty effects, so hard to concentrate as my brain gets eroded by the virus, but hopefully nothing Linux-weedog-related will be erased...

Luckily I'm double vacced plus booster (last November) or I imagine this would feel much worse.

I expect many of you have had it by this time. I expected it to hit me eventually and, I suppose, better now than later (unless the virus mutates into even less dangerous form of course).

[mikewalsh]

@wiak :-

Ouch. Sorry to hear that, Will. Here's hoping you shrug the effects off before too long.....

Mike.

[wiak]

@wiak :-

Ouch. Sorry to hear that, Will. Here's hoping you shrug the effects off before too long.....

Mike.

Wasn't sure if you had a Discord sfs/Appimage that worked with KLV, so ended up installing via Flatpak version (along with Whatsapp Desktop). Felt like overkill. Using DIscord from KLV right now to communicate from my bedroom with the rest of the family (albeit needing --no-sandbox at the end of the run command). Two in our family have currently tested as Covid negative; me and my elder son who tested positive (and sick with it) are staying isolated in our bedrooms. I thought Discord might perform too poorly on this old HP core2duo machine, but no, it is fine with both audio and video from KLV-Airedale.

My younger (10 year old) son is the Discord expert of the family. He was running weedogit EndeavourOS, but did he not go and break it this evening trying to update ICU or something so X wouldn't work any more. So I had to go through with my triple mask and covered in hand sanitizer to try and rescue him from his destruction, but failed in the short time I was willing to be there. Luckily turned out he had an old install of the same so was able himself to get Discord going on that instead... He is used to XenialDog, WDL_Arch64, and weedogged EndeavourOS, but not FossaPup unfortunately - I was trying to get him to boot into FossaPup to fix his broken Endeavour but he didn't even know how to connect to the network in FossaPup (seemed pretty obvious to me, but just goes to show if you haven't tried something it comes across as very alien - despite him being really good with the like of both Debian apt and also Arch pacman plus Network Manager (or wiakwifi come to that). I'll have to train him on Puppy use I suppose since handy at times like that (and had it on his machine).

[mikewalsh]

@wiak :-

i'm pretty sure the Discord 'portable' will work OK with KLV, but it needs updating, and slight re-building to add the menuEntry scripts in, too. Leave it with me; I'll get back to you later on that.

Mike.

[mikewalsh]

Heh. Just had that 'old' issue again. Fired-up KLV, annnd.....blank, black screen with 4 little white terminals on it. I knew I'd had this happen before, so I scanned back through the old KLV thread:-

viewtopic.php?p=46810#p46810

It was those 'swap' entries I'd added to /etc/fstab, wasn't it? Because KLV is no longer on sdc - and indeed, the swap partition on sdc no longer exists, since the old IDE/PATA SSD is now back in the Dell lappie again - the 'swap' entry for sdc was 'non-existent' once more.....and was creating the same boot-time stumbling-block that it did a few months back.

So I went into the 'upper-changes' directory from outside KLV - just like last time - deleted the line that was now referencing a non-existent UUID, and everything's happy again. Posting from it now. It's one of the snags of running multiple distros, especially the way we do.....inside self-contained sub-directories, which sometimes get moved around! You have to keep track of all the small differences between one OS and every other OS, don'tcha?

(Like with Tahrpup, f'rinstance; remembering to upgrade ffmpeg to a 'modern' version, followed by deleting avconv & re-creating it as a sym-link to the new ffmpeg.....because for that one release, for some inexplicable reason Canonical had reverted to the older, less reliable standard again. Stuff like that.)

Trying to keep track of all these tweaks'n'stuff across at least 10 distros plays havoc with the grey matter as it ages!

@wiak :-

Will, I've updated & re-built Discord-portable into my now standard format. For me, at least, it's running perfectly in "Airedale". If ya want to try it, you can find the thread here:-

viewtopic.php?t=2717

Download link in the first post, as always.

Mike.

[TerryH]

New frugal install using weedogit.sh. Booted OK, but touchpad (ASUE14A:00 043F:3134) is not identified. I checked other installations that touchpad works OK. It appears that a kernel config setting is not being set in the KLV kernel. The CONFIG_I2C_HID_ACPI is not set in the KLV kernel. I swapped in Puppy 5.15.35-jammy64 kernel and touchpad working.

The following are contained in 3 other kernels which run on this hardware:

Code: Select all

# I2C HID support
#
CONFIG_I2C_HID_ACPI=m
# end of I2C HID support 

Code: Select all

$ lsmod | grep i2c
i2c_algo_bit           16384  1 amdgpu
i2c_piix4              28672  0
i2c_hid_acpi           16384  0
i2c_hid                32768  1 i2c_hid_acpi          < **** missing in KLV
~$ 

Other than this, KLV Airedale beta 13 is running really well. Thanks for this continued development.

[rockedge]

@TerryH I added the CONFIG_I2C_HID_ACPI=m to the kernel 5.16.14-KLV configuration and re-compiled it and created a KLV-Airedale-beta14 that includes the new kernel version.

If you have the time could you test to see if the KLV-Airedale-beta14 with the modified kernel brings the touchpad to life?

[wiak]

@wiak :-

Will, I've updated & re-built Discord-portable into my now standard format. For me, at least, it's running perfectly in "Airedale". If ya want to try it, you can find the thread here:-

viewtopic.php?t=2717

Download link in the first post, as always.

Mike.

I can't try it just now Mike since this machine already has the flatpak version so would use your portable on one in other room (which I don't go to whilst isolating...). But it's good you've updated your portable Discord (0.0.17? - ah yes, I see it is) because I think it will be very useful and not just for me of course. I knew of Discord, but had never myself used it before, but I have to say I'm quite impressed with how well, smoothly and efficiently, it runs (audio, video, and text and in group meetings) even on this old laptop - good one for KLV portable package repos.

[geo_c]

I booted up KLV-beta-14 last night and it's really nice. My wife needs a laptop, and I just inherited an i3 with Win7 on it that I can't access because I have no password. So she's open to trying out one of my linux systems. KLV would probably be the ticket.

One thing that I noticed that didn't make to sense to me, is when I try to look at the /home directory using ROX, it comes up inaccessible. But that may be because of the fact I booted from 2GSD USB. I like that ROX is included, but I'm thinking it's not probably as useful as on a standard pup.

[rockedge]

Did you boot KLV in RAM2 mode? I have seen that on the first run in RAM2 mode, that I can't see the entire file system in Rox or Thunar. @wiak and @fredx181 discussed this earlier in this topic.
Some layer is not being created otherwise.

These are the boot stanza's I am using to start KLV-Airedale that uses persistence immediately, but not on 2GSD USB!

Code: Select all

title KLV-Airedale-beta14 (LABEL)
  uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
  kernel /KLV-Airedale-beta14/vmlinuz  w_bootfrom=LABEL=psystem=/KLV-Airedale-beta14 net.ifnames=0
  initrd /KLV-Airedale-beta14/initrd.gz


title KLV-Airedale-beta14 (UUID)
  uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
  kernel /KLV-Airedale-beta14/vmlinuz  w_bootfrom=UUID=8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa=/KLV-Airedale-beta14 net.ifnames=0
  initrd /KLV-Airedale-beta14/initrd.gz

Also @Clarity has experience in booting from 2GSD USB and I think he might have found the way to do it.

[Clarity]

I continue to boot KLV via its ISO files, directly via SG2D since the ability was made available. For me its a simple download the file and boot it. I have never found it necessary to do a export of the ISO contents to system drive as this step is unnecessary. The changes folders is sufficient to maintain all of the functionality needed in KLV operations and is the ONLY file excepting the ISO file itself to constitute a great experiences at a system storage cost of only the session folder(s).

I am just starting to get on-board with 2 things observed in KLV ISO file booting:

1. SG2D is a given as it use here in the forum with members demonstrates its use

2. Ventoy - I recently found in testing that I can boot directly from the Ventoy menu, v14 of KLV. This, though, comes with caveats of UEFI and firmware settings on 1 of my PCs.

   • This effort was discovered when a v14 ISO boot via SG2D yielded a desktop of 3 terminal windows and no way to get to the normal XORG desktop. This was reported earlier by other members and bears more research on my part to fully understand if this is unique to the single PC I am tested or if it is universal across to other PCs as well.

I will give an update as soon as I can isolate which of my multiple environments (PCs and accompanying USB sticks) this is occurring.

On another note: I wish to ask this forum community for help in a proper reference for the changes parm such that I can direct its location.

QUESTION

• On several prior test of RAM0 boots of the ISO file, changes are landing in the /BOOTISOS folder on the booting USB. AS we know it works, it is NOT where I would want to keep persistence.

• On all of my PCs, today, they each have a linux formatted partition labeled "Persistence". That partition has a folder "/Sessions" where ALL of my FATDOGs, PUPs persistence is kept. It is clear how to have the system find persistence on each boot. Modern PUPs use a SAVESPEC after pristine use OR I direct it via the PSAVE parm; while FATDOG, since I use "multi-sessions" (AKA same as DVD formats) the savefile parm is utilized to direct system at boot time.

Request: How would you tell a KLV pristine boot to save persistence as a folder in /Sessions on Persistence?

Help IF this is understandable and its clear.

[fredx181]

Request: How would you tell a KLV pristine boot to save persistence as a folder in /Sessions on Persistence?

I think the only way with SG2D is editing one of the grub2 stanzas, after selecting the ISO press E, and change to e.g.:

Code: Select all

menuentry "KLV-Airedale-beta13 (needs linux format)" {
    linux /vmlinuz w_bootfrom=${iso_path} w_changes=LABEL=Persistence=/Sessions net.ifnames=0
    initrd /initrd.gz
}

(second line only needs editing)
But perhaps you're looking for an easier way, it's a bit of a pain having to edit every time you boot, that's why I don't like ISO booting very much.

Btw, adding an entry to /boot/grub/sgd/main.cfg works for me without having to edit each time at boot (but main.cfg needs to writable of course)

Code: Select all

menuentry  "KLV-Airedale-beta13- LABEL bootfrom" {
insmod part_msdos
insmod ext2
set root=(hd0,2)                                              
set isofile="/BOOTISOS/KLV-Airedale-beta13.iso"
search --no-floppy --file --set=root $isofile
loopback loop $isofile
linux (loop)/vmlinuz w_bootfrom=$isofile w_changes=LABEL=Persistence=/Sessions net.ifnames=0
initrd (loop)/initrd.gz
}

[wiak]

Request: How would you tell a KLV pristine boot to save persistence as a folder in /Sessions on Persistence?

I think the only way with SG2D is editing one of the grub2 stanzas, after selecting the ISO press E, and change to e.g.:

Code: Select all

menuentry "KLV-Airedale-beta13 (needs linux format)" {
    linux /vmlinuz w_bootfrom=${iso_path} w_changes=LABEL=Persistence=/Sessions net.ifnames=0
    initrd /initrd.gz
}

(second line only needs editing)
But perhaps you're looking for an easier way, it's a bit of a pain having to edit every time you boot, that's why I don't like ISO booting very much.

I am not able to try it at the moment, but what fred writes looks right to me.

However, it is not the way I myself would set up SG2D to use persistence with KLV. Rather, KLV initrd is designed to allow KLV iso to be put in its own subdirectory in /BOOTISOS (and thus upper_changes persistence ends up in that same unique folder without messing with any other distros or even other KLV installs. Advantage of that method is that no editing of grub line is required - it should just work because designed for that.

There is a CAVEAT; you do have one extra thing to do, and this method only works if /BOOTISOS is on a Linux formatted partition:

You need to put a symlink (named as the iso) in /BOOTISOS that points to the actual iso inside the individual folder; then all the various RAMx persistence modes should just work. REALLY similar to a normal frugal install then, all the bells and whistles, but without having to open up and extract from the iso. NOTE that that method won't likely work with other distro isos - I included special (but pretty simple) code inside KLV initrd specially for that symlink method to work. RAM2 worked; I can't recall exactly, but I think even no w_changes (not RAM mode) also works with default upper_changes auto created in that individual folder also (e.g. /BOOTISOS/KLV-Airedale/upper_changes)

I haven't tried that for a while, but worked when I did. Alas, if SG2D is not going to be further developed I don't consider it worth putting more time into testing it (been lots of hours spent on it already), but for those who use it, above method should work fine I think.

[Clarity]

@fredx181 That's exactly what I was looking for verification on. THANKS.

Namely

1. Boot the SG2D USB choosing the KLV ISO

2. On KLV menu, hit 'e' key to edit the RAM0 line

3. Change the kernel line as shown
   linux /vmlinuz w_bootfrom=${iso_path} w_changes=LABEL=Persistence=/Sessions net.ifnames=0

4. F10 ... or 'b' key to start KLV system

5. Desktop!

[Clarity]

Agree!

... However, it is not the way I myself would set up SG2D to use persistence with KLV. Rather, KLV initrd is designed to allow KLV iso to be put in its own subdirectory in /BOOTISOS (and thus upper_changes persistence ends up in that same unique folder without messing with any other distros or even other KLV installs. Advantage of that method is that no editing of grub line is required - it should just work because designed for that....

BUT!
I wish to keep all PUP-DOG-KLV Sessions on my system drive-partition for performance+durability reasons. Further testing I have done over past 2 years suggests use of persistence on a system's drive not only performs better, but meets the needs that are characteristic of specific uses on any given PC once booted. A KVM use, like this, allows the user to switch from one PC to the next without disturbing the running system's operations. If the session was maintained on the USB, ... havoc!

USBs for me offers convenience, but for me again, I would consider persistence of the KLV OS on a system drive. (THIS IS NOT a request for any KLV changes!!!)

But your approach if one was to do all house-keeping on the USB is certainly a good organized approach.

[rockedge]

Here is stickyxfce working on KLV-Airedale-beta14. I will install it to the KLV_rootfs for beta15.
Set the keyboard bindings to <Super>+Up, <Super>+Down, <Super>+Left, <Super>+Right using the GUI editor to add the bindings to /usr/local/bin/stickyxfce by using the menu: Applications->Settings->Keyboard->Application Shortcuts

[wiak]

@recobayu Here is stickyxfce working on KLV-Airedale-beta14. I will install it to the KLV_rootfs for beta15.
Set the keyboard bindings to <Super>+Up, <Super>+Down, <Super>+Left, <Super>+Right using the GUI editor to add the bindings to /usr/local/bin/stickyxfce by using the menu: Applications->Settings->Keyboard->Application Shortcuts

I'll give stickyxfce a try; it may be better than what I'm already doing in my KLV-Airedale for tiling windows to either Top, Bottom, Left or Right. That much is available as standard in supplied XFCE -you just need to edit Window Manager - Keyboard - Action - Shortcuts. That is from Applications start menu klv-airedale open:

Applications -> Settings -> Window Manager

and go to tab "Keyboard" and look for the various "tile window" actions and press "Edit" button to change to what you want. In my case I use the Super + Up, Down, Left, and Right per the attached image. Note that it is a 'toggle' action so you can get the window back to its original position (e.g. do Super+Up and then do Super+Up again). I use this mechanism all the time, specially when comparing two business spreadsheets side by side - it is an essential facility.

With XFCE Window Manager it is worth studying all the other Action/Shortcuts available and editing to suit (Alt-F12 to toggle a window 'Above', for example, alt insert/alt delete for adding/deleting workspaces; also can edit for fill window horizontally or fill window vertically, and more besides).

So will be interested to see the different/extra possibilities stickyxfce brings. I do see some potential advantages to stickyxfce - since it is made from a script, it is easy to modify parameters (such as coordinate positions as mentioned somewhere in its thread). With xfce Window Manager, you probably just get what it gives you and have to live with that, so depends if you need more variability. I suspect both might be useful, but have to be careful to avoid clashing keybindings (a common issue more generally).

[rockedge]

@wiak good points! I will experiment more with the built in options as well. stickyxfce can be adjusted for sizing which is an advantage.

[wiak]

Just a quick mention that I had another go tonight trying to boot KLV-Airedale frugal installed onto internal nvme hard disk of this tricky secure boot HP Probook I have.

I used latest KLV (which has that different busybox WDL initrd required). I first enrolled puppy.cer in the UEFI BIOS and tried booting the internal nvme SSD-installed KLV via a usb stick that had Puppy grub2 configs on it (from fossapup). I'm sure I've tried that before and was disappointed it didn't work, but tonight it did...

That tends to confirm my feeling that it is the Ubuntu grub2 that needs a secure signed Linux kernel/modules, whereas the grub2 from Puppy doesn't have that requirement. (Previously I had installed Zorin, which is based on official Ubuntu, to dual boot with the machine Win 10 installation and that had auto set things up putting Ubuntu grub2 onto the nvme SSD). So next, step would be to get that Puppy grub2 working from the nvme SSD rather than having grub2 on a usb key. Whether I get that far I don't know - this machine has an important business-use purpose and I shouldn't really be risking it the way I'm doing. I am fine with Zorin on this machine and know that Ubuntu grub2 method works very well, but I may remain cautious about trying to replace that with the grub2 from Puppy since I don't really need it and pushing my luck a bit thus far I feel (considering my general ignorance in terms of detail of how secure EFI booting works and there may be well be further pitfalls I don't know about or understand). Mind you I would like to confirm using that non-Ubuntu grub2 would solve the needing-ubuntu-signed-kernel-etc issues I've had, so temptation continues to plague me...

[wiak]

So today I considered using LICKS to dual boot Win10 with Linux; I suspect that method would work fine on this secure boot machine. But I couldn't find enough information to convince me I could remove it cleanly afterwards if I decided to revert back to Windows own boot loader, so I've decided against it on that basis. I don't mind experimenting if I have enough knowledge to reverse the damage I do, but I'm not daft enough on this occasion to take gamble.

Instead, I've decided to stick with using usb stick that has nothing but grub2 and related files on it, to boot from installations I'm creating on internal nvme SSD hard drive of this secure boot HP Probook 430 G8 machine. I've simply put the usb stick as highest in boot priority, and really that works quite well (I can as I said take the usb stick out after booting).

We use Zorin Linux (full install) for business uses now, so I may go ahead and install that as actual dual boot into a partition of its own again. I do that with the knowledge that I have already been able to successfully remove Zorin, it's signed grub2, and back to standard Win 10 Pro boot loader. I'll double check first that the usb stick method continues to work since then I can confidently have KLV-Airedale on my internal nvme SSD, as I do now (in fact that's my main distro at present and I'm posting from it). I can also successfully boot any weedogit distro installed to same nvme SSD, so only minor annoyance is having to use that usb key at boot time. I can live with that.

I'm not sure at all that I can successfully also use SG2D usb stick with this machine. My limited understanding is that it would have to use a grub2 that worked with puppy.cer. Frankly I still don't really understand this EFI secure boot stuff (despite tons of reading/research I've done), but I'm having remarkable success regardless of that ignorance on my part. On the whole I don't myself care overly much about SG2D, though it does have enough attraction to interest me (but I don't like Ventoy - too tricky I find); fact is I find weedogit and pupit script method very easy to do typical frugal installs (without having to personally remember all the manual steps - though I just need to read these scripts when I forget anything anyway, and the weedogit mechanism has proved very flexible for my uses anyway).

EDIT: Yes, now tested/checked, I can indeed have proper dual boot on this secure boot machine using Win 10 Pro with signed Zorin kernel with Zorin official grub2 installation (which I think really uses official Ubuntu grub2). That grub2 will not boot KLV-Airedale (even if puppy.cer enrolled in UEFI) but the usb key method using Puppy grub2 on the usb stick does indeed successfully boot KLV-Airedale installed onto internal nvme SSD on this machine, so I'll stick with that since doesn't limit me at all really. I thus really question how secure 'secure boot' really is when it is so (relatively) easy to work around it.

[wiak]

Anyone who uses any weedogit distro should also, in my opinion, keep KLV-Airedale as one of their systems because that's where any or all related developments are likely to come. Eventually I may well package parts of the community-contributed-to KLV-Airedale developments separately for incorporating into most any weedogit distro build (for example members of my family use weedogit versions of Zorin and EndeavourOS), but in terms of keeping up and tracking developments you might want KLV-Airedale is where it happens.

[rockedge]

Excellent progress report @wiak !
I am in Colorado at the moment and limited to the phone. I didn't bring a laptop this time around to avoid bringing any luggage.

Beta 15 will follow very soon.

[wiak]

I had another development.

First was a failure... After doing a full install of official Zorin on a partition of its own (dual-booting using Zorin grub2 with existing Win 10 Pro) I tried hacking the grub2 installation to use the grub2 from Puppy with the hope internal nvme SSD KLV-Airedale could then be booted without usb grub2 stick. Alas, all that did for me was to wreck grub2 working, so I had to erase the full installed Zorin and re-install it to get its grub2 working again!

However, long time back, just as a test, I tried getting a weedog Zorin variant booting from that official Zorin grub2, but failed at the time. Tonight I tried that again and it worked. So now I can boot both a full official install of Zorin, but also a WDL_zorin (weedogit-created) without needing the usb grub2 stick. This confirms my belief that that Zorin grub2 seems to require signed kernel (and probably signed modules to go with that secure boot chain). I suspect I could enrol, say a Debian or a Fedora key in UEFI and then these distros could be booted too (and/or a weedogit version of them). I'll try that some time, but my next test will be another repeat of something I tried before (and failed with previously): using official Zorin kernel and modules to boot KLV-Airedale. I think that should work - no idea why I failed trying it the last time, but I suspect I didn't have the most recent WDL initrd at the time so the failure may have been nvme-related rather than secure boot related. Will report back later on any of that.

Meanwhile, delighted to have WDL_zorin XFCE working too, since I can also use that to try out some of the KLV-Airedale developments (and can still use KLV-Airedale at any time too albeit after booting with external usb grub2 stick...).