On Mon, Dec 10, 2007 at 09:08:53AM -0600, Bob Tracy wrote:
> Ivan Kokshaysky wrote:
> > For now I have reassigned the bug #9457 to myself and will gradually hack
> > into udev...
>
> Thanks... Let me know if there's anything useful I can do to help.
It turns out to be yet another strncpy() bug
Ivan Kokshaysky wrote:
> On Sat, Dec 08, 2007 at 10:19:39PM -0600, Bob Tracy wrote:
> > I *do* have CONFIG_MAGIC_SYSRQ set. Anyone care to bet whether my
> > machine starts working again if I disable it? Sheesh...
>
> Incredible...
>
> Toggling CONFIG_MAGIC_SYSRQ works for me too, so I'm
Kay Sievers wrote:
> On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
> > Kay Sievers wrote:
> > > Is the udev daemon (still) running while it fails?
> >
> > Yes, and there's something else I forgot to mention that may be
> > significant... For the bad case, in addition to udevd, "ps -ef"
> >
Kay Sievers wrote:
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, ps -ef
shows a sh -e
Ivan Kokshaysky wrote:
On Sat, Dec 08, 2007 at 10:19:39PM -0600, Bob Tracy wrote:
I *do* have CONFIG_MAGIC_SYSRQ set. Anyone care to bet whether my
machine starts working again if I disable it? Sheesh...
Incredible...
Toggling CONFIG_MAGIC_SYSRQ works for me too, so I'm finally able
On Mon, Dec 10, 2007 at 09:08:53AM -0600, Bob Tracy wrote:
Ivan Kokshaysky wrote:
For now I have reassigned the bug #9457 to myself and will gradually hack
into udev...
Thanks... Let me know if there's anything useful I can do to help.
It turns out to be yet another strncpy() bug that
On Sat, Dec 08, 2007 at 10:19:39PM -0600, Bob Tracy wrote:
> I *do* have CONFIG_MAGIC_SYSRQ set. Anyone care to bet whether my
> machine starts working again if I disable it? Sheesh...
Incredible...
Toggling CONFIG_MAGIC_SYSRQ works for me too, so I'm finally able
to reproduce the problem
On Sat, Dec 08, 2007 at 10:19:39PM -0600, Bob Tracy wrote:
I *do* have CONFIG_MAGIC_SYSRQ set. Anyone care to bet whether my
machine starts working again if I disable it? Sheesh...
Incredible...
Toggling CONFIG_MAGIC_SYSRQ works for me too, so I'm finally able
to reproduce the problem (which
Michael Cree wrote:
> Kay Sievers wrote:
> > On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
> >> Kay Sievers wrote:
> >>> Is the udev daemon (still) running while it fails?
> >> Yes, and there's something else I forgot to mention that may be
> >> significant... For the bad case, in addition
Kay Sievers wrote:
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, "ps -ef"
shows a "sh -e
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
> Kay Sievers wrote:
> > Is the udev daemon (still) running while it fails?
>
> Yes, and there's something else I forgot to mention that may be
> significant... For the bad case, in addition to udevd, "ps -ef"
> shows a "sh -e
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, ps -ef
shows a sh -e /lib/udev/net.agent running
Kay Sievers wrote:
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, ps -ef
shows a sh -e
Michael Cree wrote:
Kay Sievers wrote:
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, ps -ef
Kay Sievers wrote:
> Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, "ps -ef"
shows a "sh -e /lib/udev/net.agent" running with a PPID of 1. This
process doesn't exit until I
Kay Sievers wrote:
> Is the udev daemon (still) running while it fails?
Yes.
> If you run /sbin/udevtrigger, do the nodes appear?
No. Exit status is 0, and there are no errors. Everything looks
fine under /sys/block, and there doesn't seem to be a problem with
/proc/devices either.
--
Kay Sievers wrote:
> Yeah, that looks all fine.
>
> What distro is that, and what's the udev version?
Mine is Debian Etch, normally with the latest released or -rcX kernel
from kernel.org. Updates current as of about 18 hours ago. Udev
package version is 0.105-4. The RELEASE-NOTES file in
On Sat, 2007-12-08 at 09:43 +1300, Michael Cree wrote:
> Bob Tracy wrote:
> > That was quick :-). Backing out the sysctl_check.c diff gives me a
> > working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
> >
> > Michael Cree: could you try backing out the diff below from your
>
Bob Tracy wrote:
That was quick :-). Backing out the sysctl_check.c diff gives me a
working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
Michael Cree: could you try backing out the diff below from your
2.6.24-rc3 tree and see if things are now working for you?
Yes
Kay Sievers wrote:
> On Fri, 2007-12-07 at 19:06 +0100, Ingo Molnar wrote:
> > i'm not sure how to do direct debugging on udev, so i can only guess
> > about what effect on the kernel side could have caused this. One bad
> > hack would be to "probe" udevd's behavior by changing the NET_TR entry
On Fri, 2007-12-07 at 19:06 +0100, Ingo Molnar wrote:
> * Bob Tracy <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar wrote:
> > >
> > > * Bob Tracy <[EMAIL PROTECTED]> wrote:
> > >
> > > > > Current state of the source tree is the 6f37ac... version, so I'll
> > > > > start backing out the above
* Bob Tracy <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >
> > * Bob Tracy <[EMAIL PROTECTED]> wrote:
> >
> > > > Current state of the source tree is the 6f37ac... version, so I'll
> > > > start backing out the above diffs in related groups and continue
> > > > until I've got a working
Ingo Molnar wrote:
>
> * Bob Tracy <[EMAIL PROTECTED]> wrote:
>
> > > Current state of the source tree is the 6f37ac... version, so I'll
> > > start backing out the above diffs in related groups and continue
> > > until I've got a working kernel. For lack of an obvious target,
> > > I'll
* Bob Tracy <[EMAIL PROTECTED]> wrote:
> > Current state of the source tree is the 6f37ac... version, so I'll
> > start backing out the above diffs in related groups and continue
> > until I've got a working kernel. For lack of an obvious target,
> > I'll start with the seemingly innocuous
I wrote:
> "git diff 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3
> 6f37ac793d6ba7b35d338f791974166f67fdd9ba"
> produced a relatively short patch (18,437 bytes). The list of involved
> files:
>
> (omitted)
>
> Current state of the source tree is the 6f37ac... version, so I'll start
> backing out
Andrew Morton wrote:
> On Thu, 6 Dec 2007 23:07:08 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
> > Andrew Morton wrote:
> > > commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba
> > > Merge: 2f1f53b... d90bf5a...
> > > Author: Linus Torvalds <[EMAIL PROTECTED]>
> > > Date: Wed Nov 14 18:51:48
* Bob Tracy <[EMAIL PROTECTED]> wrote:
> > I'm struggling to see how any of those could have broken block
> > device mounting on alpha. Are you sure you bisected right?
>
> Based on what's in that commit, it *does* appear something went wrong
> with bisection. If the implicated commit is
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > then the test of whether I bisected correctly is as simple as
> > applying the commit and seeing if things break, because I'm running
> > on the kernel corresponding to
> > 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right now. Let me give
> >
On Thu, 6 Dec 2007 23:07:08 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
> Andrew Morton wrote:
> > commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba
> > Merge: 2f1f53b... d90bf5a...
> > Author: Linus Torvalds <[EMAIL PROTECTED]>
> > Date: Wed Nov 14 18:51:48 2007 -0800
> >
> > Merge
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > # bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of
> > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
> > git-bisect bad 6f37ac793d6ba7b35d338f791974166f67fdd9ba
> > # good:
* Andrew Morton [EMAIL PROTECTED] wrote:
# bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
git-bisect bad 6f37ac793d6ba7b35d338f791974166f67fdd9ba
# good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3]
On Thu, 6 Dec 2007 23:07:08 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
Andrew Morton wrote:
commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba
Merge: 2f1f53b... d90bf5a...
Author: Linus Torvalds [EMAIL PROTECTED]
Date: Wed Nov 14 18:51:48 2007 -0800
Merge branch 'master' of
I wrote:
git diff 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3
6f37ac793d6ba7b35d338f791974166f67fdd9ba
produced a relatively short patch (18,437 bytes). The list of involved
files:
(omitted)
Current state of the source tree is the 6f37ac... version, so I'll start
backing out the above
* Bob Tracy [EMAIL PROTECTED] wrote:
Current state of the source tree is the 6f37ac... version, so I'll
start backing out the above diffs in related groups and continue
until I've got a working kernel. For lack of an obvious target,
I'll start with the seemingly innocuous change to
* Andrew Morton [EMAIL PROTECTED] wrote:
then the test of whether I bisected correctly is as simple as
applying the commit and seeing if things break, because I'm running
on the kernel corresponding to
2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right now. Let me give
that a try and
Andrew Morton wrote:
On Thu, 6 Dec 2007 23:07:08 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
Andrew Morton wrote:
commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba
Merge: 2f1f53b... d90bf5a...
Author: Linus Torvalds [EMAIL PROTECTED]
Date: Wed Nov 14 18:51:48 2007 -0800
* Bob Tracy [EMAIL PROTECTED] wrote:
I'm struggling to see how any of those could have broken block
device mounting on alpha. Are you sure you bisected right?
Based on what's in that commit, it *does* appear something went wrong
with bisection. If the implicated commit is the next
On Fri, 2007-12-07 at 19:06 +0100, Ingo Molnar wrote:
* Bob Tracy [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Bob Tracy [EMAIL PROTECTED] wrote:
Current state of the source tree is the 6f37ac... version, so I'll
start backing out the above diffs in related groups and
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, ps -ef
shows a sh -e /lib/udev/net.agent running with a PPID of 1. This
process doesn't exit until I
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes.
If you run /sbin/udevtrigger, do the nodes appear?
No. Exit status is 0, and there are no errors. Everything looks
fine under /sys/block, and there doesn't seem to be a problem with
/proc/devices either.
--
Bob Tracy wrote:
That was quick :-). Backing out the sysctl_check.c diff gives me a
working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
Michael Cree: could you try backing out the diff below from your
2.6.24-rc3 tree and see if things are now working for you?
Yes
Kay Sievers wrote:
On Fri, 2007-12-07 at 19:06 +0100, Ingo Molnar wrote:
i'm not sure how to do direct debugging on udev, so i can only guess
about what effect on the kernel side could have caused this. One bad
hack would be to probe udevd's behavior by changing the NET_TR entry
in
Ingo Molnar wrote:
* Bob Tracy [EMAIL PROTECTED] wrote:
Current state of the source tree is the 6f37ac... version, so I'll
start backing out the above diffs in related groups and continue
until I've got a working kernel. For lack of an obvious target,
I'll start with the
Kay Sievers wrote:
Yeah, that looks all fine.
What distro is that, and what's the udev version?
Mine is Debian Etch, normally with the latest released or -rcX kernel
from kernel.org. Updates current as of about 18 hours ago. Udev
package version is 0.105-4. The RELEASE-NOTES file in
* Bob Tracy [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Bob Tracy [EMAIL PROTECTED] wrote:
Current state of the source tree is the 6f37ac... version, so I'll
start backing out the above diffs in related groups and continue
until I've got a working kernel. For lack of an
On Sat, 2007-12-08 at 09:43 +1300, Michael Cree wrote:
Bob Tracy wrote:
That was quick :-). Backing out the sysctl_check.c diff gives me a
working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
Michael Cree: could you try backing out the diff below from your
I wrote:
> If the implicated commit is the next one in time
> sequence relative to
>
> # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap
> INLINE and name timeval_cmp better
>
> then the test of whether I bisected correctly is as simple as applying
> the commit and
Andrew Morton wrote:
> commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba
> Merge: 2f1f53b... d90bf5a...
> Author: Linus Torvalds <[EMAIL PROTECTED]>
> Date: Wed Nov 14 18:51:48 2007 -0800
>
> Merge branch 'master' of
> master.kernel.org:/pub/scm/linux/kernel/git/davem/n
>
> *
OK. Finally have this thing painted into a corner: git has identified
6f37ac793d6ba7b35d338f791974166f67fdd9ba as the first bad commit.
>From "git bisect log", this corresponds to
# bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of
On Thu, 6 Dec 2007 18:16:12 -0600 (CST)
[EMAIL PROTECTED] (Bob Tracy) wrote:
> OK. Finally have this thing painted into a corner: git has identified
> 6f37ac793d6ba7b35d338f791974166f67fdd9ba as the first bad commit.
>
> >From "git bisect log", this corresponds to
>
> # bad:
On Friday, 7 of December 2007, Bob Tracy wrote:
> OK. Finally have this thing painted into a corner: git has identified
> 6f37ac793d6ba7b35d338f791974166f67fdd9ba as the first bad commit.
>
> From "git bisect log", this corresponds to
>
> # bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge
On Thu, 6 Dec 2007 18:16:12 -0600 (CST)
[EMAIL PROTECTED] (Bob Tracy) wrote:
OK. Finally have this thing painted into a corner: git has identified
6f37ac793d6ba7b35d338f791974166f67fdd9ba as the first bad commit.
From git bisect log, this corresponds to
# bad:
On Friday, 7 of December 2007, Bob Tracy wrote:
OK. Finally have this thing painted into a corner: git has identified
6f37ac793d6ba7b35d338f791974166f67fdd9ba as the first bad commit.
From git bisect log, this corresponds to
# bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch
OK. Finally have this thing painted into a corner: git has identified
6f37ac793d6ba7b35d338f791974166f67fdd9ba as the first bad commit.
From git bisect log, this corresponds to
# bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of
Andrew Morton wrote:
commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba
Merge: 2f1f53b... d90bf5a...
Author: Linus Torvalds [EMAIL PROTECTED]
Date: Wed Nov 14 18:51:48 2007 -0800
Merge branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/n
* 'master' of
I wrote:
If the implicated commit is the next one in time
sequence relative to
# good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap
INLINE and name timeval_cmp better
then the test of whether I bisected correctly is as simple as applying
the commit and seeing if
Current progress: 11 revisions left to test. The current partial
"git bisect log" is available per Ingo's suggestion on bugzilla.
http://bugzilla.kernel.org/show_bug.cgi?id=9457
--
Bob Tracy | "They couldn't hit
Current progress: 11 revisions left to test. The current partial
git bisect log is available per Ingo's suggestion on bugzilla.
http://bugzilla.kernel.org/show_bug.cgi?id=9457
--
Bob Tracy | They couldn't hit an
Ingo Molnar wrote:
> once you are done with the download of the initial cloned git repository
> (which is 200MB+), all the bisection steps will be local and you'll be
> only limited by kernel rebuild speed and by bootup and testing speed,
> not by network bandwidth.
ACK. Have tested two
* Bob Tracy <[EMAIL PROTECTED]> wrote:
> Finally got back in town. Starting the git-bisect process. I've got
> a relatively slow network connection, and the PWS 433au isn't exactly
> what I would call "fast" by modern standards, so bear with me while I
> get things set up and crank through
* Bob Tracy [EMAIL PROTECTED] wrote:
Finally got back in town. Starting the git-bisect process. I've got
a relatively slow network connection, and the PWS 433au isn't exactly
what I would call fast by modern standards, so bear with me while I
get things set up and crank through this.
Ingo Molnar wrote:
once you are done with the download of the initial cloned git repository
(which is 200MB+), all the bisection steps will be local and you'll be
only limited by kernel rebuild speed and by bootup and testing speed,
not by network bandwidth.
ACK. Have tested two kernels
Michael Cree wrote:
> On 1/12/2007, at 11:42 AM, Andrew Morton wrote:
> > On Sat, 01 Dec 2007 11:30:01 +1300
> > Michael Cree <[EMAIL PROTECTED]> wrote:
> >
> >> Bob Tracy wrote:
> >>> Here's
> >>> hoping someone else is seeing this or can replicate it in the
> >>> meantime.
> >>
> >> Snap.
>
On 1/12/2007, at 11:42 AM, Andrew Morton wrote:
On Sat, 01 Dec 2007 11:30:01 +1300
Michael Cree <[EMAIL PROTECTED]> wrote:
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get
On 1/12/2007, at 11:42 AM, Andrew Morton wrote:
On Sat, 01 Dec 2007 11:30:01 +1300
Michael Cree [EMAIL PROTECTED] wrote:
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get disabled.
Michael Cree wrote:
On 1/12/2007, at 11:42 AM, Andrew Morton wrote:
On Sat, 01 Dec 2007 11:30:01 +1300
Michael Cree [EMAIL PROTECTED] wrote:
Bob Tracy wrote:
Here's
hoping someone else is seeing this or can replicate it in the
meantime.
Snap.
2.6.24-rc2 works fine.
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get disabled.
Here's
hoping someone else is seeing this or can replicate it in the meantime.
Snap.
2.6.24-rc2 works fine.
On Friday, 30 of November 2007, Andrew Morton wrote:
> On Sat, 01 Dec 2007 11:30:01 +1300
> Michael Cree <[EMAIL PROTECTED]> wrote:
>
> > Bob Tracy wrote:
> > > Andrew Morton wrote:
> > >> Could be something change in sysfs. Please double-check the config
> > >> options, make sure that something
On Sat, 01 Dec 2007 11:30:01 +1300
Michael Cree <[EMAIL PROTECTED]> wrote:
> Bob Tracy wrote:
> > Andrew Morton wrote:
> >> Could be something change in sysfs. Please double-check the config
> >> options, make sure that something important didn't get disabled.
> >>
> > Here's
> > hoping someone
On Sat, 01 Dec 2007 11:30:01 +1300
Michael Cree [EMAIL PROTECTED] wrote:
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get disabled.
Here's
hoping someone else is seeing
On Friday, 30 of November 2007, Andrew Morton wrote:
On Sat, 01 Dec 2007 11:30:01 +1300
Michael Cree [EMAIL PROTECTED] wrote:
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get disabled.
Here's
hoping someone else is seeing this or can replicate it in the meantime.
Snap.
2.6.24-rc2 works fine.
Andrew Morton wrote:
> Could be something change in sysfs. Please double-check the config
> options, make sure that something important didn't get disabled.
>
> Failing that, it would be great if you could bisect this down to the
> offending commit.
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get disabled.
Failing that, it would be great if you could bisect this down to the
offending commit. http://www.kernel.org/doc/local/git-quick.html has
On Sunday, 25 of November 2007, Andrew Morton wrote:
> On Sat, 17 Nov 2007 23:20:36 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
>
> > Completely reproducible... 2.6.23-rc3 kernel boots, and normal messages
> > are seen on console as far as disks found and partitions on each. However,
> >
On Sunday, 25 of November 2007, Andrew Morton wrote:
On Sat, 17 Nov 2007 23:20:36 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
Completely reproducible... 2.6.23-rc3 kernel boots, and normal messages
are seen on console as far as disks found and partitions on each. However,
once /dev
On Sat, 17 Nov 2007 23:20:36 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
> Completely reproducible... 2.6.23-rc3 kernel boots, and normal messages
> are seen on console as far as disks found and partitions on each. However,
> once /dev is populated and the boottime scripts attempt to check
On Sat, 17 Nov 2007 23:20:36 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
Completely reproducible... 2.6.23-rc3 kernel boots, and normal messages
are seen on console as far as disks found and partitions on each. However,
once /dev is populated and the boottime scripts attempt to check
78 matches
Mail list logo
