tmpfs not working on custom kernel, slackware 13.1
 

The mount command is failing on any mount using -t tmpfs.
Boot error message from rc.udev, it cannot mount /dev using tmpfs.

Installing new Slackware 13.1. I have been using Slackware since 1996 (and each new install is a fight so I have plenty of experience).

Built a custom kernel with tmpfs and udev, (but without devtmpfs).
This ought to work, devtmpfs is EXPERIMENTAL after all.
This system is used in my business and I do not play with EXPERIMENTAL stuff.

Question 1: I tried the Slakware 2.6.33.4-HUGE kernel and tmpfs works (USB does not), but it uses devtmpfs (which is EXPERIMENTAL).
Do the Slackware people know something about making udev work that
I do not? Why are they using devtmpfs ???

Question 2: Has any other Slackware 13.1 user got udev working using tmpfs without using devtmpfs.

Question 3: What happens if I just leave it this way. Will udev just use the existing /dev directory ?? Does it really need the tmpfs for something that is not documented (anywhere that I can find) ??

Question 4: Is there some hidden requirement for making tmpfs work, that is NOT enforced by menuconfig ??? I cannot find anything.

Hi,

My first thought would be how do you have the static '/etc/fstab' setup?

Next would be to check the '.config' for the kernel;

:hattip:

Thank you for your reply. I am not sure which of the questions you are addressing. I have a separate question in the software category where I asked about udev problems, and where I included my pertinent fstab information, so I do not want to duplicate that line here.

I tried to mount tmpfs directly and it would not work, which makes the fstab irrelevant for this question.
>> mount -t tmpfs tmpfs /mnt/tmp

Here I am asking about Slackware and why they are using devtmpfs, and do they know something specific that makes a kernel without devtmpfs futile.
As far as I know, devtmpfs is optional and EXPERIMENTAL, and I should be able to have a kernel, with udev, and tmpfs, and WITHOUT devtmpfs, and udev should work.

Also what happens to udev if it cannot mount tmpfs, will it just use the
existing hard /dev directory ??

udev just creates device nodes based on it's rule files (or in the case of when it's run from the initrd and there are no rule files, using default values). It doesn't care whether /dev is in a tmpfs, devtmpfs or just a directory on a disk or in the case of the initrd a ramdisk.

Update:

Did some more testing.
>> mount -t ext2 tmpfs /mnt
mount: special device tmpfs does not exist

>> mount -t tmpfs /dev/ram0 /mnt
mount: bad filetype, bad option. bad superblock on tmpfs device ...
etc.
... same long error message as before

After reading the udev /usr/doc files it is not any clearer.
There is no mention of DEVTMPFS anywhere in the kernel Documentation directory.
In the kernel the CONFIG_DEVTMPFS just enables a section of code.
The comments would indicate that it gets notifications from other drivers and creates the /dev nodes itself (like udev would).
It would seem that it might implement the tmpfs device, but that was not the result of tests.

Tried setting CONFIG_DEVTMPFS=Y and CONFIG_TMPFS_POSIX_ACL and after recompile and reinstall still have the same errors mounting anything tmpfs.

Why don't you try

>> mount -t tmpfs tmpfs /dev/shm
mount: bad type, bad option, bad superblock on device tmpfs ...

>> mount -t tmpfs /dev/shm /mnt
mount: bad type, bad option, bad superblock on device /dev/shm ...

Well, it works here (Slackware 13.1, tested with 2 kernels 2.6.34.1, 2.6.35-rc6)
I've used the following to compile both kernels:
Take a look at this for tmpfs usage

I finally got tmpfs working. I only discovered this because I got curious as to why /proc/sys/version showed a date a week ago, when I knew I had compiled a new kernel the night before.

Now, this is my W11 kernel, which means I successfully compiled kernels 10 times previous (W10 was my 2.4.31 kernel). So I was doing it from memory.
>> make menuconfig
>> make kernel
>> make modules
>> make install
>> make modules_install

The mistake is that "make kernel" line. It only compiles the kernel subdirectory, and not the drivers, and then links and delivers a normal looking kernel. You have no idea, and no messages, to give you a clue as to how messed up the kernel must be. The compile looks entirely normal and if you walk away and come back you have no idea that it took only half as long as normal (which would be your only clue).

I think that it is about time to fix this trap.
The Makefile needs to trap "make kernel" with a .phony and
if the config file has changed
then either error message out, or do a normal compile.
At least warn the user.

This "mis-feature" is only used by kernel developers and it is dangerous to include it in the released code.

If you want to prevent this error, edit any new Makefile and disable the subdirectory compile feature by putting in the Makefile right before the main compile lines:

.phony kernel
kernel:
# main compile lines

(I have not checked the above for errors yet, but its the general idea)

From examining the code, the CONFIG_TMPFS only affects code in one subdirectory of the drivers directory. So I ended up with a config that said that CONFIG_TMPFS was set, but the compile was using an old object file where it was not set (before I discovered I need tmpfs for udev).

I turns out that CONFIG_DEVTMPFS is not necessary. Afterwards I compiled again with it turned off.
Now I have to figure out why Lilo keeps complaing that device-mapper is missing. It only happens on this custom kernel and not on HUGE or 2.4.

Thank you for your attention and responses.

Moderator, this is a trap that can explain many custom kernel bugs.
This information should be saved somewhere appropriate, thank you.

Hi,

Building a Linux Kernel from source should be of some help.

Your methods are not right.
:hattip:

This problem with the kernel Makefile has been around for a while, probably because some developers do not want to fix it. I worked out this general response well before seeing any actual replies.
I have been around a while and have had several bad experiences in trying to get some things fixed.

If you dig a well and put no cover over it then you have created a trap. I do not accept blaming the person who falls into this well trap nor do I accept offering them advice on how to not fall into open wells. Any person who offers them a flashlight at that point is .... The are general expectations among the civilized that any such danger will have a safety cover or some other protection.

Likewise, this kernel compile trap should have better protection.
It is too easy to fall foul of it, and the error in the produced kernel persists long afterwards with no clues as to how munged up the kernel is, it looks perfectly normal.
Linux is no longer an uncivilized back-woods, considered too dangerous to venture within by any except the scruffy woodsmen.

The four lines I gave were to show how easy it was to do "make kernel" by mistake. That is not an example of my methods, and not enough to label them as "wrong". I probably have seen the book already, I have 10+ years of Linux programming and managing experience.

I have been making customized kernels since 1996 and if I can make this mistake then so will many others.

Hi,

Loads of people fall into habits. No personal attack(s) intended. Just that your method(s) were not correct. Provided a link to a well versed and utilized methodology instead of direct examples.

HTH!

:hattip: