site  contact  subhomenews

Orange menu entries fixed in QV

June 10, 2025 — BarryK

In the release announcement for QV 250605, I posted a list of issues to work on.

One of those is the "orange ball" menu entries. Choose one of those, and it failed to install.

Fixed script /usr/local/orange/orange.install, see github:

https://github.com/bkauler/woof-quantum-vis/commit/27b859dfba605c748014d20212a1388613a1deeb   

Tags: quirky

Change snapshot management

June 09, 2025 — BarryK

As mentioned in previous posts, one of the menu items in the initrd is to bootup a different snapshot than the default. It is item-6:

img1

QV is unique in that each snapshot is the complete filesystem, everything under "/", not just a folder such as "/home" as other distros implement snapshots.

So, each snapshot is a complete and self-contained installation of QV. An older snapshot may work with a particular kernel version, and you might have to be careful with booting that snapshot with a later kernel. The kernel version that have been used with a particular snapshot are found in /boot, for example /boot/vmlinuz-6.6.68

If I have upgraded to kernel 6.12.32 in the default snapshot, then want to bootup the older one that is only tested with kernel 6.6.68, then we need to be able to manage this. For example, you might decide to test it with the 6.12.32, but if not happy then you will want to revert to 6.6.68.

If you choose to update the kernel, /usr/lib/modules will also need updating, as will /usr/lib/firmware

Or, you might choose to bootup the older snapshot, but switch back to the kernel that you know works.

If have booted with the default kernel, then choose a snapshot that has only used an older kernel, and you choose to switch to the older kernel, then 'kexec' is required.

If the kernel version in a snapshot is changed a lot, which may happen over time, proliferation of old versions and old folders in /usr/lib/modules, needs to be curtailed.

I had a coding marathon last night and today, and all of this has been implemented. Not yet tested. Here are the changes to the 'init' script in the initrd:

https://github.com/bkauler/woof-quantum-vis/commit/18b418fa1439c7e1362c753648d8f03eb9ca5295

Updated translations:

https://github.com/bkauler/woof-quantum-vis/commit/1f7f52149a02f29c1d9da903411e9abef1459cd7

This enhanced snapshot-change management not yet tested!   

Tags: quirky

Fix menu broken video in initrd woofQV

June 08, 2025 — BarryK

I applied this fix in woofQ, for Easy Scarthgap and Easy Daedalus, see previous blog post:

https://bkhome.org/news/202506/fix-broken-video-menu-in-initrd-woofq.html

Have done the same in woofQV. This applies to QV. Here are fixes in the 'init' script in the initrd:

https://github.com/bkauler/woof-quantum-vis/commit/8a8682dbe45f7ac1e4f54d7cd5314cfd1f12d1a9

Also, translations:

https://github.com/bkauler/woof-quantum-vis/commit/89d34694aa39ef0d44381f6ecf4794fb4c16da5b

There are other situations in the initrd that also require kexec, planning to tackle that next.    

Tags: quirky

Mini-tutorial creating a snapshot in QV

June 06, 2025 — BarryK

The boot menu in QV, in the initrd, has an item to choose to create a new snapshot. Scroll down this blog post, there is a photo; it is item number 4 in the menu, "Take a snapshot". What it does is take a snapshot of the current default snapshot.

To understand what is going on with this snapshot feature of btrfs, you can create one manually. This is a bit of a learning exercise about btrfs and how QV implements it.

The previous blog post, announcing the 250605 version of QV, also has a brief overview of QV:

...overview needs to be fleshed out a lot more.

You guys who are familiar with Puppy Linux, Puppy-derivatives and Puppy-like distributions, will know about a "frugal" install. QV is a specific type, it is a "full frugal". That is, it looks like a normal Linux installation, with folders /dev, /sys, /proc, /etc, /usr, etc., except in a folder, not at "/". In the case of QV in a USB-drive, it looks like this:

img4

...that path needs explanation...

sdc2 is the btrfs partition, folder 'quantumvis' is the frugal installation of QV. Then there are sub-folders "4/@qv" ... that needs explaining!

Back-tracking, after having written 'qv-250605-amd64.img' file to the USB-drive, and boot, there are only two folders; /mnt/sdc2/quantumvis/1 and /mnt/sdc2/quantumvis/2. "1" and "2" are just folder names. They each hold one snapshot, so the folder naming 1, 2, etc., is an organizational thing.

Folder "@qv" is also just a folder name, except it has mounted on it a btrfs subvolume. The "@" prefix is just a folder-naming convention, so that we know this folder has a btrfs filesystem on it.

On a subsequent bootup of the USB-drive, I chose to create a new snapshot; that is item-4 "Take a snapshot", and that automatically became number 3. So, looking with ROX-Filer, we see there is now a folder "3":

1

What would be very good is to create a snapshot manually, so as to understand better how it works. I am also doing it to refresh my memory, having left QV and btrfs back in November 2024.

So, current situation is QV is running, there are three snapshots, and the current one is "1". So, let us create a snapshot of "1", and number it "4":

Firstly, although we know in my case that the working-partition is sdc2 and frugally-installed in folder 'quantumvis', it can also be found like this:

# . /etc/rc.d/PUPSTATE 
# echo $WKG_DEV
sdc2
# echo $WKG_DIR
quantumvis/
#

Creating a snapshot is really easy:

# mkdir /mnt/${WKG_DEV}/${WKG_DIR}4
# btrfs subvolume snapshot /mnt/${WKG_DEV}/${WKG_DIR}1/@qv /mnt/${WKG_DEV}/${WKG_DIR}4

Now there is folder "4":

img2

Now look in folder "4":

img3

the btrfs subvolume filesystem "1/@qv" has been "copied" to "4/@qv", except there is no actual file copying involved; the snapshot happens in the blink of an eye. "4" behaves completely different, and is completely independent of "1" ...well, this is the magic of the btrfs copy-on-write filesystem.

Look at the photo at top of this blog post, it shows what is inside 4/@qv

Note: don't be confused by the word "subvolume". It is just a nested btrfs filesystem inside another btrfs filesystem. Normally, we have, say, ext4, with a single filesystem occupying the entire partition. Nesting a filesysystem may take awhile to get your head around, but ultimately you will see it as a simple concept.

To make this into a bonafide new snapshot, the file 'snapshot-record' needs to be edited (see above photo). Append a line, like this, in format number-date-description:

1|250605|Original Snapshot
2|250605|Snapshot of pristine first bootup
3|250605|test snapshot
4|250606|manually created snapshot of 1

Next thing I did was reboot, to see if can change into this new snapshot...

img6

...this is the menu in the initrd. I selected item-6, "Choose a snapshot to boot into". Then got this:

img7

...I chose item-4, clicked on "OK", then got a desktop:

img5

...see the text at top of the screen, letting you know what snapshot is currently running. This is now the default.

We could keep going, making more snapshots. Some users of btrfs have hundreds of them. Interesting discussion on this, one person suggesting keep it no more than about 100:

https://unix.stackexchange.com/questions/140360/practical-limit-on-the-number-of-btrfs-snapshots

...yes, deleting a snapshot that has children-snapshots (grandchildren etc.) can apparently take awhile.

That reminds me, I wrote about deleting snapshots in QV, in 2024:

...commented on the potential issue with children and grandchildren.

A clarification, if you have btrfs snapshot experience on other Linux distros:

Some other distros may only snapshot some folders, especially the /home folder. QV is different, it snapshots the entire "/" filesystem. With the exception that folder /files is a separate encrypted ext4 filesystem in a sparse file; the same /files appears in all snapshots.

Look at an above photo, there is file '.sparse-ext4' -- that is the ext4 sparse file. It is mounted on folder '.sparse-mnt' -- .sparse-ext4 is loop-mounted on that, then bind-mounted to /files in all snapshots.

This little mini-tutorial is a diversion. I've been rethinking some structure of QV, got kexec to work; so getting back onto that. Well, tomorrow.

