KLV-Airedale-beta+ Released, Ready for Download

[wiak]

@wiak I played around with the session save checkbox in the early alpha phase and I remember it did something unexpected but I don;t remember the details. I will have to play around with it.

I will also look at the save2flash and see if we can track down the mechanism.

I don't have qemu KLV-Airedale up just now cos going out. Last look I had however, I became to suspect that the issue may be in /usr/local/bin/snap-ex - possibly something to do with console operation. In quick test I disabled that script and I 'believe' the snapmergepuppy did not then occur at shutdown. I note a /dev/console mentioned in it for the dialog and perhaps that doesn't apply in qemu session (I haven't checked further for now).

[rockedge]

@wiak, @fredx181 It seems the IF statement isn't working:
/usr/local/snap-ex Line 4

Code: Select all

if grep -q "w_changes=RAM2" /proc/cmdline || grep -q "w_changes1=RAM2" /proc/cmdline; then

But it might be that this part of the script isn't even reached. If I manually run snap-ex it goes through a save.

[fredx181]

@wiak, @fredx181 It seems the IF statement isn't working:
/usr/local/snap-ex Line 4

Code: Select all

if grep -q "w_changes=RAM2" /proc/cmdline || grep -q "w_changes1=RAM2" /proc/cmdline; then

But it might be that this part of the script isn't even reached. If I manually run snap-ex it goes through a save.

FYI: save2flash can be used during a session, /usr/local/bin/snap-ex is called at shutdown (if RAM2 is specified on /proc/cmdline)
It seems to me from what I tested is that this IF statement should work, but I'll test more today, perhaps something wrong in the rest of the script.

How can I test the issue you're discussing WITHOUT qemu ? (qemu is a pain for me, it's terribly slow as my computer doesn't seem to work with --enable-kvm)
Something like this ?
w_bootfrom=LABEL=KLV-Airedale=/AIREDALE w_changes=/mnt/sda1/AIRE w_changes1=RAM2 net.ifnames=0

EDIT:

If I manually run snap-ex it goes through a save.

It's not supposed to run manually from terminal, indeed if you do that, the Save/Nosave dialog doesn't appear (and will save), it's for to run at shutdown from console.
But I could add a check for that (so that it will only save if on console).
BTW, Autologin / Login works fine now on newest beta10, congratulations

[wiak]

How can I test the issue you're discussing WITHOUT qemu ? (qemu is a pain for me, it's terribly slow as my computer doesn't seem to work with --enable-kvm)
Something like this ?
w_bootfrom=LABEL=KLV-Airedale=/AIREDALE w_changes=/mnt/sda1/AIRE w_changes1=RAM2 net.ifnames=0

I presume you are talking about booting from iso because otherwise I don't think the test will include the issue we have (where mountfrom is a read-only /dev/sr0 device). But also it may be that qemu treatment of 'console' is different (I don't know), hence my wondering if the snap-ex script dialog involving >/dev/console was working correctly with qemu. No dialog pops up but the snapmergepuppy seems to occur even when we don't want it. Trouble is, being able to work in qemu is important so I'm not sure if other test will be enough. I'll also look into the qemu problem more tomorrow anyway though - tonight I'm doing business IT work since two new laptops and screens to install and check or return to supplier if faulty... takes ages. I'm sure the RAM2 qemu issue is relatively minor (specially compared to that agetty issue you solved recently) - I also have a SG2D test I need to do since I put new facility into the initrd related to that so haven't checked it works yet. Tomorrow for me is coming soon - sleep again for me first.

[esos]

Booting beta10 direct from ISO (internal HD) in RAM2 mode using Grub4dos .
It works fine to me at next reboot the save files is there.

[rockedge]

Started beta10 in it's default mode of "normal" persistence as a frugal install. I customized the desktop and downloaded Visual Studio Code as a .deb file and converted it with xdeb and installed it with xbps.

I rebooted the system into RAM2 mode and have the customization in place but now I can save on demand or via the prompt at shutdown/reboot. This way it's easy to set up the desktop and add in the portables LAUNCH mechanisms the way I want them, then rebooted in RAM2 mode I can choose when and what I want to save and add to the /upper_changes layer after that.

In summary when installed frugally on HDD, Save2Flash and RAM2 mode are working well.

[wiak]

Booting beta10 direct from ISO (internal HD) in RAM2 mode using Grub4dos .
It works fine to me at next reboot the save files is there.

The problem (with booting from iso in qemu at least) is when in RAM2 mode you decide you don't want to save the session; gets saved anyway against your will... No such problem with traditional frugal installs though.

[rockedge]

@wiak I am beginning to experiment with beta10 on VirtualBox. So far KLV operates better on VirtualBox than on QEMU for me since I am using very basic QEMU starts. VBox finds the devices and SAMBA works with Thunar right away. Makes it very easy to share with the host machine.

I am about to play around with RAM0 and RAM2 in different scenarios (just finished updating weedoglinux forum software to the latest greatest). Soon I'll add some KLV-Airedale topics and links and try to get some documentation together in some way. Tips and tricks I think would be a plus as well

EDIT-1: Same behavior in VirtualBox as in QEMU. /upper_changes is being written too at shutdown/reboot without any prompt. So if the logic works in a frugal install but not when booting from an ISO in a virtual machine (with a formatted drive available) the script snap-ex must be being by-passed or as mentioned before, snapmergepuppy is being run directly.

Here we can see the test.sh that has the line from snap-ex, that the logic is working:

Screenshot_2022-03-20_19-43-25.png (220.23 KiB) Viewed 693 times

[wiak]

EDIT-1: Same behavior in VirtualBox as in QEMU. /upper_changes is being written too at shutdown/reboot without any prompt. So if the logic works in a frugal install but not when booting from an ISO in a virtual machine (with a formatted drive available) the script snap-ex must be being by-passed or as mentioned before, snapmergepuppy is being run directly.

Well it is good that that behaviour is consistent. I'll boot up KLV in qemu again later today and study that snap-ex/snapmergepuppy issue then.

But this particular post is for lovers of SG2D (mention no names...):

In a recent post regarding the previous WDL initrd (ver rc2; there was no rc3 release) I tested and documented how KLV-Airedale iso worked fine placed in SG2D /BOOTISOS directory. Even RAM2 (save2flash mode), or default w_changes="media", worked fine with upper_changes persistence folder being auto-written and used in same /BOOTISOS folder, and even external w_init written into /BOOTISOS worked(!) so really all pretty good. But I mentioned one issue/limitation:

If user put more than one WDL-related iso into SG2D /BOOTISOS only one could use save persistence with one of these since they cannot of course share the same upper_changes folder or w_init. If any SG2D user craved more that unfortunately raised the major potential issue - making uniquely different upper_changes folder somehow... One method would be, like puppy save files - use different filenames somehow named after the different iso, but there are huge weaknesses in that method:

1. Requires lots of auto-renaming changes to upper_changes in the complex initrd/init script (but could be done, though hardly worth the effort, and dangerous since initrd/init is such a critical component).

2. Most app/utility writers that take advantage of WDL's flexible layering facilities rely on the fact that upper_changes is a reliable name - rather than somehow having to always take care to take into account some special name related to the distro name. For example, utilities that provide rollback functionality lose ease of use, which currently is simply a matter of renaming that known and trusted upper_changes name into NNupper_changes (where NN is an appropriate doubt-digit layer name).

3. It's not just upper_changes that would need some kind of unique name for each different distro. WDL provides other facilities, such as that very powerful external w_init capability - that would need unique naming too. The overall complexity additions involved become painful.

But then I thought, that's not the way to do it. WDL needs to keep naming consistency for upper_changes and w_init for all of the above reasons. Rather we need to be able to use separate subdirectories for each iso and then the saved upper_changes and w_init files will not clash with each other. ALAS, SG2D itself only looks in a few directories for the iso files (e.g. in /BOOTISOS, and /bootisos and a few others). I don't blame SG2D design for that limitation - it only makes sense that its code does NOT need to search through other hierarchies of directories looking for isos - that would be terribly slow and complex. So... what I've done in WDL initrd/init rc4 (which is the current initrd being used in KLV-Airedale) is to support symlinks placed in /BOOTISOS to remove the limitation of SG2D's own search algorithm. Just tested that new facility and it works beautifully.

So how to use several WDL initrd using distros in SG2D such that save persistence (and external w_init) works for all of them?:

