Short description of the problem: You can't mount hard drive
volumes by using their UUID number when also using extra
statistics for your block devices by the CONFIG_BLK_STATS
kernel option.
-----------------
First of all: i dont know really if i should send this message to this
group. I tried [email protected], because he seemed the most
likely "suspect" for his email adress was in the genhd.h file. The
genhd.c/genhd.h kernel source files of kernel 2.4.20 use the
CONFIG_BLK_STATS config option the most, but genhd.c had
only Linus Torvalds as creator. I tried to find on internet the
maintainer of the generic "block devices" part of the kernel;
however i couldn't find him after a few google attempts.
I have also tried google for finding out if this problem was already
known: no answers.
Maybe this should be a case for the maintainer of the "Mount"
application. However, i would like to hear your opinion on that if it is
so.
-------------------------
This is what actually happens:
When chosing the CONFIG_BLK_STATS kernel option in the
configure menu and compiling the kernel (version 2.4.20), after
rebooting; booting with the new kernel, the file /proc/partitions has
extra statistic information about your block devices. However this
extra information seems to hamper the possibility to mount
volumes by UUID number; a feature also using the /proc/partitions
file. This can ultimately result in a failure-to-mount filesystems at
boottime resulting in a forced single user maintainance mode or re-
reboot of the system. (This is dependable on your inittab and
/etc/rc.d files.)
------------------------------
Some version info:
Kernel: 2.4.20
Mount: mount-2.10l
Some kernel make config:
CPU: AMD Athlon/Duron
SCSI kernel modules: "Adaptec AIC7xxx support" "Sym53C8xx scsi support"
Everything is linked in one kernel file (no loose modules)
System hardware:
CPU: AMD Thunderbird 1400 @ 1050MHz (100MHz FSB)
Main board: MSI k7t master-s (onboard SCSI, 1 SCSI HDD connected; this one will mount as in fstab points to /dev/sda1, 2 and 3.)
extra SCSI adapter: dual UW symbios controller with DE 500 NIC on one PCI card (Digital/Compaq) (3 SCSI HD's on the second controller. These won't mount for i use to point at them by their UUID)
-----------------------------
More info:
bash-2.04# ./ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux saphire 2.4.20 #3 Tue Dec 17 01:54:12 CET 2002 i686 unknown
Gnu C egcs-2.91.66
Gnu make 3.79
binutils 2.9.1.0.25
util-linux 2.10l
mount 2.10l
modutils 2.3.11
e2fsprogs 1.18
Linux C Library 2.1.3
ldd: version 1.9.9
Procps 2.0.6
Net-tools 1.55
Kbd 0.99
Sh-utils 2.0
Modules Loaded
bash-2.04# comment: (No modules loaded)
bash-2.04# cat /proc/cpu
cat: /proc/cpu: No such file or directory
bash-2.04# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 4
model name : AMD Athlon(tm) Processor
stepping : 4
cpu MHz : 1050.088
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge
mca cmov pat p
se36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 2090.59
bash-2.04# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: DEC Model: RZ2CD-KS (C) DEC Rev: 0306
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
Vendor: MATSHITA Model: CD-R CW-7502 Rev: 4.17
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 09 Lun: 00
Vendor: COMPAQ Model: BB00911CA0 Rev: 3B05
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 12 Lun: 00
Vendor: DEC Model: RZ2CD-KS (C) DEC Rev: 0306
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 13 Lun: 00
Vendor: DEC Model: RZ2CD-KS (C) DEC Rev: 0306
Type: Direct-Access ANSI SCSI revision: 02
bash-2.04# comment: (without CONFIG_BLK_STATS option)
bash-2.04# cat /proc/partitions
major minor #blocks name
8 0 4190040 sda
8 1 1047521 sda1
8 2 1047552 sda2
8 3 1571328 sda3
8 4 519684 sda4
8 16 8886762 sdb
8 17 8886256 sdb1
8 32 4190040 sdc
8 33 4184901 sdc1
8 48 4190040 sdd
8 49 4184901 sdd1
comment: (with CONFIG_BLK_STATS option)
major minor #blocks name rio rmerge rsect ruse wio wmerge
wsect wuse running use aveq
8 0 4190040 sda 263 2001 4534 1790 2 0 4 10 0 1330 1800
8 1 1047521 sda1 255 1908 4326 1750 2 0 4 10 0 1290 1760
8 2 1047552 sda2 3 45 96 10 0 0 0 0 0 10 10
8 3 1571328 sda3 3 45 96 10 0 0 0 0 0 10 10
8 4 519684 sda4 1 0 8 10 0 0 0 0 0 10 10
8 16 8886762 sdb 1 3 8 10 0 0 0 0 0 10 10
8 17 8886256 sdb1 0 0 0 0 0 0 0 0 0 0 0
8 32 4190040 sdc 1 3 8 10 0 0 0 0 0 10 10
8 33 4184901 sdc1 0 0 0 0 0 0 0 0 0 0 0
8 48 4190040 sdd 1 3 8 10 0 0 0 0 0 10 10
8 49 4184901 sdd1 0 0 0 0 0 0 0 0 0 0 0
I think other information is irrelevant.
---------------------------
Workaround: Only one i found so far: don't use the kernel option.
---------------------------
As this is my first kernel "bug" report i would very much appreciate
if you could tell me if i did anything wrong here...
Regards, Jiri Wichern. Nijmegen, the Netherlands. A dedicated
Linux fan since 1996.
On Tue, Dec 17, 2002 at 12:24:50AM +0100, [email protected] wrote:
> Short description of the problem: You can't mount hard drive
> volumes by using their UUID number when also using extra
> statistics for your block devices by the CONFIG_BLK_STATS
> kernel option.
Yes, we know.
You use an old version of mount, and the mount will always fail.
Two solutions:
(i) Do not use CONFIG_BLK_STATS.
(ii) Upgrade mount to a recent version (mount is part of util-linux,
recent is for example 2.11y).
Note that solution (ii) gives you a situation where mount and fdisk
fail sporadically instead of always, maybe not precisely what one
had hoped. Thus, (i) is the preferred solution.
It was really bad that CONFIG_BLK_STATS went into 2.4.20,
but you need not use it.
Andries
Two months ago I sent the below Doc patch. It is still needed.
--- Documentation/Configure.help~ Mon Oct 14 01:12:13 2002
+++ Documentation/Configure.help Tue Oct 22 20:30:39 2002
@@ -561,6 +561,8 @@
This is required for the full functionality of sar(8) and interesting
if you want to do performance tuning, by tweaking the elevator, e.g.
+ On the other hand, it will cause random and mysterious failures for
+ fdisk, mount and other programs reading /proc/partitions.
If unsure, say N.
(this is about CONFIG_BLK_STATS).
On Tue, 17 Dec 2002, Andries Brouwer wrote:
> On Tue, Dec 17, 2002 at 12:24:50AM +0100, [email protected] wrote:
>
> > Short description of the problem: You can't mount hard drive
> > volumes by using their UUID number when also using extra
> > statistics for your block devices by the CONFIG_BLK_STATS
> > kernel option.
>
> Yes, we know.
> You use an old version of mount, and the mount will always fail.
>
> Two solutions:
> (i) Do not use CONFIG_BLK_STATS.
> (ii) Upgrade mount to a recent version (mount is part of util-linux,
> recent is for example 2.11y).
>
> Note that solution (ii) gives you a situation where mount and fdisk
> fail sporadically instead of always, maybe not precisely what one
> had hoped. Thus, (i) is the preferred solution.
>
> It was really bad that CONFIG_BLK_STATS went into 2.4.20,
> but you need not use it.
Hi Andries,
Could you please expand on the "sporadically" so we can inform the user in
a better way when he should not use CONFIG_BLK_STATS ?
Mentioning that a newer util-linux is one good thing to be done.
On Wed, Dec 18, 2002 at 01:31:44PM -0200, Marcelo Tosatti wrote:
> Could you please expand on the "sporadically" so we can inform the user in
> a better way when he should not use CONFIG_BLK_STATS ?
He should never use it.
We had extensive discussion a few months ago, and I gave you
these Bugzilla references. Maybe you were confused because this
CONFIG_BLK_STATS code also was buggy, but that is unrelated.
Older versions of mount, fdisk and also the lvmutils, fail
because they expect the original format.
Later versions of mount and fdisk - I don't know about lvmutils -
just parse the start of a line, and hence can cope with additional
stuff at the end of the line.
But there is something else. One of the problems with statistics
in /proc/partitions is that the file changes dynamically - some
statistic can go from 99 to 100 and take a position more. A program
reading it will get bad data if it reads a buffer and then the next,
and between the two reads the contents shifts.
So far two solutions have been proposed:
A user side one: Tell stdio to use a very large buffer, in the hope
that all will be read at once. (This is what RedHat does.)
And a kernel side one: Make sure the kernel generates constant
length output.
[But it is really ridiculous to put ugly hacks in lots of programs -
Why? In order to avoid changing a single filename in sar?
Break mount in order not to break sar?
I still hope you remove this garbage again.]
Andries