Bug 76283 - When /boot is on /dev/hdb, / on /dev/hdb5 is not mounted read only (ro)
Summary: When /boot is on /dev/hdb, / on /dev/hdb5 is not mounted read only (ro)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-19 04:21 UTC by Nick Simicich
Modified: 2008-08-01 16:22 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 15:40:05 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Nick Simicich 2002-10-19 04:21:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461; .NET 
CLR 1.0.3705)

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
        root (hd1,1)
        kernel /vmlinuz-2.4.9-34 ro root=/dev/hdb5 hdd=ide-scsi
        initrd /initrd-2.4.9-34.img

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):

How reproducible:

Steps to Reproduce:
1. move /boot to /dev/hdb2 and fix /etc/fstab
2. grub-install /dev/hda
3. reboot

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

Additional info:

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.

Comment 1 Jeremy Katz 2002-10-19 05:33:40 UTC
If the kernel is getting passed the ro argument, then it's not a grub bug

Comment 2 Arjan van de Ven 2002-10-19 08:44:22 UTC
I wonder if your old dir is hardcoded in the initrd ?

Comment 3 Nick Simicich 2002-10-20 00:46:20 UTC
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
[root@parrot boot]#

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.

Comment 4 Nick Simicich 2002-10-20 02:02:07 UTC
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 
by grub.

Comment 5 Arjan van de Ven 2002-10-20 09:20:24 UTC
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

Comment 6 Nick Simicich 2002-10-21 04:24:49 UTC
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"
insmod /lib/jbd.o
echo "Loading ext3 module"
insmod /lib/ext3.o
mount -t proc /proc /proc
echo Mounting /proc filesystem
echo Creating root device
mkrootdev /dev/root
echo 0x0100 > /proc/sys/kernel/real-root-dev
umount /proc
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 
02:12 /mnt/initrd/lib
    12   71 -rw-r--r--   1 root     root        71198 Jun  1 
06:32 /mnt/initrd/lib/jbd.o
    13   91 -rw-r--r--   1 root     root        91716 Jun  1 
06:32 /mnt/initrd/lib/ext3.o
    14    1 drwxr-xr-x   2 root     root         1024 Jul 10 
02:12 /mnt/initrd/bin
    15    9 -rwxr-xr-x   1 root     root         8968 Jul 10 
02:12 /mnt/initrd/bin/nash
    16  538 -rwxr-xr-x   1 root     root       546472 Jul 10 
02:12 /mnt/initrd/bin/insmod
    17    1 drwxr-xr-x   2 root     root         1024 Jul 10 
02:12 /mnt/initrd/sbin
    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 
02:12 /mnt/initrd/etc
    21    1 drwxr-xr-x   2 root     root         1024 Jul 10 
02:12 /mnt/initrd/dev
    22    0 crw-r--r--   1 root     root              Jul 10 
02:12 /mnt/initrd/dev/console
    23    0 crw-r--r--   1 root     root              Jul 10 
02:12 /mnt/initrd/dev/null
    24    0 brw-r--r--   1 root     root              Jul 10 
02:12 /mnt/initrd/dev/ram
    25    0 crw-r--r--   1 root     root              Jul 10 
02:12 /mnt/initrd/dev/systty
    26    0 crw-r--r--   1 root     root              Jul 10 
02:12 /mnt/initrd/dev/tty1
    27    0 crw-r--r--   1 root     root              Jul 10 
02:12 /mnt/initrd/dev/tty2
    28    0 crw-r--r--   1 root     root              Jul 10 
02:12 /mnt/initrd/dev/tty3
    29    0 crw-r--r--   1 root     root              Jul 10 
02:12 /mnt/initrd/dev/tty4
    30    1 drwxr-xr-x   2 root     root         1024 Jul 10 
02:12 /mnt/initrd/loopfs
    31    1 drwxr-xr-x   2 root     root         1024 Jul 10 
02:12 /mnt/initrd/proc
    32    1 drwxr-xr-x   2 root     root         1024 Jul 10 
02:12 /mnt/initrd/sysroot
    33    1 -rwxr-xr-x   1 root     root          370 Jul 10 
02:12 /mnt/initrd/linuxrc
[root@parrot root]# ls -l /mnt/initrd/dev/
total 0
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
[root@parrot root]#

Comment 7 Nick Simicich 2002-10-21 04:31:11 UTC
One more bit of output.

[root@parrot root]# md5sum $( find /mnt/initrd/ -type f )
92ec20b6c8c97f7d8f2a0b9bd37fabf9  /mnt/initrd/lib/jbd.o
6f66c53e4b82d21c170d71b2833df2ff  /mnt/initrd/lib/ext3.o
11323d7d2d580e8b062ee4a6b8ee82a5  /mnt/initrd/bin/nash
1513720a2217ab19d6a443f76b7b7337  /mnt/initrd/bin/insmod
d3a837fe92f96621196cf0183c19a157  /mnt/initrd/linuxrc
[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
[root@parrot root]#

Comment 8 Bugzilla owner 2004-09-30 15:40:05 UTC
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/

Note You need to log in before you can comment on or make changes to this bug.