WeeDogged EndeavourOS

[wiak]

A bit too close to still doing dev work when taking it easy, but not really... Just noticed how popular EndeavourOS is becoming according to Distrowatch at least and thought I'd take a quick peek at it. Well, kind of... - simply downloaded the install iso, found the main sfs file and added 07 to the front of its name and booted it, in usual WeeDogged fashion via WDL generic overlayfs skeleton initrd.gz (albeit the 'special' one that contains kmod since the static busybox modprobe couldn't previously handle zstd compressed modules, which Arch-based distros all use now - I'll have to try new static busybox to see if it handles zstd on its own now... but not needed for my quick test).

Reason I'm looking at EndeavourOS is that I'm needing a new WDL_Arch64 build for the family business (and was slowly working on that) but wondered if I could save future dev work by just using something off the shelf like EndeavourOS (via WDL generic initrd). I don't have much installed on EndeavourOS at moment, but initial impression is certainly very good - the question is: would I drive it longterm via WDL initrd (which is a perfectly good option) or (????) go for a standard full install... I rarely do full installs, but... problem with frugal installs (despite their many flexible advantages) is that upgrades can be a major headache though more possible in WDL than most since can use uncompressed directories in layers. Full installs are such a pain though (my old computer simply has no partition space so I'd have to major reorganise it, but no such issue for my partner's business machine - nevertheless, the distro itself is just a platform - I still need to install all the apps required and maintain everything to work, and since much is to do with network connectivity, maintenance of system is a big job anyway... (we use ssh, vnc, and similar to interconnect on our LAN a lot as well as various rsync to cloud services for backups, so quite a lot involved in overall maintenance).

So, I'm in two minds... EndeavourOS (using XFCE) looks good - I like it more on first try than I did ManjaroXFCE - seems more responsive - pretty good actually. However, I have lots of customisations required for business computer needs and most of that is already done in my WDL_Arch64 build plugin so possibly easier just to stick to that. Have the same potential issues re major upgrades though. But easiest full upgrade mechanism is simply to make a new build via build_firstrib_rootfs script along with the Arch f_00 build plugin. However I'm thinking of not using a read-only root filesystem at all. Trick there is to simply use upper_changes (with no number) to contain the contents of what would have been the numbered root filesystem (such as 07firstrib_rootfs, be that an sfs or an uncompressed directory). If just using upper_changes (and no, or an empty underlying 07rootfs) the system becomes like a 'pseudo full install' - still using WDL initrd and overlayfs layers (so all the sfs module advantages of that) but with main upgrades going straight into the read-write upper_changes layer. Can always stick a 2-digit number in front of that later if I really want to use an optional discardable per-session upper_changes. Could do the same with EndeavourOS of course, not just with WDL_Arch64; same can be done with the likes of KLV-Airedale for that matter...

wiak

[rockedge]

@wiak I might have to give EndeavourOS a WeeDogged try out. I've been running KLV with the rootfs decompressed and using the mount/umount scripts to chroot into the rootfs run xbps-install -Suy to complete the system upgrades and then after exiting and un-mounting the rootfs, run xbps-install -Suy through the /upper_changes layer. Very much like you describe in the above post.

I do agree it is sort of a "pseudo full install". There seems to be quite a few tricks that are not discovered yet as far as running "decompressed". My system boots the same KLV's faster when the rootfs is not compressed.

I am looking at an automated way of perhaps decompressing the rootfs SFS running the update/upgrade and then squashing the rootfs again.

Easy way is just keep updating/upgrading through the /upper_changes layer but the big draw back could possibly be the growth in storage size of /upper_changes but I have not done enough study on this to say for sure.

I also have begun to successfully start in RAM0 mode and use @rufwoof's FirstRib scripts to save then merge the numbered /upper_changes directories that are created by the save.sh script. It is still really raw but the proof of concept is showing this system can work as a save on demand with a merge on demand option. Though I have found advantages to keeping the numbered XXchanges.sfs separated when experimenting when the possibility of breaking the system is really high.

The overall best way is to also run the WDL build script(s) and build the distro fresh replacing the traditional upgrade methods to keep the OS updated, when it comes to KLV-Airedale. But I do not have all of the steps needed to create the current KLV-airedale_rootfs with all the extra utilities and customization included, for a completely automatic distro build. There still is quite a bit of manual construction that still occurs to get the current KLV-Airedale rootfs set up.

[wiak]

