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: Always 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 rw. 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- ROMs. 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 hd0,1. 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 g [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 __archdata [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.
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 ext3. 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.
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 #!/bin/nash 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]#
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]#
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 persists. 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/