We err twice

One of the unexpected side benefits of owning a 100Mhz machine with only 16Mb of memory is that it is forcing me to carve away at parts of the system I hadn’t previously considered prunable.

Case in point, my previously published instructions for a slimmer kernel for Crux, which I’ve used as more or less a basic starting point for every kernel I’ve customized since 2.6.25.4. Those are decent instructions, and the kernels are quicker, but I’m realizing now that there’s still quite a bit of stuff left that my needs don’t require.

So there was the first “error,” in not recognizing parts of the kernel that I have spent time compiling, only to realize at this late date, months later, that they were completely unnecessary — or worse, completely unapplicable — to my desktop applications. Things like network protocols specific to routers, or hardware drivers that didn’t apply to my system after all.

And that’s okay; this is all a learning process, and it’s one of the reasons I do it. I enjoy learning.

But carving away too much was the obvious second “error,” which I committed when I disabled tmpfs thinking I didn’t need it, thereby chopping udev off at the knees, and rendering my system unbootable. And since the two things — udev and tmpfs — don’t always show up at the same party with each other, discovering the relationship between them was a bit difficult.

Eventually I found a post somewhere on a Slackware mailing list back in 2003 or so that mentioned udev and tmpfs in the same breath, and one quick recompile and I was back in business.

That’s the way these things work, and why it’s always best to tinker with an old leftover machine, and not with your mission-critical one. Mistakes will happen, and nobody learns anything unless they make a mistake, but the time it takes you to find your mistake and correct it … well, that’s the frustrating part. :)

P.S.: My Inspiron boots to the console login in 8 seconds now. … :twisted:

3 Responses to “We err twice”


  1. 1 JiGGaK 2008/11/15 at 11:26 PM

    Why not just compile the kernel on your more powerful machine and copy it over to the 100MHz machine? You may need to setup a cross compiler, or simply put whatever distro your using into a VM (VirtualBox, or QEMU) for compiling.

    This should greatly decrease the time required to test kernels.

  2. 2 zmjjmz 2008/11/16 at 5:45 AM

    “P.S.: My Inspiron boots to the console login in 8 seconds now. … :twisted:

    Dayum. If I ever needed to reboot my computers on a regular basis I would recompile my kernels just for that.

  3. 3 K.Mandla 2008/11/16 at 7:28 AM

    JiGGaK: Usually I do something like that, yanking the drive on the Fujitsu and transplanting it into the 1Ghz machine. It cuts down on the system rebuilds considerably.

    The downside is the time it takes to pull out the drive disconnect it from the tray, move it to the modular shell for the other drive, and reconnect it all. Plus wear and tear on the drive pins, which I am horrified of breaking ever since I snapped two pins off a laptop drive a couple of years ago, ruining both the drive and the caddy. :shock:

    But anyway, you’re right, there are better ways to do it than to wait hours to grow a kernel.


Leave a Reply




Welcome!

Some recent desktops


July 3, 2009
Openbox 3.4.7.2 on Crux Linux
1Ghz Pentium III 512Mb PC133


June 16, 2009
screen-vs on Crux Linux
700Mhz Celeron 256Mb PC100


June 18, 2009
screen-vs on Crux Linux
550Mhz Celeron 192Mb PC100


Feb. 13, 2009
Awesome 2.3.4 on Crux Linux
100Mhz Pentium 16Mb PC66 120Gb

A recent game


Neverwinter Nights
Gnome 2.26.1 on Ubuntu 9.04
1Ghz Pentium III 512Mb PC133

Be counted!

Recent Comments

CorkyAgain on The cloud is a lie
colonelcrayon on Light and efficient, at under…
tigrmesh on At long last

License

This work is licensed under the GNU Free Documentation License. Please see the About page for details.

Downloads

Blog Stats

  • 1,205,447 hits

Categories

Archives

Calendar

November 2008
S M T W T F S
« Oct   Dec »
 1
2345678
9101112131415
16171819202122
23242526272829
30