Development of 32 Bit WeeDog Void Linux Base

[fredx181]

Yes, that's odd. If pata_cs5535 isn't in modules.dep that suggests it isn't available as one of the modules anyway, so modprobing it should do nothing anyway! So can't see why removing it from modules list should have any effect (except for the slight delay caused by attempting to modprobe a non-existent module failing I suppose). Oh well.

Yes, I agree, seems not logical to me too, so I checked again with and without pata_cs5535 in the list (and ata_piix last) and without it there's no boot delay.

Fred

[wiak]

I'm adding capability in the next revision of build_weedog_initrd.../init script to remove or add multiple modules to the modules list in the initrd.

In the meantime, I've already created the new initrd/init for that purpose.

Could you kindly test that by substituting this new init into the original WeeDog32 Void initrd.gz. i.e. with the original modules list.

I've attached the new init for inclusion in the initrd.gz (just remove the dummy tar) and make sure it is executable in the reassembled initrd.gz

Then, @fredx181, if you add the following to your grub menu.lst kernel line:

w_rmmodule="ata_piix pata_cs5535" w_addmodule="ata_piix"
Note the quotes round the module lists and the w_ at the front as usual.

then pata_cs5535 should be auto-removed and ata_piix re-added as the last loaded module automatically.

Note that with this new init w_rmmodule can contain a list of as many modules as you like, and similarly for w_addmodule.

You can also still of course add w_debug=0 if you want to roughly see what is going on, though most stuff whizzes past too quick to see, but you would then see message saying ata_piix being re-added back in.

I've also included a copy of the script I use for modifying the initrd.gz (just remove the dummy tar) though I realise you have no problem with your own ways of doing that.

Hope all goes well and that I've not made a last minute blunder with the new code (worked in tests for me, but I don't have any system that has the delay issue to test upon).

In theory, with this new w_addmodule mechanism I could actually put the whole module list on the grub kernel line probably(!), but that's not my intention. Should be more useful for special difficult to boot machines though.

EDIT2: By the way, you can of course remove module aufs as well. That's a legacy from when I first started weedog - I was planning to use aufs, like so many, but opted for overlayfs and have forgotten to remove aufs from the list ever since (note to myself - remove it...). In practice, since everything I've build uses stock kernels, no aufs module is included in practice anyway.

wiak

[rockedge]

WeeDog32-Void-2.4

@wiak I commented out the network set up and setting the time. These can be set after boot.
There are older kernels for Void that I will build some WeeDog32's with. I thought the same thing as I built this version which now has kernel 5.9.14_1 and Firefox 84.0. But changing kernels will come at a later time. Once this is more user friendly.

After first boot populate the menus. In a terminal:

Code: Select all

buildmenu

Then click on /usr/share/applications/update-entries.desktop

To connect to a network after boot, open a terminal :

Code: Select all

wiakwifi

Set time by modifying /etc/rc.conf. Remove the comment and add the desired timezone.

[wiak]

Hi rockedge,

It would probably be good if you put a link to the latest iso download in first post of this thread too, since some folks who might be interested only check here on Puppy Linux Forum I think.

To connect to a network after boot, open a terminal :

Code: Select all

wiakwifi

Set time by modifying /etc/rc.conf. Remove the comment and add the desired timezone.

If you make a mistake with your wiakwifi config, you can just press Ctrl-C to exit, and then in terminal start all over with:

Code: Select all

wiakwifi reset

If you somehow lose connection, but have previously configured wiakwifi stored settings, you can open terminal and reconnect using command (often works, but not always...):

Code: Select all

wiakwifi reconnect

wiakwifi is a simple connection tool and really just for wpa/wpa2 connections (not wep and so on). Very rarely nowadays, on some older devices particularly, the default wpa driver employed doesn't work. The remedy is to manually remove a couple of comments in the script wiakwifi itself, which activates the alternative driver called 'wext'. i.e. in rockedge's WeeDog32_Void, wiakwifi is stored at /usr/local/bin (which wiakwifi at terminal reveals that location). So to change default wpa driver:

Code: Select all

geany /usr/local/bin/wiakwifi

and uncomment the following two lines in the script and try to thereafter reset or reconnect wiakwifi:

Code: Select all

# wifi_driver="wext"
# wpa_driver="-D${wifi_driver}"  # uncomment if specific required

But, yeah, usually you won't need to modify wiakwifi script at all - for most people it will just work as is.

