kernel patch failure: input please?

Using sort of a scatter-gun (maybe scatter-brained?) approach to the
problem of booting a USB drive, I've managed to install a base Debian file
system to the USB drive. Yes, the new beta Sarge installer gave me the
option of installing the system there. Booting is, as has been alluded in
the earlier booting from USB exchange on this list, another matter.
Since the system is meant to use the 2.4.25-1-386 kernel, I've decided I
should try and compile that kernel with the root file system mounting
delay patch we've spoken about. But, I've gotten stuck at the patching
phase. I'm actually using directions for patching a 2.4.23 kernel that I
found on another USB booting site (
http://www.freewebs.com/tsj/bootingUSB_ldp_v0.1.htm ) that suggests
applying the patch to do_mounts.c . When I try to apply the patch using
the directions found at that site, I get the following:

[11:39:55]root@mymachine kernel-source-2.4.25$ patch -p0
patching file init/do_mounts.c
patch: **** malformed patch at line 5: static void __init mount_root(void)

[11:40:13]root@mymachine kernel-source-2.4.25$

The file do_mounts.c appears to have been unmodified. Can anyone clue me
in as to where the problem lies and how I might get the patch to apply
after all?

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: kernel patch failure: input please?

On Mon, 19 Jul 2004, James Miller wrote:

> Using sort of a scatter-gun (maybe scatter-brained?) approach to the
> problem of booting a USB drive, I've managed to install a base Debian=
file
> system to the USB drive. Yes, the new beta Sarge installer gave me t=
he
> option of installing the system there. Booting is, as has been allud=
ed in
> the earlier booting from USB exchange on this list, another matter.
> Since the system is meant to use the 2.4.25-1-386 kernel, I've decide=
d I
> should try and compile that kernel with the root file system mounting
> delay patch we've spoken about. But, I've gotten stuck at the patchi=
ng
> phase. I'm actually using directions for patching a 2.4.23 kernel th=
at I
> found on another USB booting site (
> http://www.freewebs.com/tsj/bootingUSB_ldp_v0.1.htm ) that suggests
> applying the patch to do_mounts.c . When I try to apply the patch us=
ing
> the directions found at that site, I get the following:
>
> [11:39:55]root@mymachine kernel-source-2.4.25$ patch -p0
> > patching file init/do_mounts.c
> patch: **** malformed patch at line 5: static void __init mount_root(=
void)
>

I've seen this when I was hand-editing a diff to only use some of the
changes in a file. Can be caused by errors in the "magic numbers"
saying how many lines change/where they are. This sort of thing means
the patch will not apply for *anyone*, so you might want to see if the
version you got was corrupted, or has been updated.

If the file isn't very big, you can copy the code in a text editor, bu=
t
that isn't recommended for a newbie list because you need to understand
what the code is doing.

Also, you don't need to be root until you are trying to install things=
,
and setting PS1 to end '\$' (with the whole string in _single_ quotes)
will change the prompt to end in '#' when you _are_ root.

Ken
--=20
das eine Mal als Tragödie, das andere Mal als Farce

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: kernel patch failure: input please?

On Tue, 20 Jul 2004, Ken Moffat wrote:

> On Mon, 19 Jul 2004, James Miller wrote:
>
> > Using sort of a scatter-gun (maybe scatter-brained?) approach to the
> > problem of booting a USB drive, I've managed to install a base Debian file
> > system to the USB drive. Yes, the new beta Sarge installer gave me the
> > option of installing the system there. Booting is, as has been alluded in
> > the earlier booting from USB exchange on this list, another matter.
> > Since the system is meant to use the 2.4.25-1-386 kernel, I've decided I
> > should try and compile that kernel with the root file system mounting
> > delay patch we've spoken about. But, I've gotten stuck at the patching
> > phase. I'm actually using directions for patching a 2.4.23 kernel that I
> > found on another USB booting site (
> > http://www.freewebs.com/tsj/bootingUSB_ldp_v0.1.htm ) that suggests
> > applying the patch to do_mounts.c . When I try to apply the patch using
> > the directions found at that site, I get the following:
> >
> > [11:39:55]root@mymachine kernel-source-2.4.25$ patch -p0
> > > > patching file init/do_mounts.c
> > patch: **** malformed patch at line 5: static void __init mount_root(void)
> >
>
> I've seen this when I was hand-editing a diff to only use some of the
> changes in a file. Can be caused by errors in the "magic numbers"
> saying how many lines change/where they are. This sort of thing means
> the patch will not apply for *anyone*, so you might want to see if the
> version you got was corrupted, or has been updated.

For reference, here's the "updated" (adapted for the 2.4.23 kernel) patch:

--- init/do_mounts.c 2003-11-28 13:26:21.000000000 -0500
+++ init/do_mounts.c.mount_root 2006-01-29 10:45:53.000000000 -0500
@@ -759,6 +759,19 @@

static void __init mount_root(void)
{
+ static DECLARE_WAIT_QUEUE_HEAD (jordi_queue);
+
+ printk ("\n\n\n---------------------------------\n");
+
+ printk (" WAITING FOR A WHILE (1000) \n");
+
+ printk (" TO DETECT THE USB DISK \n");
+
+ sleep_on_timeout (&jordi_queue, 2000);
+
+ printk ("---------------------------------\n\n\n");
+
+
#ifdef CONFIG_ROOT_NFS
if (MAJOR(ROOT_DEV) == NFS_MAJOR
&& MINOR(ROOT_DEV) == NFS_MINOR) {

In the C source file do_mounts.c, the line right before "static void
__init mount_root(void)" is blank and is line number 759 (line 760 reads
"static void __init mount_root(void)"). This is the 5th line of my
kernel2-4-25patch file that is being complained about as the problem area.

> If the file isn't very big, you can copy the code in a text editor, but
> that isn't recommended for a newbie list because you need to understand
> what the code is doing.

I don't understand very well what the code is doing. I see that, in
do_mounts.c, "static void __init mount_root(void)" is followed immediately
by "#ifdef CONFIG_ROOT_NFS". From this, I deduce that what lies between
the two in the patch is what's actually getting inserted. Further, I'm
guessing the + signs at the left margin are telling the patching routine
to add the lines followed by the sign to the file being patched. Words
like "WAIT," "DETECT" and "USB DISK" are, of course comprehensible.
Others like "printk" and "jordi_queue" mean nothing to me. I'm also not
clear on the line spacing: the lines of the patch are mostly what we would
call in typesetting/page formatting terminology "double spaced" or even
triple spaced. I know generally the conventions followed in publishing
regarding line spacing, and have my own ideas about how these things can
aid in (or are irrelevant to) reading comprehension. What they mean to
computers - if anything - I have no idea.

> Also, you don't need to be root until you are trying to install things,
> and setting PS1 to end '\$' (with the whole string in _single_ quotes)
> will change the prompt to end in '#' when you _are_ root.

The file I'm patching is in /usr/src/kernel-source-2.4.25, and my user
does not have read/write permissions in that directory. At least that was
my assumption. Not that I question your advice on the root prompt, but
why would having # instead of $ matter? If it's just to remind one that
they are running as root, I have another way of indicating that: the whole
root prompt is red. But maybe there is some other reason to have #
instead of $ when running as root?

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: kernel patch failure: input please?

On Tue, 20 Jul 2004, James Miller wrote:

> On Tue, 20 Jul 2004, Ken Moffat wrote:
>
> >
> > I've seen this when I was hand-editing a diff to only use some of =
the
> > changes in a file. Can be caused by errors in the "magic numbers"
> > saying how many lines change/where they are. This sort of thing me=
ans
> > the patch will not apply for *anyone*, so you might want to see if =
the
> > version you got was corrupted, or has been updated.
>
> For reference, here's the "updated" (adapted for the 2.4.23 kernel) p=
atch:
>
> --- init/do_mounts.c 2003-11-28 13:26:21.000000000 -0500
> +++ init/do_mounts.c.mount_root 2006-01-29 10:45:53.000000000 -0500
> @@ -759,6 +759,19 @@
>
> static void __init mount_root(void)
> {
> + static DECLARE_WAIT_QUEUE_HEAD (jordi_queue);
> +
> + printk ("\n\n\n---------------------------------\n");
> +
> + printk (" WAITING FOR A WHILE (1000) \n");
> +
> + printk (" TO DETECT THE USB DISK \n");
> +
> + sleep_on_timeout (&jordi_queue, 2000);
> +
> + printk ("---------------------------------\n\n\n");
> +
> +
> #ifdef CONFIG_ROOT_NFS
> if (MAJOR(ROOT_DEV) == NFS_MAJOR
> && MINOR(ROOT_DEV) == NFS_MINOR) {
>
> In the C source file do_mounts.c, the line right before "static void
> __init mount_root(void)" is blank and is line number 759 (line 760 re=
ads
> "static void __init mount_root(void)"). This is the 5th line of my
> kernel2-4-25patch file that is being complained about as the problem =
area.
>

In that case, I don't know what the problem is. In the old file ('-')
the hunk is for six lines at line 759, in the new ('+') it's for 19
lines [ 6 existing, for context, plus 13 new =3D 19, just like it says =
].

The content of the patch scares me - all that shouting, a value of 100=
0
hard-coded in the print, but a value of 2000 used in the code, and all
those gratuitous blank lines in the printk.

The DECLARE_WAIT_QUEUE_HEAD is presumably a macro (grep for it in the
kernel tree you are building), for which jordi_queue is a parameter.

> > If the file isn't very big, you can copy the code in a text editor=
, but
> > that isn't recommended for a newbie list because you need to unders=
tand
> > what the code is doing.
>
> I don't understand very well what the code is doing. I see that, in
> do_mounts.c, "static void __init mount_root(void)" is followed immedi=
ately
> by "#ifdef CONFIG_ROOT_NFS". From this, I deduce that what lies betw=
een
> the two in the patch is what's actually getting inserted. Further, I=
'm
> guessing the + signs at the left margin are telling the patching rout=
ine
> to add the lines followed by the sign to the file being patched. Wor=
ds
> like "WAIT," "DETECT" and "USB DISK" are, of course comprehensible.
> Others like "printk" and "jordi_queue" mean nothing to me. I'm also =
not
> clear on the line spacing: the lines of the patch are mostly what we =
would
> call in typesetting/page formatting terminology "double spaced" or ev=
en
> triple spaced. I know generally the conventions followed in publishi=
ng
> regarding line spacing, and have my own ideas about how these things =
can
> aid in (or are irrelevant to) reading comprehension. What they mean =
to
> computers - if anything - I have no idea.
>

Line spacing means nothing to a computer. Yes, the lines prefixed '+'
are to be inserted, similarly any lines prefixed '-' would be deleted.
The 'incomprehensible' words are what will be printed on the console,
printk is the kernel's version of printf.

So, in theory you can copy the thirteen new lines prefixed by '+' into
the file, remove the '+' signs, and that file is done. What it does,
and whether or not it is sensible, I can't say. Presumably there are
other parts to the patch ? Do they all apply to 2.4.25 ? And why
hasn't the patch gone into the kernel (i.e. is it misconceived, or just
not submitted?). Come to that, it might be worth checking to see if
this has made it into 2.4.26 or 2.4.27-rc (yes, I know you've been told
not to use a -pre or -rc, but _if_ it gives you new functionality you
need then you should try the -rc and upgrade to 2.4.27 when it is
released).

> > Also, you don't need to be root until you are trying to install th=
ings,
> > and setting PS1 to end '\$' (with the whole string in _single_ quot=
es)
> > will change the prompt to end in '#' when you _are_ root.
>
> The file I'm patching is in /usr/src/kernel-source-2.4.25, and my use=
r
> does not have read/write permissions in that directory. At least tha=
t was
> my assumption. Not that I question your advice on the root prompt, b=
ut
> why would having # instead of $ matter? If it's just to remind one t=
hat
> they are running as root, I have another way of indicating that: the =
whole
> root prompt is red. But maybe there is some other reason to have #
> instead of $ when running as root?
>

If you're happy with a red prompt, that's fine, but expect "helpful"
comments from time to time because red doesn't show up in plain text th=
e
way '#' does :-)

Ken
--=20
das eine Mal als Tragödie, das andere Mal als Farce

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: kernel patch failure: input please?

On Tue, 20 Jul 2004, Ken Moffat wrote:

> printk is the kernel's version of printf.

Oh. Guess I'll have to mull over that one awhile.

> So, in theory you can copy the thirteen new lines prefixed by '+' into
> the file, remove the '+' signs, and that file is done. What it does,
> and whether or not it is sensible, I can't say. Presumably there are
> other parts to the patch ? Do they all apply to 2.4.25 ?

The patch and instructions are for the 2.4.23 kernel, as I mentioned. I
was guessing it might all work for the 2.4.25 kernel I'm trying to use.
The site I've referenced gives only these few lines as the needed patch:
the other patch I brought up onlist for delaying root file system mounting
(for super.c) was similarly brief. I have no senisbility whatever about
whether the brevity is suspiscious or problematic.

> And why
> hasn't the patch gone into the kernel (i.e. is it misconceived, or just
> not submitted?).

I suppose because most computer users don't need the delay in mounting of
the root file system the patch introduces. I know I never had any need
for it before I started looking into booting from USB. But I'm the rank
amateur here: someone closer to the wellsprings of knowledge and authority
on matters kernel could answer more authoritatively.

> Come to that, it might be worth checking to see if
> this has made it into 2.4.26 or 2.4.27-rc (yes, I know you've been told
> not to use a -pre or -rc, but _if_ it gives you new functionality you
> need then you should try the -rc and upgrade to 2.4.27 when it is
> released).

I've actually never been told that - at least not in this way. I'm not
even sure to what -rc and -pre refer: I'll go look it up later. But I do
know how to at least check to see if the patch is present in newer kernels
(yes, my do_init.c text scanning capabilities are by now honed to a fine
edge . . .). My unrefined newbie sensibilities tell me it's doubtful,
since this is a highly specialized kernel tweak - useful only to those
attempting to boot from USB, so far as I know. But I know so little about
these things that the range of possibilities is truly overwhelming.
Things should not be ruled out easily.

> If you're happy with a red prompt, that's fine, but expect "helpful"
> comments from time to time because red doesn't show up in plain text the
> way '#' does :-)

Does this mean you suggested the # in place of the $ pretty much solely to
help indicate to (me) the user that he is running as root? I'm just
trying to learn something here.

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: kernel patch failure: input please?

On Tue, 20 Jul 2004, James Miller wrote:

> On Tue, 20 Jul 2004, Ken Moffat wrote:
>
> > So, in theory you can copy the thirteen new lines prefixed by '+' =
into
> > the file, remove the '+' signs, and that file is done. What it doe=
s,
> > and whether or not it is sensible, I can't say. Presumably there a=
re
> > other parts to the patch ? Do they all apply to 2.4.25 ?
>
> The patch and instructions are for the 2.4.23 kernel, as I mentioned.=
I
> was guessing it might all work for the 2.4.25 kernel I'm trying to us=
e.
> The site I've referenced gives only these few lines as the needed pat=
ch:
> the other patch I brought up onlist for delaying root file system mou=
nting
> (for super.c) was similarly brief. I have no senisbility whatever ab=
out
> whether the brevity is suspiscious or problematic.
>

it was just the 'jordi_queue' parameter that made me think there must
be more to it, but then I've never looked for the macro.

> > And why
> > hasn't the patch gone into the kernel (i.e. is it misconceived, or =
just
> > not submitted?).
>
> I suppose because most computer users don't need the delay in mountin=
g of
> the root file system the patch introduces. I know I never had any ne=
ed
> for it before I started looking into booting from USB. But I'm the r=
ank
> amateur here: someone closer to the wellsprings of knowledge and auth=
ority
> on matters kernel could answer more authoritatively.
>

