'Weedogged' Void Linux XFCE

[rockedge]

Instead of using a plugin file and the build_rootfs.sh script to construct a WeeDog-Void from scratch, I am now downloading the Void Linux void-live-x86_64-20210218-xfce.iso and will use the the skeleton initrd.gz to attempt to set up a frugal WDL-Void-xfce system.

[wiak]

Instead of using a plugin file and the build_rootfs.sh script to construct a WeeDog-Void from scratch, I am now downloading the Void Linux void-live-x86_64-20210218-xfce.iso and will use the the skeleton initrd.gz to attempt to set up a frugal WDL-Void-xfce system.

Yes, that should work, though the initial rootfilesystem will likely be large compared to the versions you build using your own plugins.

[rockedge]

I ran into some small problems setting up, but seem very close to a good boot. First issue is getting the right kernel modules into the initrd.gz which is being sorted out.
The initial boot attempt ended with a kernel panic but seems related to the lack of modules in the proper place. Second is the way the Void Live ISO is shipped. It uses .img files for the rootfs so I am playing around with methods to convert to an uncompressed XXfirstrib_rootfs.

[Keef]

I got it to boot ok - but got stuck at the log in. Would not accept the password (voidlinux) for either 'root' or 'anon'.
I had decompressed the img file then made an sfs out of it.

HP Elitebook 8530w

[rockedge]

@Keef Same thing happened to me trying out Manjaro! I had overlooked adding an "08" to the front of the live.sfs so it wasn't loaded and the PAM didn't work. So after renaming it to 08live.sfs and rebooting, the login worked! Otherwise I couldn't login at all. Maybe something to look at with Void?

Which ISO did you grab the rootfs.img file from for Void?

[wiak]

I got it to boot ok - but got stuck at the log in. Would not accept the password (voidlinux) for either 'root' or 'anon'.
I had decompressed the img file then made an sfs out of it.

HP Elitebook 8530w

Actually, I just had a similar issue with WDL ManjaroXFCE but in a different scenario. I was trying out a gtkdialog addon sfs for the first time and something about that prevented auto-login to X and manjaro password as 'manjaro' didn't work; mind you I'm not sure if that is the correct password. Nevertheless I wasn't expecting it not to auto-login so I'll be looking into what caused that for me tomorrow - too late at night here just now...
EDIT: actually it wasn't an sfs - I left it as an uncompressed directory since just developing it (i.e. 10gtkdialog_filemnt/).
EDIT2: Ah... in my case I think it was because I created a /home/manjaro directory in the addon, but with the wrong owner - should be user manjaro and I accidentally had it as root so probably overlaid manjaro normal /home/manjaro and messed login up - haven't time to test though.
EDIT3: Couldn't resist - I did test and that wrong owner issue in my 'addon' was all that was wrong. I will have to think how to make sure I have the correct UserID for user manjaro in the addon - I suppose I can just check whilst booting into WDL ManjaroXFCE normally (though I'm making the addon in WDL_Arch64 because I have more dev tools there.

[wiak]

As you can see from the screenshot, some of my 10gtkdialog_filemnt/ plugin is working - screenshot is of Precord (bash/gtkdialog program) running on WDL_manjaXFCE. This is using gtkdialog compiled for GTK3.

[rockedge]

@wiak Nice!

I am close to getting the WeeDogged Void to run. I temporarily solved the login issue by using the mount / umount script tools to chroot the firstrib_rootfs and changing the password for root and anon. After umount I then booted the system which started and I was able to login, but only with the "root" user.

Also Xorg would not start though startx begins as expected and just before the GUI desktop appears, Xorg shutsdown. I ran into this in the early stages of Firstrib and beginning to build a desktop OS but I don't remember how it was fixed. So status is that I unsquashed then mounted the Void Linux ext3.img file which I copied into a directory called 04firstrib_rootfs that I am leaving unsquashed and attempting to boot. I initially uncompressed the initrd.gz and added the kernel modules plus the vmlinuz from the Void Linux kernel provided in the original ISO, and then re-compressed it.

Perhaps today I can get lucky. Meanwhile I booted into a previously built WeeDog64-Void built via plugin file and build_rootfs script, which started right away and despite not being run for several months, updated and upgraded smoothly and man oh man is it fast!

On that system I just compiled gtkdialog source I grabbed from the woof-CE github repo. Mochimoppel's mm_viewme (latest version) started right up. I found I can move the gtkdialog binary into other WeeDog's and that works.

[wiak]

