mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chiaki <ishikawa@yk.rim.or.jp>
To: linux-kernel@vger.kernel.org
Cc: ishikawa@yk.rim.or.jp
Subject: Configuration system bug? : tmpfs listing in /proc/filesystems when TMPFS was not configured!?
Date: Sun, 07 Nov 2004 02:50:51 +0900	[thread overview]
Message-ID: <418D0EFB.2040002@yk.rim.or.jp> (raw)

[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]

(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 */

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 7172 bytes --]

             reply	other threads:[~2004-11-06 17:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-06 17:50 Chiaki [this message]
2004-11-06 19:04 ` [PATCH] " Måns Rullgård
2004-11-06 21:09 ` Hugh Dickins
2004-11-07  1:31 ` Chiaki
2004-11-07  2:05   ` Chiaki
2004-11-07  2:12   ` Chiaki
2004-11-07  4:49     ` Hugh Dickins
2004-11-07  6:00       ` Chiaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=418D0EFB.2040002@yk.rim.or.jp \
    --to=ishikawa@yk.rim.or.jp \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome