DEVFS and Redhat 7.2 (was Re: [vox-tech] Urgent - Problem in upgradation of RH 7.1 to RH 7. 2 !!)

[R. Douglas Barbieri]

Hello fellow LUGODians,

I wanted to share my experience with EXT3. I was able to upgrade my
existing RH7.1 install to ext3 across the board and it was decidedly
painless. I believe EXT3 is not built into the default RH 7.1 kernel, so
I rebuilt the kernel (using the kernel-source 2.4.9-12 package) not only
to support ext3 but to enable the DEVFS as well. As per Pete's 
presentation, DEVFS was easy to install. Migrating to ext3 
was easy as well (a la tune2fs).

I had downloaded the Redhat 7.2 ISO images a couple of weeks ago, burned
the two CDRs and began upgrading a different RH7.1 system RH7.2. It was
there I ran into problems. RH7.2 comes with ext3 precompiled into the
kernel (of course, in order to get kernel 2.4.9-13, I had to get the
update RPM package). Once again, "tuning" my ext2 partitions to ext3 was
easy.  All I had to do was change my fstab entries and reboot.
Voila--instant ext3.

Now I wanted to convert the system to DEVFS. I had to get the latest RH7.2
kernel sources (2.4.9-13) and rebuild the kernel, making sure to include
the ext3 and DEVFS modules, since RH7.2 does not come with DEVFS support
built in. I also checked the "mount /dev filesystem at boot". Then I
compiled then kernel and modules, installed everything, crossed my
fingers, and rebooted. I got the message "kernel panic--no init image
found." I had noticed as well that during the boot process, I was getting
a wierd error "mknod failed: 17".

I discovered that, since I use LILO, the new installation had a "initrd="
line. I tried to reboot, typing in "linux root=/dev/hda5 initrd= single"
but to no avail--the same panic message ensued. Arg. Rebooting with the 
old stock kernel, I remarked off the "initrd=" image line in the lilo.conf 
file, re-ran lilo, then rebooted. 

Lo and behold, my new kernel finally booted correctly. After looking at
the mkinitrd script, dmesg output, and the linuxrc script in the initrc
image, I finally determined what the cause was: when using DEVFS, and with
the "mount /dev filesystem at boot" option checked in the kernel build,
the /dev filesystem is mounted right before the initrd image is loaded and
linuxrc is run. linuxrc attempts to "mknod" the entries in a temporary
filesystem and attempts to remount it (with the /dev filesystem mounted,
this is where the wierd "mknod" error came from). This requires an entry
for /dev/root, which doesn't exist. Since devfsd is not running, it cannot
be created on demand. Further, the pivot_root command really messes things
up--it seems to make the initial /dev mounting "go away".

The solution was to prohibit /dev mounting on boot (I added an 
'append="devfs=nomount"' line to /etc/lilo.conf). Then, the initrd image 
could run correctly. I then added at the top of /etc/rc.sysinit the 
following lines:

# Find this at 
# http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html#persistence
#
echo -en "Mounting dev filesystem: "
/bin/mount --bind /dev /dev-state
/bin/mount -n -t devfs none /dev
echo
/sbin/devfsd /dev

The "mount --bind..." keeps a persistent state of the /dev
filesystem--this allows one to change permissions and ownership of items
in the /dev filesystem and have them preserved across reboots. The "mount
-n -t..." command actually mounts the /dev filesystem. The "devfsd..." 
line starts the DEVFS daemon.

Doug (aka Dooglio)

BTW:

It would be nice to rework the linuxrc file in a DEVFS-only initrd image 
so it could take advantage of the devfs filesystem. The trouble is that 
pesky remounting and pivot_root stuff.

I must admit that I'm in the dark as to the need for a boot image at
all--what are the advantages? Why do we need it? On my RH7.1 system I have
the image disabled (this is why I never ran into the DEVFS problem
before). In fact, I can run my RH7.2 system just fine with the "initrd="
line in /etc/lilo.conf remarked off. EXT3 and DEVFS seem to be happy in
both instances.

On Mon, 24 Dec 2001, Peter Jay Salzman wrote:
>
[major snipage]
> 
> pete


-- 
R. Douglas Barbieri
doug@dooglio.net
www.dooglio.net