Development of 32 Bit WeeDog Void Linux Base

[rockedge]

Success!!
I am able to boot from CD-ROM or ISO in VirtualBox a WeeDog32-Void-2.5X-Live.
Boot code stanza for grub with NO persistence

Code: Select all

w_bootfrom=/mnt/sr0 w_changes=RAM

After I booted into the virtual machine I GPartED the VBox drive to /mnt/sda1 as ext4 and added the stanza:

Code: Select all

w_bootfrom=/mnt/sr0 w_changes=/mnt/sda1

This is a hack but it does work and has persistence

Screenshot(1).png (113.25 KiB) Viewed 2826 times

UPDATE : booted from CD-ROM where all changes are done to a RAM drive and are not persistent.
Then booted with w_changes=/mnt/sda1/live which also worked well once there is an /mnt/sda1/live directory to write /upper_changes and /work to. On VirtualBox I used a upupBB32 to format a virtual drive as ext4 and added the directory /live to it.

[wiak]

Success!!
I am able to boot from CD-ROM or ISO in VirtualBox a WeeDog32-Void-2.5X-Live.
Boot code stanza for grub with NO persistence

Code: Select all

w_bootfrom=/mnt/sr0 w_changes=RAM

That's great rockedge. I can't remember how I did it with WDL_Slitaz32 bootable iso I provided for download (used xorriso I think though) - I should look that out, might be similar from recollection. I didn't have virtualbox installed, so I remember I just wrote the iso to a read/write CD disk I had handy (and I have DVD rw drive on my dev laptop.

It's particularly good that you managed to produce a bootable iso since WeeDog Void tends to run very efficiently in RAM so will work very nicely in a virtual machine (even under Msoft windows I imagine).

[rockedge]

I switched to VirtualBox to test the ISO's because I started burning through a small pile of blank DVD's and CDROM's and as one knows, just as I am about to burn the last one I suddenly need to burn a music CD for the wife's Kindergarten class. So while sitting in front of on the DELL's which is running a Bionic64 all set up with the latest VirtualBox 6.1 with brand new built VBox drivers for the real time kernel 5.4.5-rt70 and so far only ran a Bionic32-CE and Windoz XP for proof that it works. I realized with an FTP link from the machine churning out the ISO's to the machine running VBox I could test out the changes almost immediately and not have to burn a disk every time that will end up minutes later in the trash can.

This actually managed to distract me from finishing up the much simpler non-booting ISO of the 32 bit WDL, and also not finishing up the refinements of the 64 bit system and it's Zoneminder add-on.

[rockedge]

I need better grub boot stanza's. Seems my grub syntax is lacking. The boot menu is doing unexpected things.

[wiak]

I need better grub boot stanza's. Seems my grub syntax is lacking. The boot menu is doing unexpected things.

I should have made better notes concerning the iso I made for WDL_Slitaz... I seem to have used isolinux for the bootable iso for that and note from its isolinux.cfg this extract used:

Code: Select all

linux /vmlinuz
initrd /initrd.xz
append w_bootfrom=LABEL=WD_SLITAZ32=/ w_changes=RAM w_copy2ram

Don't know if that info helps for your creation though.

Alas, I don't create isos very often so never remember how I do it.

Clearly I had labelled the iso and used for convenience the alternative LABEL (rather that UUID) method provided by WeeDog initrd/init system:

From output of build_weedog_initrd-latest.sh run (in final report at very end):

Or use w_bootfrom=UUID=xxx-xxx.../dir or w_bootfrom=LABEL=xxx.../dir

