On Saturday 17 July 2004 08:57 pm, James Miller wrote:
> > Let me know if you want a patch for 2.6, I can give it a shot. Just have
> > a fire extinguisher handy ;)
>
> Yes, that would be interesting. At the moment, I'm considering older
> kernels, since the root filesystem for this install has to be pretty small
> (< 120MB). The patch as is also doesn't work for the 2.2.26 kernel to
> which I've tried applying it (results in a "rejected hunk" message). I
> think maybe this is because the line number specifications aren't right
> for this kernel. Just a guess though: I have little experience compiling
> kernels and none in patching them. If you (or anyone else onlist) could
> offer tips for applying this patch to the 2.2.26 kernel, I'd be very
> appreciative.
2.2.26 eh? Ill take a look.
> On a related, though more generic, note, I'm a bit confused by the patches
> that accompany kernel source at www.kernel.org . It seems that, for every
> 2.2.x kernel source file there, there is a corresponding 2.2.x-patch file.
> What are these? Is one supposed to download, along with the kernel one
> wants, also a patch and immediately apply it?
The ones marked -prepatch? No, You shouldn't neccesarily apply these. They are
testing versions in between releases. If you are on a desktop or can stand a
few bugs, or need a new feature, then you can download the full source, and
then apply the patch. However, generally you should wait for the full
release. The numbering without the -preX at the end. eg. 2.2.26 not
2.2.27-pre2.
> As further follow up on this whole issue, I've discovered that the initrd
> method of booting/running from USB is an entirely different option than
> the kernel patch option. If one sets up an initrd, one can use just a
> stock kernel. One simply introduces a delay for mounting the root
> filesystem into the file linuxrc in the initrd. So the FAQ item really
> should say something like:
--snip--
> In all cases (BIOS-supported and non-BIOS-supported), the delay is
> required either by means of a kernel patch, or by means of a "sleep"
> argument in the requisite initrd file owing to the extra time it takes for
> the kernel to load modules for and initialize the USB device. Once the
> kernel has been delayed for the needed interval, it finds and mounts the
> root filesystem, running from it just as it would any more typical
> mass-storage device (e.g., an IDE drive)."
>
> James
Yep. Two ways to do the same thing. I think I remember hitting on that or
somewhere close in my explanations before.
Anyways heres a quick hack for 2.2.26. I couldn't try it out because I think
my compiler is too new for 2.2.x so it gave alot of strange errors, however
let me know if it works. Seems safe. The structure of super.c in 2.2.26 is
much closer to the 2.4.14 version than the 2.6 version, its just 200 lines
off and a little switched around so patch couldn't pick it up. Oh ya and BTW
I am nowhere near a kernel hacker so keep that fire extinguisher handy ;)
--- linux-2.2.26-orig/fs/super.c 2001-11-02 10:39:08.000000000 -0600
+++ linux-2.2.26/fs/super.c 2004-07-17 22:31:57.605808136 -0500
@@ -1146,7 +1146,9 @@
struct inode * d_inode = NULL;
struct file filp;
int retval;
-
+ int retry_count = 0; //Is this needed?
+ retry:
+ retry_count++;
#ifdef CONFIG_ROOT_NFS
if (MAJOR(ROOT_DEV) == UNNAMED_MAJOR) {
ROOT_DEV = 0;
@@ -1220,7 +1222,8 @@
* Allow the user to distinguish between failed open
* and bad superblock on root device.
*/
- printk("VFS: Cannot open root device %s\n",
+ printk("VFS: Cannot open root device %s \
+ retrying in 1s.\n",
kdevname(ROOT_DEV));
else for (fs_type = file_systems ; fs_type ; fs_type = fs_type->next) {
if (!(fs_type->fs_flags & FS_REQUIRES_DEV))
@@ -1239,8 +1242,15 @@
panic("VFS: add_vfsmnt failed for root fs");
}
}
+
+ /* wait 1 second and try again */
+ current->state = TASK_INTERRUPTIBLE;
+ schedule_timeout(HZ);
+
+ if (retry_count < 7) //Retry for 6 seconds.
+ goto retry;
panic("VFS: Unable to mount root fs on %s",
- kdevname(ROOT_DEV));
+ kdevname(ROOT_DEV));
}
--
-EB
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
