KLV-Airedale-beta+ Released, Ready for Download

[Clarity]

Yes, QEMU alllows screen capture such that one can easily slow down and review the console messages leading to the failure.

[Clarity]

Several, here, have seen this forum package management discussion starting from an appeal by @dimkr for volunteers.

Anway, there is a video in that for a Package management assistance that might be appealing for use.'

Today, that author pops another video of an additional PM tool, here.

This is NOT a request for any changes. Rather, if is merely information for those who value PM and anything that will improve while also making it easily understood and used.

[Phil_54]

1. Loving KLV-Airedale, thanks rockedge. Using release 16 via wiak's weedogit for frugal install, I've noticed after update xbps-install -Suy the size of the folder is now over 2Gb. Is this to be expected or should I try to 'clean' the installation? I'm running on SD card in old 16Gb Chromebook. (note I've installed Iron-portable browser as well). Base sfs files seem ok, but all files in 'upper_changes' folder created by weedogit.sh are 1.5Gb. Is there another way to frugal install than weedogit, that does not create such increase? [Note: this may need to be in weedogit forum instead of here?]
2. Also tried installing a couple of small games, 2048-qt and Aisleriot. 2048-qt appears in menu and runs fine. Aisleriot appears in menu and doesn't run. Can't find whats missing as similar files installed on GalliumOS. xbps package broken?

Any advice appreciated on both the above. Apologies if in wrong place.

[wiak]

1. Loving KLV-Airedale, thanks rockedge. Using release 16 via wiak's weedogit for frugal install, I've noticed after update xbps-install -Suy the size of the folder is now over 2Gb. Is this to be expected or should I try to 'clean' the installation? I'm running on SD card in old 16Gb Chromebook. (note I've installed Iron-portable browser as well). Base sfs files seem ok, but all files in 'upper_changes' folder created by weedogit.sh are 1.5Gb. Is there another way to frugal install than weedogit, that does not create such increase? [Note: this may need to be in weedogit forum instead of here?]
2. Also tried installing a couple of small games, 2048-qt and Aisleriot. 2048-qt appears in menu and runs fine. Aisleriot appears in menu and doesn't run. Can't find whats missing as similar files installed on GalliumOS. xbps package broken?

Any advice appreciated on both the above. Apologies if in wrong place.

1. For the case of KLV-Airedale, weedogit.sh simply extracts all the files from the iso and makes a normal frugal install (i.e. exactly as you would do if making frugal install manually), so doesn't make it any bigger.
When you upgrade with xbps-install -Suy, not only do the new packages get upgraded and thus appear inside upper_changes (persistence folder) but also Void Linux xbps stores the downloaded .xbps installable packages into /var/cache/xbps, where they later take up unnecessary extra space. You can remove them manually since they are not needed - however, there are commands that may be better trying to do that. Here is a webpage detailing various clean-up command (including for clearing that cache): https://nanxiao.me/en/clean-up-disk-spa ... oid-linux/
Note that one of them purges any oin /var/cache/xbps. You can remove them manually since they are not needed - however, there are commands that may be better trying to do that. Here is a webpage detailing various clean-up command (including for clearing that cache): https://nanxiao.me/en/clean-up-disk-spa ... oid-linux/
Note that one of them purges any old kernels/modules and so on which could also be taking up unneeded extra space.

But there is another trick that takes some organising but can save stored disk space in the end:
a. start with a fresh install (so empty upper_changes) and don't boot or upgrade yet.
b. use unsquashfs to decompress the main 07KLV-airedale_rootfs.sfs

Code: Select all

unsquashfs 07KLV-airedale_rootfs.sfs