That means I first gave the iso a "label" (clearly I gave my iso the label WD_SLITAZ32). Can't remember how to do that, but I think a simple thing to do (google...). It may be easies to just remember to give your iso a label during its construction, which is what I did I'm sure (assuming you can't find a way of doing that later - e.g. via mkisofs utility???).
https://www.unixmen.com/edit-iso-files- ... -in-linux/
https://www.linuxquestions.org/question ... 175611168/

I think @fredx181 uses xorriso regularly, so maybe he can help you with adding a label to already constructed iso?

wiak

[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, ...
This script will generate a slimmed down initrd for WDL by using dracut
...

I do most of my development work from running WDL_Arch64 system. Arch provides a similar tool to mkinitrd/dracut combination called mkinitcpio (written by Arch devs with community additions) - no dracut on the system. I'm primarily using that to cut down module sets (along with depmod to regenerate the modules.dep file and so on). I've looked at underlying dracut code (with view to writing ultra-simple slim-modules script), but overall dracut is pretty complex. mkinitcpio in Arch (configured via /etc/mkinitcpio.conf), fortunately, is relatively straightforward - it uses simple functions (called 'hooks') to include important sets of modules (dracut does similar but not so easy to decypher). For example, Arch mkinitcpio function 'hook' for block devices is simply:

Code: Select all

#!/bin/bash

build() {
    local filter

    map add_module sd_mod? sr_mod? usb_storage? mmc_block? firewire-sbp2? virtio_blk?

    # pata, sata, scsi, nvme
    for filter in 'scsi/.*ata' '/(block|scsi|fusion|nvme)/' 'ata/[ps]ata_' \
            'ata/(ahci|pdc_adma|ata_piix|ata_generic)'; do
        add_checked_modules "$filter"
    done

    # usb
    add_checked_modules -f '(_cs|sl811_hcd|isp116x_hcd)' '/usb/host'
    add_checked_modules '/drivers/usb/storage/'

    # firewire
    add_checked_modules '/drivers/firewire/'

    # mmc
    add_checked_modules '/(mmc|tifm_)'

    # virtio
    add_checked_modules 'virtio'
}

help() {
    cat <<HELPEOF
This hook loads the necessary modules for most block devices using pata, sata,
scsi, firewire, usb, or mmc. Detection will take place at runtime. To minimize
the modules in the image, add the autodetect hook too.
HELPEOF
}

So, by temporarily simply commenting out say the wee code block for "pata, sata, scsi, nvme" I can avoid including them (similarly the line for firewire devices). That's how, (for now) I am creating module set for usb only (or whatever). Of course, I'm just using that 'hack' method on a temporary basis until I produce exactly the pruner I want for WeeDog builds (it is re-inventing a wheel of course, but sometimes that's worth doing when the utility wanted is not needing to be so general purpose - and hence can be extremely simple - anyway such re-invention can increase overall understanding of modules load mechanism).

But yes, I can also do it using Fred's util by first installing dracut on WDL_Arch64 (and that might be simplest for now): can omit modules via /etc/dracut.conf (and /etc/dracut.conf.d/*.conf using omit_dracutmodules or via --omit-drivers; I expect there is a similar simple way to omit modules using mkinitcpio, but I confess I don't know it as yet...; I suspect mkinitcpio doesn't have such fine-grained control as dracut and can only prevent whole 'block' hook being used rather than say 'firewire' part of it... except by commenting out code for firewire and so on, as I currently temporarily do). Also, I'm not sure if mkinitcpio is going to continue to be maintained (a year ago were reports it wasn't, but still installed by default in Arch) so probably overall I should practice more with dracut (and I think Void uses dracut anyway) and conveniently dracut contains a --host-only modules switch, which could prove useful. Nevertheless, I am reluctant to require dracut (for calling during build_weedog_initrd script) and would like something totally simpler, so will eventually look into trying to script that.

In current WDL_Arch64, by the way, the debug initrd shells don't work as yet because I haven't included the keyboard driver modules (doesn't effect the booted system) - I should fix that in the initrd. Doesn't effect WDL_Void since appropriate drivers seem built in.

[rockedge]

Don't know if that info helps for your creation though.

It does!
Using the tool dir2iso in Puppy Linux Bionic64-CE (woof-CE built) it makes it easy to make custom volume ID.

Screenshot(2).png (36.27 KiB) Viewed 2738 times

Screenshot(3).png (47.6 KiB) Viewed 2738 times

The boot-able ISO is an experiment. The main goal is still to produce a basic working WeeDog32 desktop for the hobbyist.
I use Bionice64 in various forms to do the packaging of WeeDog work. All the tools and the final squash produces a much smaller SFS when done in Bionic than if I do it using a WeeDog itself, for some reason.

[fredx181]

I think @fredx181 uses xorriso regularly, so maybe he can help you with adding a label to already constructed iso?

To create hybrid ISO I use:
Depends on ISOLINUX package (anyway on Debian), check if the path to isohdpfx.bin is correct below.

Code: Select all

###(change below variables as preferred)

NEWISO=isodata # let's say the files are in 'isodata' folder.
LABEL=WDL
NAME=WeeDog-Void.iso

cd "$NEWISO"
xorriso -as mkisofs -r -J -joliet-long \
-l -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin \
-partition_offset 16 -V "$LABEL" -b isolinux/isolinux.bin \
-c isolinux/boot.cat -no-emul-boot -boot-load-size 4 \
-boot-info-table -o ../${NAME} ../"$NEWISO"

A while back I started with adding UEFI support to ISO's, using xorriso too (but different), and depends on much more, just tell if you want to know how.

Fred

[rockedge]

Thanks Fred, as I get deeper into it and adding UEFI support which seems like a logical choice as well, I will use the knowledge you have to build a boot ISO that can start on various machines with a strong universal boot stanza in the isolinux.cfg.

[rockedge]

The hybrid ISO I labeled WEEDOG32
Using the following block:

Code: Select all

LABEL linux
MENU LABEL WeeDog32-Void-Live 5.9.14_1 i686 (RAM)
 linux /vmlinuz-5.9.14_1 w_bootfrom=LABEL=WEEDOG32=/ w_changes=RAM copy2ram
 initrd /initrd.gz

LABEL linuxsave
MENU LABEL WeeDog32-Void-Live 5.9.14_1 i686 (save sda1)
 linux /vmlinuz-5.9.14_1 w_bootfrom=LABEL=WEEDOG32=/ w_changes=/mnt/sda1/live copy2ram
 initrd /initrd.gz

the system boots nicely from CD-ROM and ISO. The linuxsave will only work if /mnt/sda1 exists and is ext2/3/4

I am finding out that WeeDog32-Void-2.5X and WeeDog32-Void-2.5X-Live work really well on virtual machines provided by VirtualBox 6.1

Now toying with the idea of quickly running my firstrib00-NoX.plug file with the WDL build scripts which makes a WeeDog32 or 64 bit Void with no X server command line only for a VirtualBox machine. I would try out to build Zoneminder on it and see if I can then connect remotely with SSH and HTTP. Another distraction from the first goal. Though, the versions of WeeDog32-Void and WeeDog32-Void-Live that are now finished are ready to run and are fully capable base foundations for customizing an operating system

[rockedge]

@fredx181 I ran your script mk-initrd on the initrd.gz that was built for WeeDog32-Void-2.8 with complete success!
Reduced from 65 M to 20 M bringing the over all directory and ISO size to <700 M at 684 M

Further refinement of the basic desktop I added wdmount which works nicely to mount partitions. Also added xdgmenumaker to perhaps replace mjwm as the JWM menu generator. At this time both are available and can be selected by swapping the comment statement in /root/.jwmrc

Code: Select all

 <!-- <Include>/root/.jwmrc-mjwm</Include> -->
        <Include>/root/.jwmrc-menus</Include>

xdgmenumaker :

Code: Select all

fixmenu

mjwm:

Code: Select all

buildmenu

[rockedge]

@wiak Here is a WeeDog32-Void-2.8 I have running on an IBM T-42 ThinkPad.
780 M of RAM, Pentium M, no battery, CD drive tray will not slide out and no hard drive. Boots from a 8 G usb stick set up with Grub4Dos.

2021-02-17-233725_500px.png (235.88 KiB) Viewed 2764 times

2021-02-17-234259_500px.png (247.73 KiB) Viewed 2764 times

[wiak]

Impressively frugal RAM used there. Does it run smoothly on such an old system and from USB 2.0?

[rockedge]

It does run at an acceptable pace! Using Firefox 85.01 32 bit to read and post to the forum right now. The browser will hang the system a moment if I have 6 or more tabs open simultaneously with some web pages being really heavy like Facebook or Slack. It froze up but straighten itself out after a few minutes without me intervening at all.

I did some work with mtPaint 3.50 and I installed the base-devel, git and cmake packages and compiled gtkdialog that I got from the Puppy Linux woof-CE repo. Now I am running the newest version of MM_view from MochiMoppel with good results and I am able to use xbps-install -Suy without any errors. So I can build packages with it and using firefox and exploring this Forum is all working in acceptable ranges. Also mikewalsh's portable palemoon is working really well also.

[wiak]

The following was published on Void's 'News' page along time ago, but though I've read that page I didn't really think about it, but realize on re-noticing it that it explains why firstrib void rootfs builds have been known to occasionally fail (but work a few days later...):

Being rolling release and not breaking things involves a lot of coordination. Some of this coordination is baked into the software. For example, you can’t update your system while large rebuilds are in progress because that would install incompatible versions of some libraries (we’re working on improving the user experience around this though).

So I guess before ever building a Void system via built_firstrib_rootfs we should always check no large rebuild is in progress upstream...

Which reminds me, I still haven't double-checked the correctness of my latest build scripts and thus not yet uploaded them. Still sunny weather here, but thereafter that issue will eventually be remedied.

[wiak]

Shouldn't affect us really, but updates/new_builds will be quite a bit different in the sense that:

https://voidlinux.org/news/2021/02/OpenSSL.html

Switching back to OpenSSL
The Void Linux team is switching back to OpenSSL on March 5th, 2021 (2021-03-05).

I didn't notice that "news" post, but noticed openssl being installed during a make Void Linux flavour test of latest build_firstrib_rootfs script today. Then I found the news post above.

Come to think of it, though the build seems to have worked fine, I'd better check I don't need to change to newer xbps-static since that may now be compiled against openssl instead of libressl. I note that (Juan RP) xtraeme's xbps (which can be compiled against either LibreSSL or openSSL) is no longer identical to the xbps used by void (though void maintainers of their copy seem to contribute to xtraeme's xbps gitlab site); in general you have to stick to void's version for void packages so I wonder what is the point of xtraeme's which may diverge in functionality as time goes by?... Oh well, pity, long as void version works, which is does.

Lots of recent praise for upstream Void Linux here (and I have to agree with the sentiments - there is no more resource efficient, fast Linux variant out there):

https://www.reddit.com/r/voidlinux/comm ... _you_void/

[wiak]

I have the new build scripts all working apparently correctly for Ubuntu, Debian, Devuan, and Arch Linux flavours, but for some reason Void build has issues - mainly works but hanging just before login prompt for commandline Void build. Though similar script sections for each there are some major differences so may be my fault, though I'm sure if an upstream issue - some packages changed a lot on upstream Void repos recently (including kernel in two different builds one day apart...).

It's a bit frustrating since I'm keen to get the new scripts settled up at gitlab for more general testing but hesitant till I'm pretty sure they work reasonably well. If I don't find the answer to the issue in the next day or two I'll probably upload into dev section of weedoglinux gitlab site rather than for immediate general use (though I'd rather they go straight to general testing since getting much testing is difficult enough as it is).

Having said that, I couldn't sleep last night - my mind buzzing with a new idea or two I have for inclusion into initrd/init so maybe I'll try these me-dreaming-mods (to see if practical or if I was just dreaming...) to build_weedog_initrd prior to the upload anyway.

[rockedge]

there is no more resource efficient, fast Linux variant out there

Void Linux is the fastest most efficient OS I've come across. I really like using my WeeDog64-Void and WeeDog32-Void. In some forms (because it is easy to build different variants) I use it for running Virtual machines or creating electronic music and editing/producing videos. Performs well as a desktop for "office" and "surfing" work as it does as a development platform.Runs Zoneminder very well.

On the 2005 IBM T-42 ThinkPad Pentium M with forcepae on the kernel line WeeDog32-Void starts right up and hovers around 70-98 M of RAM (790 M max.) and is running a 5 series kernel and the can deal with the latest Firefox 32 bit.........

[wiak]

The problem I have with Void Linux is that I find their repos are not reliable. To be fair I have had trouble building ubuntu or debian distros sometimes when they appear to be updating or mirroring their repos, but usually they are fine. With Void, on the other hand, I often feel something must be wrong with my build script only to find it works fine a day or two later without changes - I'm almost certain it is Void repos not being stable. Same has been happening for me this evening - I was getting constant failure using xbps-install - then suddenly now it is working and the only code I've changed is the repo address. Very frustrating when testing new script...

The other slightly worrying matter remains that of xtraeme (Juan RP) continuing to develop his own version of xbps and warning Void users have to use Void version not Juan's... So what exactly is Juan's version for??? Maybe he will release a new Void distro under new name - XBPS distro or whatever...?

Meanwhile just doing another build - seems to be building smoothly this time (with no further changes to the build script code).

Do you have a reliable f_XXX plugin you could let me test with the new build scripts - then I could confirm if any changes would need to be made. One definite small change is that you will want to xbps-install eudev (and wpa_supplicant if you need it) in the plugin - they used to be installed from the core build_firstrib_rootfs script but I took them out since no always wanted. Hence f_XXX.plug needs to provide them when needed. I've looked at your site for plugin but I don't know if these are old or current especially since more recently you've concentrated on producing actual isos of your Void creations. Hence a reliable Void f_XXX.plug to test with the new build scripts would be very useful at this stage. All beginning to look fine though.

[rockedge]

@wiak
All of the plug files for the Void WeeDog versions work and have been renamed to fit the new format.
They are here -> https://github.com/techrockedge/weedog-ZM

I just ran the 32 bit auto-login and 64 bit auto-login and both work! BUT I have not yet added the xbps-install eudev (and wpa_supplicant if you need it) part yet in any of them. I just found out, but a quick add to the plug and it should work fine. Then after it builds and you've connected to the net run the build_ZM.sh script and see if Zoneminder will build. (at the moment I am using the latest master for ZM so there may be some issues since it's cutting edge.)

I just xbps-install -Suy on the WeeDog32-Void-2.8 running on the T-42 and upgraded smoothly and completed error free. Ever since I ran xbps-remove gtkdialog, then did the system update and after that compiled the Puppy's woof-CE gtkdialog again to get MM_view to work.

Since the new build of gtkdialog I've had no updating issues from the system. This is not yet compensated for in the plug files.

I will run a plug and build a WeeDog64 later today.

[wiak]

I just ran the 32 bit auto-login and 64 bit auto-login and both work! BUT I have not yet added the xbps-install eudev (and wpa_supplicant if you need it) part yet in any of them. I just found out,...

@rockedge Em... you misunderstand me. I have not yet published the latest build scripts at all - I want to ensure they work in my own tests at least prior to pushing them up to gitlab otherwise anyone using them would likely be wasting their time since I am still hacking bits of them...

You are therefore building with the previous (i.e. current published) build scripts, which were known to work and automatically include eudev and wpa_supplicant anyway (it is the as-yet-unpublished new version does not automatically install eudev and wpa_supplicant).

So all I'm needing are plugins to test on the new version (you cannot yourself test it yet). I'll therefore download the plugins from the link you give above and that should let me know if all is well

EDIT: It seems crazy up at Void at the moment. Not surprising since they have just changed from using Libressl to Openssl I suppose, but...: Everyday I have been doing new build and each time I find Void default kernel has changed! They are using 5.10 series - was that not the one that was giving trouble? I remember we had issue with modules not loading if beyond a certain number and eventually I tracked the issue down to the kernel itself rather than the modules list. I should check their git pages to see if any discussion about issues in case they don't know that kernel flaw (but I can't remember details myself now either).

EDIT2: can't work out how they do such changes on their github page. One problem I don't know way round up there is that package lists are cut because so many packages - must be simple way to see all packages but I don't know it... so just get message saying that's all it is showing or too many packages to display (depending what I'm trying to look at). Alas I remain a novice with using Void generally since been working most with WDL_Arch64. I do intend getting back more to Void though since I appreciate its speed, low resource usage, and efficiency generally.

EDIT3: Just did a successful build with your non-auto-login plugin rockedge (old one though), using my current draft new build scripts, and all went fine- posting in latest firefox from it now. I'll do one more build with each of Void, Arch, Debian, Ubuntu, Devuan - I'll probably just test 64bit only at this stage, but if ok I think 32bit will also be fine; if new builds all work without issue I'll then upload new build scripts to weedoglinux gitlab page marked as -latest. A lot of changes, but underlying operation and functionality mainly the same, except eudev and wpa_supplicant for Void have to be in the f_xxx.plug now. Also build_weedog_initrd now allows for use of uncompressed f_00 firmware directory as well as sfs (that f_00 plugin being particularly useful for huge kernel usage such as if using a Puppy kernel/firmware_modules combination). Also new build_firstrib_rootfs contains extra two build types for making very small Void-based WDL systems - one that is only Void filesystem structure that includes busybox but no xbps, and one that is same but includes only static version of xbps. The usual void build option is same as before - ends up with full xbps version and some underlying Void standard system configs. Most of the recent dev work (aside from that) was to get Debian, Ubuntu, and Devuan builds working properly - they had worked in the past, but not quite correct - then builds for these no longer worked because of some upstream core package changes - I've fixed all that so seem to work up to f_xxx.plug stage now, so just a matter of building new f_xxx.plug for these Debian-based systems. As I've said, this year I want to produce a WDL_UbuntuXX64 same desktop look and feel etc as current WDL_Arch64, which I intend to develop later. What I need to get back to soon though is tidying up and publishing of the extra, never-yet-released, build script for the recent WDLGO_Ubuntu systems (the one that as a side-effect-code-addition also produces the dpkg_apt_multiuserPAM addon for recent Pups).

[rockedge]

@wiak I meant to say I ran awhile ago the plug files, around the time I made the ISO's.

Just did a successful build with your non-auto-login plugin

Good to know! Did it boot?

[wiak]

@wiak I meant to say I ran awhile ago the plug files, around the time I made the ISO's.

Just did a successful build with your non-auto-login plugin

Good to know! Did it boot?

Yes, absolutely, that's what I meant! Both build_firstrib_rootfs and then build_weedog_initrd worked fine (using the new versions of these scripts I am currently testing) and the result booted up to the expected rockedge Void JWM desktop (following root/root login and startx), wifi connected, xbps-install further worked, all worked...