Actually, I don't care why the patch isn't in the kernel (assuming for
the moment that it isn't). What matters is for you to be able to decid=
e
if it's good enough, hence the questions. I think I've seen at least
one such patch mentioned in the past, but I don't recall any detail.

I'm guessing that a patch for the the general kernel would be wrapped
in something, e.g. #ifdef CONFIG_BOOT_FROM_USB, to stop it getting in
most people's way, but for a separate patch that clearly isn't
necessary.

> > Come to that, it might be worth checking to see if
> > this has made it into 2.4.26 or 2.4.27-rc (yes, I know you've been =
told
> > not to use a -pre or -rc, but _if_ it gives you new functionality y=
ou
> > need then you should try the -rc and upgrade to 2.4.27 when it is
> > released).
>
> I've actually never been told that - at least not in this way. I'm n=
ot
> even sure to what -rc and -pre refer: I'll go look it up later. But =
I do
> know how to at least check to see if the patch is present in newer ke=
rnels
> (yes, my do_init.c text scanning capabilities are by now honed to a f=
ine
> edge . . .). My unrefined newbie sensibilities tell me it's doubtful=
,
> since this is a highly specialized kernel tweak - useful only to thos=
e
> attempting to boot from USB, so far as I know. But I know so little =
about
> these things that the range of possibilities is truly overwhelming.
> Things should not be ruled out easily.

I just downloaded the changelog for 2.4.27-rc3 for other reasons, and
it certainly doesn't jump out and say it has been added. New kernel
versions don't (usually) just materialise, there is a process of
applying changes (the -pre series), then fixing what has been found to
be bad (the -rc versions) until eventually the maintainer decides to
release it. So at the moment we've had 2.4.26, a number of 2.4.27-pres,
and now 3 2.4.27-rcs. Most people on this list won't want to touch
anything other than stable released kernels, but anybody needing new
functionality might have to take an interest in the development.

If you haven't already done so, you might want to read the thread from
l-k starting at
http://www.uwsg.iu.edu/hypermail/linux/kernel/0405.0/0224.ht ml
particularly the final postings from Randy Dunlap and Willy Tarreau.

>
> > If you're happy with a red prompt, that's fine, but expect "helpfu=
l"
> > comments from time to time because red doesn't show up in plain tex=
t the
> > way '#' does :-)
>
> Does this mean you suggested the # in place of the $ pretty much sole=
ly to
> help indicate to (me) the user that he is running as root? I'm just
> trying to learn something here.
>
> Thanks, James

Yes

Ken
--=20
das eine Mal als Tragödie, das andere Mal als Farce

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs