site  contact  subhomenews

More /etc/init.d replacements for runit

April 16, 2024 — BarryK

QV, like EasyOS, and before that Quirky and the various pups that I maintained, uses the simple busybox init, with start/stop scripts in /etc/init.d. Except, for QV and EasyOS, there is service management with enhanced pup_event.

Void Linux uses runit to manage services. QV is capable of launching the runit daemon and using runit; however, I would prefer to stay with /etc/init.d, as it is very simple and works flawlwessly. Besides, it is what I know.

woofQV, the QV builder, has a 'packages-templates' directory that can modify any package installation. I have anticipated future packages that a user might want to install, and added /etc/init.d scripts where needed to replace runit.

Here is the commit:

Note, I got all of these from OpenEmbedded.   

Tags: quirky

QV snapshot deletion

April 15, 2024 — BarryK

About two weeks ago, I posted about btrfs snapshot management in QV:

I have now added deletion of snapshots. There is a new item in the menu:


Choosing item-4:


...snapshot #1 is missing, because that s the current default that will be booted into. Whatever is the current default will be filtered-out.

From a bit of online reading, it seems that deleting snapshots can take awhile. For that reason, the children of each snapshot are listed. For example, snapshots 3 and 5 are snapshots of number 2. Number 4 is a snapshot of 3. My reasoning is that snapshots that have children, especially children-of-children, are likely to require a lot more processing to delete.

I have selected number 5, and the next window:


There wasn't much processing to delete it, took the blink of an eye, then this window:


After bootup, it is seen that folder "5" is now gone:


Looking good!   

Tags: quirky

QV version 240409 pre-alpha uploaded

April 10, 2024 — BarryK

Download from here:

The md5sum is:


It is a bit bigger than the previous release, 1.3GB up from 1.1GB. The reason is have set zstd to compression level 3, whereas before it was 15. Want to see if it makes a noticeable difference in app startup time. ...for Firefox on my old Compaq Presario, not noticeably faster.

You will notice that the logo is just the letter "Q". That is just a whimsical thing I tried, wanted to see what it looks like in use, doesn't really "work".

If you want to do a frugal install direct to internal drive, and not bootup QV first on a usb-stick, can do. There is a script, 'qv-installer', that should work on most Linux distros. You will also need the 'mount-img' script. I will post the latest of these two scripts to the forum, here:

Grab those two scripts, remove the false ".gz", set as executable, and put them in /usr/bin or anywhere in the $PATH.

You then need to download 'qv-240409-amd64.img' and open a terminal where-ever it is downloaded to, then run, as the root user:

# qv-installer qv-240409-amd64.img

The script will check that you have all the required utilities and packages installed. For example, 'btrfs-progs' package.

Have fun, feedback welcome at the forum.

Oh yeah, the "update" icon on the desktop. That doesn't work. I have yet to figure out a strategy for updating.        

Tags: quirky

New QV Installer

April 08, 2024 — BarryK

Easy install to an internal drive. Announced in forum post:

The script is part-manual, part-automatic. Not as sophisticated as installers in the mainline distros.   

Tags: quirky

QV version 240403 pre-alpha

April 03, 2024 — BarryK

For previous news about QV, see this blog category:

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:

...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: 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:

Have fun!   

Tags: quirky

QV snapshot management

April 01, 2024 — BarryK

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: 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

April 01, 2024 — BarryK

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