The overall best way is to also run the WDL build script(s) and build the distro fresh replacing the traditional upgrade methods to keep the OS updated, when it comes to KLV-Airedale. But I do not have all of the steps needed to create the current KLV-airedale_rootfs with all the extra utilities and customization included, for a completely automatic distro build. There still is quite a bit of manual construction that still occurs to get the current KLV-Airedale rootfs set up.

Yes, definitely the best way. I have most of my WDL_Arch64 build plugin complete, but... yes, I do sometimes add new feature and don't bother to update the plugin at the same time, which is a pain, because later I can't remember exact details of what I did and if I do too much then it becomes a big job updating the plugin. In fact, that's what I'm slowly doing at this very moment - updating my WDL_Arch64 plugin since I need reliable smallish new build. In the meantime, I have used pacman -Suy and updated old system (installed a year ago) and that worked fine apart from one glitch related to vncserver, which I haven't sorted out (may or may not be my cause - may be a problem with latest Arch tigervnc with newest (of now) 5.16.3 kernel. Yes, I temporarily changed /etc/pacman.conf to allow kernel to be updated too (which meant I had to also change the modules internal to the initrd.gz, but that was easy enough with ./modify_initrd script - so yes I just updated into the read/write upper_changes so now have latest Arch kernel and glibc and everything else...

The idea I suggested before of using no NNfirstrib_rootfs, but instead just renaming it to upper_changes is for easy update without extra bloat - that way upper_changes becomes your whole system so when updated it just gets rewritten (can always make a number squashfs of it at any time of course) - so yes, that really is a useful/interesting pseudo full_install mode in WDL since can have several distros all in their own directories on same partitions per usual frugal install situation but all can be left uncompressed (which is indeed quicker/more-responsive).

Oh well, not doing much otherwise - just slowly looking at my WDL_Arch64 f_plugin to see what I need to include for next build! Some time back I also contructed a basic KLV_openbox_tint2 f_plugin based heavily on the configs I already had in the WDL_Arch64 one, so later I'll get back to that one and polish it up and try to include some of the many alterations/additions you now have in KLV-Airedale (and particularly all these many contributions from fredx181).

Oh by the way, if wanting to make a WDL'd EndeavourOS, remember you'll need the kmod version of skeleton initrd since needs to work with zstd modules - that's downloadable at same link as the smaller/standard skeleton initrd: https://weedoglinux.rockedge.org/viewto ... p=355#p355
I'll need to download latest busybox static busybox.net supplies to see if they now include modprobe zstd support since then I can make a new small skeleton WDL initrd that will always work (I could compile a special busybox since I do know a patch was produced, but prefer to wait on busybox devs doing an official static build). Just noticed I'm actually in the WeeDogged EndeavourOS as I type this - life gets very confusing sometimes...

wiak

[wiak]

Note, just built a new WDL_Arch64 and immediately renamed the resultant firstrib_rootfs/ to upper_changes/ and then created an empty 08firstrib_rootfs (can be named anything between 01 and 99 of course as long as two-digit number there). Then when you boot with WDL initrd the empty 08 directory becomes the overlayfs read-only lower layer (nothing in it...) and the upper_changes (containing the WDL_Arch64 root filesystem build) becomes the overlayfs read-write top layer that will receive absolutely all additions later.

That's the alternative mechanism I was talking about above to that of using mount_chroot and umount_chroot method of adjusting the root filesystem contents. Once booted, anything added just gets done to the upper_changes, which in this case is the whole thing; that's what I mean by a pseudo full install sort of situation, which is a very useful alternative (to mount/umount chroot) way of building the system up without adding bloat. You do need the empty 08 (or NN whatever) directory though since the overlayfs lower can't be empty and gets its value in the initrd/init by search for NN-named sfs layer files or NN-named uncompressed layer directories. It is proving to be a powerful mechanism.

What I'm trying to do thereafter is add extra configs and packages after booting, but trying my best to record every detail of what I add/change and put it in the original f_00 build plugin as soon as possible so I don't forget! - but, of course I have bad habit of not doing fixing up the plugin that quickly (and sometimes because there is, as you know, some complex work involved in scripting the alterations that were done manually).

NOTE: The other thing I do when making a new build is arrange for a buildlog via tee command. For example, for WDL_Arch64 build I used build command:

Code: Select all

./build_firstrib_rootfs_401rc1.sh arch default amd64 f_00_Arch_amd64-openboxFull_401rc1.plug 2>&1 | tee buildlog.txt

