QV version 240403 pre-alpha

For previous news about QV, see this blog category:

https://bkhome.org/news/tag_quirky.html

Things change every day; the directory hierarchy has changed again, yet to be documented.

This is a pre-alpha. Anyone wants to take it for a spin, you are welcome. Let me know of any bugs.

There is still some EasyOS stuff in there, that needs conversion.

Notice the download 'qv-240403-amd64.img' is quite big, 1.2GB. EasyVoid alongside it on Ibiblio is only 913MB. They contain about the same packages, mostly from the Void Linux repository. Squashfs and btrfs are both using zstd; however, squashfs compacts much more efficiently.

Maybe this is useful information if you have an Intel GPU. Booting on my Lenovo desktop PC, with 8th Gen i3 CPU and Intel GPU, the QuickSetup window shows that Xorg has chosen the "intel" Xorg driver. What I notice after a very short time, is text not displaying properly on the screen; characters missing. I have even had Xorg freeze.
The solution is to exit from X, then run "xorgwizard" from the shell prompt. A window will tell you that the intel driver is using 'sna' acceleration, and will offer to change to 'uxa'. This fixes it for me.

Feel free to test Lockdown mode, and snapshots. I'm thinking maybe it would be good to have some information on the screen, such as snapshot number and whether Lockdown is on.

A technical note. The drive-image file is populated with zstd:15, meaning compression level 15. However, at bootup, the rootfs '@qv' is mounted with zstd:3. This means that any future writes will be level-3. It was done this way to try and get the drive image as small as possible; however, there is a penalty of slower read times expanding the level-15 files. I might change 15 to 7 in the future.

The desktop "update" icon doesn't work. How to implement updating will require more thought. You can run the 'xbps' utility and do a complete package update, so why do we even need a "update" icon?
Well, might need to download some fixes, for example for the 'initrd' file, or update the kernel. QV cannot use the Void kernels.

Get the 'qv-200403-amd64.img' drive-image file from here:

https://distro.ibiblio.org/easyos/amd64/releases/void/

...write it to a USB-stick using 'dd' or whatever, and boot it.

The github repository has changed since the announcement a few days ago. It is now:

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

...you can download it; there are scripts in the 'rootfs' folder, that you run in sequence, and you end up with a 'qv-<date>-amd64.img' file.
However, the host OS will need to be btrfs-aware (btrfs-progs installed) and have xbps installed. Actually, I haven't tried it yet, but it should work from a running QV. Make sure you have a good quality Flash stick or SSD; apart from quality drives being able to handle more writes, slow cheap Flash sticks will cause very noticeably longer app startup times.

Feedback is welcome here:

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

Have fun!   

Tags: quirky

QV snapshot management

Snapshots are a very exciting feature of btrfs. In Puppy Linux, you know that you can copy a "save file", then at bootup choose which save-file you want to use. In brtrfs, a snapshot is like that; however, it is not a copy, nor is it a file.

Brtfs is a COW filesystem, meaning "Copy On Write". This enables a snapshot, similar to creating a Puppy save-file, but it happens almost instantly, with no copying. Quoting from here:

In Btrfs, it uses Copy-On-Write (COW). Every file update is stored in a separate block, and the original file pointer points to this updated data block. So, in a snapshot, there’s no actual copying of files or folders; instead, we freeze the state of the pointers pointing to the data blocks.

For example, if we have 10 GB of data in a sub-volume and create a snapshot, it might seem like a copy-paste, but the total size consumed remains 10 GB. Updating the original sub-volume only takes up space for the newly updated data, not duplicating the entire content.

I have implemented snapshot management in QV. At bootup, there is a menu in the initrd:

I showed this menu in a post about Lockdown, a couple of days ago:

https://bkhome.org/news/202403/qv-lockdown-implemented.html

...at that time, there were snapshot items, but not yet implemented. I have also now added item-7.

Choosing item-3:

Choosing "OK", next window:

After bootup, taking a look at the directory hierarchy:

I have re-organized the directory hierarchy. Folder '1' is the original installation, '2' is the snapshot. '@files' is at the same level, as it will be bind-mounted in all snapshots, as folder /files -- this is for your personal storage, and is not snapshotted. Your photo collection, for example, will be available in all snapshots.

Looking into folder '2':

...'@qv' is the folder that becomes '/', the rootfs, with '@data' bind-mounted as '/data' and '@home' as /home -- these are private to the snapshot. Initially, these three folders are snapshots of the previous current snapshot.

I don't want to explain too much, as just doing it is simple. You bootup and you are in a new snapshot. Only /files has not been snapshotted, as it is common to all snapshots. That is, you download a file into /files, and it is available in all snapshots.

OK, now running in snapshot '2', which is now the default. At a reboot, though, can choose item-4 "Choose snapshot to boot into":

Choose '1':

...back at the original installation!

This snapshot mechanism is really neat. Each snapshot is entirely independent, and they all have the full free space of the partition to play in. You could setup a snapshot just for compiling, another for video editing. Oh, and as Void is a rolling-release if you do a package update in one snapshot, that breaks things, can bootup a different snapshot.

And yes, you can look inside other snapshots. Just click on the "sdc2" desktop icon, and poke around, do whatever you want. It is only in Lockdown mode that you cannot do that.

Haven't yet implemented deleting of snapshots; will do that.  

Tags: quirky

QV strategies to reduce SSD writes

EasyOS and the pups are able to run in RAM, saving to the storage media only when you want to. That is very good for Flash media. QV does not have a aufs or overlay layered filesystem, so writes are direct to the storage media.

Back in the Quirky Linux days, I implemented strategies to minimize writes to Flash media. In those days, was using ext4, so did things like disable the journal. QV though, is using btrfs, which from a bit of reading does seem pretty good running on Flash.

When a btrfs partition is mounted, it auto-detects if it is Flash, and makes certain decisions. What those decisions are, I don't know. Anyway, here are actions that I have taken:

1. Set the "noatime" option
   An operation that trawls through files, such as grep, will set the access-time on files. That is a write operation, so have disabled it. Apparently, mounting with noatime is particularly important with how btrfs works.
2. Set "commit" to high value
   The default commit value for btrfs is 30 seconds, which is how often RAM file buffers are flushed to the storage media. I have changed it, if there is more RAM than 3GB then set commit to 240; that's 4 minutes. I presume that a "sync" operation, such as running 'sync' utility, will flush immediately -- at least I hope so.
3. zstd compression
   I am mounting with zstd, compression-level 3. This actually makes reading and writing faster, due to smaller files. Another benefit is less bytes written to the Flash media.
4. Caches in /tmp
   /tmp is a tmpfs, and I have setup all cache folders that I can find as symlinks inside /tmp. This includes /var/cache, /root/.cache and /home/*/.cache. /run is a symlink inside /tmp
   

These strategies will greatly reduce writes to the Flash media, but not entirely, so it is recommended to use a reasonable quality drive. Most SSDs should be OK. Bargain-bin USB Flash sticks, well, I don't know how long they will last -- they are really only intended for occasional writes, like keeping ones collection of photos.

On past occassions, I have recommended SanDisk Ultra and Extreme USB Flash drives. However, have discovered something disturbing; a couple of Ultra model that I bought in the last year, from a reputable local retailer, have considerably slower write speed than those I purchased a few years ago. In EasyDD, I am getting about half the speed of the older ones, just over 7MB/sec.

I really do need to buy another Ultra drive, from a different local retailer. Also need to buy another Extreme model, see if that has also degraded. Extreme model is the best, if you can afford it; they have an SSD type of controller chip and very fast read/write -- presume they still do.

A quality Flash drive will also have spare storage locations, that are substituted when parts of the memory start to fail. The controller chip handles this automatically. A very cheap Flash stick may have little or none of this spare storage. Also, I'm not sure, but if you partition an SSD to use less than it's rated capacity, the left-over memory will then become spare capacity -- read that somewhere. But maybe very cheap Flash sticks don't have that kind of clever management.   

Tags: quirky

woof-quirky-void created at github

The last couple of months, have been exploring an "EasyOS like" distro based on the XBPS package manager and built from Void packages. Then more recently exploring btrfs for the working-partition, instead of ext4, and without a layered-filesystem nor squashfs files. I have nicknamed the latter "QV", and the last post is here:

https://bkhome.org/news/202403/qv-lockdown-implemented.html

It is starting to reach usability, well, has reached usability, so decided to put it up at github:

https://github.com/bkauler/woof-quirky-void

So, what direction to take in the future?

EasyOS Kirkstone-series will continue; it still has life in it, maybe for a couple more years. But probably updates will be infrequent.

OpenEmbedded/Yocto will be releasing the Scarthgap series in April this year. That is the schedule anyway, no definite date published. The intention is to do an OE compile when it is released, and that will become a new series to replace Kirkstone. I do intend that people who have a Kirkstone version installed, will be able to update to Scarthgap.

A few weeks ago, was working on EasyVoid, but that has now morphed into Quirky Void, or just "QV". And as mentioned above, no aufs/overlay layers nor SFS squashfs files.

QV has been fun, exploring possibilities, without really knowing whether it will become a stayer.

One disappointment is that the kernel btrfs fscrypt patches do not work; cause the kernel to crash. The last iteration is v5, about three months ago, and there doesn't seem to have been any activity since then. My crash report has gone unanswered.

So, is QV good enough to keep going, without fscrypt? It was the promise of fscrypt that attracted me to btrfs originally. That, and other features such as snapshots, compression and checksumming.

Today I tested Flapi, the Flatpak manager. Installed Frogatto and it works. Toggled to Lockdown mode then installed OpenShot; again works. Good. Haven't tried Appi, the Appimage manager yet.

A couple more things to do, then intend to release a pre-alpha.        

Tags: quirky

QV lockdown implemented

About a week ago, I posted about the return of Quirky Linux:

https://bkhome.org/news/202403/quirky-has-returned.html

...well, not exactly; this is a somewhat different beast. I have named it "Quirky Void", or just "QV". Which may also be the Latin words "Quantum Vīs", meaning "as much as you want".

Those using EasyOS will know about Lockdown modes. The most stringent is bootup and run in RAM, with all drives disabled. Lockdown is described here:

https://easyos.org/user/ultra-secure-web-browsing.html

QV does not use a layered filesystem, nor Squashfs files; it is a traditional installation. With a significant difference that QV can install into a folder in a partition. In Puppyland, we refer to that as a "Frugal installation".

The ability of QV to install into a folder inside a partition is important; it is possible to lock the user inside that folder, unable to see outside. Hence Lockdown can be achieved.

Like EasyOS, QV has a little menu in the initrd. Here is the QV menu:

...notice item-1. Previously, item-1 had "Turn ON lockdown, disable access drive partitions", which I chose. By choosing item-1 again, I can toggle Lockdown off.

Oh, one thing. The menu had a message "Hit the SPACEBAR to disable 15-second timeout", because it will timeout then bootup will happen. But if you want more time to read the menu items, just hit the SPACEBAR and you will get the menu as shown above.

So, it is currently in Lockdown-mode; I just press the ENTER key and after bootup:

...the important thing to see in that photo is only one partition icon is displayed. That is the working-partition. In fact, you can't even mount that and access outside the '@qv' folder. In the previous blog post, there is this image, showing the folder hierarchy in the USB-stick:

The 'init' script in the initrd has booted into the '@qv' folder. 'data', '@files' and '@home' are bind-mounted on '/data', '/files/ and 'home' inside '@qv', so they are accessable. But that's it, cannot access anything else in /mnt/sdc2, nor any other partitions.

You are still running as the root user, administrator, but it is "crippled root". Here is some of the code in the 'init' script in the initrd:

The ability to prevent mounting of partitions relies upon dropping "cap_sys_mount". Linux Capabilities allows selective dropping of the administrator's capabilities. Unfortunately, the designers created "cap_sys_admin" which, when dropped, takes away just about all of administrator's capabilities, making it hardly more than a normal user -- cap_sys_admin also drops ability to mount partitions. It really should have been broken into smaller pieces.

So, I have a patch, that separates out the ability to mount from cap_sys_admin; named cap_sys_mount. I can then just drop ability to mount, while keeping all of the rest of cap_sys_admin capabilities. The patch for the 6.8.1 kernel can be found here:

https://distro.ibiblio.org/easyos/source/kernel/6.8.x/6.8.1-20240325/

That cap_sys_mount patch origin is described here:

https://bkhome.org/news/202012/kernel-510-lockdown-success.html

...I have modified the original patch a bit, and it also required a fix for the 6.8.1 kernel.

QV now has Lockdown, and I kept it very simple. There are no types of Lockdown; just the one. EasyOS has the ability to plugin a USB drive and can save to that; however, QV doesn't need that, as it already saves direct to the working-partition. Plugging in a USB drive won't work in QV; it cannot be mounted, even though the partition icon(s) will appear.

Note also, like EasyOS, when in Lockdown mode, the 'init' script in the initrd will detect any HDD (rotating platter drive) and power it down. So it will be turned off, which is an extra security mechanism.

In Lockdown mode, swap partitions are also disabled. However, you can create a swap file in '/data', and that will be automatically used. Name it "pupswap.swp".

QV's Lockdown mode is pretty good. You can do everything that you would normally do, except not access any other partitions. You have all the space in the working-partition, so use a big enough partition for any foreseeable requirements. Probably if running off a USB-stick, at least 16GB would be OK, preferably 32GB.

However, there may be some applications that will want to perform a mount operation. That will fail. Haven't tried Flatpaks yet. A Flatpak app runs as a user (same name as the executable), but it can bump its Linux Capabilites and acquire some root abilities. The ability to do this is required by Flatpaks, and back then I was very reluctant to enable that feature in the kernel. I forget the particular kernel config that allows capability-jump. However, in the case of QV, the ability to mount is removed while still in the initrd, so it is gone and cannot be bumped up to by a Flatpak app.   

Tags: quirky

Quirky has returned!

I created Quirky Linux in 2010 and the last release was in 2018. I then notified Distrowatch that the project was discontinued.

Quirky was a full installation, occupying an entire partition, the same as most Linux distributions. It did not support squashfs (SFS) files, nor did it use aufs or overlay fs layered filesystem. So it did not have "run in RAM with a save file";  what it did have was strategies to minimize flushes to the storage media, to help prolong the life of flash media.

There are some guys active on the Puppy Forum who would have fond memories of Quirky. Well, Quirky is back, though this is "Quirky on steroids". And very highly experimental.

Yes, the features are as described above; however, major new features are added. Quirky can be installed frugally, that is, be in one folder in a partition used for other purposes -- but it has to be a btrfs partition. There is a snapshot and potentially rollback/roll-forward capability, like we have in EasyOS and the pups. The filesystem has read-write compression. There is per-folder encryption.

Regarding the requirement for a btrfs partition, if you want to install to an internal drive, you would probably have one if have installed Fedora or OpenSuse. It is theoretically possible to create a file in a ext4 partition and create a btrfs filesystem in that file (maybe a sparse file) and mount it as subvolume; then can boot into it.

The containers feature of EasyOS is gone. Instead, there will be more attention given to isolation of apps from each other by the method introduced in Easy; to run each app as its own user. This mechanism can be tightened further.

This new Quirky is built with Void Linux packages, and uses XBPS package management, with PKGget (PPM) as a GUI frontend. As introduced in easyVoid. I was struggling with easyVoid, as it uses SFSs and aufs layered filesystem, which is very incompatible with XBPS. It is this incompatibility that was causing me to implement hacks that I did not like, and turned my attention to bringing back Quirky.

A name for this new Quirky can be "QuirkyVoid", or just "QV". Here is the old logo:

...I never created an SVG for it; will put that on the to-do list.

The new build system is derived from woofV that builds easyVoid; the new name is "woofQV". I will be uploading it to github very soon.

woofQV is very simple. A series of scripts to run, and it creates a drive image file 'qv-<date>-amd64.img'. Just like with EasyOS, write it to a USB-stick and boot it. OK, I did that, and got a normal-looking desktop:

Works as you would expect. What is important though, is what is underneath. The filesystem is completely different. If I am running another distro and plugin the USB-stick and mount the working-partition, this is what is seen:

...the working-partition has a btrfs filesystem, and those folders named "@*" are what is called "subvolumes". This is a frugal-install, as all of this is inside folder 'quirkyvoid'. Folder '@qv' is the root-filesystem -- before clarifying that, explaining more about the drive-image file...

Just like EasyOS, the drive-image file has two partitions; an esp boot vfat partition, and a working-partition. Except the working-partition is no longer ext4. Here is the boot-partition:

...for various reasons, this has 'vmlinuz' and 'initrd'; not in the working-partition.

Here is code in the 'init' script in the initrd, before the switch_root operation:

...that SUBVOL variable is "quirkyvoid/@qv", which mounts the @qv folder onto /newroot folder.  SUBDIR is "quirkyvoid/". Then /dev, /proc, etc are moved to /newroot, and a switch_root performed.

There are three "--bind" mounts, that mount the external folders 'data', '@home' and '@files' inside /newroot. So, after bootup, this is what "/" looks like:

...which looks similar to EasyOS. Except for that new 'data' folder.

It is intended that 'files' and 'home' will be encrypted. This will require a password to be entered at bootup. Currently don't have that, as the 6.8.1 kernel with fscrypt patches doesn't work; booted to the shell prompt, then a second later the kernel crashed. I have reported this to the 'linux-btrfs' mail-list, with a screenshot of the crash.

QV has huge potential, but a lot of work to get it to a reasonable working condition that can be released. A pre-alpha maybe not to far away.

I will post more explanations in future blog posts. I'm a beginner with btrfs, so refinement will happen. Those 'data', '@home' and '@files' located outside of '@qv' is unusual, I gather from reading so far; it seems that it is more usual to create '@home' for example, nested inside '@qv' -- but intuitively it seemed better to have '@home' outside and bind-mount it inside -- anyway, my way seems to be working.    

Tags: quirky

btrfs-progs with fscrypt take-2

I posted yesterday about compiling Josef Bacik's fscrypt branch of 'btrfs-progs':

https://bkhome.org/news/202403/btrfs-progs-with-fscrypt-patches.html

There were some things that I didn't understand, and sent an inquiry email to Josef. Here is part of my email:

With ext4, "mkfs.ext4 -O encrypt,..." will enable fscrypt; however
"mkfs.btrfs -O list-all" does not show "encrypt" as an available
feature.

So that is my question, is it just the documentation that is lagging,
and "-O encrypt" will work?

And if so, how do I check? With ext4, can use "tune4fs -l ..." to list
features. I'm new to btrfs, not familiar with the tools.

And here is part of Josef's reply:

You need to make sure when you're configuring btrfs-progs you use

./configure --enable-experimental

so you get the encryption support.  However you don't need that to
enable encryption.  If you just use the normal fscrypt tools to enable
encryption it'll work properly, we don't do anything specific at mkfs
time like ext4 does, we do it all live.

Good. I have recompiled 'btrfs-progs' and updated the PET. Also recompiled it statically in OE for use of the utilities in the initrd.  

Tags: quirky

btrfs-progs with fscrypt patches

Recent posts about btrfs:

https://bkhome.org/news/202403/kernel-681-with-btrfs-fscrypt.html

https://bkhome.org/news/202403/improved-support-for-btrfs.html

https://bkhome.org/news/202403/btrfs-progs-compiled-statically-in-oe.html

However, to support fscrypt, patches need to ba applied to 'btrfs-progs'. One of the main developers of btrfs is Josef Bacik, and he is the primary implementer of fscrypt support in btrfs. He has fscrypt patches for btrfs-progs:

https://github.com/josefbacik/btrfs-progs/tree/fscrypt

I have compiled his btrfs-progs in EasyOS Kirkstone and created a PET:

https://distro.ibiblio.org/easyos/amd64/packages/pet/pet_packages-kirkstone/

For the record, this is how I configured the source:

# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-crypto=builtin \
  --with-convert='' --disable-python --disable-libudev --disable-zoned --disable-convert \
  --disable-documentation --disable-backtrace

I uploaded the source tarball to ibiblio:

https://distro.ibiblio.org/easyos/source/alphabetical/b/

Need static binaries for the initrd. Here is the build recipe:

https://github.com/bkauler/oe-qky-kirkstone/commit/e80f8a9bc3eb8241b03127d61379e55738b3092f     

Tags: quirky