[SOLVED] tmpfs not working on custom kernel, slackware 13.1
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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 188.8.131.52-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.
Last edited by selfprogrammed; 07-20-2010 at 03:35 PM.
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.
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 ...
... 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.
Last edited by selfprogrammed; 07-24-2010 at 02:59 PM.
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:
# 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.
Last edited by selfprogrammed; 07-25-2010 at 02:57 PM.
Reason: Moderator message.
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.
Last edited by selfprogrammed; 07-27-2010 at 03:20 PM.
Reason: Tone down