though I only do that if not sure all is going well since slows build down a bit. You can watch the log progress in geany even - just open the file and occasionally switch ebetween tabs and choose RELOAD. Of course there are better ways of doing it... (even the 'less buildlog.txt' command and hit 'end' key on keyboard every so often or 'g' to beginning and 'G' to end of file...). Otherwise I just keep an eye on the terminal (scrolling up and down) as the build proceeds. Also the buildlog gets pretty big...

EDIT: putting main filesystem all into upper_changes can cause problems if wanting to load the likes of gtkdialog in an earlier readonly sfs layer though - that's currently not working for me though in WDL_Arch I'm planning to put the gtkdialog/filemnt stuff in upper_changes anyway.

[rockedge]

@wiak I use in a terminal:

Code: Select all

tail -f buildlog.txt

to follow the log in real time

[wiak]

@wiak I use in a terminal:

Code: Select all

tail -f buildlog.txt

to follow the log in real time

Ah that's the one! I remember there was a command to do with tail but couldn't remember the details or if it needed piped to anything. Very simple in fact.

EDIT: putting main filesystem all into upper_changes can cause problems if wanting to load the likes of gtkdialog in an earlier readonly sfs layer though - that's currently not working for me though in WDL_Arch

Above gtkdialog issue turned out to be a faulty usb copy I had of the 10gtkdialogGTK3 sfs addon. After re-downloading the 10gtkdialogGTK3 sfs I find now that it works fine afterall also with upper_changes containing whole rootfs in pseudo full install (i.e. when main root filesystem ends up in higher layer than the gtkdialog sfs). I like this pseudo full install method. I'm also using it with w_changes=RAM2 mode when I don't want new session changes to be added (in that RAM2 mode the read/write external upper_changes folder gets instead mounted read-only in memory to /mnt/layers/RAM/upper_changes (that is wrong: see EDIT2 below...); even then it is possible to write the session changes back via carefully crafted rsync script - however, when I really want changes to reflect back I simply remove w_changes=RAM2 from my grub kernel boot line such that all changes get recorded.

EDIT: No. 10gtkdialogGTK3 sfs doesn't like main filesystem in read/write upper_changes (fine without 10gtkdialogGTK3 sfs active), but oddly, it is fine with w_changes=RAM2 when that upper_changes arrangement is used. That RAM mode mounts the external upper_changes as I said at /mnt/layers/RAM/upper_changes (that is wrong: see EDIT2 below...). At the moment I can't think why that works and without w_changes=RAM2 doesn't; I'll have to think about it.

EDIT2: Turns out I don't know my own initrd/init. When using the special RAM upper_changes mode, w_changes=RAM2, the external (media) upper_changes doesn't get mounted to /mnt/layers/RAM/upper_changes (which is for the new session alterations) but instead to /mnt/layers/uc_ro (the ro in the name signifying that it is mounted at a read-only overlayfs layer). Interesting... even an empty and uncompressed 10addon causes failure if not using w_changes=RAM2 when upper_changes contains whole filesystem - weird - I am experimenting with this now to work out what is going on - probably pretty obvious once I remember how the overlay works.

[wiak]

re: my above post.

Currently I'm perplexed... I now have put main filesystem in upper_changes for pseudo full install use - that works fine on its own (with empty 08firstrib_rootfs).

But very odd goings on. Now I am using a not empty 08firstrib_rootfs (in fact contains exactly the files from 10gtkdialogGTK3 sfs addon) and that works fine actually, but...

I then made a copy of that 08firstrib_rootfs/ and then renamed the first one D08firstrib_rootfs to disable it, and renamed the new one to 08firstrib_rootfs/ and it doesn't boot!!! Kernel panic. If I disable the new identical one and go back to the original all boots fine again (this is with no w_changes kernel line). I can only think of two possibilities:

1. My file system is corrupt (this is very possible on this old machine - I had trouble with the partition a few days ago), or

2. It 'may' be something to do with xino and overlayfs. I tried to accommodate xino handling (according to my understanding) in WDL initrd but never come across any issues that might be to do with it before.

So for now, I don't know what is going on with my machine and it may well just be my machine has that faulty filesystem. If you find any issues using pseudo full install arrangement please let me know rockedge because I feel like I am going crazy...

I will try an install on other machine tomorrow - that should determine matters.

Looking at the mount overlay line, should just be a simple merge, so looks like my computer partition is indeed corrupted (messed up inodes) and causing false boot results. Annoying. Another case of time will tell. So much for my rest from computing - I think I'll just get back to that!!!

EDIT: Yes, hard disk failure. Just tried 'normal' WDL frugal install and having same issues so nothing to do with using pseudo-full-install, just dodge hard drive. Hmmm... I need new machine. I'll have a go with fsck, but think it is likely a goner.

[wiak]

I've changed my mind. I dd zero'd out my hard disk partition and fsck'd it and have a feeling it is innocent. Also I don't think any issue to do with using pseudo full install technique since I've discovered I can get same issue in normal frugal install anyway.

Now build new WDL_Arch64 and I can get same issue (depending how I arrange things). I do not believe it is anything to do with WDL, but probably my computer doesn't like the kernel - it is pretty new: 5.16.4-arch1-1

Could be the kernel itself or something in relation to the overlayfs code in it - problems with inodes maybe. Perhaps someone has made a blunder up high. I'll try going back to earlier kernel now of course.

[rockedge]

@wiak So far I am have no issues at all with the "full" install to report! This system is working very nicely and very responsive. The entire frugal directory is just under 2 G in size.

I have had problems with 5.15+ on some older machines but that usually involves the ethernet devices in some way and some kernel panics. Swapping out the kernel seems to fix it, but I have not investigated this very deeply yet if it is in fact the kernel version causing the woes.

[wiak]

@wiak So far I am have no issues at all with the "full" install to report! This system is working very nicely and very responsive. The entire frugal directory is just under 2 G in size.

That's very small for uncompressed. I wouldn't bother compressing that for home use since disk size used is irrelevant at that level and responsiveness much better. Indeed I'm definitely planning to use the pseudo full-install mode for business machine, with all apps installed and everything configured and with w_changes=RAM2 so that media upper_changes folder only gets used mounted as read-only layer (session layer stuff then goes into RAM proper at /mnt/layers/RAM/upper_changes, which I normally discard on exit, keeping the reboot pristine - so cuts down on critical maintenance need greatly, or use special rsync script to merge that back into the upper_changes folder on media).

[rockedge]

@wiak can you show an example of the rsync script line? I would like to try out the same exact thing.

I am really liking this pseudo "full" install mode. Especially to squash the combined /upper_changes folder into the base KLV-Airedale rootfs SFS, and spin off KLV's that run from SFS. Great systems that will run stable for a long time without the need to constantly update.

Of course anyone can easily unsquash the rootfs SFS and begin to use the rootfs decompressed, right from any KLV-Airedale using manual methods. I did one using a KLV by setting up run actions in ROX to call filemnt when clicking on an SFS file, and copied that into a new frugal install directory. Added the other components and ready to go.

Going for a a KLV using the Void Linux kernel for some testing as well. @fredx181 is already working with this.

[wiak]

@wiak can you show an example of the rsync script line?

I can @rockedge, but with the disclaimer that I am not saying this line is 'correct'. For one thing, I am unnecessarily syncing caches with this line. Also, the issue is whether overlayfs whiteout files are an issue - remember:

https://www.kernel.org/doc/html/latest/ ... layfs.html
"A whiteout is created as a character device with 0/0 device number"

I haven't really considered the implications of all of this. I know, when @fredx181 later created his first overlayfs DebianDog (BusterDog?) he ended up writing a relatively complex rsync-based script to search for and deal with whiteouts in the way he felt likely necessary. I, however, have always used a very simple one-liner, and used it for months with no issues, but I may just have been lucky... This is for w_changes=RAM2 mode only, which is where external media upper_changes gets mounted to /mnt/layers/uc_ro, which is used as top read-only layer by mount overlay, and the session (read/write) upper_changes gets put in /mnt/layers/RAM/upper_changes.

Here is the simply rsync line I use to merge session upper_changes with external media upper_changes for that RAM2 mode:

Code: Select all

sudo rsync -av /mnt/layers/RAM/upper_changes/ /mnt/sda4/WDL_whatever/upper_changes

Now, I admit to simply using that (and successfully in terms of nothing (apparently) bad happened (?) when I used it and it seemed to work) but did not investigate its effects (re: whiteouts) carefully. I was too busy to check all that all and never got round to it. Worth a big discussion, testing, and evidence regarding issues that might occur though. I did use it for months though (and am about to use same method again). I am planning to also examine the likely whiteout-related possible issues more carefully though; I haven't published the line before because I know it could be insufficient and don't want anyone complaining I wrecked their install!!! So, yes, totally at your own risk and not for production system thus far. Fred's bigger rsync script used in overlayfs DebianDogs has been used by others for quite a while now. Even if my one-liner proves not to be 'dangerous' or 'insufficient' depending on deletions to files and so on, it certainly needs improved anyway to include not rsyncing back unnecessary caches and so on.

One thing related I'm about to look into is that the copy command 'cp' does not, by default at least, copy 0,0 char device files (not even cp -a; EDIT: I'm wrong. It does... see foot of post EDIT).

