[21207] in Athena Bugs
Re: linux 9.1.18: kernel
daemon@ATHENA.MIT.EDU (Arun A Tharuvai)
Tue Dec 17 13:15:34 2002
To: Greg Hudson <ghudson@mit.edu>
Cc: bugs@mit.edu, aatharuv@mit.edu
From: Arun A Tharuvai <aat@alum.mit.edu>
Date: 17 Dec 2002 13:15:31 -0500
In-Reply-To: <1040100213.10794.203.camel@error-messages.mit.edu>
Message-ID: <tqt8yyo8qbg.fsf@cutter-john.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
The /sbin/mkinitrd did the trick (though the machine in question
hasn't been rebooted yet, I've yet to test it.) Thanks!
However, I had to do a bit of hacking (because of a change I made
after my last email to bugs), and noticed a screw case which might
affect some users, namely, if their root filesystem is listed as ext2
in /etc/fstab, an initrd won't get created and /boot/grub/grub.conf
won't get modified. Attempting to manually modify /boot/grub/grub.conf
will cause a kernel panic upon boot. This is because /sbin/mkinitrd
looks at /etc/fstab to determine the filesystem of the root
filesystem, while (it seems ) the kernel will (if there's ext3
support) assume it's ext3, or (if there's no ext3 support), kernel
panic. It seems like it would be best to add some code in mkinitrd after:
rootfs=$(awk '{ if ($1 !~ /^[ \t]*#/ && $2 == "/") { print $3; }}' $fstab)
to set rootfs to ext3 if it the filesystem has a journal and is ext2
or ext3.
Arun
Greg Hudson <ghudson@MIT.EDU> writes:
> I've attached a modified /sbin/mkinitrd which uses a ramdisk instead of
> a loop device. Copying this over /sbin/mkinitrd should make a kernel
> install work. That should be a reasonable workaround for users, since
> it's the workaround I plan to use in the release.
>
>
--
Arun A Tharuvai
aatharuv (at) mit (dot) edu
aat (at) alum (dot) mit (dot) edu