I initially uncompressed the initrd.gz and added the kernel modules plus the vmlinuz from the Void Linux kernel provided in the original ISO, and then re-compressed it.

I presume you don't mean you put a copy of vmlinuz into the initrd since that isn't required.

I hate when X doesn't start since when that happens I generally am unsure how to process having very little knowledge of X start up procedures. Fortunately it usually just starts. I may have a try at using official Void Linux iso in a day or two also.

Since you are able to login now as root, I imagine you can change anon password from booted system now. Yes, once you have a working gtkdialog, as long as no additional libs are needed, then that will generally work in other distros. My main work isn't so much the gtkdialog, but arranging Terry Becker's (sunburnt) filemnt to work in filemanager - I already use that in WDL_Arch64 with pcmanfm, but Manjaro uses thunar and getting actions to occur may be different - also I may have to insert Mime-related code, which is always a bit tricky. It is filemnt that on clicking an iso in filemanager causes it to open up for copying its parts out, and similarly for sfs files.

Good to hear you are making good progress

wiak

[rockedge]

I presume you don't mean you put a copy of vmlinuz into the initrd since that isn't required.

That's right, no vmlinuz in the initrd! Just mentioning I used the vmlinuz that belongs to the modules.

[rockedge]

WeeDog-Void, 64 bit jwm - rox using a 5.11.4-rt11 Puppy Linux kernel
Built with wiak's build_rootfs script and using the skeleton initrd-v400rc1.gz

2021-09-15-234015_1024x768_scrot.png (49.64 KiB) Viewed 2684 times

2021-09-15-235307_1006x719_scrot.png (132.21 KiB) Viewed 2682 times

[gabtech]

@rockedge

Care to share the build_firstrib_rootfs-400rc1.sh script? I also pm you on how to use puppy kernel in another distro.

[wiak]

<-- Back to WDL Cheatsheet menu: https://forum.puppylinux.com/viewtopic. ... 426#p36426

Care to share the build_firstrib_rootfs-400rc1.sh script? I also pm you on how to use puppy kernel in another distro.

Without having time to write much in the way of 'howto' help details I've temporarily attached the get_WDL_build_firstrib_rootfs script here (I'm hoping its the most recent copy - I'll check later). Just remove dummy tar and make it executable for use. I've also attached some useful related WDL utilities: modify_initrd.sh, mount_chroot.sh and umount_chroot.sh (run all of these with --help option for brief usage).

The fetched build_firstrib_rootfs_401rc1.sh script itself gives basic help with:

Code: Select all

./build_firstrib_rootfs_401rc1.sh --help

(actually, I think it does so even without the --help)

