Development of 32 Bit WeeDog Void Linux Base

[fredx181]

Hi wiak, yes good to find what's exactly the cause of the boot delay, instead of depending on some possible lucky coincidence.

For what it's worth:
I did some research, by using the same for loop as from Weedog Void initrd (modprobe modules) on DebianDog porteus-boot and found that if ata_piix is not at the end (or near) then booting hangs on that too.
So it seems to me that the order is important.
Other research I did was trying out replacing with other (older) version of busybox in the initrd and had better results (much smaller delay time booting Weedog Void) (but adding ata_piix as the last module was still required), e.g. very old v1.19 from here https://busybox.net/downloads/binaries/1.19.0/ (busybox-i686, is the one I tried).

[wiak]

Hi wiak, yes good to find what's exactly the cause of the boot delay, instead of depending on some possible lucky coincidence.

For what it's worth:
I did some research, by using the same for loop as from Weedog Void initrd (modprobe modules) on DebianDog porteus-boot and found that if ata_piix is not at the end (or near) then booting hangs on that too.
So it seems to me that the order is important.
Other research I did was trying out replacing with other (older) version of busybox in the initrd and had better results (much smaller delay time booting Weedog Void) (but adding ata_piix as the last module was still required), e.g. very old v1.19 from here https://busybox.net/downloads/binaries/1.19.0/ (busybox-i686, is the one I tried).

No it's simply a delay issue Fred.

I discovered the reason last night and via further tests this morning.

The reason the slimmed down modules work on all machines tested so far is that it takes modprobe less time to look through the list loading modules and dependencies. It is nothing to do with ati_piix (EDIT: hmmm... well, there is a bit more to this because still not sure why it would work for you moving ata_piix to end - my view was that ata_piix coincidentally just happened to be far enough along in the module list such that earlier module loads reached the 'critical' delay that triggers the big big delay... but I do have to think more about that). If you put a short delay (even say a sleep 1 second) before any single module being modprobed you will find the big delay then occurs but at the time of whatever module you put the short delay.

Even easier to show its delay to do with the for loop is to simply put something like sleep 4 immediately after the for ... do; i.e. right after the do. Then the big big delay will occur before any actual module starts loading. I also have tried this on WeeDogLinux Arch64 and if I put sleep value at start of the for delay then the big big delay also happens then. Fortunately for me, none of this delay happens on any of my machines normally.

I have not tried on DebianDog similar loop, but you might like to try putting sleep 4 right at beginning of for loop (even sleep 1 probably enough on WeeDog anyway). It's an odd thing that the loading of modules seems to need done within a certain time or that big delay effect occurs - most machines manage to parse and load the modules quick enough (in which case no delay) but your machine and rockedge's thinkpad don't manage in time (unless slimmed down module set being used). In terms of modules themselves affecting this - only one thing maybe - if the for list set includes a non-available module (e.g. aufs in the case of WeeDog) it may be that the error not found failure causes enough delay that the big delay effect gets triggered (I have still to experiment with that - i.e. remove any modules named in the list that do not actually exist on the system). Seems to me that keeping delay short is the answer - no sleeps in the loop!!!

I have no machine that had this delay. The reason I stumbled across delay trigger effect was that I was experimenting with using udev instead of that load module list (so different initrd) - but first tests still had that loop and suddenly I noticed 30 second delay just at time of ati_piix. Further debugging told me it was because that new initrd was using actual kmod rather than busybox modprobe (I switched to busybox modprobe and the delay vanished... kmod was slower loading modules and that delay was enough to trigger the bigger delay - this was using slimmed down modules by the way so I knew that was not the issue). Then I tested my theory by inserting sleep just before an earlier module in the list and sure enough things hung there instead...

In general, the best thing for me to remove the likelihood of the boot delay occurring is to use as small a for loop list as possible and to have no extra coding within the loop, just the line modprobe <module_required>, that minimising loop delay seems to be the solution. Odd still, that the kernel, or as I also suggested, busybox ash, cares about how long the loop takes...

wiak

[rockedge]

I am wondering if going to kernel 5.9.16_1 fixed the delay in my case with the IBM T-42. This machine always has a slight delay at the beginning of a boot cycle, and now the delay with WeeDog32-Void-2.5X (has the 20 M initrd.gz) is like 20 minutes shorter. Now from on/start to desktop is just under 3 minutes. That's good for this machine. My case is different than Fred's, seems though that the kernel update fixed it.

