loading the wrong FS during boot
 

[Running Debian unstable 2.6.5]
I'm trying to figure out what's going on during my bootup. Here's a part of my system log:

hda: TOSHIBA MK6021GAS, ATA DISK drive
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: UJDA745 DVD/CDRW, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 117210240 sectors (60011 MB), CHS=65535/16/63, UDMA(100)
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 >
VFS: Can't find ext3 filesystem on dev hda7.
VFS: Can't find ext2 filesystem on dev hda7.
Unable to identify CD-ROM format.
found reiserfs format "3.6" with standard journal
Reiserfs journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
reiserfs: checking transaction log (hda7) for (hda7)
Using r5 hash to sort names
VFS: Can't find ext3 filesystem on dev hda7.
VFS: Can't find ext2 filesystem on dev hda7.
Unable to identify CD-ROM format.
found reiserfs format "3.6" with standard journal
Reiserfs journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
reiserfs: checking transaction log (hda7) for (hda7)

As you can see, the kernel eventually figures out that hda7 is reiserFS. What I'm trying to figure out is why it thinks otherwise. Additionally, I always seem to have 7 cdrom directories placed under / even if I delete them.

I'm getting the feeling that this is the result of an installation gone slightly awry. So far, the machine works (but gives the wacky error messages above) when using a 2.6 or a 2.4 stock kernel from Debian, but when I load up my own compiled kernel, it keels over on boot, saying that the FS on hda7 is wrong.

I've looked at /etc/fstab, and it looks right. I checked my partition table just to be sure, and it too says that hda7 is reiser.

What's going on here, and how do I fix it?

"I've looked at /etc/fstab, and it looks right. I checked my partition table just to be sure, and it too says that hda7 is reiser."

What directory is /dev/hda7 mounted on? Maybe the problem is occuring before the kernel processes /etc/fstab. Could you post your entire /etc/fstab?

Another thing to check is that there may be inconsistencies in the /dev/hda7 superblock. You can check this by booting a rescue CD and running these commands:
umount /dev/hda7 (Just in case the rescue CD mounts /dev/hda7.)
fsck -t reiserfs /dev/hda7

___________________________________
Be prepared. Create a LifeBoat CD.
http://users.rcn.com/srstites/LifeB....home.page.html

Steve Stites

It rather looks like mount fithout filesystem specified - then all known are tried. What's hda7? Is it your / or it's a partition mounted later?

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/hda7 / reiserfs defaults 0 1
/dev/hda6 none swap sw 0 0
/dev/hda2 /mnt/windows-c ntfs nls=iso8859-1,iocharset=iso8859-15,ro,umask=0002,umask=0,gid=users,users 0 0
/dev/hda5 /mnt/windows-d ntfs nls=iso8859-1,iocharset=iso8859-15,ro,umask=0002,umask=0,gid=users,users 0 0
#/dev/floppy/0 /floppy auto rw,user,noauto 0 0
/dev/hdc /cdrom auto ro,user,noauto 0 0
proc /proc proc defaults 0 0

There's my fstab.

$ cat /etc/mtab
/dev/hda7 / reiserfs rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw 0 0
/dev/hda2 /mnt/windows-c ntfs ro,noexec,nosuid,nodev,nls=iso8859-1,iocharset=iso8859-15,umask=0002,umask=0,gid=100 0 0
/dev/hda5 /mnt/windows-d ntfs ro,noexec,nosuid,nodev,nls=iso8859-1,iocharset=iso8859-15,umask=0002,umask=0,gid=100 0 0
usbfs /proc/bus/usb usbfs rw 0 0

There's the mtab.

Mara, how would I go about specifying what kind of filesystem my root partition is? Is that something I take care of in my bootloader (currently grub)? Isn't that what fstab is for?

[edit]

Here's /boot/grub/menu.lst:

$ cat menu.lst
# menu.lst - See: grub(8), info grub, update-grub(8)
# grub-install(8), grub-floppy(8),
# grub-md5-crypt, /usr/share/doc/grub
# and /usr/share/doc/grub-doc/.

[snip]

title Debian GNU/Linux, kernel 2.6.5-1-686
root (hd0,6)
kernel /boot/vmlinuz-2.6.5-1-686 root=/dev/hda7 ro
initrd /boot/initrd.img-2.6.5-1-686
savedefault
boot