Simple. You can now put the WDL-related distro inside its own subdirectory under /BOOTISOS and alongside that put a symlink to the iso itself (which is in the subdirectory). SG2D thinks the symlink is the iso (and hence manages to find it) and WDL initrd/init sorts out where the actual iso is (i.e. follows the symlink) and sets that subdirectory as the play to save upper_changes and to read any external w_init.

For example:

1. Create a subdirectory for storing, say, KLV-Airedale iso in (any name you like):

Code: Select all

mkdir -p BOOTISOS/klv

2. Copy the iso into that klv subdirectory. For example, KLV-Airedale-beta10.iso

3. In BOOTISOS directory simply make a symlink to KLV-Airedale-beta10.iso
e.g. Assuming at terminal in BOOTISOS:

Code: Select all

ln -s klv/KLV-Airedale-beta10.iso klv.iso

or use your filemanager to make that simple symlink (that symlink's filename is irrelevant as long as it ends with .iso).

4. Repeat similar process for any other WDL-initrd-using distro.

Now SGD2 will find all these isos (even though it really only finds the symlink (which must end with filename .iso) and WDL initrd/init sets up the system to use put save persistence folder upper_changes inside the individual subdirectories being used for each distros iso. So with WDL systems, SG2D is now working just like any other psubdir-type traditional frugal install, with no limitation at all.

This is certainly convenient and powerful, and logically tidy moreover in terms of distro organisation.

I do hope SG2D continues to be maintained therefore, though the symlink capability of WDL can also be used with direct grub2 boot from iso as well, so a useful development anyway.

[rockedge]

This is certainly convenient and powerful, and logically tidy moreover in terms of distro organization.

Most definitely an important feature and ability that WDL-KLV systems have. The flexibility is there to suite all types of wants and needs. Using "pseudo full installs" or the ability to create the /upper_changes first by booting KLV in a "normal" mode then after everything is set up, boot into the RAM2 mode and save only on request.

[rockedge]

For a test I have not done in awhile is to see how easily or even if ZoneMinder would install, start and work, I ran the script ./build_ZM.sh I put together for WDL-Void64 and FirstRib some time ago.

Turns out it still works!
Ran it KLV-Airedale-beta10 in RAM2 mode and initiated a session save with save2flash

create a directory /root/Build and copy the script to it. Open a terminal and run the script

Code: Select all

./build_ZM.sh

upon completeion of the script at the next terminal prompt:

Code: Select all

hiawatha
zmpkg.pl start

remove the fake ".gz"

[mikewalsh]

Well, I take my hat off to you guys. This thing just gets better, release on release.

Well done, everyone..!

Beta 10 running here as sweet as a nut. Very smooth, very stable, and incredibly usable. I won't say it'll ever replace Puppy for me - I've got too used to the sweet li'l canine over the years! - but this certainly gets regular all-day sessions.

The icing on the cake - for me - will be to get printing up-and-running.

Rarities aside, it's got to the stage where the 'kennels' are so well set-up now that the choice of what to use for the day honestly boils down to "eeny, meeny, miny, mo..."

I don't care what I boot into. Whatever I choose, I know everything will just work.

Mike.

[geo_c]

I won't say it'll ever replace Puppy for me... it's got to the stage where the 'kennels' are so well set-up now that the choice of what to use for the day honestly boils down to "eeny, meeny, miny, mo..."
Mike.

Your comment reminds me that I've been wondering what the 'kennel' distinction actually means. Is there a link to a thread discussing it?

I'm not sure I even understand the true difference between a 'dog' and a 'pup' for certain, I think a dog is basically an actual 'mainline distro' on some level, only using squashed files and loopback layering.

So what's a kennel install exactly?

[mikewalsh]

@geo_c :-

I won't say it'll ever replace Puppy for me... it's got to the stage where the 'kennels' are so well set-up now that the choice of what to use for the day honestly boils down to "eeny, meeny, miny, mo..."
Mike.

Your comment reminds me that I've been wondering what the 'kennel' distinction actually means. Is there a link to a thread discussing it?

I'm not sure I even understand the true difference between a 'dog' and a 'pup' for certain, I think a dog is basically an actual 'mainline distro' on some level, only using squashed files and loopback layering.

So what's a kennel install exactly?

Hallo, mate.

Um; AFAIK, in the KLV-'Airedale' context, I don't think there IS any specific 'meaning' as such. It's just a name!

I use the term 'kennels' to mean my main Puppy partition, housing my collection of Puppies, each in its own, separate sub-directory. For me, as for many others, it's an affectionate term of 'tongue-in-cheek' endearment, getting into the whole 'Puppy' spirit of things.....

'Puppies' are any descendants of the original early, BK-era Pups.....almost invariably constructed using the Woof-CE 'build system' from over at Github. Prior to this, it was the older T2 build system.

'Dogs' are, as I understand it, based around 'LiveCDs' of mainstream distros, but modified to look and behave in the same manner as a Puppy.

That's all I can really tell you. Doubtless others can supply more information than I.

Mike.

[wiak]

Um; AFAIK, in the KLV-'Airedale' context, I don't think there IS any specific 'meaning' as such. It's just a name!
...

'Dogs' are, as I understand it, based around 'LiveCDs' of mainstream distros, but modified to look and behave in the same manner as a Puppy.

That's all I can really tell you. Doubtless others can supply more information than I.

Mike.

My understanding per rockedge's original klv posts is that a Kennel Linux distribution uses any chosen components from the various dog and pup distros discussed/developed on the forum. So klv-airedale, the first such distro really, uses a Puppy kernel, modules, and firmware, lots of dog-provided system control utilities (especially from debiandogs, but also from Puppy, such as snapmergepuppy for RAM2 save persistence control, and this particular KL uses the initrd boot mechanism from wee dog linux.

The main Airedale root files stem is not an upstream void Linux system but is fully compatible with Upstream since constructed via rockedge build recipe bit by bit using upstream official package manager xbps plus integration of all the above mentioned overall forum system components and utilities. Of course some aspects are very different from any void Linux system, and depending what forumcommunity adds it could end up only partially upstream compatible (like a Pup). However, the compatibility is good for reliability I think. Also, we are able to use non-upstream add on portable app systems, so best of both worlds.

[Clarity]

Curious if this view is consistent with Forum offerings:

• PUPs are distros found on this forum that are built using 1 of the "Woofs" to build the distro.

• DOGs are distros found on this forum that are built using methods other than Woof builders; aka T2/etc, for example.

Each PUP/DOG attempts to present a desktop that makes some attempts to mirrors BarryK's original Menus, desktop icons, and similar OOTB productivity offerings.

[wiak]

Curious if this view is consistent with Forum offerings:
...
Each PUP/DOG attempts to present a desktop that makes some attempts to mirrors BarryK's original Menus, desktop icons, and similar OOTB productivity offerings.

I think that last sentence isn't true or necessarily true - some do, some don't attempt to mirror much if anything about earlier Pups - up to the builder what they make it look and feel like. Except, I do think all distros discussed on this forum tend to concentrate on frugal install layer-type arrangements (whether via aufs or overlayfs) - I don't know if Puppy was the first to make such layered distros - I doubt it (though Puppy was the first layered distro I myself ever used, though I paid no attention to how its layers worked - wasn't my interest in my main Pup using days). Certainly, lots of the functionality we have become used to on Pups is purposively included as options in pretty much all forum discussed distros, but often implemented in entirely different ways. Does it matter?

Personally, I just use whatever distro appeals to me regardless of history or relationship to other distro designs. In particular I'm personally a fan of Arch Linux package management and underlying root filesystem organisation - otherwise, I'd almost certainly mainly be using KLV-Airedale since it does contain everything I like (except based on Void Linux, which is my second favourite upstream distro and best one I feel for making slimmed down distros such as KLV-Airedale and VoidPup).

In the past (a couple of decades now ago) I was mainly using Red Hat Linux (prior to it becoming such a big enterprise operation), and experimented with pretty much all the small distros (such as Damn Small Linux, Puppy, Slitaz, and TinyCoreLinux when it later came along). But I stuck mainly with Red Hat simply because I needed to teach Linux admin and needed multi-user, and most Linux exam/certifications are about RedHat, so Puppy didn't fit my overall needs, though I still liked and used it for years as a convenient boot as root to desktop system. Using Dogs for me, began from the start with the DebianDogs, which did indeed attempt to mirror Puppy functionality (and one version was also interested in the look and feel, but that changed such that DebianDogs tend to not emulate Puppy look and feel at all). Also DebianDogs were based on Debian Live frugal install technology and later Porteus boot initrd layering design, again not Puppy at all.

I've been using Linux (and small versions) for over ten years prior to the first Puppy release, but were full install distros. (First I used being Yddrasil LGX in 1993, which was the first Linux live CD, though I full-installed it from original published CD I still have somewhere, but I watched a colleague of mine try an even earlier version of Linux a couple of years prior to that so probably a Torvald's original - installed from a couple of dozen floppy disks - so I don't give Puppy too much credit for the Linux work I do nowadays - but I certainly also used Puppy for a number of years alongside some others). Obviously, when we contribute to this forum, we tend to consider what facilities traditional Puppy users are used to having, and implement similar as part of the work as best we can. There are other major influencers though - such as Slax developed by Tomáš Matějíček.

Oh I suppose: "some attempts" then, but that's a pretty much all-encompassing phrase. Also make some attempts to mirror loads of other distro Linux developments, which is what it should be about IMO. Development and research is a wide field and not limited to any particular distro (or even OS - yes, we look also at Microsoft and Apple interfaces and offerings and so on) unless you want stuck in a rut eventually. Main thing though, is that we discuss and feedback on the developments on this forum, which increases the usefulness of this forum to the general community and especially the Linux one, so hopefully helps promote this forum as a good place to join for the discussions, collaboration, and friendships involved.

Personally I think some of these 'other' small distros are all but dead in terms of real use - Slitaz for example. I'm not even convinced many will now really be using TinyCoreLinux. The fact Puppy is holding ground is a testament to a shift towards moving forward rather than standing still, and the various Dogs on this forum tend to push each other (and Puppy) forward in this world where the modern computer is like a super-computer of not so many years ago. Kennel Linux variants, and the developer and user collaborations that involves, are a good idea to pull some of the many ideas together for the ultimate benefit of all of them.

[geo_c]

Using Dogs for me, began from the start with the DebianDogs, which did indeed attempt to mirror Puppy functionality (and one version was also interested in the look and feel, but that changed such that DebianDogs tend to not emulate Puppy look and feel at all). Also DebianDogs were based on Debian Live frugal install technology and later Porteus boot initrd layering design, again not Puppy at all.

The fact Puppy is holding ground is a testament to a shift towards moving forward rather than standing still, and the various Dogs on this forum tend to push each other (and Puppy) forward in this world where the modern computer is like a super-computer of not so many years ago. Kennel Linux variants, and the developer and user collaborations that involves, are a good idea to pull some of the many ideas together for the ultimate benefit of all of them.

Thanks @wiak, that helps explain quite a bit.

If I had to sum it up in one line, I might say something like: Puppy Linux is a technique of building and installing derivative Linux operating systems, which utilizes innovative filesystem layering and compression structures, and is developed and enhanced in tandem with other unique custom builds of upline distros -- operating systems often referred to as 'dogs' rather than 'pups.'

[rockedge]

KLV is like my Wolfsburg Edition VW, lots of options and parts thrown in a car that were leftovers from a production run. A Frankenstein VW Passat.

I need a little program that examines the Hash values of downloaded ISO's. In Puppy Linux's there is just such program called gtkhash. So I went to a Bionic64 and found the binary and now it's going to be in KLV-Airedale.

Sometimes I just go through a Puppy's /usr/bin or /usr/local/bin (you get the picture) while running KLV and just click on programs to see if they'll run OTB. Turns out gtkhash is one of them and handy to have around so it's going to be included in RC1. Puppy Linux has all of these little tools and utilities that are very useful like easily making ISO's that are bootable.

As on example, a big major difference in these distro's discussed on this forum is the ablitiy to very easily mount and open an ISO go into that ISO and mount and open an SFS contained within that ISO. Click, click and one is in and ready to copy or look at individual files in an SFS in an ISO.....try that on Ubuntu or Red Hat

Name one distro not on this forum that can load then use then unload SFS packages on the fly or have them individually loadable at system boot.

[mikewalsh]

@rockedge :-

From what mikeslr tells me, the method I published for turning websites into desktop 'apps' a few years ago, is apparently very similar to a system that PeppermintOS has had in place for some years.

I've never even looked at the PeppermintOS website, much less tried to download/install/run it for real. But the old saw "great minds think alike" must have some merit here; obviously, the same technique must have occurred to at least one other person some years ago.

(Apparently, there's a native method now available for doing just this; involves the installation of Node.js and something called "npm", along with then installing an app called "nativefier".....but this would have to be installed to every single Puppy you wanted to do this in.)

I think I'll stick with my manual method, 'cos by this time I can do that one in my sleep. Plus, it's easily shared across the kennels.....and will work with most Chromium-based 'clones'. I'm not going to all that trouble when all that's required is a simple wrapper script.....though I'll own it's quite possibly a good idea for anyone who doesn't have much experience with the clones.

(*shrug*)

Mike.

[rockedge]

I still pretty amazed that the build_ZM.sh worked to the extent it did.

I made a small addition to the script that is important. Zoneminder creates directories for new alarm events to store image files and video data and for these folders tobe created with the correct permissions, an adjustment must be made to web server user /home/www-data.

The script now adds this line to /home/www-data/.bash_profile

Code: Select all

umask 022

This can be of course done manually if one has already run the script and installed Zoneminder.

Running Zoneminder on KLV-Airedale-beta10, looking at the web console on @mikewalsh's Chrome-portable

Screenshot_2022-03-23_09-20-11.png (160.63 KiB) Viewed 795 times

Remember the improtant commands to run directly after the script completes ->

Code: Select all

hiawatha
zmpkg.pl start

Also I linked Hiawatha as a runit service so I can control it with:

Code: Select all

sv start hiawatha
sv status hiawatha
sv stop hiawatha
sv restart hiawatha

Screenshot_2022-03-23_09-29-38.png (282.79 KiB) Viewed 789 times

[rockedge]

Testing KLV-Airedale-beta10 out on a 2007 Dell VOSTRO 1500, single core Celeron M CPU, 1 Gb of RAM machine that has a dead wifi device but is connected with a $9.95 WiFi USB dongle which NetworkManager finds and configures correctly. Using a wireless mouse.

System starts up boots to desktop and idles okay. Opened up Firefox v 98.0 and went to the Puppy Linux forum and logged in. Opened up 3 more tabs of light pages and Firefox remained stable and responsive enough. Forum runs good in 2 tabs.

At idle KLV-Airedale-beta10 is using 176 Mb of RAM reported by htop

Frugally installed on an internal HDD with Grub4Dos for boot mechanism.
There is a 512 Mb swap partition

[wiak]

At idle KLV-Airedale-beta10 is using 176 Mb of RAM reported by htop

Yes, for an XFCE desktop distro, KLV-Airedale64 is very efficient.

I've been battling with brand new HP business laptops (HP Probook 430 G8 with i7 processors, 32GB RAM and 1TB nvme SSD hard drive.

Trouble is, these have Windows Pro 10 (upgradable free to Win 11) with every security provision imaginable; that combination proved to be nightmare trying to dual boot with Linux... In particular, not just Secure Boot, but refuses to run without Secure Boot cos also has UEFI bios-linked BitLocker nvme SSD hard drive full encryption and HP Wolf Sentry Security at boot-watching-level and involving firmware TPM so the combination watches everything going on at boot... Worked for hours on this madness.

First tried disabling Secure Boot hoping for an easy test run, but no... refused to boot without re-enabling Secure boot and demanded now BitLocker "Recovery Key". I managed to escape out of that (but did login to Microsoft Account where BitLocker Recovery key were stored so I could record what the key was).

Realising I was in danger of bricking the laptop I did indeed back its drive up, though whether I could manage to restore it's Win10 Pro from that usb backup stick is another matter I hope I don't get tested on...

I've had plenty old HP machines (old Elitebook and not so very old Probook before) and didn't have much trouble at all getting them to work with Linux, but I've now read that newer HP models are amongst the hardest to satisfy (if at all...). I began to think it was impossible (and not knowing much at all about any of the security mechanisms involved didn't help). Anyway, I did resort to risking a try of Fossapup via its frugalpup grub2 installer onto usb stick and then booting that and registering its puppy.cer via MOK. That seemed to work, but Fossapup crashed out after storing all its sfs files to RAM... But then, I put KLV-Airedale64 on same usb stick and configured its grub2 to boot KLV. Well, that worked (first Linux I actually managed to boot on this horrendously tricky machine, albeit only from usb stick)! So far so good, I thought the problem was solved (at least if using a usb stick to boot). So I went back into Windows 10 and shrunk the huge disk to create a large unallocated portion. Then booted KLV from usb and used gparted to format the nvme unallocated part to ext4 - I thought would be plain sailing now... WRONG. I copied the KLV-Airedale folder onto that nvme SSD and configured the usb grub.cfg to boot from the system hard drive. Started booting okay but then major crash out (wouldn't mount the nvme partition KLV was on and nothing I could see to do about it... Something about the crazy UEFI security I guessed, which I couldn't disable... Stuck.

Okay, long story short, I 'solved' the main issue (getting some Linux onto this system) using the big boys, in my case using Ubuntu installation media, but FIRST, I disabled BitLocker from withing Windows 10 itself (apparently that is important - maybe would have fixed my earlier attempts with KLV, I don't know). Oh well, I chose the expert "Something Else" method, having repartitioned the nvme SSD further from KLV booted from usb, leaving a 64GB partition at nvme partition 5 for Ubuntu, and putting its grub2 bootloader in there (was just guessing that), and... I'm posting from it now. At least I now have Linux (albeit currently Ubuntu) dual booting with Windows 10 Pro now on this fast big resource of a laptop. Now I'm hoping the Ubuntu grub2, grub.cfg will be able to boot KLV and weedogged EndeavourOS on this same machine (oh, I had tried weedogged Endeavour OS in my earlier failed attempt too and also VoidPup, but nothing worked in those early attempts - Ubuntu to the rescue it seems...). So now to try Ubuntu grub.cfg mods to see if I can finally get KLV and so on to boot from this tricky laptops harddrive...

[wiak]

Yes, result not too surprising... Won't boot either KLV kernel or EndeavourOS kernel because "not-signed" (presumably meaning by Ubuntu). Way round that 'might be' to try and use Puppy grub2 and puppy.cer (or with BitLocker disabled maybe can disable Secure Boot) or, as Clarity suggests, resort to using qemu or similar, but I really want a 'raw' boot if I can get it. However, I am relieved to at least have a variant of Linux installed - I can more generally live with that (and alter it to behave the way I want and I still have my 'normal' old dev machine for most work most of the time anyway... which is important since allows me to test on more "realistic" machines (though 'which' size machine is actually more realistic now or in the coming years?

Trouble is I'm planning to turn BitLocker encryption back on again for the business Windows install, so have to probably live with Secure Boot and the rest...

One thing that may work for now will be to change the kernel used in the WeeDogged distros to official Ubuntu ones - that much is easy to arrange since just the usual copy in the relevant modules and firmware, but will other stuff need signed too I wonder. This security stuff is mental.

The tricky thing right at the moment is that Ubuntu isn't a good distro to develop on (none of the usual filemnt open up sfs files and so on by default). But I already know I can usb boot into KLV, so I'll use that to try a Ubuntu kernel on the hard disk version of the KLV and weedogit EndeavourOS installs. Actually I used weedogit to install both of them in the first case since saved much thinking on my part (except I had to copy the grub stuff into /etc/grub.d/blahblahblah and ran update-grub (yeah, I didn't resort to rough edit of main grub.cfg - I did it 'properly').

[wiak]

Only other Linux I find I can install to the hard drive and get it to dual boot with Win 10 Pro when secure boot enabled seems to be Zorin. At least it seems to be installing correctly right now; basically its a modified Ubuntu so install procedure pretty much identical, but I like the (simple/unbloated) look and feel of Zorin 16 lite (tested it previously using weedogit.sh variant). Actually, Ubuntu itself would do at a push on this machine (it is fast enough) but I'd prefer Zorin 16 lite (XFCE) if it will work. Full install though... but I still have my main dev machine, as I said, for other work (and maybe sometimes qemu if that proves usable for my purposes).

Update:
Well, just finished the install (with Secure Boot enabled). Was asked at boot to register the Zorin Mok key, which I did, and then reboot started it up straight into the desktop. Looking good. Logged in as normal user, but with simple xfce frontend I can handle that (and modify for my own purposes later). What a relief. Next I'll see how things go with qemu - will be fast enough anyway - this machine flies. Ah, it's nice - how I like it: switch user to root desktop worked like a dream. Nothing I need to do there.

Aside from the old-Windows/jwm-like bottom panel, it reminds me of KLV-Airedale being nice clean xfce environment. Not quite as efficient as KLV, but will do (though I'll have to get used to apt again). Now I have to get gtkdialog and yad on here and so on. No layering so some things won't work, but I suppose sfs-load will work since not using layers for that anyway?

Also I haven't wrecked the boot to Windows option that my partner wanted to keep and upgrade to Win 11 when it is ready for this machine (it isn't ready yet...). Of course once she realizes what a lot of junk that is, I'll be able to free up the quarter of the drive space I've left allocated to Windows...

[fredx181]

@wiak @rockedge
I got qemu working OK now (still very slow for me, but acceptable) but...
How can I save changes ? (booting from ISO) I 'd like to use RAM2 option but the guest system doesn't see any partition at all (usb or hdd).

[rockedge]

@fredx181 I have KLV going in QEMU and VirtualBox and both are very responsive and it's hard to tell that they are virtual machines.

I am trying right now to see if I can get RAM2 to work, which I have not been able to yet.

If I install frugally on a VirtualBox HDD and boot RAM2 mode that will work. It's launching from ISO (CD/DVD) that I can not get RAM2 to even see a mounted file system. I can see /root but not / in Thunar or Rox.

It seems that RAM0 will work when using the save.sh and merge_changes.sh scripts (rufwoof's
FirstRib creations) to create XXchanges.sfs and merge those if there are more than 1. They save like -> 31changes.sfs, 32changes.sfs.....so on and so forth

[fredx181]

@fredx181 I have KLV going in QEMU and VirtualBox and both are very responsive and it's hard to tell that they are virtual machines.

I am trying right now to see if I can get RAM2 to work, which I have not been able to yet.

If I install frugally on a VirtualBox HDD and boot RAM2 mode that will work. It's launching from ISO (CD/DVD) that I can not get RAM2 to even see a mounted file system. I can see /root but not / in Thunar or Rox.

It seems that RAM0 will work when using the save.sh and merge_changes.sh scripts (rufwoof's
FirstRib creations) to create XXchanges.sfs and merge those if there are more than 1. They save like -> 31changes.sfs, 32changes.sfs.....so on and so forth

Hi rockedge, I think I found what to do, added -usb -device usb-host,hostbus=2,hostaddr=3 (from looking first at output of lsusb) to the qemu command line, but get error:
libusb: error [udev_hotplug_event] ignoring udev action bind
Will investigate further.

[rockedge]

@fredx181
I have a new QEMU 4.2 running on a Fossapup64. I made a 2 Gb virtual hard drive and started KLV-Airedale-beta10 as a CD-ROM in RAM2 mode. Filesystem "/" is empty in Thunar and Rox

In RAM0 I can open " / " in Thunar and Rox

Code: Select all

root# save2flash
Merging /mnt/layers/RAM/upper_changes onto /mnt/layers/uc_ro...
rsync: [generator] recv_generator: mkdir "/mnt/layers/uc_ro/etc" failed: No such file or directory (2)
*** Skipping any contents from this failed directory ***
rsync: [generator] recv_generator: mkdir "/mnt/layers/uc_ro/mnt" failed: No such file or directory (2)
*** Skipping any contents from this failed directory ***
rsync: [generator] recv_generator: mkdir "/mnt/layers/uc_ro/root" failed: No such file or directory (2)
*** Skipping any contents from this failed directory ***
rsync: [generator] recv_generator: mkdir "/mnt/layers/uc_ro/var" failed: No such file or directory (2)
*** Skipping any contents from this failed directory ***
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1330) [sender=3.2.3]

Odd is I can cd into /mnt in a terminal but the file managers shows empty "/":

Screenshot(9).png (86.46 KiB) Viewed 690 times

[fredx181]

I have a new QEMU 4.2 running on a Fossapup64. I made a 2 Gb virtual hard drive and started KLV-Airedale-beta10 as a CD-ROM in RAM2 mode. Filesystem "/" is empty in Thunar and Rox

In RAM0 I can open " / " in Thunar and Rox

The fact that "/" is showing empty indicates that something is wrong, I guess.
Probably then the w_changes=... path is not found.