lkml.org 
[lkml]   [2004]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectConfiguration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?
(Please cc: me since I am not subscribed to linux-kernel list.)

I think there is something fishy about kernel 2.6.9.

I failed to enable TMPFS during configuration of
my linux kernel 2.6.9.

However, somehow /proc/filesystems lists "nodev tmpfs" line !?

Is this to be expected?

Background:
I found this hard way. At least one program, namely,
Debian udev package checks whether the system
supports tmpfs by looking at the contents of /proc/filesystems.
Because of this entry in /proc/filesystems, the script fails miserably
now.

Because of the listing of tmpfs although TMPFS was not configured(!?),
a system initialization script for udev is fooled into believing that
tmpfs is supported and tries to mount tmpfs on /dev.


Worse. Somehow the mount command doesn't complain
about tmpfs not supported, and returns succcess code to the
invoking shell. (I checked.)
(If mount fails, then we can probably fix the script to detect the
internal consistency problem and quits.)

Since the tmpfs functionality is not actually available,
from that point on, udev script fails miserably
and my kernel 2.6.9 no longer boots from that point on.

I had to disable udev initialization script for this reason by booting
under older kernel 2.4.25 and then modifies it, and
then figured out what the problem is after rebooting into 2.6.9
without udev and reporting it.

(I experienced a similar problem earlier with Debian's udev script a
few weeks ago, but when udev script was updated to a new version this
problem was not observed. The udev script used different method to
decide whether udev ought to be invoked or not. But the latest udev
script in Debain, which I upgraded recently, now uses the checking of
availability of tmpfs feature by looking at /proc/filesystems
and then mount tmpfs, and this strange kernel behavior is causing a
grave problem.

Listing;

Kernel version.
ishikawa@duron$ uname -a
Linux duron 2.6.9-test-tmscsim #10 Sat Oct 23 01:25:17 JST 2004 i686
GNU/Linux

Used config /proc/config.gz (attached in full)

ishikawa@duron$ zcat /proc/config.gz | grep -i tmpfs
# CONFIG_TMPFS is not set


/proc/filesystems contents:

ishikawa@duron$ cat /proc/filesystems
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev sockfs
nodev binfmt_misc
nodev futexfs
nodev tmpfs <==== Why is this line here???
nodev pipefs
nodev eventpollfs
nodev devpts
ext2
nodev ramfs
msdos
nodev devfs
hpfs
vfat
nodev usbfs
nodev usbdevfs
ishikawa@duron$ lsmod
Module Size Used by
via686a 18720 0
w83781d 34096 0
i2c_sensor 4608 2 via686a,w83781d
i2c_isa 2048 0
i2c_core 23168 4 via686a,w83781d,i2c_sensor,i2c_isa
snd_ymfpci 66212 0
snd_pcm 114056 1 snd_ymfpci
snd_ac97_codec 74960 1 snd_ymfpci
snd_opl3_lib 12160 1 snd_ymfpci
snd_timer 33540 3 snd_ymfpci,snd_pcm,snd_opl3_lib
snd_hwdep 8836 1 snd_opl3_lib
snd_page_alloc 8328 2 snd_ymfpci,snd_pcm
snd_mpu401_uart 9472 1 snd_ymfpci
snd_rawmidi 28068 1 snd_mpu401_uart
snd_seq_device 7432 2 snd_opl3_lib,snd_rawmidi
snd 59492 9
snd_ymfpci,snd_pcm,snd_ac97_codec,snd_opl3_lib,snd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device
soundcore 9440 1 snd
uhci_hcd 34188 0
usbcore 133348 3 uhci_hcd
evdev 7808 0
nls_iso8859_1 3968 1
vfat 14592 1
radeon 137860 0
ide_cd 39456 0
st 35612 0
tmscsim 23360 0
sr_mod 15396 0
cdrom 38172 2 ide_cd,sr_mod
sg 35232 0
nls_cp437 5632 1
hpfs 87172 0
ishikawa@duron$

--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
[unhandled content-type:application/gzip]
\
 
 \ /
  Last update: 2005-03-22 14:07    [W:1.462 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site