Note that in WDL_Arch64 I actually put wiakwifi in /usr/bin rather than in /usr/local/bin on the grounds that it is a core part of that system, but the best location is arguable since wiakwifi is certainly not an official package from Arch repos either.

If you do have more complex connection needs, you would need to install some more sophisticated Internet connection manager program. I may take a look at getting PeasyWifi to work since it hadn't more use-cases. I'm unlikely to cater for extra wifi protocol types in wiakwifi itself since it is only intended as a simplest scenario network manager (which nevertheless works fine for most common simple wlan network situations).

[rockedge]

Ready for download and testing:
Kernel 32 bit 5.9.14_1
Firefox 84.0

WeeDog32-Void-2.4

https://rockedge.org/kernels/

[wiak]

Ready for download and testing:
Kernel 32 bit 5.9.14_1
Firefox 84.0

WeeDog32-Void-2.4

https://rockedge.org/kernels/

Yes, booted fine for me using:

Code: Select all

title WeeDog32-Void (initrd.gz)
  uuid () afa4effa-e396-4872-b2d8-9648bf8e0a1b
  kernel /WeeDog32-Void/vmlinuz-5.9.14_1 w_bootfrom=UUID=afa4effa-e396-4872-b2d8-9648bf8e0a1b=/WeeDog32-Void
  initrd /WeeDog32-Void/initrd.gz

No longer tries to connect to Internet on default boot, which is good. Connected fine for me thereafter using:

Code: Select all

wiakwifi reset (or simply wiakwifi)

I note that this version 2.4 iso release does not contain the latest initrd/init I've created to allow multiple alterations to loaded modules for tricky machines such as Fred's HP Compaq. That's fine, since the new initrd/init could probably do with further testing.

However, if you wish to give the new initrd/init a try it is currently a matter of editing the iso download initrd.gz (e.g. using modifiy_initrd utility script) and replacing the /init found in there with the new one per this recent post of mine:

viewtopic.php?p=12864#p12864

Once I'm happy with the new initrd/init (revision 2.0.9 instead of previous revision 2.0.8) I'll upload a new build_weedog_initrd-latest.sh script to the weedoglinux gitlab site.

[rockedge]

@wiak
I just finished a WeeDog32-Void-2.4X, which uses the initrd.gz 2.0.9. The latest from the factory wiak. The boot times have been significantly shortened. The IBM T-42 that took 22 minutes booted in 4 minutes and the 64 bit machines boot WeeDog32-Void-2.4X in under 45 seconds.

The 32 bit DELL INSPIRON E1505 laptop boots it in less than 60 seconds. So WeeDog32-Void-2.4X with the initrd.gz 2.0.9 has really improved in performance

WeeDog32-Void-2.4X

[fredx181]

Then, @fredx181, if you add the following to your grub menu.lst kernel line:

w_rmmodule="ata_piix pata_cs5535" w_addmodule="ata_piix"

That works (no delay) with the new init, thanks.
Easy to experiment this way, so I tried to exclude aufs:

Code: Select all

w_rmmodule="ata_piix aufs" w_addmodule="ata_piix"

And boots too without the delay. Tried similar with some other modules that are not in modules.dep and works too, so I see a connection with that, but still cannot understand

As you said, it' would be a puzzle for a user to know what's the offending module to exclude, so still searching for a real solution by modifying init, get back later.

Fred

[wiak]

Easy to experiment this way, so I tried to exclude aufs:
...
As you said, it' would be a puzzle for a user to know what's the offending module to exclude, so still searching for a real solution by modifying init, get back later.

Yes, it does make it easy to experiment with. Finding a solution that didn't require user to know the offending modules would be a big plus though.

[wiak]

Back on topic.