You change the filename of the resulting squashfs-root to upper_changes (make sure it is the only upper_changes folder). You can then delete the original 07KLV-airedale_rootfs.sfs since that upper_changes you just made contains everything that was in the sfs. However, you do need a dummy numeric filesystem (even though it won't be used) so simply make an empty directory with suitable 2-digit numeric name. For example, this will do:

Code: Select all

mkdir -p 07dummy

Now boot your KLV distro for the first time and do the xbps-install -Suy upgrade.
All the new upgrade packages will overwrite those in your specially prepared upper_changes folder (so not waste additional space). You still need to clear the /var/cache/xbps if you wish of course to remove the download xbps packages per that link: https://nanxiao.me/en/clean-up-disk-spa ... oid-linux/

The resulting system is a frugal install that acts like a full-install in that new packages will truly replace old ones (hence we refer to that method as a pseudo fullinstall, but actually it remains a proper frugal install with all frugal install advantages). That is one of the advantages of KLV-airedale along with that secret that, unlike most other frugal installable distros, it doesn't care whether addon filesystems are sfs files or uncompressed directories.

2. As far as a Menu game not starting up. You should try starting it from a terminal rather than from the Menu. If you don't know the command used to start the game, I'd advise you to look in /usr/share/applications/ folder for the desktop file of the game - open that desktop file up in an editor (such as geany) and look for the 'Exec' line: that contains the command used to start up the game.
Starting the game from a terminal has the advantage that you normally then see the error messages (which might be missing libraries that you can later install or whatever).

3. OPTIONAL: MAKING IT ALL SMALLER AGAIN.
NOTE that pretty much all distro swell up to a few GB in size (in their persistence folders) if you upgrade all their packages. That's because the save persistence folder storage (which is KLV is upper_changes) is not itself compressed, so the size of packages once they appear in there are several times larger than they were when kept in squashfs (sfs) form. If you want to get the 'small' size back after the above upgrade method, then simply reverse the process (assuming you won't need to upgrade again for a while). That is, after the upgrade reboot back to the original Linux host you made the build from (or any suitable other Linux distro) and convert that new big upper_changes into a squashfs using for example:

Code: Select all

mksquashfs upper_changes/ 50upper_changes.sfs

or whatever filename layer 2-digit number you want to give it.

You no longer need the empty 07dummy, but it doesn't do any harm either since adds nothing to the overlay since nothing in it anyway...