One other thing is the ever useful old tape archive" utility 'tar', as far as I know, does indeed faithfully archive everything so that may prove to be useful in accurate remasters or filesystem merges too, which is worth keeping in mind I feel. Yes, I must look into this save-back mechanism, merges, and remastering sometime - I really have a feeling that tar may prove useful if all else fails or introduced problems, but DebianDogs already done a lot of this kind of work and no major issues there apparently.

Overall it is important to really work out the effect whiteout files are having between all the different filesystem layers - it would be wrong to delete whiteout files in intermediate layers, it seems to me, without finding out what they refer to and which layer (filesystem) the object resides in actually deleting that. Such would involve big overall layer search and delete operation; I took the view that I may not need to deal with intermediate layer whiteouts so just leaving them in since they will continue to fulfill their designed purpose of hiding underlying files - different matter remastering of course since want to cut down the saved result, but I take the view that /mnt/layers/merged effectively contains what I'd want as a remaster anyway (minus unneeded caches and similar) - that won't contain any whiteouts because merged is the final result of the mount overlay command.

I should add, that for our business machine install, I never use rsync back anything. Rather I run these machines in w_changes=RAM2 mode for normal use and don't rsync back anything (i.e. I keep them pristine between boots). If I really do want to modify these systems (e.g. new configs or new apps) I simply temporarily run them as w_changes="" mode (which is same as not using w_changes line on the grub kernel at all, such that any changes go immediately into external media upper_changes so will be there on next boot too. Then I change the grub kernel line back to w_changes=RAM2 mode prior to next boot and don't save further sessions back - i.e. I play safe... and don't rsync anything on the business-use install (I simply don't trust any rsync mechanism/algorithm/script totally (!!!) so either just save persistence back everything immediately (rather than holding session changes temporarily in RAM) or run in no-save-persistent mode).

EDIT: just checked rsync man pages and it has the following related to above options:

--devices
This option causes rsync to transfer character and block device files to the remote system to recreate these devices. This option has no effect if the receiving rsync is not run as the super-user (see also the --super and --fake-super options).
--specials
This option causes rsync to transfer special files such as named sockets and fifos.

I don't know if the above are included in rsync defaults or not (would have to experiment). I checked man page for cp command but can't see any similar options for that, so worth bearing in mind. But, as I say, tar should be fine (I think...) since it makes proper archive usually.

EDIT2: Just did a simple experiment to check my above rsync line operation with whiteout file included (not a direct RAM2 rsync experiment, just a simple direct to other folder rsync experiment). What I did is made a new empty directory: /mnt/sda4/WDL_arch64/test

and then, I deleted, the vmlinuz I had in my main WDL_ARCH64 rootfilesystem in /boot. That could then be seen as a vmlinuz 0,0 char whiteout file in /mnt/layers/RAM/upper_changes/boot (I'm running under w_changes=RAM2 mode, hence session changes are instantly reflected into /mnt/layers/RAM/upper_changes). Then I simply tried rsyncing that directory back to the empty 'test' directory by using command:

Code: Select all

sudo rsync -av /mnt/layers/RAM/upper_changes/ /mnt/sda4/WDL_arch64/test

That copied down all of /mnt/layers/RAM/upper_changes into that 'test' directory. I checked /mnt/sda4/WDL_arch64/test/boot/ and sure enough the vmlinuz 00 char whiteout file was correctly there. I continue to believe that is sufficient - that I don't really need to worry about any other whiteout files in lower down layer filesystems (they will continue to do their correct overlay job...). I could be wrong, but seems to me to be as simple as that (except I don't also want to rsync back all these caches, but that just needs me to add some of these valid additional rsync options to (either or both):

Code: Select all

     --exclude=PATTERN       exclude files matching PATTERN
     --exclude-from=FILE     read exclude patterns from FILE

Actually, the above simple 'test' experiment indicates an alternative method of 'saving a session'. In above, I didn't rsync back to media upper_changes, so if I now rebooted the session (deleted boot/vmlinuz in this experiment case) would be lost, so boot/vmlinuz would be back again... However, I 'could' add another mode (RAM3, not there at the moment) to the WDL initrd/init (or simply the extra code in external w_init (so just optional then) that would boot into RAM2 mode but additionally rsync 'test' (or whatever it is named) back into empty boot version of /mnt/layers/RAM/upper_changes. Then when mount overlay done, that previous 'test' session would already be re-loaded...

I don't intend implementing that RAM3 alternative session save into the main initrd/init, but worth doing as optional plugin w_init form I think (since very simple and safe save persistence mechanism - disadvantage being that it uses more RAM since whole last session copied back into RAM rather than ending in loop mounted external upper_changes).

I consider w_changes=RAM2 mode the most useful though and most RAM efficient, so top of post given rsync line is for that (albeit with the disclaimers...).

All illustrates the power of w_ optional plugins... not fixed and simplified boot options, with the limits these bring, but instead flexible boot options are the result - that's why initrd/init in simple shell-script form with optional external w_init file is so useful in terms of easy plugin/editing/flexibility (and since busybox in initrd, awk language is also available for w_init plugin use).

Thanks for asking about this rockedge, because thinking about it all makes me realise an error I have in current RAM1 mode (RAM2 mode is fine). In w_changes=RAM1 mode I use cp -a to copy external upper_changes up into /mnt/layers/RAM/upper_changes when I really should use rsync since cp is not including any whiteout files...
I will fix that RAM1 mode in next WDL initrd release, but probably no-one using memory-inefficient RAM1 mode anyway - I'm not either since only using no w_changes (same as w_changes="") or using w_changes=RAM2 mode. EDIT: I am wrong. Just tried cp -a and that also did indeed copy the whiteout file so existing w_changes=RAM1 mode should be okay and not need fixed. Overall, rsync is a nicer way to do most copying though since doesn't repeat copy what is already there...

[rockedge]

@wiak excellent info! Just what the doctor ordered.

I tend at the moment while testing and tweaking KLV-Airedale to use w_changes= or w_changes=RAM0 and @rufwoof's save and merge scripts from FirstRib to manually save a chain of /XXchanges.sfs files and then (optionally) use the merge script to combine all the /XXchanges.sfs files into a single /30changes.sfs file and leaves an empty /upper_changes, which loads at boot up.

I was thinking of trying during the dev stage of KLV, to merge the /upper_changes directory with the /XXrootfs folder (decompressed). So I can add stuff to the base system while it is up and running, before I spin off the rootfs SFS files.

Though this sounds fraught with challenges, so far the RAM0 mode with those 2 scripts is doing the basic job reliably as a save session on demand method. But it is not ready really for main stream use and one mistake or failure and the entire /XXchanges.sfs chain merge ends up empty. So one ends up with an empty or corrupted /30changes.sfs. the 30changes is the order number I chose which is hard coded in the save.sh script.

I have run in RAM2 but not really worked with this mode that much yet to find out that potential.

Another crazy thing is someone mentioned JWM_Kit which looks really interesting to perhaps add to KLV-Boxer-alpha2, which is the JWM - ROX desktop KLV. And use this set of tools to customize JWM as easily as it is to modify XFCE4 for most users. If I can find the time I will add the JWM_Kit to a KILV-Boxer that has the default jwm config files

[wiak]

I have run in RAM2 but not really worked with this mode that much yet to find out that potential.

Another crazy thing is someone mentioned JWM_Kit which looks really interesting to perhaps add to KLV-Boxer-alpha2, which is the JWM - ROX desktop KLV. And use this set of tools to customize JWM as easily as it is to modify XFCE4 for most users. If I can find the time I will add the JWM_Kit to a KILV-Boxer that has the default jwm config files

I really recommend w_changes=RAM2 mode when you want to temporarily try something without saving the session (or experiment with the rsync line I gave, if you do want to merge in the session - like I said, worked for me).

As for JWM_Kit, I also took the view in the KLV openbox/tint2 version I was working on (and will come back to later) that Python 3 would be available by default. So using a very pretty dynamic menu called "jgmenu" that is written in Python 3 and doesn't need GTK or Qt the way it is written. It is also easy to change the look and feel (theme-able and can tell it to use 1 or 2 levels of menu hierarchy or more ): https://github.com/johanmalm/jgmenu

I've attached a screenshot of one themed version. Actually the way I have it running in KLV openbox/tint2 is even prettier, and as I say it is dynamic and no fix-menus type script required - does that itself automatically when new packages added (via usual freedesktop desktop files mechanism). Jgmenu is available from Void repos as far as I remember.