Development of 32 Bit WeeDog Void Linux Base

[rockedge]

WeeDog32-Void-2.4 is ready in ISO form for download and testing.

• Kernel 32 bit 5.9.14_1

• Firefox 84.0

• ALSA sound

WeeDog32-Void-2.4

https://rockedge.org/kernels/

[wiak]

now and I am approaching the idea of supplying a ready to go version as an ISO for those more familiar with that method of installation

Will be interesting to see this, and an iso. Not so many new 32bit installations nowadays.

[rockedge]

@wiak

I have an example ready enough to check out! An ISO file 698 megs. I am currently running it from an 8 gig USB stick set up with 2 partitions:
FAT32 = 256 meg boot flag
ext4 = 7.3 gig WeeDog32-Void-2.1

kernel 5.9.13
JWM
ROX
Firefox 83

WeeDog32-Void

To install it just make A frugal install directory like WeeDog32-Void, and copy the contents of the ISO to the directory.

I ran Grub4Dos on the USB stick and made a menu.lst :

Code: Select all

# menu.lst produced by grub4dosconfig-v1.9.4
color blue/cyan yellow/blue white/black cyan/black
#splashimage=/splash.xpm
timeout 10
default 0

title WeeDog32-Void-2.0 (Void Linux Flavour)
  uuid 366cf788-f936-4970-9e30-1750c01f4c03
  kernel /WeeDog32-Void-2.0/vmlinuz-5.9.13_1  bootfrom=/mnt/sdb2/WeeDog32-Void-2.0
  initrd /WeeDog32-Void-2.0/initramfs05.gz

# Advanced Menu
title Advanced menu
  configfile /menu-advanced.lst
  commandline

I know on the test computer, a DELL INSPIRON 1505e laptop (32 bit only), that the USB stick will show up as sdb1 and sdb2....what I need is a better boot code to compensate for the changing drive names assigned to the USB stick.

Use what ever method you devise to start it!
wiakwifi will prompt for wireless or eth0 connections on first boot.

IMPORTANT : Populate the menus on the first boot by running in a terminal /usr/local/bin/buildmenus
and clicking /usr/share/applications/update-entries.desktop
This will also be the method to use to UPDATE the menus after adding or removing packages.
To update repos and operating system

Code: Select all

xbps-install -Suy

Next step would be add the stuff to boot from just burning the ISO to CD-ROM and toy with UEFI. But all my 32 bit machines are BIOS driven so it isn't a problem using Puppy Linux to set up the drive with GPartED andGrub4Dos very easily and quickly.

I have not yet modified the plug file with the new advancements. Then one could just build the WeeDog32-Void from the scripts.

[rockedge]

I just manged to start the WeeDog32-Void with the Puppy Linux full real time kernel 4.19.82-rt30 with both the 64 bit and 32 bit versions of the kernel.

The screenshot is WeeDog32-Void running the Puppy Linux 64 bit full real time kernel.

2020-12-14-040923_1024x768_scrot.png (48.4 KiB) Viewed 3491 times

[wiak]

I know on the test computer, a DELL INSPIRON 1505e laptop (32 bit only), that the USB stick will show up as sdb1 and sdb2....what I need is a better boot code to compensate for the changing drive names assigned to the USB stick.

I'm downloading your iso right now rockedge.

Regarding the 'better boot code' comment you made above. From the resulting name (initramfs05.gz) it seems that you have not used the latest build_weedog_initrd-latest.sh version to create the weedoglinux initrd. If you had done that, the initrd created would have been automatically simply named initrd.gz. Either that, or you have simply renamed it yourself for old times sake...

There is a big advantage to using build_weedog_initrd-latest.sh though since that contains advanced uuid determination code. With that you do not need to refer to USB by names such as sdb1 or sdb2 at all, but simply by uuid as follows:

Code: Select all

