I am running a Scientific Linux 4.x (RHEL 4 clone) system on a P4 desktop. In an attempt to build in JFS support, I have built a new kernel from sources obtained from kernel.org. The newest vendor-issued kernel that I have is 2.6.9-42.0.10, and it works fine, other than the missing JFS support.

To build the kernel, I have created .config in a few different ways, and succeeded in creating a kernel image (2.6.27) and an initrd. However, when the kernel is used, I find that there is no /dev/tty0, and several components seem to rely on the presence of such device. Most importantly, Xorg bails, complaining that it cannot write to /dev/tty0. Also, the Rehdat Graphical Boot system fails for similar or identical reasons.

I am confused about where this gets created. It seems to be kernel dependent, but I can't find anything that looks like it controls how it is created. From researching online, I believe that at some point there has been a change in how console devices are created and named. Have I crossed some boundary between the two styles? If yes, where is that boundary? I don't necessarily need the latest/greatest kernel, just one that supports my requirements. What can I do to get a kernel that contains JFS support and still runs properly on my host system. Changing to a different distro is not an option, and a complete re-install would be quite undesirable.

What I have observed that might be relevant:
mkinitrd creates /dev/tty1 .. /dev/tty4 character devices with major number 4 and minor numbers 1 .. 4. Character device 4 0 is created and called '/dev/systty'.
mkinitrd creates cpio-archive style initrd's and I've experienced some difficulty getting these to work properly, too. Sorry I haven't kept good track of details on that, but I'm sure I can reproduce it if someone thinks it is germane.
If this is not a kernel-related issue as I have guessed it to be, please do point to a more suitable forum.

Thanks.

--- rod.

It's possible that you may have dev filesystem installed and that may be the problem.

You can find the .config that the distribution kernel is compiled with either in /boot or in the source packages then view it and possibly use the options or the entire .config in the kernel.org source and add the other options you wish to enable so this is not a problem.

Thanks for your reply. Comparing the distribution .config and the .config that I created for my own build, the original distro version contains
While the new .config has no entry whatsoever for DEVFS. Is this the configuration item to which you refer?

Viewing a diff of the configs reveals nothing that looks, to me, anything like it would affect the creation of TTYs, although the two configs are so different that diff has trouble maintaining a readable correlation.

One thing that seems relevant is in the initrds. In the one created for my new kernel (using mkinitrd from the SL distro), I see a dev directory, containing:
These appear to be consistent with the mkinitrd script code. The distribution initrd contains a dev directory that is empty.

Having exhausted all ideas of my own, I have now built a kernel that is only slightly newer (2.6.10) than the original working (but without JFS support) kernel, and it seems to be unencumbered by the TTY0 issue. For now, I will chase the few other problems I have with it, and use it unless it has issues I can't live with. Still, I'd like to know what is at the root of the problem. At this point, I'm thinking that this is an example of an upgrade that requires so much change to other parts of an installation that packagers like Redhat and the others simply say 'time for a new release', make all of the required changes that keep everything compatible, and release it as a new version. If I'm correct, it makes one appreciate the work that packagers do.

--- rod.

Yes it looks like your new kernel has devfs setup. Try to disable it and see what happens.

How can I disable it? I can't find any entry for it in the config file. Or are you suggesting to re-work the initrd? Not too sure how to do that; perhaps by modifying mkinitrd?

--- rod.

With your distro I'm not sure how to add it to the initrd. In some like redhat or centos there is a make install which creates it. You can also do mkinitrd as well.

I meant to disable it in the kernel config, or enable it if it's disabled at that point you can rebuild the kernel and it will work.

Thanks for your reply. From what I can see, I don't think devfs is at the root of the problem. In all versions of the working kernel, the respective config contains
In /usr/src/linux-2.6.27/Documentation/ABI/removed/devfs I read:
My interpretation of this is that devfs has not been in use in the kernels installed on this host for some time.

What I really would like to know is where and when the '/dev/tty*' tree gets populated. Since in the initrd used by the working kernels, the /dev tree is initially empty, I can only surmise that there is some boot-time mechanism that populates the tree. If I knew how this happens, perhaps I could influence it to work in my favor. What seems to be the case is that it happens within the kernel or some kernel-specific component, and not as a generic part of the system, otherwise the behavior would be consistent across kernel versions.

--- rod.

"W-H-O-A-A-A! Slow down there, pardner! Can't you see that sign up ahead that says, 'BRIDGE OUT' ??? Now, why don't you just look there at your map and see where you want to be goin', before you just go off and 'do stuff' ...? Sure, I got a wad of rope here with me, but it ain't gonna be nearly long enough to fish you out of that canyon!"

...

Linux systems have changed a whole lot, particularly in the latest "two-point-six" versions. The whole hardware-discovery process is new, and you can define what shows up in "/dev," how it's named, and when it shows up there. It all has to do with the so-called "hotplug" (and, you guessed it, "coldplug") system. So, why not start your readings with man hotplug, and see where that takes you?

"Y'see, devices these days are removable, and people got tired of having hundreds of entries in /dev for devices that didn't really exist. So, they devised a really flexible way to let the system recognize when you stuck a device into the USB-port or pulled it out again. Named that one 'hotplug.' And then, they turned their attention to how you set things up when you first turned the computer on. Named that one 'coldplug,' but I don't reckon they ever quite got around to writing a manual-page about it..."

Sure, I get that. Been there, done that.
I haven't changed any of that stuff, and yet booting a newer kernel has changed how the /dev tree gets populated. Note that I've upgraded from a 2.6 version to a newer 2.6 (2.6.27) version. As I understand it, hotplug is used to respond to changes in installed devices, such as USB devices. In my case, I'm talking about a virtual device, /dev/tty0, which is (or should be) a console (not a serial port, just to clarify). I cannot see anywhere in the hotplug files (/etc/hotplug/...) that has anything to do with such device nodes. And that seems to make sense to me; nothing has changed there since the old kernel was used.
What does make some sense is that hotplug can respond to the kernel according to arguments given to it by the kernel. I cannot see anywhere that hotplug deals with stuff in the /dev/tty* hierarchy. For that matter, I can't seem to see anything anywhere that allows me to 'define what shows up in "/dev," how it's named, and when it shows up there' where it relates to the /dev/tty* hierarchy. My surmise is that it must be hardcoded into the kernel, and is likely, therefore, to be immutable for all intents and purposes. I haven't given up yet, though.

--- rod.