title Debian GNU/Linux, kernel 2.6.5-1-686 (recovery mode)
root (hd0,6)
kernel /boot/vmlinuz-2.6.5-1-686 root=/dev/hda7 ro single
initrd /boot/initrd.img-2.6.5-1-686
savedefault
boot

title Debian GNU/Linux, kernel 2.6.3
root (hd0,6)
kernel /boot/vmlinuz-2.6.3 root=/dev/hda7 ro
initrd /boot/initrd.img-2.6.3
savedefault
boot

title Debian GNU/Linux, kernel 2.6.3 (recovery mode)
root (hd0,6)
kernel /boot/vmlinuz-2.6.3 root=/dev/hda7 ro single
initrd /boot/initrd.img-2.6.3
savedefault
boot

title Debian GNU/Linux, kernel 2.4.22-1-386
root (hd0,6)
kernel /boot/vmlinuz-2.4.22-1-386 root=/dev/hda7 ro
initrd /boot/initrd.img-2.4.22-1-386
savedefault
boot

title Debian GNU/Linux, kernel 2.4.22-1-386 (recovery mode)
root (hd0,6)
kernel /boot/vmlinuz-2.4.22-1-386 root=/dev/hda7 ro single
initrd /boot/initrd.img-2.4.22-1-386
savedefault
boot

### END DEBIAN AUTOMAGIC KERNELS LIST

title Windows XP
root (hd2,0)
makeactive
chainloader +1


Also, for reference's sake, I'm interested in what initrd does - my 2.6.3 kernel was missing one in it's menu.lst entry, so I used mkinitrd to make one, but I'm still not so clear on what it does.

Thanks for the help!

"Also, for reference's sake, I'm interested in what initrd does - my 2.6.3 kernel was missing one in it's menu.lst entry, so I used mkinitrd to make one, but I'm still not so clear on what it does."

initrd loads all loadable modules that are necessary for the bootable kernel to run. Since / is a reiserfs then the reiserfs driver must be loaded by initrd. Later the kernel goes through /etc/fstab and mounts everything.

So, as Mara says, your problem appears to be that when you boot it takes several tries before /dev/hda7 is recognized as being reiserfs. By the time you get through /etc/fstab the problem seems to be resolved OK, as you state in your first post. mtab correctly shows /dev/hda7 as a reiserfs.

So, I suggest that you use fsck to check the /dev/hda7 superblock to see if there is something garbled in the first superblock to where the kernel has to make several attempts before it recognizes / as being a reiserfs. This may not be the problem but it is certainly a possibility. If the first superblock is garbled then the solution is to either live with the problem or reformat the file system.

___________________________________
Be prepared. Create a LifeBoat CD.
http://users.rcn.com/srstites/LifeB....home.page.html

Steve Stites

Considering that I compiled reiserFS into the kernel, I suppose there isn't a need for initrd then...

I'm going to try the fsck stuff now. Here goes...

"Considering that I compiled reiserFS into the kernel, I suppose there isn't a need for initrd then..."

If reiserfs is compiled into the kernel and you are loading it a second time with initrd that could be the source of the kernel confusion.

___________________________________
Be prepared. Create a LifeBoat CD.
http://users.rcn.com/srstites/LifeB....home.page.html

Steve Stites

I've fsck'ed /dev/hda7 and there's been no corruptions found. However, on boot (before the system logger is started, so I can't see it in dmesg), I see something about a filesystem's master boot block or something being corrupted.

I'm going to try and pause the screen when it boots (ctrl-s ?)

PS - Sorry, I should have mentioned this before:

I have two kernels that I'm (trying) to use. The 2.6.5 is a Debian stock kernel. It works, and has reiserfs as a module. The 2.6.3 is compiled by me, and has reiserfs compiled in. However, the 2.6.3 doesn't load. The error message I get from it is:

VFS: Cannot open root device "hda7" or unknown-block(0,0)
Please append a correct "root=" boot option.
Kernel Panic:
VFS: Unable to mount root fs on unknown-block(0,0)

While figuring out why my custom kernel won't boot, isn't my main problem, could it be a clue into figuring out why I'm getting the original problem of /dev/hda7 being mounted as "auto" somewhere?

The weirdness continues...

Here's a hand-typed version of what I got out of using ctrl+s and ctrl+q to start and stop the boot sequence:

[name of Debian kernel]
root (hd0, 6)
Filesystem type is resierfs, partion type 0x83
kernel /boot/vmlinuz-2.6.5-1-686 root=/dev/hda7 ro

