devfs, or the lack thereof, in 2.6

Posted Feb 26, 2004 12:18 UTC (Thu) by Duncan (guest, #6647) [Link]

> I now feel much more comfortable with the idea of upgrading.

Whoever may be reading this far back in the archives I don't know, but
someone might come across this article while doing a search on
2.6/udev/devfs, and someone else might do what I just did and take a look
around after following an LWN back-reference to an earlier article, so..

.. In particular for anyone coming by looking to upgrade, and particularly if
that upgrade is on Mandrake..

It's now late Feb. and I've been running the 2.6 kernel for several weeks. The
switch was fairly easy and painless, even on Mandrake, with their normal
devfs dependance, and even tho they haven't posted a packaged kernel, even
to cooker, for my arch (amd64/x86_64/ia86e), because their supermount
patches apparently won't compile on the platform with 2.6. I'd never liked
supermount anyway, it was to potentially problematic, and once I got used to
mounting removable drives manually (since supermount had been
temporarily removed due to issues in 8.1, my "jump from MSWormOS"
version), I actually PREFERRED the control of doing it that way and
KNOWING the status of my various mounts, so that loss wasn't missed.

I decided to take the opportunity to learn a bit more about the kernel, this
time, since the last time I'd really examined things and when I learned how to
compile my own kernels was a couple years ago, back less than three months
into the switch from MSWormOS thing.. while I was still booting back to it to
run OE for mail and news! Also, since I hadn't tried compiling a kernel AT
ALL on my new architecture (dual AMD Opteron, thus AMD64), I wasn't
familiar with 2.4 either, yet. Therefore, I started there, procuring Mandrake's
latest 2.4 kernel source package, installing it, and then starting with make
menuconfig to get an idea of what had changed since I last looked at the
kernel and how it might be different on the new arch.

After eventually getting a workable 2.4 kernel up and running with my chosen
options, I d/led the two available Mdk kernel 2.6 srpms, the mainline one, and
the tmb or "hackkernel". Note again that Mdk hadn't provided binary 2.6
packages for AMD64, as their supermount wouldn't (and still won't, AFAIK)
compile in 2.6, on AMD64, apparently due to 64-bit unclean code. Thus, I
had to extract the tarballs from the srpms and copy the source over manually,
but that sort of srpm hacking has become somewhat the norm on Mdk 9.2 RC
for AMD64, as I've had fiddle with them to procure binaries for stuff not yet
ported in a number of instances. However, i586 folks wouldn't have had that
issue to deal with.

Anyway, having extracted the two Mdk 2.6 kernels, then 2.6.2-rc1, I believe, I
manually configured each one separately including all options from scratch
(using make menuconfig), compiled, attempted to run, tweaked and
recompiled again, until one ran, manually went thru the menuconfig on the
other again, then ran diff on the opposite config files to figure out how they
differed, and what I wanted to do about it where I'd chosen different options
on one vs the other. Again, note that I had one running by this point, so I
was just holding true to my goal of going a bit more in depth learning about
the kernel, and trying to get the best compilation for my system. After
deciding how I really wanted the options, from the diffs, and figuring out
which items appeared only in one kernel, I compiled the other kernel (and
modules), installed, and fired it up. After further tweaking now that I had 2.6
running to find exactly what I needed and what I could leave uncompiled (or
as modules, but without an initrd), I had both of those kernels configured
roughtly the same and both operational.

Then I did the same thing over again only with the vanilla 2.6 kernel.org
kernel, by now a couple RCs later, this time importing the .config and doing a
make oldconfig on it first, then verifying with make config before compiling.

As I had two years ago with 2.4 on my old Athlon system, I eventually
decided it wasn't worth the hassle doing Mdk kernels, and now run the 2.6
kernel.org kernels exclusively.

An additional note on devfs, traditional /dev dirs, and /udev. I can't vouch for
the authenticity of the claim, but I read somewhere that 2.4 is now considered
depreciated for AMD64, due to issues with the arch mostly stemming from
devfs, which apparently isn't even an option any more for new kernel.org 2.4
kernels, for the AMD64 architecture, with the fixing the problems judged not
worth the trouble on the arch, for a new arch and a depreciated devfs anyway.
That may or may not have been part of the cause of my stability issues on the
platform (again, dual AMD64 Opteron, Mandrake 9.2 for AMD64 RC), but
I'm now running entirely without devfs, not compiled in, not activated,
period.

As for udev, which mounts by default on /udev, lacking any documentation
on the subject that I could find, I decided to experimentally find out if, like
devfs, it could mount directly over /dev. At this point, THE ANSWER IS
NO!! DO NOT TRY TO MOUNT UDEV ON /DEV!! At least here, not
only did it fail to boot, but it also screwed up the existing static /dev dir, so I
couldn't boot my OLD kernel either! Luckily, I could boot off my other
drive, which I keep loaded with a working system for just such issues, and I
was able to copy its unaffected static /dev over the normal one that udev
hosed.

As best I can figure from the docs I've seen (and from the Mdk /udev init
script), mounting udev on /dev should eventually be possible, as being the
replacement for devfs would indicate it should, but all the parts aren't there
yet, and at least as on Mandrake, udev can't bootstrap itself yet, but requires
being initialized from an existing /sys on a running system. It simply won't
mount directly over /dev, then, again, on Mandrake (with a static /dev, as
mounting it over devfs would be expected to be rather problematic <g>)
Cooker for AMD64 as of this date.

OTOH.. something I did NOT try that MIGHT work would be remounting it
once fully up and running over /dev. That MIGHT work.. tho safely
unmounting for shutdown would potentially create another race condition..
unless one reversed the process and remounted it back to /udev first,
unmounting it on /dev, exposing the static /dev for proper shutdown of udev
on the way to system shutdown. Still.. I think I'll wait another update of
/udev and inittools first, unless I get bored someday and want some
excitement like a not normally bootable system! <g>

Duncan