title WeeDog32-Void-2.0 (Void Linux Flavour)
find --set-root uuid () 366cf788-f936-4970-9e30-1750c01f4c03
kernel /WeeDog32-Void-2.0/vmlinuz-5.9.13_1 w_bootfrom=UUID=366cf788-f936-4970-9e30-1750c01f4c03=/WeeDog32-Void-2.0
initrd /WeeDog32-Void-2.0/initrd.gz

It doesn't matter how you created the firstrib_rootfs. The important thing is to build the initrd.gz using that latest build_weedog_initrd-latest.sh script.
Available at weedog/weedoglinux gitlab site here:

https://gitlab.com/weedog/weedoglinux/- ... ild_latest

Then the above suggested grub4dos menu.lst stanza should work no matter what sda position your system 'sees' the usb stick at. I suggest you just run that latest build_weedog_initrd-latest.sh script to remake the initrd using your already created firstrib_rootfs. That wouldn't take long at all.

Cheers, wiak

[wiak]

I have an example ready enough to check out! An ISO file 698 megs.

Of course I can imagine people questioning why such a simple system has such a large iso size. But actually the reason is equally simple. Upstream Void Linux repos provide tons of firmware by default - this is not a problem, except that it takes longer to download and occupies that bit more on a systems storage (hard drive or wherever you install it). In explanation, compare with the amount of firmware provided by Puppy BionicPup32:

size of Puppy BionicPup32 /lib/firmware provided: 1.9 MiB in its zdrv + 58.6 MiB in fdrv (don't know if there is more).
size of WeeDog32_Void_2.0 /lib/firmware provided: 305.1 MiB

So there are certainly likely to be systems that WeeDog32 will fully run on that BionicPup32 won't. Having said, that BionicPup32 runs on most systems so simply providing similar set of firmware in WeeDog32_Void should be fine for most people and slim down the iso considerably (but a lot of bother to slim it down really - and for little good reason IMO). There are a few other smaller savings that can be made if someone wishes to try and produce smallest WeeDog32 iso possible (Puppy size or less) - for example the initrd is much bigger than it needs to be - for example it contains more modules than most common systems would need and they are currently individually compressed per Void's method - funnily enough it is better to have them uncompressed since the final compression (into gz or xz or whatever) of the initrd.gz results in a much smaller size of initrd that way. But main thing is the huge amount of firmware provided by default - you can expect WeeDog32_Void to work with most any devices installed on your system!

Best way to slim down the firmware would in any case not be to manually selectively prune it though, since that would have to be done by the iso creator each time they produced a new release. Rather, it could be automated via a set list of required firmware. In practice, for most systems, as I say, not much firmware is required to satisfy the needs of most common systems anyway. Also, initrd could be created really tiny, per rufwoof fashion, for custom builds for specific systems (e.g. build the drivers into the kernel rather than including as modules). I doubt I myself will be doing any of these slim-it-down ''tricks' since media storage size is not something I care about (unless I want version to run wholly in RAM and not much RAM availabe...).

By the time you add all the interesting apps you find or want or need, all systems soon swell in size to a few GB often enough in the end anyway if we are honest about it. And any installed system under 1 GB is pretty small and fine for a custom purpose (such as zoneminder) I'd say. What becomes more important is RAM and CPU usage, and most important of all: stability (along with flexibility/save/rollback/frugal-install facilities provided by the initrd). And of course an excellent reliable dependency-resolving package manager, which Void provides us with via its official xbps + kept-up-to-date repos.

wiak

[rockedge]

@wiak Excellent points. I have the WeeDog32-Void with an uncompressed firstrib_rootfs that I can run the latest build_weedog_initrd-latest.sh on !

I was going with what was working so well, but as I refine the WeeDog32 I can see big advantages in using the latest build scripts.
A run will occur in the next 20 minutes.

I have just begun to shrink the overall ISO size. All I did so far was remove the packages in /var/cache/xbps and cleared the cache before building initramfs05.gz

Really excited about running the build_weedog_initrd-latest.sh on the firstrib_rootfs I have setup. I would like to create a fully functional 32 bit OS for those hobbyist tinkerer's wanting a fast responsive fully expandable operating system.

[rockedge]

@wiak

I ran the the latest build script and it shrunk the firstrib_rootfs.sfs to 575 meg and the complete ISO is now 647 meg!

Running tests on booting from different USB drive set ups. Some sticks and some USB adapted HDD's.
I am using a WeeDog64-Void as practically my main daily driver on 2 machines. For now though I am concentrating on a 32 bit version that can be released as an RC or experimental for tests.

As far as I can tell this 32 bit OS offers the latest stable kernel and an advanced Firefox with the excellent XBPS package management system. Also possible is to use older versions of kernel and WeeDog32-Void can run many of the Puppy Linux kernels, so if faced with older machines in need of firmware from the era of said machine, it is possible to outfit WeeDog32-Void with a kernel that includes the firmware to run the devices.

And this is a rolling release and can be fully updated at any time in a terminal with :

Code: Select all

xbps-install -Suy

recommended is to put a hold on the kernel update. I will devise an easy way to upgrade or downgrade the kernel at a later time.

Code: Select all

xbps-pkgdb -m hold linux5

[rockedge]

Update on attempting to boot the version built with the latest build_weedog_initrd-latest.sh and I've run into a kernel panic. Of course the error runs by long enough to move the important part out of the terminal's buffer......so I am poking around diagnosing the problem.

So far the system WeeDog32-Void-2.1, built with build_weedog_initramfs05_s207.sh :

Component	Size
01firstrib_rootfs.sfs	625 meg
initramfs05.gz	65 meg
vmlinuz-5.9.13_1	7601 K

works very well on the test platform a DELL INSPIRON 1505e laptop.

The system WeeDog32-Void-2.2, built with build_weedog_initrd-latest.sh :

Component	Size
01firstrib_rootfs.sfs	575 meg
initrd.gz	65 meg
vmlinuz-5.9.13_1	7601 K

results in a kernel panic. Some error messages suggest too many layers and missing mount/bind points.

Update. I think there is incorrect syntax in the Grub4Dos menu.lst entry that might be the cause of the kernel panic

[rockedge]

Success!!
Had successful boots of WeeDog32-Void-2.2 built with build_weedog_initrd-latest.sh, running from a 4 gig and 8 gig USB stick(s).
WeeDog32-Void-2.2.iso ------- 647 meg

This version sports the components ->

Component	Size
01firstrib_rootfs.sfs	575 meg
initrd.gz	65 meg
vmlinuz-5.9.13_1	7601 K

Code: Select all

title WeeDog32-Void-2.2 (initrd.gz)
  uuid 04154b23-6616-40d7-b80d-52ac5f7126f8
  kernel /WeeDog32-Void-2.2/vmlinuz-5.9.13_1  bootfrom=UUID=04154b23-6616-40d7-b80d-52ac5f7126f=/WeeDog32-Void-2.2
  initrd /WeeDog32-Void-2.2/initrd.gz

After initializing the menus htop reports 95 meg of RAM used at idle after start up.

[wiak]

Success!!
Had successful boots of WeeDog32-Void-2.2 built with build_weedog_initrd-latest.sh, running from a 4 gig and 8 gig USB stick(s).
WeeDog32-Void-2.2.iso ------- 647 meg

...

Code: Select all

title WeeDog32-Void-2.2 (initrd.gz)
  uuid 04154b23-6616-40d7-b80d-52ac5f7126f8
  kernel /WeeDog32-Void-2.2/vmlinuz-5.9.13_1  w_bootfrom=UUID=04154b23-6616-40d7-b80d-52ac5f7126f=/WeeDog32-Void-2.2
  initrd /WeeDog32-Void-2.2/initrd.gz

Hmmm, something wrong with above menu.lst if you created initrd.gz using build_weedog_initrd-latest.sh. The variable name nowadays is definitely w_bootfrom and NOT simply bootfrom. I changed the name of most all variables used by that build script to remind myself if the variable was to do with build_firstrib_rootfs (for which I use variables starting with f_) or with build_weedog_initrd (for which I use variables starting with w_). Anyway, I assume what you posted is just a typo on your part and that what you use in that menu.lst entry actually is w_bootfrom. Otherwise, yes, I'd expect that entry to find the vmlinuz... and the initrd.gz and (all else going well..!) boot successfully so I'm happy to hear it has.

Yes, I think your plan of making a 32bit WDL_Void version is very good since could be extremely useful to keep older 32bit machines running with up-to-date components. Let's hope upstream Void Linux continues to support 32bit architecture. I blew up all my old 32bit laptops, except for one machine that has a Pentium M CPU (works with force PAE), a dodgy hard drive and german keyboard... I used that machine for years though, so never been willing to throw it away and may give it another new life via your iso now...

I'm actually pleasantly surprised your iso is already not particularly huge. Might be fun to later experiment further with slimming it since I bet we could cut its size in half, following all the usual tricks and removal of docs and/or put some of the NLS alternative language stuff into a separate sfs maybe. Having said that, such slimming isn't really important and leaving things standard is better/simpler for upgrades anyway.

wiak

[rockedge]

@wiak Yes it was a typo!

I wasted about 4 hours booting and re-booting with kernel panic until I realized I wasn't using the correct syntax. A simple

Code: Select all

w_bootfrom=UUID=<my-partitions-uuid>=/WeeDog32-Void-2.2

the entire time I overlooked the "w_".

I have only done 2 things so far to shrink the size of the iso and firstrib_rootfs:
1. before building the initrd.gz, mount the firstrib_rootfs using the mount script, ran the command below then the umount script.

Code: Select all

xbps-remove -Oo

.
2.From the firstrib_rootfs, remove all the files from /var/cache/xbps
3. run build initrd.gz script
4. used dir2iso tool in Puppy Linux Bionic64-CE (woof-CE generated) to build ISO file of 647 megs.

Further work to strip out some of Docs man and NL files will be experimented with.
But at this time I feel 647 meg is close enough to most of the latest generation of Puppy Linux's ISO size to be in an acceptable range.

Also some further refinement of the current WeeDog32 will occur to add some ease of use tools and add some automatic mechanism to trigger the menu population at the time of the very first boot up.

I have several 32 bit machines to test on. Desktops and laptops and so far they all boot WeeDog32-Void and seem to run cool and fast.
WeeDog32-Void is at this point still considered experimental but I am convinced when released will compete with any and all 32 bit operating systems offered.
WeeDog32-Void is fairly bare bones with a a basic desktop and window manager, it is intended for the hobbyist and tinkerer. The foundation is there to create what ever system one desires. The XBPS package manager and a reference to the Void Linux packages : https://voidlinux.org/packages/ will make expansion and adding other desktop managers and packages easy.

I will eventually modify the original PLUG file that guides this build of WeeDog to create this desktop by running 2 simple scripts one of which calls the PLUG file. I would like to create a range of PLUG's that will quickly build WeeDog's with exactly the amount of detail one chooses.

So far I have the WDL64 and WDL32 which are similar and one for a pure Zoneminder / web server WeeDog version with no X server and is intended for headless operation from remote terminals/systems.

[rockedge]

for fun I booted WeeDog32-Void-2.2 on a 64 bit machine and equipped it with a 64 bit full real time kernel from the Puppy Linux collection, 4.19.82-rt-30.
I used the conversion tool zdrv_convert.sh, to build a 00firstrib_firmware_modules.sfs from a zdrv_bionicpup64_8.0.sfs. Added the vmlinuz from the 4.19.82-rt30 kernel.

The 32 bit WDL runs really well with the 64 bit kernel.

[wiak]

for fun I booted WeeDog32-Void-2.2 on a 64 bit machine and equipped it with a 64 bit full real time kernel from the Puppy Linux collection, 4.19.82-rt-30.
I used the conversion tool zdrv_convert.sh, to build a 00firstrib_firmware_modules.sfs from a zdrv_bionicpup64_8.0.sfs.

I'm happy to hear that 00firstrib_firmware_modules.sfs code mechanism still works to use Puppy kernel/modules when desired. I always wondered if the many changes I made to the initrd/init might have ended up messing up that facility, but I've never got round to trying it again. I did think there was a chance it would still work and had read the code and it looked okay, but nothing like an actual test result! That gives you a lot of flexibility in terms of what kernel/modules/firmware you use since, as you do, you can draw on such key system components from Puppy's arsenal to make a hybrid with full Void xbps support thereafter.

[wiak]

@rockedge Actually I had forgotten all about the existence of zdrv_convert.sh until you mentioned it above. From old firstrib thread:

...if using BionicPup kernel instead of Linux Void kernel, it is no longer sufficient to simply rename e.g. Bionicpup zdrv. Rather, you need to convert the zdrv sfs by placing it in same directory as utility zdrv_convert.sh and running command:
./zdrv_convert.sh <filename of Puppy zdrv>
from the same directory you store a copy of BionicPup zdrvXXX.sfs

One consequence of me forgetting about it is that I don't think I've included a copy in the weedoglinux gitlab utilities directory. I've thus now downloaded zdrv_convert.sh from old murga thread and will put it on the gitlab site. So copy of zdrv_convert.sh can now be found at:

https://gitlab.com/weedog/weedoglinux/- ... /utilities

My copy has "Revision 0.0.1 Date: 25 July 2019", but I think that was the only one made(?)

EDIT: Whilst looking for original copy of zdrv_convert.sh I came across the following, somewhat amusing to me, somewhat frightening to me, thread about firstrib that mikeslr started (which even alludes to the recent US presidential election...!). It still makes me panic that I will suddenly wake up and find that WeeDog does not in fact exist at all (like alone zdrv_convert.sh), and let's not mention Trump...:

http://www.murga-linux.com/puppy/viewto ... 11#1034406

[rockedge]

I remembered that I had made progress earlier using WeeDogXX-Void with a Puppy Linux AUFS huge kernel in a hybrid WeeDog - Puppy Linux Bionic with a lot of success. I didn't go much further than experimenting around with a proof of concept. But the reality is, I was running many Puppy Linux Bionic tools and scripts and had the xbps package system fully functional. As I have mentioned I was able to run the WeeDog32-Void-2.2 with the full real time kernel 4.19.82-rt30 I made for Puppy Linux 64 bit systems recently.

For now the ISO's will focus on the 32 bit WeeDog with the Void Linux kernel until it reaches a decent stable release point. Although WeeDog's in the ISO form will be highly experimental basic building block OS's. Perhaps examining the PLUG file examples it would an option to learn how to make custom PLUG files to build this or similar systems from scratch.

Then I'll go into creating a hybrid that uses XBPS and perhaps alongside Pkg.

[wiak]

Hello rockedge,

As I've also posted on weedoglinux forum,

"I downloaded your ver 2.2 of the iso and put its contents into /WeeDog32-Void-2.2 directory on my harddrive (which blkid reveals has uuid c6a96ce1-8c76-4aca-be99-5fc57039b49b). Then I simply added the following stanza to my grub4dos menu.lst, and it booted first time, and asked for my wifi details, which connected fine. Just did all that a few minutes ago and posting from it now via the currently provided Firefox ver 83.0. This HP Elitebook 2530p machine actually has a 64bit capable core2duo processor, but that works fine with 32bit distro too of course.

Code: Select all

title WeeDog32-Void-2.2 (initrd.gz)
  uuid c6a96ce1-8c76-4aca-be99-5fc57039b49b
  kernel /WeeDog32-Void-2.2/vmlinuz-5.9.13_1  w_bootfrom=UUID=c6a96ce1-8c76-4aca-be99-5fc57039b49b=/WeeDog32-Void-2.2
  initrd /WeeDog32-Void-2.2/initrd.gz

Nice job indeed. Fun to play with Void Linux xbps package manager again!"

I forgot to mention that I followed your buildmenu instructions to the letter (and so on) and all worked perfectly.

Great also that your build is for a 32bit WDL_Void in this current world where 32bit distros are becoming very rare.

Cheers,

wiak

EDIT: Playing youtube video worked fine (including audio) out of the box (in provided Firefox ver 83.0 32bit), by the way, on this old HP Elitebook 2530p laptop of mine. Could do with some nicer fonts, but that is a minor matter since easy enough to install them using xbps package manager. Xlunch working and nice too. Perfectly easy-usable efficient system, even at this early 'experimental' stage. I'm enjoying it.

[wiak]

One other item that seems needed is a mechanism to set up timezone - my clock was one hour out on booting so I expect that is the issue.

https://docs.voidlinux.org/config/date-time.html

[fredx181]

I've made a frugal install (on harddisk) of the ver 2.2 ISO. First few times that I tried to boot, it did hang on "Run /init as init process" and gave up, thought perhaps I did something wrong (e.g. in menu.lst entry) tried again and again, but nothing worked.
Then I left it for a long long time (hanging at "Run /init as init process"), and... after +/- 15 minutes it went on, booting to the Desktop.
Any ideas ?

Fred

[rockedge]

3 things need improvement!
Right now to set the time zone open /etc/rc.conf. And change TIMEZONE then reboot. Otherwise it is set for UTC at first run. This could be better with a GUI or command line script to work with the time settings.

There is no mechanism yet to see hot plugged USB drives or devices automatically. Mounting of partitions, drives and devices has to be done manually or by script. Some menu text can be improved such as Restart JWM and Exit JWM and replace "Lock" with "Exit X".

Add a User logout mechanism. Right now I am using the user "spot" and the script "run-as-spot" that I added in to experiment with running browsers as some other user than "root". But Void is a true multi-user system so the ability of creating other users and switching between them should be included.

Code: Select all

# /etc/rc.conf - system configuration for void

# Set the host name.
#
# NOTE: it's preferred to declare the hostname in /etc/hostname instead:
# 	- echo myhost > /etc/hostname
#
#HOSTNAME="void-live"

# Set RTC to UTC or localtime.
HARDWARECLOCK="localtime"

# Set timezone, availables timezones at /usr/share/zoneinfo.
TIMEZONE="America/New_York"

# Keymap to load, see loadkeys(8).
#KEYMAP="es"

# Console font to load, see setfont(8).
#FONT="lat9w-16"

# Console map to load, see setfont(8).
#FONT_MAP=

# Font unimap to load, see setfont(8).
#FONT_UNIMAP=

# Amount of ttys which should be setup.
#TTYS=

[rockedge]

@fredx181

I've also experienced this on occasion. I will look into it. I have had it hang on boot when the network connection fails to set up. Although in my case it seems that it hangs trying to set the clock with chrony when the network set up fails. I have no mechanism yet to deal with this scenario.

[fredx181]

@fredx181

I've also experienced this on occasion. I will look into it. I have had it hang on boot when the network connection fails to set up. Although in my case it seems that it hangs trying to set the clock with chrony when the network set up fails. I have no mechanism yet to deal with this scenario.

OK rockedge! Just for info, the "hang" point for me is long before setting up the network, I think it's at the time initrd.gz should be loaded.

Fred

[wiak]

@fredx181

I've also experienced this on occasion. I will look into it. I have had it hang on boot when the network connection fails to set up. Although in my case it seems that it hangs trying to set the clock with chrony when the network set up fails. I have no mechanism yet to deal with this scenario.

OK rockedge! Just for info, the "hang" point for me is long before setting up the network, I think it's at the time initrd.gz should be loaded.

Fred

So far it just boots up straight away on my machine. I'll try and force the network to hang to see what happens in such a case. If it was using systemd, depending how the network was being activated, that could have caused a hang, but this is using runit and I don't know enough about the runit set up to guess. If the hang is well before that, would have to determine if it occurs before the switch_root? But if so would expect to see a kernel panic message. I assume therefore it occurs after runit takes over, so presumably associated with some service runit manages, though can never really presume anything when an intermitent bug arises. I wouldn't be surprised if it is a network connection fail issue of some sort since I've certainly seen hangs when I've used systemd to manage wiakwifi so maybe something similar with runit. Might be worth trying booting without trying to get network to connect during that phase.

wiak

[fredx181]

Tried booting again, same happened, as I said earlier, it did hang for around 15 minutes at the init stage, and then it continued (and reached the Desktop after I configured the network) , weird isn't it ?

Fred

[wiak]

Tried booting again, same happened, as I said earlier, it did hang for around 15 minutes at the init stage, and then it continued (and reached the Desktop after I configured the network) , weird isn't it ?

Fred

Yes, that is weird (though doesn't happen to me).

@rockedge: Where do you start wifi anyway? I'm afraid I've forgotten all about how runit works (which I presume you use to start it). EDIT: Just noticed, you actually start it via /etc/rc.local

[wiak]

It could be one of these scripts failing (with timeout) in rc.local that causes the hang you experience Fred.

i.e. net_connect (so could be wiakwifi hanging since net_connect simply calls that up), set_time, or start_sound (I see that all these scripts are in /usr/local/bin)

[wiak]

Here is what I get on initial boot, which is successful. You'll need your glasses to see this. The boot ends up reaching wiakwifi running, so at that stage the user has to enter their wifi details after which boot proceeds to desktop. As soon as boot says 'Welcome to Void!' you are definitely past the switch_root so runit has taken over by then.

Perhaps if wifi fails to connect, the attempt to set_time via ntp (which I see is the next script to run in rc.local after wiakwifi) will fail with timeout?

[fredx181]

Hi wiak, the hang point for me is before what your picture shows, I think just after vmlinuz has been loaded, message while hanging is; "Run /init as init process"

Fred

[rockedge]

Hello @fredx181

After "Run /init as init process" is the creating and loading the /upper_changes directory and the /work directory also is created. When this runs successfully the output text is red and /upper_changes merged as the top layer.

This may be where to start debugging. I am going to attempt to re-create the boot failure.
Thanks for testing it out Fred.

[rockedge]

I want to switch over from using scripts listed in /etc/rc.local.conf to using runit to start the services to test it. I just start learning how to use runit starting the Hiawatha web server, mariaDB and Zoneminder at boot.
It looks like using runit would be the correct way to deal with the time outs and stream line the boot process in general.

I found it easier initially when designing the PLUG file that constructs this WeeDog32-Void, to start the network, start retrovol for audio and set the system time with scripts. As it is set up now it would be easy to create more sophisticated scripts to start the services. The idea was simplicity for the sake of a stable PLUG file and quick changes as I was testing and improving.

All the controls are in /usr/local/bin. I think eventually with the scripts optimized and improved to account for start failures. I build the starting firstrib_rootfs then modify and add the tweaks and improvements and then I use the build_weedog_initrd-latest.sh script to build the initrd.gz, firstrib_rootfs.sfs and the vmlinuz.

@fredx181 On some of USB sticks I have used to test, there has been lengthy loading times for the firstrib_rootfs.sfs and occasionally at the same stage of booting that you experienced, where it took more time than it should. All the times I've experienced though are like 45 - 60 maybe 90 seconds. But it's pretty weird that it did eventually boot! It is an interesting problem. I hope to pin point where the actual failure is occurring or find out what is the source of the extremely long time it took to boot your machine. I think we can fix it.
Does it work once it booted?