I am using a 76 M initrd.gz in the WeeDog64-Void-1.1 I will upload. Similar to WDL32-Void in structure and basic function. I added the script /root/Build/build_ZM.sh which I tested and installation of ZoneMinder was completely successful.

I am not worried about the size of the ISO's. They are a decent overall size and the 32 bit initrd.gz at 65 M and the 64 bit version at 76 M, are the ones I am using because they work well.

[wiak]

I've just tried same in BionicDog64 I have on my system. Put a sleep 4 in the for loop, but DID NOT create the big delay (keeping modules list in for loop same as standard BionicDog64 list). So, from Fred's test, that does suggest module order could be culprit (my goodness that's a tricky one to resolve). Funnily enough, the early list I used came from one of the DebianDog's on my machine - maybe Porteus had this delay issue occasionally in the past too(?)

Certainly, one way to get rid of the issue in practice is to simply avoid delays in that loop (including slimmed down modules introduce less delay as it turns out does use of busybox modprobe rather than actual kmod...). But if the cause of the delay is ultimately module order related, it will also be best to try and sort that out. Some more tests required. I've moved my testing to BionicDog64 to see if I can cause the big delay via module ordering in the list.

In practice simply slimming modules has 'fixed' the issue in practice for all machines tested so will do for now, but really not the ideal fix yet...

Christmas now here, so I'll have to come back to this later if no one else sorts it out meantime.

[rockedge]

At the moment all of the test machines are booting in a totally acceptable range of time.
This screenshot is a preview of the WeeDog64-Void-1.1 running Zoneminder I am uploading and will create a topic about.

zoneminder64_600x468.png (175.35 KiB) Viewed 2894 times

[wiak]

This screenshot is a preview of the WeeDog64-Void-1.1 running Zoneminder I am uploading and will create topic about.

zoneminder64_600x468.png

This great! I'm excited about this one! An installation of your zoneminder WDL Void will be my christmas present to myself rockedge!

[wiak]

Unless I find another reason to test this again, after some exhaustive (exhausting) tests I have reached the conclusion that it is a kernel issue.

Keep in mind that none of my own hardware had any significant boot delay in default build. However, I can force my HP Elitebook 2530p (64bit Intel core2 duo processor) to get that boot delay. The way I can do that is to simply add a small sleep right before the for loop that loads the modules (I normally use sleep 4, less might work, but that was sufficient anyway to create the much much longer than 4sec delay immediately thereafter (and prior to the actual modules loading as it happens). And just in case I also tested, at different time, with a small sleep immediately after the do... (right before modules loaded). For either case, my WeeDog32_Void exhibited large boot delay when using recent 32bit kernel 5.9.14_1.

My next step was to use mount_chroot script to also install 32bit kernel 4.4.247_1, which is the one I think would be best used in WDL32_Void for the most part since prime use for old computers, I'd say. So I ended up with modules in /usr/lib/modules for both these kernels (both in the initrd and also in the 01firstrib_rootfs of course. I was then able to boot using either set of modules simply be using the appropriately matched vmlinuz (via the grub4dos menu.lst). And the result was that the 4.4.247_1 kernel gave no boot delay (aside from that forced 4 seconds) but, as I said above, the 5.9.14_1 consistently without fail gave the large boot delay (and did so even if just the sleep 4 used before the for loop).

I therefore feel satisfied to say that the kernel is the issue. We have managed to work round that by minimising accumulating module load delay via slimming down the modules list. That's fine for most machines clearly and nothing further really needs done. Better though, will be that 4 series kernel.

Note well that I also discovered that this issue also effects the recent Arch Linux kernels... I expect such kernels will always boot without delay on newer faster computers but we may run into such issues again if trying to use such new kernel on older machines. The slightly older 5 series kernel employed in FossaDog64 didn't seem to suffer the issue (I put that plus its modules in my WDL_Arch64 as a test, and also had that hybrid WDL_FossaDog64 that I quickly tested - whether Ubuntu compiles them differently and thus fix the issue I have no idea, but I expect just that they are not so recent versions as those used in Arch and Void).

Back to Christmas. I consider the matter 'understood and closed' unless because an issue again later.

EDIT: On second thoughts, I'd recommend using the available Void 4.19 kernel - I have some recollection there was some improvement to overlayfs support in there.

[wiak]

Repeated in case you missed it rockedge:

EDIT: On second thoughts, I'd recommend using the available Void 4.19 kernel - I have some recollection there was some improvement to overlayfs support in there.

EDIT2: I just quickly also tried vmlinuz-5.4.83_1 and vmlinuz-4.19.163_1 kernel/modules and actually both of these worked without the boot delay on my system. You may therefore have a choice: for 4 series I recommend the 4.19, if you want to use 5 series clearly that 5.4 one is what to go for rather than that current flaky 5.9 version. (Of course, it is possible there still is an older machine "delay issue" with all 5 series kernels, but much worse at least in 5.9 than if also in 5.4 at all it seems...)

For different distro, my WDL_Arch64 uses kernel 5.7 but it is also flaky if I put in these sleeps, so for older machines I might be better downgrading it. Can't remember now what Fred's current FossaDog64 uses, but I didn't have the problem with that in earlier (albeit not so thorough) test (ah, I read onlne that it uses kernel 5.4 so that could be why it was okay for me).

Whatever you use, rockedge, you might be best to try with unslimmed modules on that Thinkpad first since that is known to result in the big boot delay with current kernel.
-----------------------------------

Note that I did not change the order of any modules in the list (that proved irrelevant to me assuming kernel used not 5.9). I believe the reason moving ata_piix to end of load module list helped in marginal case is (as I noted during its load) that it takes slightly longer than most other modules to load - sticking that as last module would thus prevent the 'freeze' if the critical delay was just reached by that one being loaded (since no more modules needed to be loaded thereafter). But with the earlier kernels, moving it proved unnecessary even with the big 4 second delay I was forcing using a sleep. Removing any other module from loading would also reduce overall loop delay and hence help avoid reaching the critical delay that triggers the big boot delay. Why ctrl key had any effect I have no idea, but keyboard interrupts can result in odd kernel scheduler spreading/timing effects so not so black magical really. Anyway, I'm just conjecturing, but certainly have confirmed on my own machine at least that there are no such issues with earlier available Void Linux kernels. It wasn't a 'loop' delay anyway (so I shouldn't call it that really) - just a delay (e.g. I used the short 'sleep' immediately before the loop to force the overall big boot delay. It is certainly a weird bug but nothing we can do about it - I suppose it will never cause issue in more modern computers because they will do everything faster (low delay) anyway, so maybe newer kernels will not boot easily in future with older machines (seems like a kernel design/bug to me though - as if the scheduler goes off to do something else and takes ages to return).

[fredx181]

Thanks, wiak, interesting discoveries. I will experiment in the next days with different kernels and see what happens when adding sleep 4 in front of the for loop.

Funnily enough, the early list I used came from one of the DebianDog's on my machine - maybe Porteus had this delay issue occasionally in the past too(?)

Yes, maybe was from Jessie, or Stretch, not sure, I never experience a boot delay in the past (but that was with much older kernel).

Merry Christmas !

Fred

[wiak]

Merry Christmas Fred! and to you too Erik!

[rockedge]

Merry Christmas!

I agree that it is most likely a kernel problem causing the delay. I will look into producing a WDL32-Void with a 4.19 kernel.

UPDATE: I modified the PLUG file to use kernel 4.19 which is now being built as a WeeDog32-Void-2.6. There will be some modifications to the firstrib_rootfs that need to be done to keep in line with WDL32-Void-2.5X and some testing before it becomes available for download.

[rockedge]

Running and posting from WeeDog32-Void-2.6 equipped with the kernel 4.19.163 SMP PREMPT.
Size of the ISO is 613 M. The machine is an IBM T-42 Pentium M

2020-12-25-202926_1024x768_scrot.png (54.52 KiB) Viewed 3463 times

[wiak]

Running and posting from WeeDog32-Void-2.6 equipped with the kernel 4.19.163 SMP PREMPT.
Size of the ISO is 613 M

Will download and try once available online.

[rockedge]

maybe a WDL32-Void-2.6X using the 20 M initrd.gz.......

[wiak]

maybe a WDL32-Void-2.6X using the 20 M initrd.gz.......

I don't see 2.6X online; do you mean simply 2.6 (it is 613MB)?

[fredx181]

From several tests I did on DebianDog (porteus-boot) with different kernels, I can confirm that there should be a problem with kernel 5.9.
As wiak suggested, I've put a "sleep 4" in front of the "for loop" and Debiandog Sid with kernel 5.9.0-3 didn't boot at all for me, got stuck on "loading kernel modules", also after waiting forever.
It's like any small delay is being multiplied (or whatever ).
(same as I found earlier, holding the CTRL key breaks the delay. Btw, holding any key works also for me, e.g. hhhhhhhhhhhhhhhhhhhhhhhhhhhhh)
EDIT: For completeness I should mention that without the "sleep 4", k-5.9.0-3 boots without delay, but again, only when ata_piix is near the end of the for loop)

Tried the same with k-4.19 (Busterdog), k-5.4 (Fossadog) and there was no delay (except for the 4 sec sleep)
Also the order in the for loop didn't matter for above kernels (e.g. ata_pixx at the end or at the beginning of the loop)

Some good news for Christmas! :
Did the same tests with kernel 5.10 (from Debian Experimental) and got no delay.
So it seems that what was "wrong" with k5.9, got fixed in 5.10.

Fred

[wiak]

@fredx181Thanks for the confirmation.

Not sure if I should laugh or cry since it was a lot of work determining the fault as being connected to delay-effects during running of initrd/init by dodgy kernel (which the sleep <4 or whatever> evidenced even on machines that otherwise seemed to boot fine). However, good to hear fixed in kernel 2.10 and that my results proved valid. I'm particularly happy it wasn't modules/module-ordering, which initially it looked like it might be.

I'm currently experimenting (but with WDL_Arch64) with even smaller modules lists, just for fun really, to see how small I can make the initrd for my laptop only - seems likely I can make an initrd around one or two MB for dedicated machine use. That's about same size of Puppy initrd, which has all the drivers built into its rather large kernel.

The init doing all the overlayfs stuff in WeeDog is actually much smaller than Puppy init that does the aufs stuff though. So one interesting thing about Puppy having all boot drivers built into the kernel itself is that an even tinier than Puppy initrd can be built to boot a WDL_Pup_rootfs (such as WDL_FossaPup64) since no /usr/lib/modules required in the WeeDog initrd for that build case. Having said that, for a dedicated machine only a few modules are required in a tiny initrd anyway...

[rockedge]

here is the link to WeeDog32-Void-2.6:
WeeDog32-Void-2.6 (k 4.19.163)

@wiak Yes it is 613 M

On some of the desktops and laptops I've tested on, only the T-42 shows the delay. The T-42 does boot version 2.6 slightly quicker than 2.5X (with the 20 M initrd.gz). In the end all of my machines I tested on will boot WeeDog32, and I will make a WeeDog32 later on with the 5.10.XX series.

The 4.19.163 kernel WeeDog32 is working well never the less. I thought about a version 2.6X (X meaning the smaller initrd.gz) that would use the 4.19 kernel and the smaller initrd.gz Fred came up with.

[rockedge]

Closer to a true release candidate are these versions:

WeeDog32-Void-2.4
kernel 5.9.14_1
initrd.gz is 65 M

WeeDog32-Void-2.4X
kernel 5.9.14_1
initrd.gz is 20 M

WeeDog32-Void-2.5X
kernel 5.9.16_1
initrd.gz is 20 M

WeeDog32-Void-2.6
kernel 4.19.163_1
initrd.gz 53 M

All four OS's are basically the same in design other than the kernel and or the initrd.gz size.

http://rockedge.org/kernels/data/iso

http://rockedge.org/kernels

[wiak]

EDIT: Sorry, I should point out that the following was for WeeDog Arch64, but likely similar for WDL_Void.

As a matter of interest, the machine I do dev work on (HP Elitebook 2530p) only needed the following modules booted (actually I could reduce that list further since I'm not using firewire to boot). My resultant initrd.gz for that is only 1.6MB. It could be made considerably smaller still if I used xz compression, for example. However, using that tiny modules list makes no difference in running practice (RAM used the same) since all modules actually required by my system are re-modprobed by udev system after the switch_root and the initramfs RAM is released.

Code: Select all

kernel/uhci-hcd.ko:
kernel/ehci-pci.ko: kernel/ehci-hcd.ko
kernel/overlay.ko:
kernel/ata_piix.ko:
kernel/ata_generic.ko:
kernel/crc32c-intel.ko:
kernel/ehci-hcd.ko:
kernel/loop.ko:
kernel/crc16.ko:
kernel/crc-itu-t.ko:
kernel/mmc_block.ko: kernel/mmc_core.ko
kernel/virtio_blk.ko:
kernel/pata_acpi.ko:
kernel/firewire-ohci.ko: kernel/firewire-core.ko kernel/crc-itu-t.ko
kernel/mbcache.ko:
kernel/ext4.ko: kernel/crc16.ko kernel/mbcache.ko kernel/jbd2.ko
kernel/jbd2.ko:
kernel/sdhci.ko: kernel/mmc_core.ko
kernel/sdhci-pci.ko: kernel/cqhci.ko kernel/sdhci.ko kernel/mmc_core.ko
kernel/sr_mod.ko: kernel/cdrom.ko
kernel/squashfs.ko:
kernel/firewire-sbp2.ko: kernel/firewire-core.ko kernel/crc-itu-t.ko
kernel/firewire-core.ko: kernel/crc-itu-t.ko
kernel/cqhci.ko: kernel/mmc_core.ko
kernel/usb-storage.ko:
kernel/mmc_core.ko:
kernel/cdrom.ko:
kernel/crc32c_generic.ko:

[wiak]

Again, the following is for WDL_Arch64 since that's what I'm currently experimenting on:

I boot WDL_Arch64 from SSD hard drive installation, so here is the minimum modules I found I needed to successfully boot (so no usb and so on). Somebody may find this informative useful. Note, however, that your system is likely to have slightly different hardware even for similar HD install - not sure by what, maybe pata_acpi (I have no idea of course - you need to use lsmod and check your system hard drive module needs, or use mkinitXXX script to work most of it out for you automatically). Size of the resultant initrd.gz (normal gz compression was 1.2MiB only. For xv --extreme compression, initrd.xz just 945 KiB. And that with Arch Linux kernel 5.7.2-arch1-1, which has vmlinuz-linux size of 7.1MiB, so this is an extremely small bootable system (assuming I used a tiny root filesystem with it). Same sort of result could be obtained with WDL_Void; for example 32bit Void Linux vmlinuz 4.19 is only 4.1 MiB in size and again you should be able to trim modules for an individual machine to around 1 MiB only... And could make tiny Void-based firstrib_rootfs.

For example:

just with busybox and Void's static package manager xbps included, the whole frugal installed distro could be as small as (approx):

busybox static: 1 MiB
xbps static: 44 MiB
initrd.gz: 1 MiB
vmlinuz: 4 MiB
TOTAL: 50 MiB

EDIT: ACTUALLY, the result would be much smaller than that unless you chose to use the WeeDog facility of uncompressed 01firstrib_rootfs. Instead if you are using 01firstrib_rootfs.sfs the above 50 MiB size will be compressed to whatever mksquashfs compression manages... (i.e. very small distro download possible). I guess I should make it a priority to produce an iso for that mini-WDL_Void or maybe rockedge will do that easily enough since he has lots of recent experience with WDL_Void creation. Note that upper_changes and all other WeeDog initrd overlayfs (sfs support) will all work with that mini-WDL_Void system too). (However... if you include Void modules and firmware in a main rootfs, sorry, suddenly pretty big - so idea would be to simply use the initrd (i.e. no switch_root) or... I'd have to think about suitable root_fs to use with it that avoids bloat... such as bind mounting usr/lib/modules across - possibility might be already in the initrd/init - I can't remember). One quick solution would be to use the likes of a huge kernel here (with drivers built in). Truth is though, times have changed and I'm not crazy interested in slimming things down beyond a certain point nowadays since other priorities much more important.

and be fully compatible with Void repos via its official Void xbps package manager! And not much bigger (probably around 10 MiB for initrd if using xz compression) if you use generic machine slimmed module set for initrd. Most of the size in that mini-build would thus be xbps static, but the value of having such a powerful official package manager is probably obvious - easy to build full desktop systems, such as rockedge is doing or can be much the same as the openbox/tint2 WDL_Arch64, for example - and all scriptable via the relatively simple WeeDogLinux firstrib_plugin build script system - main job is to decide whether to use simple busybox init (with inittab and so on) or something else, and make very simply and bare firstrib_rootfs to contain that arrangement and then use build_weedog_initrd on that to complete the build for the iso. Come to think of it, there is already an rc.sysinit created by build_weedog_initrd for use with busybox init/inittab SysVinit possibility, drops to a simple ctty hack shell - just a simple one made during early build firstrib_rootfs/weedog_initrd developments, but that one needs eudev+dependencies so that increases size considerably (long time since I looked at it, since always used runit with WDL_Void flavour, so prob needs some mods to build_firstrib_rootfs to build this simplest WDL_Void). Will later work on simple one that doesn't need eudev...

Code: Select all

ata_generic.ko
ata_piix.ko
crc16.ko
crc32c_generic.ko
ext4.ko
jbd2.ko
loop.ko
mbcache.ko
overlay.ko
pata_acpi.ko
squashfs.ko

[wiak]

For that 4.19 (ver 2.6), the easiest way to slim down the modules (in the firstrib_rootfs) before building the weedog initrd (slimmed version) is to use Void utility mkinitrd as Fred described (you simply need to change the version number below from the 5.9.14_1 version to the exact version for the kernel 4.29.xxx and then copy the resultant modules into the initrd.gz (after uncompressing it with say ./modify_initrd_gz.sh initrd.gz). Note that you of course have to do this within your already booted WDL_Void32 that used 4.19 kernel (i.e. your version 2.6 build).

in WeeDog32-Void-2.4 the "mkinitrd" tool and did:

Code: Select all

mkinitrd /boot/initramfs-5.9.14_1.img 5.9.14_1  # create initramfs-5.9.14_1.img from kernel 5.9.14_1
mkdir /boot/newinitrd; cd /boot/newinitrd
(cpio -id; zcat | cpio -id) < /boot/initramfs-5.9.14_1.img  # extract initrd

The extracted initrd will contain (Fred's stuff above) will contain its own usr/lib/modules and that's the one you substitute into WeeDog initrd

EDIT: Ah... maybe you don't have mkinitrd in that 2.6 build (but I thought it was in earlier build - I must be missing something in my haste...).

[wiak]

Posting from 4.19 kernel version WDL_Void32 (2.6) right now. Going to borrow its kernel/modules to see if my planned small Void will run with it... not sure if that will work (the 'modified' rc.sysinit I'm 'borrowing' from build_weedog_initrd... well, I'm not installing eudev so will have to rely on normal modules loading... if not work, I'll give up fast cos a movie coming on...)

[wiak]

I must be on form today because my quick hack building of the above described WDL_miniVoid32 boot to commandline system went smoothly. Basically, I just used modified build_firstrib_rootfs-latest.sh script to build simplified firstrib_rootfs. I then copied the slimmed down modules set for Void kernel 4.19 into that along with putting the Void 4.19 kernel into /boot. Then I ran build_weedog_initrd-latest.sh with that in the same directory (I may have tweaked build_weedog_initrd slightly - I already can't remember... Anyway, that churned out the appropriate initrd.gz and compressed the firstrib_rootfs into 01firstrib_rootfs.sfs for me and since I didn't install Void base or eudev or wpa_supplicant (had removed that from build_firstrib_rootfs code) the build_weedog_initrd script automatically copied (using internal cat) the inittab and rc.sysinit provided there into the firstrib_rootfs. Much to my surprise that old rc.sysvinit code worked fine first boot (since eudev wasn't installed it simply didn't use it so didn't need to hack that at all...)! and I found myself in tiny WeeDog void system at command line. 'free' command reported 27MB RAM used and top of course saying CPU idle at 100%. As for the size of the initrd.gz and the 01firstrib_rootfs.sfs - turned out much like I predicted (see attachment of its build directory). xbps is provided by it, as is busybox (per design I described) - I think it would connect via ethernet since has the appropriate udhcpc scripts (EDIT: it does and can use '/usr/bin/wiakwifi reset' to do that), but not via wifi since I didn't include wpa_supplicant+dependencies for this one since these would have bloated it a bit from current tiny size. Might develop this further and make tiny iso of it later.

So total size of this ultra-quickly hacked version is approx: 57 MiB (no X of course!, but that could be added later via the inbuilt full Void compatible xbps package manager obviously...). Slitaz (and/or WDL_Slitaz) gives nice X desktop in similar size of course, but that doesn't have a package manager of xbps capability or the repos to match the likes of those Void xbps-access provides, so using xbps is a price worth paying in the end IMO, even for the simplest of X desktop additions (but can be installed up to full desktop Void via xbps-install of course...)

Note that I could make it smaller since the slimmed modules set is currently duplicated in both the initrd and also in the firstrib_rootfs... The slimmed module set is the one that should allow it to boot on pretty much most systems (around 20MB worth of modules).

That initrd could be made considerable smaller if compressed with xz (like Fred does in DebianDogs) - maybe 10MB or less in size in this case.

EDIT: Played a bit further with this, and yes it works, though highly rough around the edges. No /etc/passwd file, no PATH set, but xbps works. First thing you'd tend to do is try and build it into something like rockedge's JWM WDL_Void32 anyway(!), except useful if you really want to start from simplest xbps scratch to build say a commandline distro. It's not the smallest WeeDogLinux Void that could be easily built (aside from trimming the modules back for specific machine) - the smallest would be to leave out xbps altogether and boot with no package manager included at all (so that would come in at basically the size of the initrd plus 1 MiB for static busybox... basically could be a 2 MiB distro if modules chosen only for booting a particular machine...). Then could assemble a distro simply by including the apps you wanted (or via sfs files in overlay) - that could be interesting too... Alternatively 'if' (which I personally doubt) you could get sc0ttman's 'Pkg' to work independently (and with only busybox) then you could use Puppy repos as an alternative to those of Void Linux. And any WDL initrd-based distro always brings WeeDog initrd frugal install facilities (upper_changes rollback, sfs loading on boot, and so on). Could be a distro that gets expanded only via sfs addons (without needing any package manager at all)...

I'll leave any further development of this bare-bones xbps WeeDog_Void till later though since it would just be a pretty rough distraction from rockedge's far more useful JWM WDL_Void32 release.

wiak

[rockedge]

@wiak Wow! Extremely interesting work being done. Excellent stuff.

I have ready to build for experimentation, a version of WeeDog that is a simple, with No X server, command line, that can compile and also support a Hiawatha, mariaDB, PHP 7.4, ZoneMinder (LHMP) web server.

I already have a PLUG file to build the WeeDogXX-Void-NOX, so with some tweaking and deciding on the extent of the developer's tools that are pre-installed. Once completed just run the zoneminder install script and it should be ready. It can without zoneminder be a fully functional command line operating system with the xbps package manager also fully functional.

I think development of WeeDog in a variety of forms can be beneficial overall

[wiak]

Yes, I'll release some new stuff later (whilst I still have them) but just now I think it is best to keep focus on you WeeDog_Void32 release developments.

Eventually, I'll publish even the "for my own machine modules cut down no xbps version" (which should come in at around 2MiB but be pretty much useless for doing anything - except it should connect to internet via ethernet... so I suppose that is not really useless afterall - except won't boot unless you have the appropriate modules or can amend them to match your own system module needs... anyway, 2MiB will be a quick/easy download and certainly the wee-est of dogs). If you have any trouble getting the 'slimmed modules' for 4.19 kernel using mkinitrd (per Fred's earlier use) let me know and I'll post a copy (will work assuming Void keep to the same 4.19 version).

Other thing is I will be releasing the new build_weedog_initrd script (to include recent init ver 2.0.9). Furthermore, I've noticed slight error in build_firstrib_rootfs-latest.sh: wiakwifi wget download line isn't correct.

One other, possibly important thing I had forgotten about. After putting my command line busybox+xbps(static) on internet yesterday, I couldn't get xbps to find the repos (the program xbps itself was running okay, but couldn't do anything online for some reason). Per usual, I suspected certificates error... but couldn't understand it since the build script chroot had already successfully found and installed xbps_triggers package with no certificates-related error. Then checking build_firstrib_rootfs-latest.sh script I noticed in the void functions, that prior to running the static version of xbps, I used/needed the line:

Code: Select all

export XBPS_ARCH=x86_64

or

export XBPS_ARCH=i686

depending whether using 64 or 32bit versions. This export appears not needed for the non-static normal version of xbps package that usually gets installed later. That need also came relatively recently - earlier static xbps didn't need it so earlier build_firstrib_rootfs scripts don't have it (so will fail to build...). Always use the latest build scripts...

Sure enough, as soon as I export that variable from my commandline only busybox+xbps creation, xbps was able to find its repos. I mention this just in case some of the Void build failures you had recently were a result of that line missing. Static xbps now requires that to function, but didn't used to, so possibly most versions of build_firstrib_rootfs prior to the latest one didn't have that so builds made with them won't work now - that's another reason it is vital to always build using the latest scripts since some changes made were necessary to keep working with upstream repos. Nothing you need to do just now though (as long as you build using latest versions of the scripts that code line is already in there, and you builds will work fine (they end up with normal xbps so static version not used in actual build). I ran into the issue because that tiny creation keeps using static xbps so always needs that XBPS_ARCH variable set in the actual build or xbps tries to use inappropriate musl repo instead.

Anyway, aside from newest build_weedog_initrd-latest.sh (2.0.9) soon, I'm not planning any immediate distro releases at the moment. Later though I think it could be beneficial to some if I release these very latest ultra-small creations I've experimented with and also an iso version of WDL_FossaPup64 and WDL_BionicPup32 since they provide an alternative way (the WeeDog way) of running the underlying root filesystem via overlayfs support.

wiak

EDIT: Good to hear you have a commandline version especially crafted so works with headless Zoneminder - that is what is really required - the small and tiny ones I've been recently making are nice for understanding/experimenting but really need a lot of work on them for any purposeful use.

[fredx181]

Here's a simple script "mk-initrd" attached (not to confuse with possibly existing mkinitrd in /usr/bin) to easily create a slimmed down initrd.gz, usage:

Code: Select all

# ./mk-initrd --help
This script will generate a slimmed down initrd for WDL by using dracut
Usage:
mk-initrd </path/to/initrd-decompressed> or: 
mk-initrd </path/to/initrd-decompressed> <kernel-version> 
<kernel-version> can be any kernel name found in /lib/modules
If <kernel-verion> not provided, the kernel that you booted with will be used: 5.9.14_1

Depends on "dracut" installed.
It will create a date-stamped initrd.gz in the parent dir of </path/to/initrd-decompressed>
No initrd.img will be created in /boot, a directory dracut.* in /var/tmp/ will be created, from there the contents of lib/modules will be copied to </path/to/initrd-decompressed>
Note that it will replace the contents of lib/modules in </path/to/initrd-decompressed>
EDIT: the dracut option -N is used in the script, which means "no-host-only" simply change that to -H ("host-only") to create a much smaller initrd.gz, for use only on your own computer (must say that I didn't test booting with that).
EDIT2: at the end the script will remove the directory dracut.* in /var/tmp/, if you want to keep it, comment out this line:

Code: Select all

rm -rf /var/tmp/dracut.*  # not needed anymore, so remove

Fred

mk-initrd.gz

Remove fake .gz and make executable

(1.72 KiB) Downloaded 146 times

[wiak]

Here's a simple script "mk-initrd" attached (not to confuse with possibly existing mkinitrd in /usr/bin) to easily create a slimmed down initrd.gz,

Thanks Fred, will prove very handy.

[rockedge]

I realized there is no logging set up in these WeeDog builds. So I added the installation of socklog-void to the PLUG file and can add it to the existing WeeDog32-Void versions. Question is should it be part of the WDL32-Void as default or should I leave it out and let the user decide and install a logging system?

To install a logging system open a terminal:

Code: Select all

xbps-install -Sy socklog-void

now to enable logging activate the corresponding services with runit, in a terminal:

Code: Select all

ln -s /etc/sv/socklog-unix /var/service/
ln -s /etc/sv/nanoklogd /var/service/

To access logs without root privileges, add your user to the socklog group

Code: Select all

usermod -aG socklog <your username>

The logs are saved in sub-directories of /var/log/socklog/, and svlogtail can be used to help access them conveniently.

The ability to read logs is limited to root and users who are part of the socklog group.

[rockedge]

I manged to create a boot-able WeeDog32-Void ISO that is one step away from working. Borrowing the grub and boot files from a Void Linux Live ISO and load them all together in a single directory.
I burned the ISO image to DVD which worked up to creating and layering /upper_changes and /work directories. There it fails and causes a kernel panic.
I am now experimenting booting a WDL32-Live using VirtualBox running on a Puppy Bionic64-8.0.

I do not have the correct grub boot stanza to deal with /upper_changes. The next test is a run in a virtual machine that I already ran upupBB32 on, and with GPartED created a ext4 partition on the virtual hard drive as sda1. So I will see if I can get the CD-ROM (DVD) WDL32-Void-Live to boot to desktop if /upper_changes can be created and written to.