I'm testing with 415, which has module-init-tools version 3.3-pre11. Well, not quite. We have a history of trouble with module-init-tools, and in Puppy4 the PET package has the 'insmod' utility from module-init-tools version 3.2.2, as 'insmod' in 3.3 crashed.
Testing on my IBM Aptiva, a PC that I particularly like as I reckon it is "nicely built", I get an "out of memory" report and the kernel kills depmod, then bootup succeeds. X starts up and all is fine. Running 'df' and 'free' shows plenty of free space. Exiting from X, then run 'depmod', the computer hangs, then after awhile the error log reports "out of memory" and it is killed.
So, I have compiled module-init-tools version 3.6:
# ./configure --prefix=/ --sysconfdir=/etc --localstatedir=/var --build=i486-pc-linux-gnu --enable-zlib
Tried it on the Aptiva, same problem.
So, still on the Aptiva, I loaded a 100MB swap file, then 'depmod' worked. Very annoying that they have designed depmod to be such a resource hog. I have grumbled about this before, so will curtail the complaining.
I need a workaround...
1. Don't run depmod
Horrible, but don't run depmod if the free RAM is below a certain amount ...I'll have to check but I think there was about 26MB free in the Aptiva.
2. Always load a swapfile
As Windows is nearly always present on an old PC, use the 'Win386.swp' Windows swap file. GuestTwo pioneered this,and found that when Windows was booted afterward it was able to repair the Win386.swp file.
Comments:Posted on 2 Jul 2009, 18:08 by BarryK
Depmod, further explanation
On the first boot, or with "pfix=ram", 'depmod' is run. There are two reasons for this:
One is that the kernel modules in the initramfs are copied across to the main filesystem just prior to the switch-root, so depmod needs to be run. This is a one-off event, not needed on second and subsequent boots.
Secondly, in recent Woof builds I have deleted all the 'modules.' files when building the live-CD, to save space. Thus, depmod must be run at first boot, otherwise no modules can be loaded after the switch-root.
The problem is that on my test PC with 64MB RAM and no swap file/partition, the free RAM after switch-root is 14660KB (due to the creation of a tmpfs of for the layered filesystem), and depmod will not work with this amount free. I have modified /etc/rc.d/rc.sysinit so that it will simply not run depmod under these conditions.
Puppy still boots up ok, as all essential modules got loaded in the initramfs. But the user will have to create a save-file on the harddrive and/or a swap partition, so that on next boot there is enough RAM for depmod to run.
I also modified /usr/sbin/delayedrun to put up a warning message if depmod failed to run, with advice to shutdown and create a save-file, and/or create a swap file/partition.
Right now, I'm downloading the latest Busybox, that has depmod. That should work in lo-RAM situations, so the problem might just go away.