On Wednesday 03 March 2004 02:11, Chris Evans wrote: > I'm splitting my response to this post into two. I'm sure that > someone out there who knows about mount and /proc/mounts can clarify > this bit: > > On 3 Mar 2004 at 12:24, Neil Brown wrote: > > On Wednesday March 3, [EMAIL PROTECTED] wrote: > > > Aha, didn't know that wrinkle: lovely. Mount says: > > > /dev/md0 on / type ext3 (rw,errors=remount-ro) > > > proc on /proc type proc (rw) > > > devpts on /dev/pts type devpts (rw,gid=5,mode=620) > > > > > > and cat /proc/mounts says: > > > rootfs / rootfs rw 0 0 > > > /dev/root / ext2 rw 0 0 > > > proc /proc proc rw 0 0 > > > devpts /dev/pts devpts rw 0 0 > > > > > > Does that "/dev/root" bit indicate anything useful? > > > > No, but the fact that root is actually 'ext2' even though mount (and > > presumably fstab) thinks it is ext3 is a bit suspicious. > > I suppose that might be because the difference between ext2 and ext3, > as I understand it, is just a journalling block reserved at the end > of the normal ext2 space so perhaps /proc/mounts indicates all ext3 > as ext2? > > From a quick bit of googling, I understand that /dev/root is a label > for the root mount point that's passed to the kernel as it loads, in > my case, I assume that's passed to the kernel from whatever lilo has > done to the mbr and that this ensures that the kernel then holds that > mount open (presumably in case it needs to write something back there > when it quits ... or perhaps it always writes something back there in > a clean dismount ... I don't know). > > Can someone: > a) confirm or deny my hunch that the ext2/ext3 issue is normal?
Based on my own experience, it is not normal. Here's my situation: # cat /proc/mounts /dev/root / ext3 rw 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw 0 0 /dev/md0 /boot ext3 rw 0 0 Here's my mount output, for good measure: # mount /dev/md1 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/md0 on /boot type ext3 (rw) > b) clarify the way that lilo and the kernel interact? > I will have to leave this to someone else more knowledgable. > I wonder if it's pertinent that /proc/partitions shows this: > > cat /proc/partitions > major minor #blocks name > 9 0 78124928 md0 > 22 0 80043264 hdc > 22 1 78125008 hdc1 > 3 64 80043264 hdb > 3 65 80035798 hdb1 > No, that seems normal. I get basically the same thing: # cat /proc/partitions major minor #blocks name 9 0 15936 md0 9 1 7903872 md1 22 0 9965592 hdc 22 1 16033 hdc1 22 2 1 hdc2 22 5 1542208 hdc5 22 6 7903948 hdc6 22 7 497983 hdc7 3 0 8420832 hda 3 1 1 hda1 3 2 16033 hda2 3 5 7903948 hda5 3 6 497983 hda6 > cfdisk /dev/hdb shows a single primary bootable partition occupying > the entire drive of Linux raid autodetect type. For /dev/hdc I have > a single primary bootable partition of the same type and some free > space (to ensure that there'd be enough room on /dev/hdb1 to add it > to the array). > That should be fine. The two critical items are that each partition that is to contain /boot, whether as part of an array or not, needs to be marked bootable. And, of course, all your partitions that you want in the raid must be marked Linux Raid Autodetect. > Thanks, > > Chris > PSYCTC: Psychotherapy, Psychology, Psychiatry, Counselling > and Therapeutic Communities; practice, research, > teaching and consultancy. > Chris Evans & Jo-anne Carlyle > http://psyctc.org/ Email: [EMAIL PROTECTED] Post your lilo.conf that you think should be working. Note that you do not want to access any partition on /dev/hdb or /dev/hdc directly. Use /dev/md0 instead. Justin Guerin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
