From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461; .NET
Description of problem:
/boot was /dev/hdb2, / was /dev/hdb5. The grub loader was installed in /dev/hda
(master boot record). The grub stanza was:
title Red Hat Linux (2.4.9-34) /dev/hdb
kernel /vmlinuz-2.4.9-34 ro root=/dev/hdb5 hdd=ide-scsi
But, regardless of that, the /dev/hdb5 was initially mounted as rw, and the
file system check failed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. move /boot to /dev/hdb2 and fix /etc/fstab
2. grub-install /dev/hda
The boot will fail because the / filesystem is mounted rw.
Actual Results: The boot failed because / cannot be checked when it is mounted
Expected Results: / should have been mounted ro as specified in the grub
kernel command line and reported in
Kernel command line: ro root=/dev/hdb5 hdd=ide-scsi
The system is a Compaq Pentium III. It had one hard drive and a couple of CD-
The bios reported an "error 4" on the hard drive and I got a hardware error
when I tried to start quotas or run fsck, but normal daily operations worked
fine. I ordered a replacement drive under warranty, and a new second drive.
I installed the second drive as a slave (hdb) and booted to single user mode.
Then I allocated new partitions on the hdb drive, and copied all data,
partition by partition, filesystem by filesystem, using rsync. I made the swap
partition as well.
I fixed the /etc/fstab to use the device numbers instead of labels, and to
use /dev/hdbn for all of the mounts and for the swap space.
I then booted from a diskette that was set up to point to a root on /dev/hdb5,
with all filesystems used on the second drive. After running that way for a
few days, I zeroed out the first drive (before it was uninstalled).
A new hard drive was installed as the master, diagnostics were run (which now
passed) and the system was booted from diskette into single user mode.
The /boot/grub/grub.conf file was fixed to properly reference hd1,1 for /boot
and everything in it. The root clause in the kernel staza was fixed to use the
right device name (/dev/hdb5).
Everything worked, splash screen, choices, loaded the kernel, found the
root....except that the system would not mount the filesystem ro. The ro
parameter *was* in the command line reported by the kernel, as noted above.
After trying a number of fruitless things, I determined to move /boot to my new
hard drive, /dev/hda.
1. I allocated a partition for /boot, /dev/hda2. Like all of the other /boots,
it was under cylinder 1024.
2. I did a mke2fs -j on this new partition.
3. I mounted it on /mnt and moved all the data with rsync.
4. I fixed the /etc/fstab
5. I umounted /mnt, and I umounted and mounted /boot. I verified that this
was the /boot on /dev/hda2.
6. I did a grub-install. I also manually edited grub.conf to change hd1,1 to
7. I booted. With this now twice-copied data, the system booted and mounted /
as read-only, as it is supposed to. Then it remounted it as ext3, properly.
rpm -q -s grub shows an intact grub.
I consider this to be a severe problem. I never lost data because I always
shut down properly. Someone recovering after a disaster who had moved a disk,
say, to the second drive of a different system might end up losing their
recovery log because the mount was rw instead of ro. And there would be little
that they could do about it.
Again, to summarize: /boot on /dev/hdb2 and / on /dev/hdb5 is mounted rw
despite instructions to the kernel to mount it ro.
/boot on /dev/hda2 and / on /dev/hdb5 and the same instructions except for
minor differences to reference the new drive from grub, and / is mounted ro as
it must be for proper boot action.
If the kernel is getting passed the ro argument, then it's not a grub bug
I wonder if your old dir is hardcoded in the initrd ?
I am using the standard initrd - it was the one that came with the up2date and
the last kernel (again updated yesterday). As to the possibility that it
mentions any file system on hda:
[root@parrot boot]# gunzip < /boot/initrd-2.4.9-34.img > /tmp/initrd-2.4.9-34.im
[root@parrot boot]# mount -r /tmp/initrd-2.4.9-34.img /mnt -t ext2 -o loop
[root@parrot boot]# find /mnt -type f | xargs grep hda
Binary file /mnt/bin/insmod matches
[root@parrot boot]# strings /mnt/bin/insmod | grep hda
So the only file in the init that matches the string hda is the insmod command,
and that match has nothing to do with /dev/hda2.
I am willing to try and attach the kernel and initrd that I was using when I
noted this bug. Since then I have done another up2date and a new kernel was
installed. I have not verified that this bug still exists....I hate to test
because of the possibility of data loss on a live system, but I will if you
think it is warranted.
Hmmm...another issue is that when I checked /proc/mounts when dropped into the
recovery shell after entering the password, the / filesystem was mounted as
ext2.. If the linuxrc in the initrd had run the mount command is specified as:
mount --ro -t ext3 /dev/root /sysroot
meaning that there should be no possible way for the mount to be done rw, no
matter what the kernel's mounting procedure. Also, if the jbd.o and ext3.o
modules had been loaded out of the initrd as specified earlier in linuxrc, then
the filesystem should have been ext3 mounted, not ext2 mounted.
I suspect that there are two actual failures here:
1. That the ro in the kernel parameter line is being ignored -- that is a
kernel failure, but that is not the important failure here.
2. That the initrd is not being set up properly by grub - if grub had setup
the initrd properly, the ro parameter would have been ignored..and that is the
first and foremost problem, because it also causes / to be mounted as ext2 not
So I really think that this is a grub problem, first and foremost, because,
given that there is no reference to the kernel parameter line out of linuxrc in
a normal boot procedure, and given that there is no way for the root to be
mounted rw out of the linuxrc, I can only assume that the initrd is not set up
the initrd is created at install time of the kernel to match your system.
The only interesting bit will be the linuxrc script from the initrd, if you
could attach that it might be useful
OK. I will throw in a find to show what files are in it as well. I will also
ls -l the dev directory that is in the initrd. But I really do not think that
this stuff was getting executed or referenced, because the / filesystem was
being mounted ext2, not ext3, and rw, not ro.
[root@parrot root]# cat /mnt/initrd/linuxrc
echo "Loading jbd module"
echo "Loading ext3 module"
mount -t proc /proc /proc
echo Mounting /proc filesystem
echo Creating root device
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount --ro -t ext3 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
[root@parrot root]# find /mnt/initrd -ls
2 1 drwxr-xr-x 10 root root 1024 Jul 10 02:12 /mnt/initrd
11 1 drwxr-xr-x 2 root root 1024 Jul 10
12 71 -rw-r--r-- 1 root root 71198 Jun 1
13 91 -rw-r--r-- 1 root root 91716 Jun 1
14 1 drwxr-xr-x 2 root root 1024 Jul 10
15 9 -rwxr-xr-x 1 root root 8968 Jul 10
16 538 -rwxr-xr-x 1 root root 546472 Jul 10
17 1 drwxr-xr-x 2 root root 1024 Jul 10
18 0 lrwxrwxrwx 1 root root 3 Jul 10
02:12 /mnt/initrd/sbin/bin -> bin
19 0 lrwxrwxrwx 1 root root 9 Jul 10
02:12 /mnt/initrd/sbin/modprobe -> /bin/nash
20 1 drwxr-xr-x 2 root root 1024 Jul 10
21 1 drwxr-xr-x 2 root root 1024 Jul 10
22 0 crw-r--r-- 1 root root Jul 10
23 0 crw-r--r-- 1 root root Jul 10
24 0 brw-r--r-- 1 root root Jul 10
25 0 crw-r--r-- 1 root root Jul 10
26 0 crw-r--r-- 1 root root Jul 10
27 0 crw-r--r-- 1 root root Jul 10
28 0 crw-r--r-- 1 root root Jul 10
29 0 crw-r--r-- 1 root root Jul 10
30 1 drwxr-xr-x 2 root root 1024 Jul 10
31 1 drwxr-xr-x 2 root root 1024 Jul 10
32 1 drwxr-xr-x 2 root root 1024 Jul 10
33 1 -rwxr-xr-x 1 root root 370 Jul 10
[root@parrot root]# ls -l /mnt/initrd/dev/
crw-r--r-- 1 root root 5, 1 Jul 10 02:12 console
crw-r--r-- 1 root root 1, 3 Jul 10 02:12 null
brw-r--r-- 1 root root 1, 1 Jul 10 02:12 ram
crw-r--r-- 1 root root 4, 0 Jul 10 02:12 systty
crw-r--r-- 1 root root 4, 1 Jul 10 02:12 tty1
crw-r--r-- 1 root root 4, 2 Jul 10 02:12 tty2
crw-r--r-- 1 root root 4, 3 Jul 10 02:12 tty3
crw-r--r-- 1 root root 4, 4 Jul 10 02:12 tty4
One more bit of output.
[root@parrot root]# md5sum $( find /mnt/initrd/ -type f )
[root@parrot root]# cksum $( find /mnt/initrd/ -type f )
1153928805 71198 /mnt/initrd/lib/jbd.o
3736353880 91716 /mnt/initrd/lib/ext3.o
1769847438 8968 /mnt/initrd/bin/nash
507501753 546472 /mnt/initrd/bin/insmod
419252372 370 /mnt/initrd/linuxrc
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/