Since 32 bit WDL32_Void is a great contender for old and dusty low-powered machines, it might be worth slimming down at least its initrd.gz file. Culprit there (aside from compression method used) is that all that kernel's modules are included in /usr/lib/modules. Clearly, we only need whatever modules prove to be reasonably general purpose. I note, Fred, that you include a restricted set of modules in your Porteus boot initrd1.xz included with your DebianDogs. I can't imagine you cut out the needed modules by hand, since that would be very arduous even though you can search for where they are via modules.dep (and need the dependencies too of course). Do you happen to use any slim-modules down utility where we can feed in the list wanted and that utility will automatically produce the slimmed down module folder for inclusion in the initrd (Puppy doesn't have this issue since they use huge kernels with all modules needed for booting built into the kernel itself I think)?

I could probably design such a utility (I have scribbled many an algorithm down last time I thought about doing this, but it hurt my brain, and I never finished any implementation - it may in fact be easy, but I'm overlooking that easy solution - I haven't even googled to see if any such util already out there, which would be wiser of me...). Anyway, if you have such, would be very handy. If not, I will consider making one (one day...).

Need to also make a similar routine for cutting down on firmware, which per Puppy and the Dogs can of course be included as sfs file (WeeDog in fact being able to use Puppy kernel, and modules and firmware sfs, per some early code included in its initrd. But personally I trust better official Void kernel (to work best with the underlying Void repo packages some of which download extra Void firmware anyway) so would like to whittle these needed resources down myself (or not bother whittling)...

wiak

[rockedge]

Slimming down the over all size of WDL32-Void is a process we are just starting to begin. Right now WDL32-Void is sporting an initrd.gz of 65 megabytes and the file system in SFS form around 578 megabytes. I was able to wack off 600 meg from the original versions just by clearing out /var/cache/xbps before compression to bring the file system size down from 1.6 gig to the 578 meg it is now.

Most likely there is room to trim in Locale files and all the packages are installed without any trimming at all at this point. Myself I believe that the storage size as it is now, is acceptable since the actual RAM usage when running, is very compact.

I am excited about the range of "older" machines that WDL32-Void has been able to boot on and run so far. I have not tried to use the uncompressed firstrib_rootfs yet in the IBM T-42 since with the initrd.gz version 2.0.9 has so significantly decreased the boot up time.

I have also created a WDL-Fossapup hybrid that seems to run with either a huge Puppy Linux AUFS kernel or the monolithic Void kernel. I have not yet done that much with it other than to see if it would run.

But I really have to focus back on translating all the improvements achieved on the WDL32-Void ISO, to a PLUG file. So anyone can take the PLUG either run it as is are add some modifications and build a similar OS from scratch using the WDL scripts.

Although overall I like the idea of the ready to get going operating system via an ISO file as well. Just for the speed of setting up a USB or other frugal install is a reason.

[fredx181]

Hi wiak and rockedge,

I note, Fred, that you include a restricted set of modules in your Porteus boot initrd1.xz included with your DebianDogs. I can't imagine you cut out the needed modules by hand, since that would be very arduous even though you can search for where they are via modules.dep (and need the dependencies too of course). Do you happen to use any slim-modules down utility where we can feed in the list wanted and that utility will automatically produce the slimmed down module folder for inclusion in the initrd

In Debian there's mkinitramfs or update-initramfs to create initrd.
Good that you bring this up, I found 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

(EDIT: The mkinitrd script makes use of dracut, I guess there should be a way to edit the script to use the --keep option of dracut, so then copy the kernel modules directly from initramfs dir in /var/tmp, then no need to extract the initrd.img, not sure how yet.)

Then I replaced lib/modules/5.9.14_1 in the extracted weedog initrd.gz with 5.9.14_1 from extracted initramfs-5.9.14_1.img, compressed to new initrd.gz, and... guess what...
Booting with this new (small) initrd.gz the long delay problem is gone for me !! (don't ask me how come )

Can you both try if this works ok for you too? : initrd.gz-5.9.14_1 size: 19 MB (included latest init from wiak)
https://dl.dropboxusercontent.com/s/lrw ... .14_1?dl=1

edit: @rockedge

with the initrd.gz version 2.0.9 has so significantly decreased the boot up time

I probably have missed something, what is this initrd.gz version 2.0.9 ?

Fred

[rockedge]

@fredx181

The initrd.gz version 2.0.9 is the init version wiak added fixes mentioned here viewtopic.php?p=12940#p12940

I am really excited about your discovery Fred! Good work. I'll be trying it out within hours.

Although there is also a tool from wiak that decompresses the initrd.gz which I used to swap out the init file, maybe I can use it to perform your suggestions.

modify_initrd_gz.sh.tar

(1.62 KiB) Downloaded 23 times

[fredx181]

@fredx181

The initrd.gz version 2.0.9 is the init version wiak added fixes mentioned here viewtopic.php?p=12940#p12940

Ah, I see, and you used it in combination with this on the grub kernel line, I guess ?
w_rmmodule="ata_piix pata_cs5535" w_addmodule="ata_piix"
Just saying, above should not be needed with the initrd.gz-5.9.14_1 that I posted (at least not for me), which is the good thing IMO.

Although there is also a tool from wiak that decompresses the initrd.gz which I used to swap out the init file

modify_initrd_gz.sh.tar

Yes, I use it already, handy tool indeed.

Fred

[wiak]

Good that you bring this up, I found in WeeDog32-Void-2.4 the "mkinitrd" tool and did:
...
Can you both try if this works ok for you too? : initrd.gz-5.9.14_1 size: 19 MB (included latest init from wiak)
https://dl.dropboxusercontent.com/s/lrw ... .14_1?dl=1

That's good to hear. Now that you have mentioned it I remember that Void uses dracut for this (and noticed mkinitrd mentioned somewhere). In fact I used dracut myself previously/way-back to decompress the Void original initramfs I worked with so I shouldn't have missed that possibility, but did.

I don't have a machine that has the delay you mention anyway, but I'll take a look at your initrd.gz-... (just work up so haven't downloaded yet...) Good that you've found a hopefully reliable solution.

wiak

[wiak]

@fredx181

The initrd.gz version 2.0.9 is the init version wiak added fixes mentioned here viewtopic.php?p=12940#p12940

Ah, I see, and you used it in combination with this on the grub kernel line, I guess ?
w_rmmodule="ata_piix pata_cs5535" w_addmodule="ata_piix"
Just saying, above should not be needed with the initrd.gz-5.9.14_1 that I posted (at least not for me), which is the good thing IMO.

My quick first attempt with the slimmed initrd.gz-5.9.14_1 hung, but fortunately I quickly noted from my grub4dos menu.lst I was still using previous rockedge release files that had kernel 5.9.13_1 not 5.9.14_1.
I had already downloaded and used rockedge's latest iso, but probably on other laptop so I'm redownloading right now (edit: done. Booted fine Fred).

Like I say, I don't have any machine that has the delay anyway, so I won't be able to confirm aside from my machine bootings fine. However, could you explain to me how that new set of modules fixes the delay? Isn't it just a slimmed down list of the larger set of modules, in which case load order hasn't been changed at all. Are you sure it isn't simply Void upgrading the kernel by that one point and hence recompiling the modules? I just can't see how slimmed down module list would effect anything, so I must be missing something in my understanding here???

EDIT: I presume it must be that mkinitrd chose only relevant modules and so some that have been excluded have fixed the delay issue? But no, that surely can't be the reason - that would imply either the initrd was for particular system only. Except, when I rethink about it, mkinitrd will presumably only include modules that might be required to boot??? and some modules excluded so indeed fix matters. But actually, I still don't get it - how could mkinitrd know what modules a distro designer chooses (meaning, actually wants) to activate in their initrd?

It is certainly great to get that slimmed down modules directory since makes the initrd.gz considerably smaller.

I'm currently posting from WDL_Void32. It's certainly a fun wee distro to play with. Looking forward to 64bit version also and that most useful build plugin to allow easy/repeatable always-up-to-date-rolling modification. But certainly handy having an iso version for quick download/installation (though a tar.gz version would do for me since I don't use the iso itself to boot - in fact, is the iso you supply a bootable iso rockedge?).

[rockedge]

is the iso you supply a bootable iso rockedge?

not yet. I have played around with it but did not incorporate it yet. I would like to see what that would look like!

[wiak]

(EDIT: The mkinitrd script makes use of dracut, I guess there should be a way to edit the script to use the --keep option of dracut, so then copy the kernel modules directly from initramfs dir in /var/tmp, then no need to extract the initrd.img, not sure how yet.)

Yes, that's what I was thinking as I read the first part of your post. For the build WD void flavour part of build_firstrib_rootfs script I'll need to automate this or extract the code that does this module slimming out of mkinitrd+dracut. Similarly for Ubuntu/Debian/Arch build functions. Depending how convoluted the mkinitrd+dracut code is, it ''might' be possible to simply work out the algorithm they use and code that part more simply, but more than likely complex. I still don't understand how this slimmed modules directory fixes your old laptop's boot delay issue though.

[wiak]

Just a quick check on available kernels from WeeDog32_Void:
https://docs.voidlinux.org/config/kernel.html

Code: Select all

bash-5.0# xbps-query --regex -Rs '^linux[0-9.]+-[0-9._]+'
[-] linux4.14-4.14.210_1 Linux kernel and modules (4.14 series)
[-] linux4.19-4.19.163_1 Linux kernel and modules (4.19 series)
[-] linux4.4-4.4.247_1   Linux kernel and modules (4.4 series)
[-] linux4.9-4.9.247_1   Linux kernel and modules (4.9 series)
[-] linux5.10-5.10.1_1   Linux kernel and modules (5.10 series)
[-] linux5.4-5.4.83_1    Linux kernel and modules (5.4 series)
[-] linux5.5-5.5.18_1    Linux kernel and modules (5.5 series)
[-] linux5.6-5.6.19_1    Linux kernel and modules (5.6 series)
[-] linux5.7-5.7.19_1    Linux kernel and modules (5.7 series)
[-] linux5.8-5.8.18_1    Linux kernel and modules (5.8 series)
[*] linux5.9-5.9.14_1    Linux kernel and modules (5.9 series)

So that 4.4 kernel may be a good candidate for older machines. Worth comparing with 4.19 and against most recent 5.9.14_1 (as currently provided). General kernel info: https://www.kernel.org/

[wiak]

I remember now that back in the days of first WeeDog Void flavour I considered dracut along with udev for purposes of build_weedog_initrd but I was striving to avoid complex subsystems in the actual core build scripts - i.e. keeping them as first principles simple as possible for ease of understanding, build script code simplicity and operation, and ease therefore of expansion (especially via plugin code). I continue to be sensitive to keeping that as main principle of WeeDog build script action. It has to be kept in mind that my simplest WeeDog creation simply includes busybox and standalone package manager (and Void Linux provides the best such package manager via xbps static). Dracut with mkinitrd facilities, per recent experiments/evidence, proves useful as plugin build support for some builds, but not something I want as essential core, in which I strive to avoid complex subsystems like that. (I'm currently reading mkinitrd and some of the dracut scripts - dracut is a monster... seems it can even figure out "host only" modules required... I suspect not much of dracut facility/code is required for module slimming purpose anyway)

Yes, I see the dracut --keep option...

Currently, per almost everyone building Debian-based-derived distros, there is no good alternative to complex subsystem debootstrap (and I use similar for Arch WeeDog builds) but Void is special in how extremely basic/simple distros can be made simply via the likes of busybox/xbps so I'm keeping that in mind.

FirstRib plugin dracut support (or whatever else does the slimming modules list job) would certainly be an answer to this relatively complete WeeDog32_Void distro, since that can create the slimmed module list prior to build_weedog_ram producing the final initrd, but I don't intend to lock the build WDL_Void system into that method since the firstrib_rootfs need not always include dracut and so on anyway. Very useful generally and for this WeeDog32_Void creation (and similar) though. I'll be thinking about this further for next build system revision. I also want to see if I can understand the algorithm being used by mkinitrd with dracut to slim the list since I'd like to self-script that since I'm sure that could be done in a first principles simple form (though maybe not so easy with bash - last year I was planning to use awk for that since associative arrays very powerful for such work - I almost had an algorithm worked out, but tricky to get my head round since recursion (re-entering loop) was involved.

Anyway, until I come up with solution I prefer, that Fred discovery mkinitrd/dracut approach will certainly be usable and I'll implement it via plugin support. Looking at it, I think that modules.dep list may be quite stable though, which provides me with a scripting solution for now anyway (actually there are a few modules there that remain unneeded in WeeDog initrd - to do with sound, for example - most of the rest are pretty obvious being mainly fs-related).

I particularly want to know, however, why that slimmed down module list fixed the delay problem anyway, since that much makes no sense to me thus far! Just remembered you said

(don't ask me how come )

Are you quite sure, Fred, the delay fix for your system isn't simply that this latest download is for a slightly newer kernel release?

[wiak]

I think it is dracut that is doing all the work and I see the basic idea, though whether I can pick out all the bits I have to determine.

Main thing is dracut uses a function 'instmods' to take a named module or module group from big modules.dep list to store it in the slimmed down initrd modules folder.

The modules it takes depends how dracut was called. One of the main pieces used looks likely to be the following file from /usr/lib/dracut:

Code: Select all

/usr/lib/dracut/modules.d/90-kernel-modules/modules-setup.sh

For example:

Code: Select all

instmods
=drivers/tty

tells it to get all the kernel/drivers/tty stuff from big modules.dep list into the slimmed down set

Figuring out that much doesn't mean I'll manage to work out the whole set; I'm still looking to see if all I discover accounts for everything that ends up listed in slimmed down modules.dep. If it does then I could easily generate the same basic set of modules without relying on dracut.

We shall see...

[fredx181]

fredx181 wrote:

(don't ask me how come )

Are you quite sure, Fred, the delay fix for your system isn't simply that this latest download is for a slightly newer kernel release?

If I understand well what you mean, I had the same delay problem with the initrd.gz for kernel 5.9.14_1 (in the latest ISO) and problem is gone booting the slimmed down initrd.gz.
I have trust in what mkinitrd/dracut does creating initrd (including only kernel modules that are needed for booting) but cannot be absolutely sure because I have only one machine to test on, that's why I asked you and rockedge to test it.
@rockedge I'm interested how it goes with the small initrd on your old Thinkpad, can you test ?

Fred

[wiak]

fredx181 wrote:

(don't ask me how come )

Are you quite sure, Fred, the delay fix for your system isn't simply that this latest download is for a slightly newer kernel release?

If I understand well what you mean, I had the same delay problem with the initrd.gz for kernel 5.9.14_1 (in the latest ISO) and problem is gone booting the slimmed down initrd.gz.

Yes, that's what I meant. In that case, in that list of modules being modprobed there must be some module or modules (including therefore their dependencies) that should not be included for successful boot on these machines such as yours that exhibit that delay problem. That's the only conclusion, thus far, that makes logical sense to me about why slimmed down module set fixes it. Alas, my own tests tell nothing since all my machines boot fine with either that slimmed down set or the full set of modules included. Indeed it would be good to get some confirmation from rockedge assuming his delay problem is same one. For various reasons to do with scripting it, I'd prefer to work out how dracut derives that slimmed down list; as I said, I think I see how it basically does it, but it is certainly not a trivial process (since also dracut includes dependency modules so has to must scan through modules.dep to find these and then the dependencies of these and so on - that is very similar to the algorithm I was trying to make myself just about a year ago before my brain hurt too much). Of course, no-one need trust any algorithm/code I come up with, and dracut solution will likely always work regardless... Currently I cannot account for some of the modules dracut includes, but very close - close however is not enough so dracut method remains only solution thus far (at least in terms of slimming down to only modules needed to boot). The delay 'might' have an alternative fix (assuming full modules were in the initrd) if it is a fact that some module or modules in the for loop should not be included (and are, in other words, the cause of the delay). Not having a 'delayed' machine to test, I can't find that out by trial or error or otherwise. Anyway, will maybe revisit this some other time. Actually, I maybe can - if I scan through the modules.dep list with the items from the for list at least I should be able to tell which of these for list items are not provided as modules (doesn't mean they haven't been compiled into the kernel itself of course).

Glad you have it working now without delay anyway. Problem may occur that new build will later involve newer kernel and no guarantee the dracut will come up with same modules.dep list so would need to use mkinitrd/dracut each time unless could reverse engineer the dracut algorithm and code a simple routine for that one modules slim purpose. That's the reason I've been checking dracut, despite the unlikeliness I'd sort that out - it is painful to have to fetch dracut and build initramfs via the kernel each time before 'scripting' a build of the initrd - that's what I don't like about it. But at the end of the day, I just build WeeDog's that work for my family and publish the scripts - good that they prove useful for others, but I'm not promising there won't be some work to do for some systems out there! For such machines, seems mkinitrd via dracut will provide the answer.

[wiak]

The following is a more likely longterm sort of way I'm likely to end up doing it:

Code: Select all

# Install the kernel modules if requested
if [ -n "$KERNEL_VERSION" ]; then
  find                                                                        \
     /lib/modules/$KERNEL_VERSION/kernel/{crypto,fs,lib}                      \
     /lib/modules/$KERNEL_VERSION/kernel/drivers/{block,ata,md,firewire}      \
     /lib/modules/$KERNEL_VERSION/kernel/drivers/{scsi,message,pcmcia,virtio} \
     /lib/modules/$KERNEL_VERSION/kernel/drivers/usb/{host,storage}           \
     -type f 2> /dev/null | cpio --make-directories -p --quiet $WDIR

  cp /lib/modules/$KERNEL_VERSION/modules.{builtin,order}                     \
            $WDIR/lib/modules/$KERNEL_VERSION

  depmod -b $WDIR $KERNEL_VERSION
fi

That's an extract from http://www.linuxfromscratch.org/blfs/vi ... ramfs.html

It illustrates what void mkinitrd with dracut basically do. I was reading through dracut functions to try and identify the likes of (block, ata, md, firwire) and so on to try and get the most general workable set of modules without having to have the whole dracut+udev system onboard.

Anyway, like I've said, it's too much summer here for this just now, except on rainy days!

[rockedge]

It is hard for me to test the boot delay since only one machine really does it. What I put this IBM T-42 through should be noted on some memorial dedicated to those computers these fringe OS's get tested on.

I also started out making these WDL32-Void and (now the new) WeeDog64-Void because they worked so well for me and I found WDL to be a great platform to build, setup and configure to make all kinds of dedicated systems or a regular general purpose that offers many ways of setting it up just as one wants.

WeeDog32-Void-2.5X uses the smaller initrd.gz and has so far booted on every machine I tested on. Including my IBM T-42 and now a 1998 Gateway desktop has been re-activated. This thing runs Tahr-6.0.5 fairly well so I think it will fire up.

Some time today I will upload WeeDog64-Void-1.0
Same concept of WDL32-Void but I will add the build_ZM.sh script into the build to make a Zoneminder system with a LHMP stack, when so desired.

[rockedge]

I'm interested how it goes with the small initrd on your old Thinkpad, can you test ?

So far WeeDog32-Void-2.5X is booting fine and under 3-4 minutes on the old T-42. Huge improvement!

it is using the much smaller initrd.gz that fredx181 has built with good results. The entire ISO is now 604 meg with the initrd.gz weighing in at 20 meg.

Htop reports 68 meg RAM used after start up.

I am interested in the same now for WDL64-Void-1.0 which would reduce it's ISO size

2020-12-23-091700_1024x768_scrot.png (49.83 KiB) Viewed 991 times

[rockedge]

After a WDL64-Void is uploaded for testing I will look into making a PLUG file for WeeDog32-Void with openbox/tint2 desktop combo and offer a WDL32-Void with OpenBox.

[wiak]

Some time today I will upload WeeDog64-Void-1.0
Same concept of WDL32-Void but I will add the build_ZM.sh script into the build to make a Zoneminder system with a LHMP stack, when so desired.

That's excellent rockedge, it will be good to compare the 32bit and 64bit versions to see which one performs better (if either) on the same machine. Like I've said, I plan to use your build for Zoneminder on a laptop I have set aside for this so I'm likely to adopt whichever performs best for my personal Zoneminder use.

After a WDL64-Void is uploaded for testing I will look into making a PLUG file for WeeDog32-Void with openbox/tint2 desktop combo and offer a WDL32-Void with OpenBox.

Another great idea. Looking forward to that. For general desktop use I prefer openbox, though not much in it. For Zoneminder machine I'm more likely to use jwm version since slightly more efficient.

wiak

[wiak]

Will be lazing about for the next few Christmas days, but still planning to implement a modules slimming function since using large system components is against the whole philosophy I outlined as what FirstRib WeeDog is all about. In early days of WeeDog initrd creation I was advised to use DebianLive, but that has already been done and I wanted to create something original - a unique/original initrd/init that uses overlayfs, was as simple in script code as possible and designed line by line from first principles. I do not intend to deviate from that aim with WeeDogLinux.

Personally, I have not felt settled by the WDL Void-flavour apparent boot delay 'fix' of 'slimming down the initrd modules content'. I had asked if anyone had a simple script/utility for slimming down modules, but I did not do so as some idea that was anything to do with the boot delay issue some experienced! - I simply wanted to create smaller initrd... Alas no small utility was forthcoming/suggested, only one of the popular quite complex system utilities big distros use to create/rebuild their official initramfs components, being mkinitrd, which relies on dracut and uses udev. In WeeDog simple/first-principles build from scratch philosophy I definitely will find or more likely it seems create a simple alternative (whether that is trusted by users other than myself or not).

Having said that, using any flavour variant of mkinitrd/dracut is useful and fine for now, on a temporary shrink the initrd modules code basis since it immediately allows a small reduction in the iso size of WDL32_Void, but after my break I will certainly get back to working on my simple first principles slim modules code. I may or may not reliably manage that (but I am reasonably confident I will) but it doesn't matter to me it initrd is large or small really (except it's nice for download purposes); in practice the initrd which is loaded into RAM by the kernel is itself cleaned out of RAM during switch_root (as free results can establish), so its size, aside from storage/download should be technically irrelevant IMO. Simplicity and efficiency of WeeDog implementation principal/philosophy is key fundamental important to me, and not storage/download size of any component, since I want relatively non-guru developers to actually be able to understand its underlying operation - big system components hide that from us mere mortals... Unlike Puppy and DebianDogs, I have no interest in producing smallest iso possible - run efficiency/reliability/flexibility/elegant-simplicity is all that counts to me as far as end of the day usage is concerned.

But yes, a somewhat rare problem was identified for WDL32_Void flavour re: a couple of machines exhibiting boot delay (apparently, from w_debug=0, occurring in attempt to modprobe ata_piix).

Otherwise, were only my own machines be involved in tests, I would have decided all was well and nothing boot-related needed fix.

However... two machines proved to have a 'delay' during ati_piix loading. I modified the initrd/init to allow one 'fix' to the still unexplained/not-understood issue:

Code: Select all

w_rmmodule="ata_piix pata_cs5535" w_addmodule="ata_piix"

Didn't have a delayed boot machine to test myself, but above 'worked', and the new initrd/init code facility of being able to add/remove multiple modules is useful to me anyway.

When I asked if anyone had a utility for slimming down modules, that was simply for the download size situation - not for a second did I see that as relevant to the boot delay! Anyway, Fred suggested mkinitrd/dracut and that does that job of course, but odd thing the resulting substitution of that slimmed module list resulted in the boot delay going away!!!!! Frankly, I did not see any possible logical relationship between providing a smaller modules directory and the boot delay issue. After all, the list to be modprobed remains the same, the modules available in the initrd need to include all these required by that list... So, not for a second did I feel happy with that being a reliable bug-fix. Sure, all the tested machines now boot without delay, so problem can be ignored unless it rears its ugly head again - but fixed??? This I doubt and I continue to work on it, but problem being no machine that had the boot delay issue in the first case - until NOW...

I do not know the fix, but I now know that the slimmed module directory is not a proper fix since I have a boot delay at modprobe ata_piix unless I include

Code: Select all

w_rmmodule="ata_piix pata_cs5535" w_addmodule="ata_piix"

I need to test further to see if the pata_cs5535 bit is relevant on my machine and I do not have any other 'fix' myself yet, but I am happy because now I have confirmed to myself that slimmed modules itself is not a proper fix (as I suspected) but rather I expect just effected timing (such that the boot delay lockdown was luckily avoided on all machines tested thus far, till now).

So, I will get back to working on my own slim module code in a few days time, but I am also now in the surprisingly happy position of being able to test the boot delay problem (even though using an initrd containing slimmed-down modules). I may or may not manage to find a permanent proper fix, but at least I can now employ kernel tracing utilities and try my best to work out the actual problem. Not to worry, the problem is clearly now so rare that it can likely be ignored (however, call me fussy, but my approach to coding/debugging is that I strive to understand the issue and address the issue discovered via that understanding - such understanding has not happened yet, so the current 'fix' is really just some matter of luck probably related to timing/collisions/deadlock issues - you couldn't trust such a fix to control your home nuclear power station...!

I'll test further in a few days and explain what I've found and find including any other 'fixes' I come up with that I believe are more relevant/reliable.

By the way, the boot delay I have established on this machine isn't long - only about 30 seconds, so if worst comes to the worst I could live with that anyway (except I do not like knowing the reason for the bug is not understood and not actually 'fixed' at all - I do not myself feel happy as a developer to simply ignore a bug because it somehow appeared to 'vanish' when I used an official util to slim down the modules; that alone would never inspire confidence in the development process for me.

Anyway, fingers crossed that I get to the true bottom of this or at least find the reason why that boot delay is actually happening!

Until then, for now, I suggest continuing to include the following on your grub menu.lst kernel line since that effects a fix in all scenarios thus far (though reason still not determined). The slimmed modules list, I now know, does not always do the job so, for sure, isn't an actual bug fix at all, just a lucky timing effect (you cannot rely on) it seems.

Code: Select all

w_rmmodule="ata_piix pata_cs5535" w_addmodule="ata_piix"

Merry Christmas to one and all!!!

wiak

[wiak]

No answer yet, but I'm certainly finding weird ways to influence this boot delay. Seems, as I suspected, to actually be nothing to do with the modules themselves. Seems to be some kernel or other time issue. Any actual delay during load module loop effects the delay (one result being that a module, such as ata_piix apparently freezing is actually an illusion - I can adjust the time delays such that is a different module altogether that appears to freeze - to say that it is odd is an understatement. This is will the cut-down modules in the initrd. I will investigate further tomorrow. There may be no great answer... no holy grail found thus far. Could just be this kernel. Less likely could be busybox ash (I doubt that).