If you would like to provide feedback, there is a forum topic to discuss btrfs snapshots here (hint: woofwoof):

https://forum.puppylinux.com/viewtopic.php?t=14548    

Tags: quirky

QV version 250605 released

June 05, 2025 — BarryK

"QV" is an acronym for "Quirky Void" or "Quantum Vis". It is built with woofQV. The github project page has a brief introduction to QV:

https://github.com/bkauler/woof-quantum-vis

I worked on it for several months in 2024, then went back to working on EasyOS; so QV has lapsed since then. It is a unique distro, fascinating concepts, and really does deserve to have ongoing attention. So, back on it.

You can read about the development of QV in the "quirky" tag of this blog. Here are the most-recent several posts:

...you can look through those to get basic ideas what QV is all about. Though, I do need to write some documentation.

Here is a screenshot, taken in an earlier release:

img1

A couple of things don't work...

One of the above links describes an "update PET package"; that currently doesn't work. The intention is that it will be like EasyOS; a small download. QV is a very big initial download, "qv-250605-amd64.img", about 1.8GB; however, the update PET packages are expected to be about 90MB.

The menu has some "orange ball" entries. You would know about these if you have used EasyOS. They are applications in the menu, but not yet installed, and choosing from the menu, it will download and install. Currently broken.

Well, that's all the bugs I can think of now, but of course we will find more.

The usual thing, just like EasyOS; you write the drive-image file to a USB drive, then boot it. You must use a good quality drive, and fairly big, at least 32GB. Personally, I use SSDs in USB-caddies; big, fast and last indefinitely. Currently using a "small" SSD of 500GB.

Brief introduction to QV concepts

Unlike EasyOS, QV does not use squashfs files, nor aufs/overlayfs layers. It is "frugal" though, with everything in a folder; that is, looks like a normal Linux installation, except in a folder and not under "/"

Another big difference is that the working partition is a btrfs filesystem, which brings something great to the table; snapshots. Snapshots are managed via a menu in the initrd. Photo:

img2

Snapshots are great. You could, for example, create a "compile environment" snapshot, and install the 'devx-1.0.pet' into it. Snapshot creation is virtually instantaneous. This article introducing btrfs principles, including snapshots, looks good:

https://fedoramagazine.org/working-with-btrfs-general-concepts/

I mentioned above, minimum size of 32GB; but if you really get into snapshots, like want to compile packages, or want to download woofQV and build your own QV, then you are going to need a lot more space. An SSD in USB-caddy is a good solution, or you can install to a btrfs partition in an internal drive -- QV has "QV Installer" to make that easy.

Notice the above photo, a password to decrypt the working-partition. Currently though, only the /files folder is encrypted. This folder is where you keep all your personal stuff, and you can also setup apps to store their stuff in there, like, for example a video editor project.

An important point about /files is that it is outside the snapshot mechanism, so all snapshots will see the same content in /files.

The thing is though, btrfs does not have native encryption. What has been done is rather sneaky; /files is actually a ext4 filesystem, which is in a sparse file. ext4 supports fscrypt, per-folder encryption.

Unlike EasyOS, QV does not offer containers. However, like EasyOS, QV offers each application running as its own user. This provides fantastic isolation between apps. A further security feature can be seen in the above boot menu, "Turn ON lockdown"; this will prevent the user from mounting any partitions -- the btrfs partition in which QV is running, is mounted, but the user cannot fiddle with it, nor even see outside the folder in which QV is installed.

I am intending to experiment with using bcachefs instead of btrfs. Stay tuned for that.

URL links

Primary download:

https://distro.ibiblio.org/quirky/quirky-void/amd64/releases/base/

Fast mirror in Europe, courtesy of NLUUG:

https://ftp.nluug.nl/os/Linux/distr/quirky/quirky-void/amd64/releases/base/

The EasyOS documention explains how to write a drive-image file to a USB drive, in case all you know about are ISO files:

https://easyos.org/install/how-to-write-easyos-to-a-flash-drive.html

Feedback is welcome in the QV section of the Puppy Forum:

