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. … 😈

3 thoughts on “We err twice

  1. JiGGaK

    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.

    Reply
  2. zmjjmz

    “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.

    Reply
  3. K.Mandla Post author

    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. 😯

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

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s