I just tried changing my root and /usr partitions from ext2 to reiserfs and noticed some weird messages on boot.
Partitions on my ide-drive are like this:
Device Boot Start End Blocks Id System
/dev/hda1 * 1 521 4184901 c Win95 FAT32 (LBA)
/dev/hda2 524 654 1052257+ 83 Linux
/dev/hda3 655 785 1052257+ 82 Linux swap
/dev/hda4 786 5606 38724682+ 5 Extended
/dev/hda5 786 1308 4200966 83 Linux
/dev/hda6 1309 5606 34523653+ 83 Linux
Where hda2 is root and hda5 is /usr. The windows partition was empty at the time and i use lilo on the MBR. Lilo is version 22.1, kernel version 2.4.15-pre1. Anyway, i took backups of the root and /usr partitions with cp -a to another partition, booted from a bootdisk with reiserfs support, ran mkreiserfs and copied stuff back with cp -a. Checked that everything went back alright, ran lilo and booted.
Machine booted ok and everything seemed to be ok, but i noticed a few weird messages in boot messages right before mounting the root-partition:
FAT: bogus logical sector size 0
FAT: bogus logical sector size 0
Other reiserfs mounts didn't give this message. it doesn't seem serious but a little disturbing still.
Also, I noticed some weird interactions with the bttv-driver. I have a bt878 based tv-card.
The bttv module and all other modules it requires loaded without hickups, didn't see anything unusual in their log-messages, but as soon as i tried starting any program that uses the video-device, I got this message:
kernel: bttv: vmalloc_32(4259840) failed
As soon as i changed my root and /usr partitions back to ext2 the same way I changed to reiserfs before, these problems disappeared. Nothing else on my computer changed in between these filesystem changes. Any ideas on what might cause this?
E.
> FAT: bogus logical sector size 0
It is not a problem at all.
It happens if you compile fat in the Kernel and not as module. In this case
the fat-driver seems to check every partition for a fat-filesystem. When it
fails it gives you this message.
So you can
1. ignore these messages or
2. compile fat as a module.
greetings
Christian
Christian Borntr?ger wrote:
>>FAT: bogus logical sector size 0
>>
>
>It is not a problem at all.
>
>It happens if you compile fat in the Kernel and not as module. In this case
>the fat-driver seems to check every partition for a fat-filesystem. When it
>fails it gives you this message.
>
>So you can
>1. ignore these messages or
>2. compile fat as a module.
>
>greetings
>
>Christian
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
It is a user interface error by the FAT coder, a serious one actually,
because it affects partitions that are not FAT. Would be nice if it got
fixed.
Hans
On Nov 21, 2001 09:55 +0200, Eric M wrote:
> Machine booted ok and everything seemed to be ok, but i noticed a few
> weird messages in boot messages right before mounting the root-partition:
> FAT: bogus logical sector size 0
> FAT: bogus logical sector size 0
When the kernel is booting, it doesn't know the filesystem type of the
root fs, so it tries to mount the root device using all of the compiled-in
fs drivers, in the order they are listed in fs/Makefile.in.
It appears that the fat driver doesn't even check for a magic when it
starts trying to mount the filesystem, so it proceeds directly to
spewing errors. You get two such messages because it is trying both
msdos and vfat (which both use the fat driver underneath). You don't
see this with ext2 because it tries to mount before vfat/msdos.
This is a minor bug in the fat read_super() method, because when the
kernel is trying to mount the root fs, it passes the "silent" flag
to the filesystem, so it should not print any messages if it is not a
fat filesystem. If this wasn't the case, then you would get spew from
every filesystem it tried.
Note that reiserfs is guilty of this as well, since it prints out:
can't find a reiserfs filesystem on (dev 08:03, block 64, size 4096)
So a patch for that is attached (against 2.4.13, but I didn't see any
changes which would affect it).
This message is never normally seen, because currently reiserfs is
at the end of the search list for filesystems. I will also propose a
patch to move reiserfs earlier in the probe sequence, since it has
a well-defined magic, and is more commonly used than most others. I
only put it where it is to avoid context issues with my tree (which
has ext3 and jbd (an experimental filesystem interface for journal
devices) at the top.
Please feel free to re-submit these to Linus, I will not do so.
Cheers, Andreas
====================== reiserfs-2.4.13-silent.diff =======================
--- linux.orig/fs/reiserfs/super.c Thu Oct 25 03:05:11 2001
+++ linux/fs/reiserfs/super.c Wed Nov 21 11:01:57 2001
@@ -346,7 +356,8 @@
free, SB_FREE_BLOCKS (s));
}
-static int read_super_block (struct super_block * s, int size, int offset)
+static int read_super_block (struct super_block * s, int size, int offset,
+ int silent)
{
struct buffer_head * bh;
struct reiserfs_super_block * rs;
@@ -362,9 +373,10 @@
rs = (struct reiserfs_super_block *)bh->b_data;
if (!is_reiserfs_magic_string (rs)) {
- printk ("read_super_block: "
- "can't find a reiserfs filesystem on (dev %s, block %lu, size %d)\n",
- kdevname(s->s_dev), bh->b_blocknr, size);
+ if (!silent)
+ printk("read_super_block: can't find a reiserfs filesystem on "
+ "(dev %s, block %lu, size %d)\n",
+ kdevname(s->s_dev), bh->b_blocknr, size);
brelse (bh);
return 1;
}
@@ -393,11 +405,11 @@
rs = (struct reiserfs_super_block *)bh->b_data;
if (!is_reiserfs_magic_string (rs) ||
sb_blocksize(rs) != s->s_blocksize) {
- printk ("read_super_block: "
- "can't find a reiserfs filesystem on (dev %s, block %lu, size %d)\n",
- kdevname(s->s_dev), bh->b_blocknr, size);
+ if (!silent)
+ printk("read_super_block: can't find a reiserfs filesystem on "
+ "(dev %s, block %lu, size %d)\n",
+ kdevname(s->s_dev), bh->b_blocknr, size);
brelse (bh);
- printk ("read_super_block: can't find a reiserfs filesystem on dev %s.\n", kdevname(s->s_dev));
return 1;
}
/* must check to be sure we haven't pulled an old format super out
@@ -621,7 +633,7 @@
}
if (blocks) {
- printk("reserfs: resize option for remount only\n");
+ printk("reiserfs: resize option for remount only\n");
return NULL;
}
@@ -634,9 +646,9 @@
}
/* read block (64-th 1k block), which can contain reiserfs super block */
- if (read_super_block (s, size, REISERFS_DISK_OFFSET_IN_BYTES)) {
+ if (read_super_block (s, size, REISERFS_DISK_OFFSET_IN_BYTES, silent)) {
// try old format (undistributed bitmap, super block in 8-th 1k block of a device)
- if (read_super_block (s, size, REISERFS_OLD_DISK_OFFSET_IN_BYTES))
+ if (read_super_block(s, size, REISERFS_OLD_DISK_OFFSET_IN_BYTES,silent))
goto error;
else
old_format = 1;
====================== reiserfs-2.4.13-order.diff =======================
--- linux.orig/fs/Makefile Thu Oct 25 02:02:41 2001
+++ linux/fs/Makefile Wed Nov 21 10:51:11 2001
@@ -26,7 +26,10 @@
subdir-$(CONFIG_EXT2_FS) += ext2
subdir-$(CONFIG_CRAMFS) += cramfs
subdir-$(CONFIG_RAMFS) += ramfs
+subdir-$(CONFIG_REISERFS_FS) += reiserfs
subdir-$(CONFIG_CODA_FS) += coda
subdir-$(CONFIG_MINIX_FS) += minix
subdir-$(CONFIG_FAT_FS) += fat
@@ -60,7 +63,6 @@
subdir-$(CONFIG_AUTOFS_FS) += autofs
subdir-$(CONFIG_AUTOFS4_FS) += autofs4
subdir-$(CONFIG_ADFS_FS) += adfs
-subdir-$(CONFIG_REISERFS_FS) += reiserfs
subdir-$(CONFIG_DEVPTS_FS) += devpts
subdir-$(CONFIG_SUN_OPENPROMFS) += openpromfs
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
> > Machine booted ok and everything seemed to be ok, but i noticed a few
> > weird messages in boot messages right before mounting the root-partition:
> > FAT: bogus logical sector size 0
> > FAT: bogus logical sector size 0
> When the kernel is booting, it doesn't know the filesystem type of the
> root fs, so it tries to mount the root device using all of the compiled-in
> fs drivers, in the order they are listed in fs/Makefile.in.
> It appears that the fat driver doesn't even check for a magic when it
> starts trying to mount the filesystem, so it proceeds directly to
To be complete we should also apply this patch.
diff -urN linux/fs/fat/inode.c linux-new/fs/fat/inode.c
--- linux/fs/fat/inode.c Thu Oct 25 09:02:26 2001
+++ linux-new/fs/fat/inode.c Wed Nov 21 21:28:49 2001
@@ -609,7 +609,8 @@
CF_LE_W(get_unaligned((unsigned short *) &b->sector_size));
if (!logical_sector_size
|| (logical_sector_size & (logical_sector_size - 1))) {
- printk("FAT: bogus logical sector size %d\n",
+ if (!silent)
+ printk("FAT: bogus logical sector size %d\n",
logical_sector_size);
brelse(bh);
goto out_invalid;
@@ -618,7 +619,8 @@
sbi->cluster_size = b->cluster_size;
if (!sbi->cluster_size
|| (sbi->cluster_size & (sbi->cluster_size - 1))) {
- printk("FAT: bogus cluster size %d\n", sbi->cluster_size);
+ if (!silent)
+ printk("FAT: bogus cluster size %d\n", sbi->cluster_size);
brelse(bh);
goto out_invalid;
}
Christian Borntr?ger wrote:
>>>Machine booted ok and everything seemed to be ok, but i noticed a few
>>>weird messages in boot messages right before mounting the root-partition:
>>>FAT: bogus logical sector size 0
>>>FAT: bogus logical sector size 0
>>>
>>When the kernel is booting, it doesn't know the filesystem type of the
>>root fs, so it tries to mount the root device using all of the compiled-in
>>fs drivers, in the order they are listed in fs/Makefile.in.
>>It appears that the fat driver doesn't even check for a magic when it
>>starts trying to mount the filesystem, so it proceeds directly to
>>
>
>To be complete we should also apply this patch.
>
>diff -urN linux/fs/fat/inode.c linux-new/fs/fat/inode.c
>--- linux/fs/fat/inode.c Thu Oct 25 09:02:26 2001
>+++ linux-new/fs/fat/inode.c Wed Nov 21 21:28:49 2001
>@@ -609,7 +609,8 @@
> CF_LE_W(get_unaligned((unsigned short *) &b->sector_size));
> if (!logical_sector_size
> || (logical_sector_size & (logical_sector_size - 1))) {
>- printk("FAT: bogus logical sector size %d\n",
>+ if (!silent)
>+ printk("FAT: bogus logical sector size %d\n",
> logical_sector_size);
> brelse(bh);
> goto out_invalid;
>@@ -618,7 +619,8 @@
> sbi->cluster_size = b->cluster_size;
> if (!sbi->cluster_size
> || (sbi->cluster_size & (sbi->cluster_size - 1))) {
>- printk("FAT: bogus cluster size %d\n", sbi->cluster_size);
>+ if (!silent)
>+ printk("FAT: bogus cluster size %d\n", sbi->cluster_size);
> brelse(bh);
> goto out_invalid;
> }
>
>
How about putting fat last in the list, and having it say something more
like "FAT: bogus cluster size, perhaps XXX is not a FAT partition"
In article <[email protected]> [email protected] wrote:
| > > Machine booted ok and everything seemed to be ok, but i noticed a few
| > > weird messages in boot messages right before mounting the root-partition:
| > > FAT: bogus logical sector size 0
| > > FAT: bogus logical sector size 0
| > When the kernel is booting, it doesn't know the filesystem type of the
| > root fs, so it tries to mount the root device using all of the compiled-in
| > fs drivers, in the order they are listed in fs/Makefile.in.
| > It appears that the fat driver doesn't even check for a magic when it
| > starts trying to mount the filesystem, so it proceeds directly to
|
| To be complete we should also apply this patch.
To be totally honest I think this is the wrong way to go. Like masking
the symptoms instead of treating the disease. The problem is that the
FAT driver seems to not check f/s type before claiming a f/s as its own.
The better solution is to put in a check before going forward with using
the f/s as FAT.
--
bill davidsen <[email protected]>
His first management concern is not solving the problem, but covering
his ass. If he lived in the middle ages he'd wear his codpiece backward.
[email protected] (bill davidsen) writes:
> In article <[email protected]> [email protected] wrote:
> | > > Machine booted ok and everything seemed to be ok, but i noticed a few
> | > > weird messages in boot messages right before mounting the root-partition:
> | > > FAT: bogus logical sector size 0
> | > > FAT: bogus logical sector size 0
> | > When the kernel is booting, it doesn't know the filesystem type of the
> | > root fs, so it tries to mount the root device using all of the compiled-in
> | > fs drivers, in the order they are listed in fs/Makefile.in.
> | > It appears that the fat driver doesn't even check for a magic when it
> | > starts trying to mount the filesystem, so it proceeds directly to
> |
> | To be complete we should also apply this patch.
>
> To be totally honest I think this is the wrong way to go. Like masking
> the symptoms instead of treating the disease. The problem is that the
> FAT driver seems to not check f/s type before claiming a f/s as its own.
> The better solution is to put in a check before going forward with using
> the f/s as FAT.
FAT doesn't have the field like the magic number, AFAIK.
--
OGAWA Hirofumi <[email protected]>
On 27 Nov 2001, OGAWA Hirofumi wrote:
> [email protected] (bill davidsen) writes:
>
> > In article <[email protected]> [email protected] wrote:
> > | > > Machine booted ok and everything seemed to be ok, but i noticed a few
> > | > > weird messages in boot messages right before mounting the root-partition:
> > | > > FAT: bogus logical sector size 0
> > | > > FAT: bogus logical sector size 0
> > | > When the kernel is booting, it doesn't know the filesystem type of the
> > | > root fs, so it tries to mount the root device using all of the compiled-in
> > | > fs drivers, in the order they are listed in fs/Makefile.in.
> > | > It appears that the fat driver doesn't even check for a magic when it
> > | > starts trying to mount the filesystem, so it proceeds directly to
> > |
> > | To be complete we should also apply this patch.
> >
> > To be totally honest I think this is the wrong way to go. Like masking
> > the symptoms instead of treating the disease. The problem is that the
> > FAT driver seems to not check f/s type before claiming a f/s as its own.
> > The better solution is to put in a check before going forward with using
> > the f/s as FAT.
>
> FAT doesn't have the field like the magic number, AFAIK.
Actually the original poster used "magic" and I didn't quibble, but I
believe you're right. I just noted that it is better to check to see if
the filesystem is FAT before reporting the error message. Obviously this
can be done, since you don't get the message with FAT as a module, I just
haven't looked to see if the check is in the module or the kernel before
even loading the FAT module.
Thanks for noting that, in any case.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Bill Davidsen <[email protected]> writes:
> On 27 Nov 2001, OGAWA Hirofumi wrote:
>
> > [email protected] (bill davidsen) writes:
>
> Actually the original poster used "magic" and I didn't quibble, but I
> believe you're right. I just noted that it is better to check to see if
> the filesystem is FAT before reporting the error message. Obviously this
> can be done, since you don't get the message with FAT as a module, I just
> haven't looked to see if the check is in the module or the kernel before
> even loading the FAT module.
Yes. You can't use the module before you mounted the root filesystem.
This is a reason for not seeing an error message.
--
OGAWA Hirofumi <[email protected]>
Modular or monolithic, the bogus messages are the same.
>Yes. You can't use the module before you mounted the root filesystem.
>This is a reason for not seeing an error message.
>
David Ford <[email protected]> writes:
> Modular or monolithic, the bogus messages are the same.
Sorry, I'm incorrect. If you use a stuff like initrd, it is same message.
--
OGAWA Hirofumi <[email protected]>
On Tue, 27 Nov 2001, OGAWA Hirofumi wrote:
> Bill Davidsen <[email protected]> writes:
>
> > On 27 Nov 2001, OGAWA Hirofumi wrote:
> >
> > > [email protected] (bill davidsen) writes:
> >
> > Actually the original poster used "magic" and I didn't quibble, but I
> > believe you're right. I just noted that it is better to check to see if
> > the filesystem is FAT before reporting the error message. Obviously this
> > can be done, since you don't get the message with FAT as a module, I just
> > haven't looked to see if the check is in the module or the kernel before
> > even loading the FAT module.
>
> Yes. You can't use the module before you mounted the root filesystem.
> This is a reason for not seeing an error message.
What? Of course you can! That's what initd files are for ;-)
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.