[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <40D03617.3050606@tls.msk.ru>
Date: Wed, 16 Jun 2004 15:59:19 +0400
From: Michael Tokarev <mjt@....msk.ru>
To: owl-users@...ts.openwall.com
Subject: Re: crash
Solar Designer wrote:
[]
> I am also going to let the subscribers of this mailing list test the
> updated patch before I make it official:
>
> ftp://ftp.openwall.com/pvt/linux-2.4.26-ow2pre2.diff
Speaking of the patch... The following change, which is
in ow patches for quite some time, is rather questionable.
diff -urPX nopatch linux-2.4.26/init/do_mounts.c linux/init/do_mounts.c
--- linux-2.4.26/init/do_mounts.c Fri Nov 28 18:26:21 2003
+++ linux/init/do_mounts.c Sat Apr 17 02:13:55 2004
@@ -367,11 +367,12 @@
* Allow the user to distinguish between failed open
* and bad superblock on root device.
*/
- printk ("VFS: Cannot open root device \"%s\" or %s\n",
+ printk ("VFS: Cannot open root device \"%s\" or %s, "
+ "retrying in 1s.\n",
root_device_name, kdevname (ROOT_DEV));
- printk ("Please append a correct \"root=\" boot option\n");
- panic("VFS: Unable to mount root fs on %s",
- kdevname(ROOT_DEV));
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(HZ);
+ goto retry;
}
panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
out:
when sys.kernel.panic is set to some reasonable value, I
expect the kernel to reboot in case of boot failure,
instead of going into the endless loop. It is almost
irrelevant when you're able to access the machine
physically, but makes quite some difference when the
machine in question is remote. When trying out the
new kernel, I usually install it in parallel with
currently running kernel, set lilo to load it only
once (with -R option), panicing if can't boot
(panic=30 to mean reboot in 30 sec in case of panic).
Several times already I came across a problem when
due to the above "fix" the system won't boot and
needs physical presense to bring it up again --
mostly when booting initrd and forgotting to compile
appropriate filesystem support into kernel (which is
lame but still happens sometimes), or when root fs
is on nfs, but it did happen with normal on-disk
filesystems as well. After finding the problem
(which took me quite some time), I always delete
the above chunk of changes when applying Owl
kernel patches.
Why the above change is needed?
/mjt
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