https://forum.puppylinux.com/viewforum.php?f=236

Testers welcome!

Do bear in mind that QV is very experimental, much more than EasyOS. Report bugs, suggestions welcome.

TODO list

Lots of things to work on. Thinking, off the top of my head...

See item above "6 Choose snapshot to boot into". Each snapshot may have a particular Linux kernel, and if, for example, you switch back to a much older snapshot, that requires an older kernel, currently you will be asked if you want to update that snapshot to the current kernel (and modules), or not. If you decide to boot with the older kernel, a reboot is required, which is clumsy. I intend to get "kexec" working, which is a fast method to change kernel.

Fix the orange-ball menu entries.

Fix updating.

Write documentation.

Evaluate bcachefs.

EDIT 2025-06-06:
I have written a mini-tutorial on btrfs snapshots and how QV implements them:

Hope to write more docs in the future, though as QV is a moving target they may get out of date quick.   

Tags: quirky

woofQ changes merged into woofQV

June 04, 2025 — BarryK

woofQ builds EasyOS, woofQV builds QV. The latter is a very experimental distribution that I worked on for several months in 2024, then sometime in November 2024 dropped back to working on EasyOS. I posted about why put QV on-hold, see recent posts:

woofQV forked from woofQ; kind of. Most of woofQV is a complete rewrite; however, there are so many common factors. You would pretty much think that you are using EasyOS, except for no SFS files and no containers. No running in RAM either; hence no "save" icon on the desktop.

There are a lot more differences, but so many common factors; many fixes and improvements made to EasyOS this year could also be applied to QV. Lots of scripts are the same, and we have been applying fixes and improvements to them, that need to be merged into woofQV.

It would be extremely tedious to do this manually, going through file-by-file, seeing which ones need to be merged. So, I wrote a script to help. It is here, in woofQV:

https://github.com/bkauler/woof-quantum-vis/blob/main/buildquantumvis/support/merge-woofq-2-woofqv

It has done a pretty good job. Here are all the recent commits:

https://github.com/bkauler/woof-quantum-vis/commits/a3af5a5aeb8f4984330b3819c4fc84be0a2bb2d2/

We have good news with the bcachefs utility, got it to work in the initrd; see github issue:

https://github.com/koverstreet/bcachefs-tools/issues/386

Would like to move forward with introducing bcachefs into QV; without "burning the bridges", so can rollback to btrfs. So will have a variable in woofQV to choose build with btrfs or bcachefs.

One concern with bcachefs is that it is very slow:

https://www.phoronix.com/review/linux-615-filesystems

...if add compression and encryption onto that, wonder how much more speed will degrade?

I know that improving the speed of bcachefs is not a priority now, but even so, it has been under development for a very long time. Originally announced in 2015, so 10 years of development. More than that, because Kent was working on it for a few years prior to 2015.    

Tags: quirky

bcachefs utility crash in initrd

June 02, 2025 — BarryK

The previous post is plans for moving ahead with QV:

...thinking of replacing btrfs with bcachefs.

The bcachefs utility project is here:

https://github.com/koverstreet/bcachefs-tools

Man page:

https://manpages.debian.org/experimental/bcachefs-tools/bcachefs.8.en.html

Unfortunately, a small part of it is written in rust. It was originally written in C, but the developer, Kent, is adding to it in rust code. I say unfortunate, because it bloats the final executable, and makes it (I think) very difficult to create a statically-linked binary -- all the binary executables in the QV initrd are statically-linked.

Anyway, I put the 'bcachefs' utility from the 'bcachefs-tools' package, from Void Linux repository, as well as all required shared libraries, into the initrd.

Compiled the 6.15 kernel, with the bcachefs driver builtin. Put that into the QV USB drive, along with modified 'initrd'.

Booted, and chose to dropout to a shell in the initrd, so as to test the 'bcachefs' utility. Crashes. Have reported to github:

https://github.com/koverstreet/bcachefs-tools/issues/386

So, hoping that this can be resolved.   

Tags: quirky