A new empty non-numeric upper_changes folder will be auto-created on reboot (or make one manually), which will be used for future additions (and if you wish you can later make additional changes sfs files such as 51upper_changes.sfs simply be using mksquashfs command again later (with new numeric value). That gives a simple 'roll-back' mechanism to the KLV operating system (i.e. you could later delete any 51upper_changes.sfs and get back to the earlier 50upper_changes.sfs historic situation... Remember also that you can choose to keep such rollback NNupper_changes folders compressed as sfs files or uncompressed - either will work... but sfs keeps things smaller on your hard disk (but no difference in RAM).

[rockedge]

Well said @wiak !

I have several examples of "frugal pseudo full install" KLV-Airedale's. They look basically like this:
(this version is using a Void Linux kernel 5.18.16_1)

Screenshot(14).jpg (19.47 KiB) Viewed 1340 times

Notice that in this "pseudo full install" that the /boot directory is not needed. Also in most frugal installs the /boot directory is not needed.

@Phil_54 To make an easy frugal install download the ISO from -> https://rockedge.org/kernels/
under ISO->Kennel_Linux->beta17 (or beta16) and mount and open the ISO (extract the contents).
Create a directory on the target partition and copy the contents of the ISO file into it.
Make your boot menu include the boot stanza to boot the KLV and your good to go.

Screenshot(16).jpg (23.22 KiB) Viewed 1338 times

[Phil_54]

@wiak - brilliant description and advice. Thank you. I will do this later today.
Re the game not starting, I did use the terminal with the exec command (it was 'sol'). It closed the terminal, and that was that. I'll dig further. I'll try some other apps to install to see if it replicates, and if so, come back here.
Edit Aug 22: Terminal launch gives "Non UTF-8 locale (ANSI_X3.4-1968) is not supported!". Chased this on google, but didn't find specific help. I can't find how to load ANSI_X3.4-1968. A shame, I like this solitaire collection. I can play it on other linux installations though.

@rockedge . Thank you also for a better understanding of frugal. I'll try version 17 now.
Please keep this developing towards a stable release. It is the best small distro that has integrated so well with my old chromebook.

[wiak]

By the way, rockedge, the upcoming release of version 2 of weedogit.sh scrapes the current KLV-Airedale version from your first thread post page so for the moment, by default, it will be installing beta16 rather than beta17 though a user of weedogit.sh script can still manually put in the beta17 address for the iso instead.

Of course weedogit does not weedog klv-airedale at all since it is already in perfect frugal installable form! It just copies all the files out of the iso into whatever bootdir a person wants to use (wherever they run weedogit.sh from), but I didn't bother deleting boot folder since so small anyway of course. The version 2 of weedogit.sh also has a big improvement in that the grub.cfg and menu.lst configurations it suggests are now complete, meaning that they now auto-use whatever the folder name is that the build was done in and auto-insert the required UUID's so it will just boot straight away once the stanza is copied into grub.cfg (or menu.lst); saves having to even think or use blkid to manually find and insert the UUID - all now done for you! A bit experimental the automatic stuff, but seems to work on my tests this evening - makes it even easier to use for any of the distros it handles. Currently I'm posting from a quick weedogit build of Mx XFCE, but I put it in a folder called WDL_linlite just to confuse myself... hahaha, but it still auto used that folder name and correct UUID for where it is so booted fine as hoped...

[Clarity]

... but it still auto used that folder name and correct UUID for where it is so booted fine as hoped...

I do understand the benefit of using UUID. But, I also understand the benefit of using the partition LABEL. Is there a chance that the LABEL could also be 'advantaged' at boot?

An idea which would not diminish or change the ideological architecture of booting via GRUB2/etc.

[wiak]

... but it still auto used that folder name and correct UUID for where it is so booted fine as hoped...

I do understand the benefit of using UUID. But, I also understand the benefit of using the partition LABEL. Is there a chance that the LABEL could also be 'advantaged' at boot?

An idea which would not diminish or change the ideological architecture of booting via GRUB2/etc.

KLV-airedale can boot via LABEL information. However, all partitions will be assigned a UUID when created whereas a user may 'optionally' not have assigned any LABEL in which weedogit.sh would be left in the dark... I suppose, weedogit could search to see if a LABEL had been assigned, but that's an added complexity, but I'll think about it for future possibility. I can see how using LABEL would work for those whose always assign a common LABEL name for partition where they store frugal installs since then you could easily move a frugal installation from one partition to another, even on another disk, and would still work via the same-named LABEL.

[fredx181]

Some findings about gvfs mount (problem with nvme partitions only perhaps ) : viewtopic.php?p=65129#p65129 (see at Update and Update2).

[fredx181]

Some findings about gvfs mount (problem with nvme partitions only perhaps ) : https://forum.puppylinux.com/viewtopic. ... 129#p65129 (see at Update and Update2).

Obviously the problem with the gvfs mount is not having to do with "nvme", just tested google-chrome-portable from Mikewalsh on a "normal" partition mounted with gvfs (on USB, not nvme) and got the same 'permission denied' error.

[Clarity]

I look forward to the next KLV allowing LABEL use in the boot stanza.

On EVERY computer I have, for years now, I have a Linux partition (ext4) named Persistence for keeping ALL of my save-sessions. It is referenced whenever I boot a PUP/DOG on any of these PCs. It is a standard for my housekeeping knowledge of PUP/Forum distro boot sessions. There on those PC, they each have a folder named "/Sessions" for easy visual understanding to find any/all PUP/DOG sessions that are saved.

Persistence for PUP-DOG use.jpg (34.76 KiB) Viewed 1340 times

Session folder for PUP-DOG use.jpg (14.35 KiB) Viewed 1330 times

Mechanisms for identifying where Sessions are saved:

• In PUPs, @gyrog's SAVESPEC file is a director for this without boot-time interactions.

  

  SAVESPEC in BOOTISOS folder.jpg (21.01 KiB) Viewed 1327 times

• On pristine PUPs and DOGs (PFIX=RAM), I sometimes will need to edit the boot-stanza at boot-time to direct to the partition via its label or via a partition designation.

• The recent changes added to weedogit.sh, here, @wiak addresses the ability to reference KLV or debian-type DOGs via the partition's label; same as the PUPs and DOGs of the forum.

Thanks @wiak for your continued contributions making things easy for community understanding and use.

[wiak]

I look forward to the next KLV allowing LABEL use in the boot stanza.

Clarity, KLV-airedale already does allow LABEL use in the boot stanza. I was referring to the weedogit utility automatically creating suitable UUID or LABEL syntax for any and all distros it was weedogging including KLV-airedale, with the appropriate directory and label values in it (though KLV-airedale itself doesn't need weedogged anyway - just usual uncompress). So nothing to do with weedogit really, KLV-airedale already does work with LABEL, but that has never been documented properly (my fault). The grub2 menu stanza that would be used in simplest form is as follows (assuming partition labelled "Persistence" for your case. Just try it (obviously you will need to change directory name WDL_klv throughout to whatever you have called the relevant bootdir on your system):

Code: Select all

menuentry "WDL_klv" {
  insmod ext2
  search --no-floppy --label Persistence --set
  linux /WDL_klv/vmlinuz w_bootfrom=LABEL=Persistence=/WDL_klv
  initrd /WDL_klv/initrd.gz
}

What weedogit.sh usefully does is creates the above stanza automatically (with correct dir and label or uuid values per where the build was undertaken) as a report in its grub_config.txt output, but it has been the case for a year maybe that a WDL initrd user could use the above LABEL form of stanza to boot the likes of KLV-airedale.

[rockedge]

@Clarity LABEL is what I use most of the time:

Code: Select all

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

[Clarity]

I had been using the partition designation in the past; namely 'sda4' on this PC. The Sessions are always kept on each PC's Linux system drive whose partition is named 'Persistence'.

I will try LABEL soonw_bootfrom=LABEL=Persistence=/Sessions/ instead of the sda4 designation. The label is more universal as every PC I have has a Linux partition named "Persistence" started back in my days of Knoppix. From PC to PC the drive designation may change, BUT the Linux partition is ALWAYS labeled "Persistence" for saving sessions when PUPs/DOGs are booted on each.

Mind you, in my use I hope everyone understands, all Sessions are maintained in the "/Sessions" folder on this PC's system drive (sda4), while all ISO files is on a SG2D USB. This brings to the table a simple understanding of PUP-DOGs usage into a singularity: Boot from their ISO file directly and Save all sessions activity within the Sessions folder. Thus yielding a no-hassle Frugal operation.

Will report results as soon as I can test.

[wiak]

Code: Select all

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

Aside form being for grub4dos that one you gave above rockedge is a bit different from the grub2 one I gave. Your one still using uuid to find the partition, whereas below finds via LABEL:

Code: Select all

menuentry "WDL_klv" {
  insmod ext2
  search --no-floppy --label Persistence --set
  linux /WDL_klv/vmlinuz w_bootfrom=LABEL=Persistence=/WDL_klv
  initrd /WDL_klv/initrd.gz
}

but yes, that label grub2 method has been available as boot stanza for a year or more.

[wiak]

So, because I've been using weedogit A LOT recently to test out lots of weedogged upstream distros and on this laptop of mine that has huge Windows ntfs partition (shrunk per my usual so I have Linux fs for frugal installs) I have been running out of space and have my eye on the bags of ntfs space Windows still has. I don't want to shrink its ntfs partition further though so suddenly became interested in using an ext4 savefile and been experimenting with that in modified WDL initrd. Actually, the experiment only required one line modified in the initrd/init and one line added to w_init (where all the real work gets done). It works fine. However, to make it a proper 'option' I will have to add half a dozen extra lines to auto-select the ntfs-related mount code when the savefile is present and when underlying fs is ntfs or fat - probably won't get round to that for a while, but definitely on the cards. I did have tons of trouble getting it all to work, but that's because I made a simple mistake and didn't notice. Also whilst doing this I stumbled across an error in w_init for case of w_copy2ram when also using RAM2 mode - not surprised I missed it before since so many combinations/permutations of ways of using WDL initrd in w_changes RAM modes. Only effects that one combination so not probably important to most people, but I will fix it next time I make a new release (presumably also with the savefile in addition to usual preferred savefolder option; savefile really just usefuil if wanting save persistence on non-Linux filesystems of course - more generally I hate them...).

[rockedge]

Your one still using uuid to find the partition

Will Grub4Dos work with a similar approach to find the partition using LABEL?

Like this:

Code: Select all

title KLV-Airedale-beta16 (LABEL)
  find --set-root --label psystem
  kernel /KLV-Airedale-beta16/vmlinuz  w_bootfrom=LABEL=psystem=/KLV-Airedale-beta16 net.ifnames=0
  initrd /KLV-Airedale-beta16/initrd.gz

[wiak]

Your one still using uuid to find the partition

Will Grub4Dos work with a similar approach to find the partition using LABEL?

Like this:

Code: Select all

title KLV-Airedale-beta16 (LABEL)
  find --set-root --label psystem
  kernel /KLV-Airedale-beta16/vmlinuz  w_bootfrom=LABEL=psystem=/KLV-Airedale-beta16 net.ifnames=0
  initrd /KLV-Airedale-beta16/initrd.gz

No, I don't think so.

Instead can use a unique marker file. In weedogit builds a file is created called grub_config.txt and I simply use that as a marker file (any file should do as a marker I think), but I don't have grub4dos on my systems just now so couldn't test. The menu.lst stanza looks like this:

Code: Select all

title WDL_klv
  find --set-root --ignore-floppies /WDL_klv/grub_config.txt
  kernel /WDL_klv/vmlinuz w_bootfrom=LABEL=frugals=/WDL_klv
  initrd /WDL_klv/initrd.gz

By the way, is there some reason you are not updating the first post thread link to beta17? I scrape that download link in weedogit.sh nowadays to build it and so always getting beta16 that way.

I still find KLV-Airedale the best xfce distro in terms of resource usage - quite a bit less RAM used than most other xfce distros. Less background services running I suppose.

[rockedge]

is there some reason you are not updating the first post thread link to beta17?

Yes, I was hoping beta17 had another quick download and fresh install to double check that there is no lingering Chrome profile holding stored logins before putting the link to now beta18!

[rockedge]

KVL-Airedale-beta18.iso is ready for download in the usual place

More information and the direct download link is in the first post of this topic

[wiak]

is there some reason you are not updating the first post thread link to beta17?

Yes, I was hoping beta17 had another quick download and fresh install to double check that there is no lingering Chrome profile holding stored logins before putting the link to now beta18!

Sorry became busy so never had time to do Chrome-portable check again. Maybe today!

[wiak]

I'm been busy today - working on new initrd.gz - jump to version 6.0.0

Modifying/developing the initrd/init is never something I do readily - so tricky, and when most all working solidly, I prefer to leave well alone...

However, owing to my experimenting with so many weedogged distros and running out of ext4 space I want to try them on my plentiful ntfs partition. Of course, with initrd version 5.x.x I can already do so, but only with w_changes=RAM0 mode since can't use a save folder on ntfs (symlinks, for example, would likely not work, and other matters besides). But yes, instead could use a linux formatted savefile image, though I took the view that I never use these (since always use Linux format for my WDL installs thus far).

Yesterday, I basically tested that would work with both direct writes (w_changes default, which is same as w_changes=media and w_changes=""), and with w_changes=RAM2 (yesterday, I just checked the /mnt/layers/upper_changes/ /mnt/layers/uc_ro/ directories ended up with the appropriate savefile image contents merged and, where appropriate in read-writable form. Pretty simple for individual test scenarios (such as RAM2 with ntfs).

However... it is one thing to get things 'basically' working in a one-off test initrd/init, but to combine the functionality such that it works with any of w_changes= default, RAM0, RAM1 or RAM2 modes, and taking into account whether the underlying media partition is say vfat, or ntfs, or Linux format, risks breaking the selection logic of the whole initrd/init...

Of course, it is an even more complex undertaking since WeeDog initrd allows putting upper_changes anywhere on the system... so I want same flexibility when using a savefile image instead of an uncompressed upper_changes directory.

Anyway, this is just a report that I'm getting there and new initrd ver 6.0.0 should be just round the corner - hope to finish it tomorrow sometime, though will test it for some time prior to release, and will need lots more testing by others later since far too many combinations involved in flexible WDL initrd/init for me to be sure I tested every eventuality. Indeed, all of these are now working with vfat, and ntfs with linux formatted savefile: w_changes= default, RAM0, RAM1 or RAM2 modes. It's a wonder I bothered doing this since it is only really for those who insist on making frugal installs to the likes of vfat or ntfs and still have save persistence, which is not usually me ever (since habitually always using Linux format partitions with easy save persistence), but I suppose it's good to fill that tiny gap in functionality.

[wiak]

Using the new initrd facility is very straightforward. Completely backward compatible - nothing to change there in any way at all.

If you want to use a savefile, you don't need to change any grub config or put in any optional arguments anywhere. The way it works is quite simple: if you don't provide a savefile (which you normally don't) then weedog will make and/or use pre-existing uncompressed upper_changes folder, be that on external media or in /mnt/layers/RAM for the w_changes=RAMn modes. That's how it is now.

If however you do provide a savefile, weedog will notice it and use that instead (whether on Linux or non-Linux partition doesn't matter, and no matter what w_changes mode you want to use it for). If you try and confuse weedog by providing two such savefiles, weedog will just use the first one in alphabetic order. i.e. it is all very automatic and user of savefiles doesn't need to think about how it all works under the hood. I try to always make weedog a sensible/clever but flexible weedog that behaves itself without further work on my part. I enjoy weedoggiting all these other and upstream distros too since then they all obey any and every command all weedog's obey without argument.

My own brain gets tired when life gets too complicated for me so that's why weedog is pretty much a one-script wonder-dog: a skeleton that is full of flesh and plenty of bite - so simple in that sense that it is almost crazy to call it a build 'system'; the surprising thing (to me actually) is that the approach ended up working as various results thankfully evidence.

Truth is, the design has grown out of my laziness or you might have needed to download a huge gzipped build system full of scripts, component parts, and complex interacting pieces, but then, by now, I would have lost the track too, but I haven't yet (and I try my best to encourage others to do the hard work involved after...). One script (or maybe two at the most at any one time) is probably my comfortable limit so I work with that limitation to guide me. I do think I used to be able to work with more complex assemblies than that - horrible C includes and header files and so on, but despite the wonders of grep I tend almost entirely to avoid such pain nowadays.

[Clarity]

As @wiak is sharing..."NTFS". I am curious to something I saw on old forum.

My question: With Linux now taking on NTFS (secure 30 year old filesystem technology), does todays NTFS in Linux allow "linking" same as Linux. If so, should we (or rather 'can we') save Sessions FOLDERS on a NTFS Linux filesystem? Currently ONLY Linux EXT2/EXT3/EXT4 filesystems are allowed. Security is similar-same and respected in Linux, but ...

Use of save-files are a maintenance component which is unnecessary in save-folders.

If session's save-folders would work as it does for the mentioned Linux filesystems, it would eliminate a need for Windows "converts" users to create a Linux files-system for experiencing all that PUPs have to offer.

I am looking at this, not as a Microsoft proponent, rather as viewing the filesystems as FILESYSTEMS; nothing more. This is viewed in light of NTFS being accepted in Linux kernel development.

If the none of the old concerns have changed, then this post should be ignored.

[rockedge]

@wiak Looking forward to v6 for inclusion in the KLV-Airedale builds. An added save file on NTFS partitions ability will be an important addition.

Since save folders do not work well ISO booting on most non-Linux disk formats, and since I do not really use ISO booting because it's a painful experience to get constant performance across all the different approaches.

Reasons:

#1 is if I am going to ISO boot then I'll use ISObooter.

#2 I rarely use ISO booting so I'm not willing to spend the time to specifically cater to this feature. @Clarity if you would like it to work better in ISO booting then go for it and fix it so it will.

#3 I'm happier that KLV-Airedale works well on ChromeBook's.

#4 I'm happy KLV-Airedale will work as a frugal install alongside Micro$$ stuff.

#5 I do not see any advantage in booting ISO's. Just to much compressed file structure in a read only state. So in my case....no fun and unnecessary.

#6 my brother is a rocket engineer/scientist and responsible for the Artemus moon rocket's 2nd stage (the core stage) which launches for the first time hopefully on Aug 29th. Most powerful rocket ever made and I'm enthusiastic about the mission. (a little quote from HAL9000)

hal-9000-eye-320.jpg (5.56 KiB) Viewed 1270 times

[Clarity]

... my brother is a rocket engineer/scientist and responsible for the Artemus moon rocket's 2nd stage (the core stage) which launches for the first time hopefully on Aug 29th. Most powerful rocket ever made and I'm enthusiastic about the mission.

Great to know your family members are contributing to positive movements of mankind.

Fantastic news. Sure you are proud!

BTW: You have done something similar by "launching this forum".

[Clarity]

Following 3 steps just done with the KLV ISO file. (less than 2 minutes, total time, to operational desktop)

1. Just downloaded Beta 18.

2. Opened "qemu_gui" in terminal

3. booted the ISO file to desktop

4. ALL is well and browsing is operational!

This is normal for KLV booting.

QEMU BOOT Stanza created and executed from QEMU_GUI

Code: Select all

qemu-system-x86_64 -boot d -m 2048 -enable-kvm -cdrom /mnt/sdc2/boot-isos/KLV-Airedale-beta18.iso -smp 2 -cpu host -usb -device usb-tablet -device AC97

I have other QEMU stanza I test from, as well with varied storage and needs. I also have QEMU stanzas that I test booting SG2D, Ventoy, and ISObooter USB sticks to emulate their bare-metal operations.

I know the mention of this is upsetting to some, but hopefully, some will find value of this ability to quickly get to desktop (or to use in a productive manner, quickly)

[rockedge]

I've only actually booted beta17 and beta18 once each on bare metal machines.

Most of the testing for these 2 models has been with QEMU and VirtualBox machines!

[mikewalsh]

@Clarity / @wiak :-

So far as I'm aware, a save-file will run from almost any storage, regardless of format.....because of the "internal" Linux file-system. I always used these on the old rig, 'cos copying save-folders used to take SOOO long.....hardly surprising, given the elderly hardware in use (including DDR1 RAM)..!

With this new rig, a save-folder copies/transfers a sight faster than a save-file would in the old one. That's progress, I guess.

Personally, I've used ext3 from my very first Puppy. I've seen no reason to change from it.......it's always been dead reliable.

Mike.