[snip]

(It repeats the following three times at one point, with a few things going on inbetween repeats)

hda: 117210240 sectors
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 <p5 p6 p7>

VFS: Can't find ext3 filesystem on dev hda7

mount: wrong fs type, bad option, bad superblock on /dev2/root2, or too many mounted file systems.

VFS: Can't find ext2 filesystem on dev hda7

mount: wrong fs type, bad option, bad superblock on /dev2/root2, or too many mounted file systems.

Unable to identify CD-ROM format

mount: wrong fs type, bad option, bad superblock on /dev2/root2, or too many mounted file systems.

found reiserfs format "3.6" with standard journal

[snip]

(begins the other two repeats)

[snip]

Loading /etc/console/boottime.kmap.gz

Activating swap

[snip]

fsck (fsck stuff)

[AReiser super block (reiser stuff)

Filesystem marked as clearly umounted

Filesystem seems mounted read-only. Skipping journal replay
Checking internal tree..finished

[Does clock stuff]

[Loads all modules ok]

Creating device-mapper devices...done

Checking all filesystems...
...done

Mounting local filesystems

[NTFS stuff]


************************

Phew. Ok, so now I can see that it tries three times to load ext3, ext2, cdrom fs, and then finally finds the reiser. It's weird that it does this three times. It's also weird that grub detects the filesystem properly (see the output at the very beginning) and yet I get what looks like an auto-detection routine going on.

"While figuring out why my custom kernel won't boot, isn't my main problem, could it be a clue into figuring out why I'm getting the original problem of /dev/hda7 being mounted as "auto" somewhere?"

"title Debian GNU/Linux, kernel 2.6.3
root (hd0,6)
kernel /boot/vmlinuz-2.6.3 root=/dev/hda7 ro
initrd /boot/initrd.img-2.6.3
savedefault
boot"

On kernel 2.6.3 you have reiserfs compiled into the kernel and you are also using an initrd. reiserfs isn't necessarily the only thing loaded by initrd. I think that you should review what is being loaded by 2.6.3 initrd and fix it if necessary. initrd problems may be why 2.6.3 and 2.6.5 react differently to whatever the original problem is. But I do not think that initrd is a problem in 2.6.5 so I doubt that initrd is the original problem.

"on boot (before the system logger is started, so I can't see it in dmesg), I see something about a filesystem's master boot block or something being corrupted."

"VFS: Cannot open root device "hda7" or unknown-block(0,0)"

It is plausible that both kernels are hitting the same filesystem error on /dev/hda7 and giving different error messages because they hit the problem at different points in their logic due to the reiserfs driver being loaded differently in the two kernels.

If this is the original problem for both kernels and fsck run from a rescue CD will not fix it then the only way that I know to fix it is to reformat /dev/hda7 (after saving your data someplace).

___________________________________
Be prepared. Create a LifeBoat CD.
http://users.rcn.com/srstites/LifeB....home.page.html

Steve Stites

Sounds good to me. I could use the practice of another install.

Thanks Steve.

"Phew. Ok, so now I can see that it tries three times to load ext3, ext2, cdrom fs, and then finally finds the reiser. It's weird that it does this three times. It's also weird that grub detects the filesystem properly (see the output at the very beginning) and yet I get what looks like an auto-detection routine going on."

Yes. Grub detects /dev/hd7 as reiserfs OK. The /etc/fstab mounts happen late enough in the boot sequence that they appear in dmesg. So the confusion comes either in initrd or in the kernel boot before logging starts. In the portion that you snipped is there anything that tells you whether initrd completed before or after the weirdness starts?

I don't understand what /dev2/root2 is.

___________________________________
Be prepared. Create a LifeBoat CD.
http://users.rcn.com/srstites/LifeB....home.page.html

Steve Stites

I'm pretty sure that the problem is before the initrd.

I've tried to boot with the 2.6.3 kernel without the initrd, and get the same error message as when I did have an initrd:

VFS: Cannot open root device "hda7" or unknown-block(0,0)
Please append a correct "root=" boot option.

[edit]

As for /dev2/root2 business... I haven't a clue what it is either. I've got a feeling that it may be leftovers from an install with a Debian cd. I've been googling it for a while now, and haven't found anything useful apart from it possibly being linked to having a 2.6 kernel.

[/edit]