Normal build procedure is to create empty directory you will build and later boot from. Then run the script along with the f_00xxx.plug file you create yourself containing any extra install-commands/packages-you-want-to-include. Without any f_plugin file, the script itself would just build the smallest core variation of the flavour you are creating. I'd include simple exemplar plugin but don't have any handy right now. Perhaps rockedge can help you with that. Important thing generally to add in your plugin(s) are the likes of eudev (or whatever is around now) - and possibly wpa_supplicant and so on for wifi connecting (the build does include a couple of tiny weedog scripts such as wd_mount, and wiakwifi (a simple ethernet and wpa wlan connect program using busybox udhcpc) - I generally put all wd scripts in /usr/local/bin so as to separate them from underlying distro.

For some expected f_plugin naming conventions (especially for contributed plugins), it would be good to read:

"HowTo use multiple f_XXX plugins and create your own" at link
https://weedoglinux.rockedge.org/viewto ... p=122#p122

Assuming an f_XXX plugin named f_00_Void_i686_jwm_rockedge, the sort of command you end up running could be something like:

Code: Select all

export CONNECTION_TIMEOUT=-1
./build_firstrib_rootfs_401rc1.sh void default amd64 f_00_Void_generic_NoX_WDLteam_v100rc1.plug

'default' above is just a placemarker to make sure the architecture appears in correct $3 arg position since Void doesn't come in different 'release' varieties. Its a purposively simplistic script so no complex option handling. The overall format of the build command is:

Code: Select all

Usage:
./build_firstrib_rootfsX.sh distro release arch [filename.plug(s)]

Note that all files with filenames starting with the two characters f_ will get temporarily copied into the auto-created firstrib_roots/tmp directory (and can be accessed there by the chroot build, so you can arrange for named f_plugin to call other plugins if you need that extra facility (such as a zoneminder build script... or whatever). If no plugin is named on the commandline, the script will automatically load any f_plugin files named f_00.plug and f_01.plug and 'source' their contents one after the other at the end of the build before the chroot stage of that ends.

NOTE WELL (per comment notes in build_firstrib_rootfs script): if you want udev hotplug device/modules-autoload management daemon (most will)
# and/or wpa_supplicant you need to apt install them in an f_XXX build plugin
# For example: xbps-install -y eudev wpa_supplicant
# For a bootable system you'll also want linux kernel and appropriate firmware.
# You may also need to configure system for use of other repos (e.g. non-free).

wiak

Now that WeeDog is in the process or being re-developed/re-branded back to original project name FirstRib, it is no longer being discussed or new downloads made available via the Puppy Linux forum. If you remain interested in any of the FirstRib/ex-weedog releases, for now you should login to https://weedoglinux.rockedge.org/ and some of the older utility and build scripts will be made available to you. Other parts of the build system will only be made available, either at that location or site yet chosen, only after the next FirstRib dev version changes have been made, which may take a while because of other circumstances out of my control.

NOTE WELL that the version below are old and will be removed from this site soon - rebranded FirstRib dev versions are currently being worked on.

[gabtech]

@wiak

Thanks for the firstrib script and instructions.

[rockedge]

@gabtech here is an example of the plug file used to build the WeeDog-Void. It should give you an idea of how the plug is put together.

f_00_void_amd64_WeeDog64_jwm_rox_1.5.plug.gz

(16.3 KiB) Downloaded 89 times

remove the fake ".gz"

Here is an example of a very simple WDL-Void with no Xserver

f_00_void_WDL64_NoX-Fossa.plug.gz

(729 Bytes) Downloaded 63 times

remove the fake ".gz"

[gabtech]

@rockedge

Thanks for the scripts!

[rockedge]

@gabtech ,
The steps to use a huge Puppy Linux kernel in WeeDog-Void are fairly straight forward.

Step 1. is to select the kernel. I used 5.11.4-rt11that I compiled with PREEMPT enabled. Although not full real time, I used it because I had a copy in a convenient location, so really any huge Puppy Linux kernel can be used.
Download the conversion script (remove the fake .gz) ->

zdrv_convert.sh.gz

(1.85 KiB) Downloaded 57 times

The script was written during the early Firstrib development period when Void Linux was the main base distro, and I wasn't sure if it still would work but it did.

Take the zdrv_convert.sh script place it in a directory along with the desired kernel's zdrv.sfs and run the script:

Code: Select all

./zdrv_convert.sh <filename of Puppy zdrv>

which creates the file : 00firstrib_firmware_modules.sfs

2021-09-18-140452_406x208_scrot.png (22.42 KiB) Viewed 2588 times

2021-09-18-143208_470x257_scrot.png (27.24 KiB) Viewed 2581 times

Step 2. Place the 00firstrib_firmware_modules.sfs into the WeeDog-Void frugal directory along with the matching vmlinuz

GRUB4DOS boot stanza:

Code: Select all

title WDL-Void-SK-1(uuid)
  uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
  kernel /WDL-Void-SK-1/vmlinuz-5.11.4-rt11  w_bootfrom=UUID=8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa=/WDL-Void-SK-1 copy2ram net.ifnames=0
  initrd /WDL-Void-SK-1/initrd_v400rc1_2021_09_14_130829.gz

Step 3. Using the modify initrd script decompress the initrd_v400rc1.gz and mount the 00firstrib_firmware_modules.sfs and copy the kernel modules to the decompressed initrd and re-compress the initrd. It should be now ready to boot.

Nice "Official" background (remove fake .gz)->

weedog_Void_tinylinuxinfo.svg.gz

(33 KiB) Downloaded 58 times

[rockedge]

I booted into Puppy Linux Fossapup64 that is equipped with apt_sfs_load_fossa_amd64.sfs that is completely up to date via APT. This system has been running flawlessly with wiak's SFS addition for months. Also with Zoneminder at it's very latest cutting edge version....but that's for another thread. With Fossapup64's tools I simply squashed the 04firstrib_rootfs into 04firstrib_rootfs.sfs and renamed the uncompressed to No-04firstrib_rootfs then booted the system with the rootfs SFS.

2021-09-19-113007_406x254_scrot.png (26.1 KiB) Viewed 2557 times

The resulting system with background looks faimilar with the jwm - rox desktop combo. Using the uncompressed firstrib_rootfs it is possible with the mount/umount scripts to upgrade the kernel in the main rootfs.

2021-09-19-104605_1024x768_scrot.png (49.05 KiB) Viewed 2557 times

[gabtech]

I'm trying to build a firstrib folder using the script in the above post and the void plugin but keep getting an error both on German and US servers.

#Error: failed to download 'glibc-2.32_2

[wiak]

I'm trying to build a firstrib folder using the script in the above post and the void plugin but keep getting an error both on German and US servers.

#Error: failed to download 'glibc-2.32_2

Maybe the following post information helps avoid download issues. In particular, see CONNECTION_TIMEOUT environment variable info below. I haven't tried that Void Linux timeout fix, but the Arch Linux build I did with pacman option --disable-download-timeout seemed to work for me:

viewtopic.php?p=36473#p36473
I'm back developing my build_firstrib_rootfs f_build_plugin for my WDL_Arch64 distro. Mainly just re-organising the plugin. I've tried that several times before, but each time I've broken it and ended up going back to the original, but today at last I'm managed.

In the process I'm trying to see if I can make it work better even when upstream repos are timing out or whatever (you know the problem), and for Arch builds at least, I may have managed... turns out pacman has an option (I should have checked before...):

--disable-download-timeout
Disable defaults for low speed limit and timeout on downloads. Use this if you have issues downloading files with proxy and/or security gateway.

"Time" will tell if that really has worked, but certainly had a faultless build couple of times today.

Actually, I've just taken a look at Void Linux xbps man page... and turns out you can set an environmental variable for that, which hopefully might fix things there too!!! We should have noticed really:

CONNECTION_TIMEOUT
Sets connection timeout in milliseconds instead of default value of 5 minutes. When -1, waits indefinitely.

I'd therefore try doing the ./build_firstrib_rootfsXXX.sh step after first exporting env variable CONNECTION_TIMEOUT=-1

Code: Select all

export CONNECTION_TIMEOUT=-1

[gabtech]

I'd therefore try doing the ./build_firstrib_rootfsXXX.sh step after first exporting env variable CONNECTION_TIMEOUT=-1

Code: Select all

export CONNECTION_TIMEOUT=-1

@wiak
The above tip worked and the download went smoothly, but I'm running into another error as seen in the screenshot. Can you help troubleshoot?

[rockedge]

I think there is something wrong with the initrd.gz /lib/modules. And the mounting of the file system isn't happening.

What kernel are you using? I built a initrd.gz with wiak's build_initrd_latest.sh script (I don't have a newer version) which also sets up using Void Linux's kernel's vmlinuz file. This booted for me the new 01firstrib_rootfs. So far I have not gotten a clean boot from the skeleton initrd when I have used it.

I am about to go for an attempt to use the skeleton initrd.gz with the firstrib_rootfs, set up manually and then a version after running Fred's cr-initrd script on it

[rockedge]

Once booted there are some adjustments to make for a smoother experience. This is a desktop in it's rawest form and barely refined.

There are a couple of small scripts to add which should be added also to the plug file.

[wiak]

The above tip worked and the download went smoothly, but I'm running into another error as seen in the screenshot. Can you help troubleshoot?

I haven't used Puppy huge kernel or zdrv_convert for a long time so I'm not sure if something has changed there or I've changed that part of the initrd/init related to it (and perhaps messed it up). I'll check and come back to you on the matter. The zdrv_convert seems to have made an appropriate 00firmware_modules.sfs (I shouldn't actually have called it firmware_modules since it is only the modules we are interested in here...).

[wiak]

The above tip worked and the download went smoothly, but I'm running into another error as seen in the screenshot. Can you help troubleshoot?

I haven't used Puppy huge kernel or zdrv_convert for a long time so I'm not sure if something has changed there or I've changed that part of the initrd/init related to it (and perhaps messed it up). I'll check and come back to you on the matter. The zdrv_convert seems to have made an appropriate 00firmware_modules.sfs (I shouldn't actually have called it firmware_modules since it is only the modules we are interested in here...).

Actually, looking at my new initrd/init (actually w_init) code, I appear to have made an improvement so as not to need zdrv_convert.sh. I haven't been able to try it myself yet, but I suggest simply try taking original zdrv_XXX.sfs file and simply rename it to 00zdrv_XXX.sfs (and remove that previous 00firstrib_firmware_modules.sfs (but keep a renamed copy of it just in case I'm wrong here). Then try booting with the related Puppy huge kernel and that 00zdrv_XXX.sfs file.

Let me know if all good thereafter. If not, I'll investigate further.

wiak

[wiak]

The above tip worked and the download went smoothly, but I'm running into another error as seen in the screenshot. Can you help troubleshoot?

I haven't used Puppy huge kernel or zdrv_convert for a long time so I'm not sure if something has changed there or I've changed that part of the initrd/init related to it (and perhaps messed it up). I'll check and come back to you on the matter. The zdrv_convert seems to have made an appropriate 00firmware_modules.sfs (I shouldn't actually have called it firmware_modules since it is only the modules we are interested in here...).

Actually, looking at my new initrd/init (actually w_init) code, I appear to have made an improvement so as not to need zdrv_convert.sh. I haven't been able to try it myself yet, but I suggest simply try taking original zdrv_XXX.sfs file and simply rename it to 00zdrv_XXX.sfs (and remove that previous 00firstrib_firmware_modules.sfs (but keep a renamed copy of it just in case I'm wrong here). Then try booting with the related Puppy huge kernel and that 00zdrv_XXX.sfs file.

Let me know if all good thereafter. If not, I'll investigate further.

wiak

Okay, so I'm right about the 'improvement'. So you now just need to rename Puppy zdrvXXX.sfs file to 00zdrvXXX.sfs

However, I did forget to move the mount point, so whilst the system will boot the other modules will not be currently available (which they should be) in /usr/lib/modules. With this special 'using huge kernel 00zdrvXXX.sfs' configuration there SHOULD be no need for any modules to be placed inside the firstrib_rootfs itself (except that I forgot one line in the initrd/init_w_init script that was needed to make that true...

To get this special-case Puppy huge kernel method working, therefore, do the following:

1. Use original Puppy zdrvXXX.sfs but renamed to 00zdrvXXX.sfs
EDIT (I had this the 'wrong way round previously'): Note that this is assuming the Puppy zdrv contains its modules in directory /lib/modules (which they are for zdrv of Fossapup); if you come across a case of the modules being instead in /usr/lib/modules then we need to supply a grub kernel parameter as far as I recall (will have to check the script again...).

2. Download the attached (fixed) w_init file (remove the dummy tar) into your boot directory

That fixed w_init contains two changes. I no longer unmount /usr/lib/modules at line 295 (In attached w_init I inserted a # to comment out last part of that line) - unmounting it was an earlier mistake.

and (around line 320), I use mount --move to move the mounted /usr/lib/modules to the overlayfs merged version so all should now work (and without needing ANY modules in the firstrib_rootfs itself for this special Puppy huge kernel + zdrv case):

Code: Select all

mountpoint -q /usr/lib/modules && mount --move /usr/lib/modules merged/usr/lib/modules

NOTE: @rockedge: as far as I see it, though the old build initrd would allow system to boot (after using the 'usually' no longer now needed zdrv_convert.sh script), the main issue still existed since you probably previously needed to copy all the modules also into firstrib_rootfs, which should not be necessary when zdrv is available as 00zdrv (in WDL this can be left uncompressed or made into an sfs of course...). Above code (attached w_init) fixes that unnecessary duplication of modules situation.

NOTE also, that none of this really affects previous steps for creating WDL_manjaXFCE and similar. It is only concerned with using a Puppy huge kernel and existing zdrv as 00zdrvXXX.sfs layer (i.e. modules as layer 00 in the overlayfs so no modules needed AT ALL in firstrib_rootfs for that special case).

I'll tidy up the code and fix the skeleton initrd(s) later with these little Puppy huge kernel related fixes.

Thanks, @gabtech, for noticing there was an issue with this long-ago implemented 'using Puppy huge kernel' facility. Let me know if now works for you with that replacement w_init. You can certainly easily create a very small WDL distro using a huge kernel and 00modules.sfs (such as 00zdrvXXX.sfs) in this matter (remember only the 00 part is important in that filename - the rest of the name can be anything you like...). That is:

NO MODULES need to be stored in EITHER the initrd OR inside the firstrib_rootfs if using a huge kernel and external 00modules.sfs (i.e. 00zdrvXXX.sfs) since WDL will automatically use the ones provided in the 00modules.sfs. Of course you could arrange things to also use a Puppy firmware sfs (fdrv) and not need any firmware in the firstrib_rootfs either (I'll think further about that to see if script could better accomodate that (probably was my original intention when earlier in WDL development choosing name 00firstrib_firmware_modules.sfs).

wiak

[gabtech]

@wiak

Thanks for the above pointers. The module error has gotten, only one error remaining. See attached images. Could it be because I'm using the skeleton make initrd script?

[wiak]

Hi gabtech,

I note error message:

Code: Select all

can't run '/etc/init.d/rcS': No such file or directory

Unfortunately, that doesn't tell me very much, so I can't help without checking out a WDL_Void build myself, which I don't currently have.

What happens at the end of w_init is:

Code: Select all

exec switch_root merged /sbin/init

That's probably what you want to check-out/fault-find assuming that 'switch_root to merged occurs okay, which I'm presuming it does. In otherwords, check what /sbin/init actually is inside your firstrib_rootfs. For Void Linux I kind of recall it will likely be a symlink to runit (but you'd have to check that with ls -al NNfirstrib_rootfs/sbin/init). If you have truly succeeded in building the Void Linux firstrib_rootfs without error then runit configuration should just be working - I don't know Void Linux runit configuration any more (haven't looked at it at that level for over a year), but it 'should' just work (i.e. boot) so I can't say what is causing your error. Anyway, at this stage check what firstrib_rootfs/sbin/init is (or the target it points to) - and report back here. Rockedge should then be able to help out since his WDL_Void is booting fine, but I can't say without having a working WDL_Void build myself sorry. I'll try building one myself later if you don't get it sorted out.

By the way, am I correct in thinking you used build_firstrib_rootfs to create the firstrib_rootfs and then using the skeleton initrd along with the 00zdrvXXX.sfs and associated vmlinuz-linux kernel from Fossapup64? That should work (if using the w_init I posted for you to try). And did you build your firstrib_rootfs with one of rockedge's f_plugins? If so, which one? Would need your exact build configuration to find out why it is not working for you.

[wiak]

Okay, I just tried a quick WDL_Void build using rockedge's f_00_void_WDL64_NoX-Fossa.plug.

So the build firstrib_rootfs command used was:

Code: Select all

./build_firstrib_rootfs_400rc1.sh void default amd64 f_00_void_WDL64_NoX-Fossa.plug

Anyway, aside from root passwd issue, all booted fine after I did the following:

1. renamed 'borrowed' Fossapup64 zdrv_fossapup64_9.5.sfs to 00zdrv_fossapup64_9.5.sfs (26.7MiB). and placed that in WDL_Void64/ directory.
2. Put Fossapup64 vmlinuz-linux kernel (6.3MiB) in same directory. The Fossapup kernel/modules I used are version 5.4.53).
3. Put skeleton initrd.gz (609.1 KiB) in that bootfrom directory too (didn't need to add any modules to it since using 00zdrv as overlay).
4. Renamed the built firstrib_rootfs directory to 08firstrib_rootfs/ directory (i.e. left uncompressed for test; size 1GiB).
5. Modified my menu.lst to include (use your own uuid):

Code: Select all

title WDL_Void64
find --set-root uuid () b812c597-8099-4bee-9bb3-8b9c10f1e902
kernel /WDL_Void64/vmlinuz-linux w_bootfrom=UUID=b812c597-8099-4bee-9bb3-8b9c10f1e902=/WDL_Void64
initrd /WDL_Void64/initrd.gz

And rebooted, and it booted fine up to login prompt, where I had arranged user:passwd to be root:root.

/sbin/init, by the way, was a symlink to runit-init and that worked out-of-the-box without errors.

Note: rockedge's f_ plugin actually installs Void kernel modules (installing 'linux' is actually a template which I guess includes the modules at same time), which aren't required at all in the firstrib_rootfs constructed since using Fossapup kernel + modules from zdrv. I should really have modified the plugin to not bother fetching Void modules, but I ended up deleting them anyway since not required when using 00zdrv. Also I think 'shadow' is already provided by base-minimum template, but I may be wrong.

Note that I later compressed 08firstrib_rootfs/ directory using mksquashfs with high xz compression (after removing unneeded kernel and initramfs image in /boot, the unneeded Void Linux provided modules in /usr/lib/modules, and xbps archive from /var/cache/xbps) and the resultant 08firstrib_rootfs.sfs size was 201 MiB. If you want much smaller size, then swap the /usr/lib/firmware provided by Void Linux (which is a lot...) with firmware from Fossapup fdrv. Should be relatively similar in size thereafter to Fossapup with same X/JWM components installed.

wiak

[gabtech]

@wiak

I used 'f_00_void_amd64_WeeDog64_jwm_rox_1.5.plug.gz' from above post by rockedge. And firstrib_rootfs/sbin/init is a symlink to firstrib_rootfs/usr/bin/busybox.