On Sun, Jan 21, 2001 at 11:35:49PM -0800, John Baldwin wrote:
>
> On 22-Jan-01 Donald J . Maddox wrote:
> >
> > 1) rm -r /usr/include; cd /usr/src; make includes
>
> I just do 'make includes' w/o the rm of /usr/include when I do this..
I used to do 'm
Ok, fair enough. I have to confess that my usual procedure remains,
as it has been for a long time, like this:
1) rm -r /usr/include; cd /usr/src; make includes
This may be controversial, but it has always worked for me, and although
it's not supposed to (in my understanding), the build (I thin
On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote:
>
> Argh! I wish people would stop using buildkernel! :-( It calls config(8)
> in such a way that buries the warning messages where people dont see.
> config(8) is meant to be used interactively :-(
Is there another target that will ge
On Sun, Jan 21, 2001 at 03:29:22PM -0800, Kris Kennaway wrote:
> On Sun, Jan 21, 2001 at 06:05:20AM -0500, Donald J . Maddox wrote:
>
> > It may have absolutely nothing to do with either of these cases, but
> > I found out the hard way recently that booting with no device.hints
If it helps at all, it's marginal. I still get skips.
On Sat, Jan 20, 2001 at 05:36:08PM +0200, Mark Murray wrote:
> > This is directly traceable to entropy harvesting by /dev/*random.
> > I know it's not an option if you need to use ssh, but not loading
> > random.ko will fix the sound problems
This is directly traceable to entropy harvesting by /dev/*random.
I know it's not an option if you need to use ssh, but not loading
random.ko will fix the sound problems when moving the mouse or
typing. It doesn't fix the 'hwptr went backwards' messages, though.
On Fri, Jan 19, 2001 at 11:42:32P
Ok, thanks for the info... But this begs the question: Why does the
code limit maxdeps to 8?
On Sun, Dec 24, 2000 at 11:50:13AM -0800, Mike Smith wrote:
> > Last night I installed a kernel with 'device acpica' for the 1st
> > time, and all seems fine, except that I see this at boot:
> ...
> > t
Last night I installed a kernel with 'device acpica' for the 1st
time, and all seems fine, except that I see this at boot:
.
.
.
npx0: on motherboard
npx0: INT 16 interface
too many dependant configs
too many dependant configs
too many dependant configs
too many dependant configs
atkbdc0: at po
On Wed, Dec 20, 2000 at 10:43:39AM -0800, David O'Brien wrote:
> On Wed, Dec 20, 2000 at 05:28:45AM -0500, Donald J . Maddox wrote:
> >
> > How can you be using the same X libs as me, and not be using
> > XFree86?
>
> XFree86 has many components to it -- bina
On Wed, Dec 20, 2000 at 10:14:09AM -0800, David O'Brien wrote:
> On Wed, Dec 20, 2000 at 11:15:55PM +1000, Stephen McKay wrote:
> > Correcting slightly for your slightly off assumption: The X11 libs were
> > probably built on a 3.x box. Their problem is that being newer than
> > libc.so.2.2 (or w
Interesting. After I installed the XFree86-aoutlibs port, SimCity
works fine for me (on an 8-bit display)...
It didn't work with the X libs built by the port when aout libs
are requested, and it didn't work with the X libs from 3.3.6, but
it works with these.
> > Looks good. Can you install th
On Wed, Dec 20, 2000 at 02:24:26AM -0800, David O'Brien wrote:
> On Wed, Dec 20, 2000 at 05:09:45AM -0500, Donald J . Maddox wrote:
> > >res> ldd sim
> > sim:
> > -lXext.6 => /usr/X11R6/lib/aout/libXext.so.6.3 (0x200c5000)
> > -lX11.6 => /
On Wed, Dec 20, 2000 at 01:52:23AM -0800, David O'Brien wrote:
> On Wed, Dec 20, 2000 at 03:57:07AM -0500, Donald J . Maddox wrote:
> > Looks like you got a lot farther than I did with it... Are you
> > sure you don't have an old aout ld.so on that machine?
>
>
Actually, the aout libs I am using when I get the ___error undefined
are the ones from the XFree86-3.3.6 distribution, compiled for
FreeBSD 3.x. Originally I was using the aout X libs I built myself
when building the XFree86-3.3.6 port. Using those, I still got an
undefined symbol, but it wasn'
Looks like you got a lot farther than I did with it... Are you
sure you don't have an old aout ld.so on that machine? Here's
what I get:
>dmaddox> SimCity
Starting SimCity ...
SimCity Classic - UNIX / Tcl & Tk Toolkit version 3.6b - Mattes
/usr/libexec/ld.so: Undefined symbol "___error" called
I apologized in advance, and I do again, but I have no way of
knowing if Ollivier is subscribed to -chat. Thanks for
understanding. Further discssion has been moved to chat.
On Wed, Dec 20, 2000 at 08:19:34AM +0200, Mark Murray wrote:
> This is offtopic! If you need to discuss it, please take i
modems here
Last-Attempt-Date: Tue, 19 Dec 2000 18:19:38 -0500 (EST)
On Tue, Dec 19, 2000 at 09:56:36PM +0100, Ollivier Robert wrote:
> According to Donald J . Maddox:
> > open. Also, why the odd format in the addresses?
>
> Looks like some kind of IPv6 address...
You're ri
On Tue, Dec 19, 2000 at 09:56:36PM +0100, Ollivier Robert wrote:
> According to Donald J . Maddox:
> > open. Also, why the odd format in the addresses?
>
> Looks like some kind of IPv6 address...
You're right. I compiled the new kernel with IPV6 enabled. I
didn't
You're right that the answer to my question was IPV6 (I didn't have
it compiled into the previous kernel). You're wrong that a port
need not be open to receive connections. You will note in the
log excerpt below that these are connection *attempts*, not actual
connections.
On Tue, Dec 19, 2000
On Tue, Dec 19, 2000 at 07:33:49PM +0100, Szilveszter Adam wrote:
> On Tue, Dec 19, 2000 at 01:20:57PM -0500, Donald J . Maddox wrote:
> > After my latest update, I am getting LOTS of the following in my logs:
> >
> > Dec 19 12:21:04 cae88-102-101 /boot/kernel/kernel: Conn
After my latest update, I am getting LOTS of the following in my logs:
Dec 19 12:21:04 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25
from ::0001:1286
Dec 19 12:24:08 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25
from ::0001:1299
Dec 19 12:27:13
You don't need a CDROM... You can get it from:
ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/commerce/games/SimCity/SimCity-3.6b.tgz
On Mon, Dec 18, 2000 at 10:03:15AM -0800, David O'Brien wrote:
> On Tue, Dec 19, 2000 at 01:00:28AM +1000, Stephen McKay wrote:
> > So we could in principle b
Well, if you do manage to uncover the lost magic, please let me
know :)
On Mon, Dec 18, 2000 at 04:41:17PM +1000, Stephen McKay wrote:
>
> I expected some build tool expert to say "Just compile with these
> options". But they haven't. So I'll see if the bits have rotted,
> or whether we can ke
reinstall from scratch a while back by installing
4.2-RELEASE and then cvsupping back to -current, so I
guess I lost my working aout ld.so in the process. Bummer :(
On Mon, Dec 18, 2000 at 02:58:16AM +1000, Stephen McKay wrote:
> On Saturday, 16th December 2000, "Donald J . Maddox" wrote:
&g
The other day, on a whim, I decided to try running an old binary
of SimCity (the same one found in the 'commerce' directory on
many FBSD cds), and it failed in a odd way...
/usr/libexec/ld.so: Undefined symbol "___error" called from
sim:/usr/X11R6/lib/aout/libX11.so.6.1 at 0x20160644
# ldd sim
I don't think so... I am -current as of yesterday and my manpages
are displaying just fine, headers and all.
On Fri, Dec 08, 2000 at 06:05:01PM -0500, Brandon D. Valentine wrote:
> On Fri, 8 Dec 2000, Thomas D. Dean wrote:
>
> >Since a 12/6 cvsup and 'make world', I notice a problem with the
>
if_dc.ko
82 0xc037e000 10004miibus.ko
91 0xc038f000 76e0 linprocfs.ko
On Mon, Dec 04, 2000 at 09:59:31PM -0500, Donald J . Maddox wrote:
> Just as a data point, I just tried this as well... The daemon saver was ok,
> the fire saver was ok, but as soon as I loaded logo_sav
Just as a data point, I just tried this as well... The daemon saver was ok,
the fire saver was ok, but as soon as I loaded logo_saver and it activated,
I got a 'dc0 timeout'(?) and I was unable to access any of the vtys after
that... I could switch vtys, but could not type anything.
The fire_sa
Thanks! This works great. I remember reading the stuff at the
bottom of /boot/defaults/loader.conf about the 'module_name'
variable, etc. and wondering what on Earth it might be useful for :)
Guess I know now :) Thanks again...
"Daniel C. Sobral" wrote:
>Use two variables to control this. For
ised that this works on Linux, shouldn't our emulator emulate
this behavior too?
On Tue, Nov 28, 2000 at 07:03:38PM -0500, Marcel Moolenaar wrote:
> "Donald J . Maddox" wrote:
> >
> > I actually thought that COMPAT_LINUX had been completely removed, just
> > cau
deprecated a while back...
On Tue, Nov 28, 2000 at 06:22:33PM -0500, Marcel Moolenaar wrote:
> "Donald J . Maddox" wrote:
> >
> > Also, it doesn't seem to be possible to compile 'device tdfx'
> > statically into the kernel either, since it d
The standard way of loading a particular module at boot from
/boot/loader.conf is 'modulename_load="YES"', right? This
doesn't seem to be possible with the 3dfx module, however...
Since it's name starts with a number, it causes a syntax error.
Being FORTH-impaired, I have no idea how to work aro
Thanks again, Daniel... I'll take a look. If the ID isn't in there,
I'll submit a PR to get it added. (should only take about 10-12
months to actually get it comitted, if experience is a reliable guide :-/)
On Sun, Sep 26, 1999 at 10:09:58PM +0200, D. Rock wrote:
> "Don
It's defined in sys/boot/common/bootstrap.h. I think all you want to know
is in that file.
On Tue, Oct 12, 1999 at 09:46:12PM -0400, Chuck Robey wrote:
> I'm looking at sys/boot/common/pnp.c so I can find out how pnp is handled,
> and I found something called a COMMAND_SET, and I can't figure ou
case, the issue is easily resolvable. I will just build a kernel
with bpf and no tun0, and see if 'tun0 as kld' works with bpf :-)
On Mon, Sep 27, 1999 at 04:53:21PM -0700, John-Mark Gurney wrote:
> Donald J . Maddox scribbled this message on Sep 26:
> > I see that support has be
Thanks, Doug. Peter already provided an equivalent patch, and I am
happy to report that it works like a charm (of course :-)).
On Mon, Sep 27, 1999 at 10:35:46AM +0100, Doug Rabson wrote:
> On Sun, 26 Sep 1999, Donald J . Maddox wrote:
>
> > I couldn't get my PnP Creative AW
God knows, I'll second that one... :-) Hear, hear!
On Sun, Sep 26, 1999 at 07:39:27PM -0700, Darryl Okahata wrote:
> I want to publicly thank Peter Wemm for posting a reply that is
> courteous, informative, and useful. Recently, there has been too much
> noise in this and other FreeBSD lis
On Mon, Sep 27, 1999 at 05:05:37AM +0800, Peter Wemm wrote:
>
> The old PnP code was matching on the card vendor ID. The new pnp code
> treats each logical device on it's own and matches by logical ID..
> (It's actually far more useful that way as most cards have their own
> manufacturer ID but
On Sun, Sep 26, 1999 at 02:29:43PM -0700, Mike Smith wrote:
> > Again, thanks for the very helpful and informative answers. I would still
> > appreciate it if someone could give me a little bit more of a clue as to
> > what is necessary to add newPnP-awareness to the AWE driver, though.
> > (S
While your response seems a bit strong, to say the least, I confess
that the redirection was a real mistake... I thought Mike had replied
to me on the list and I had hit 'r' by accident, instead of 'g', in
mutt. My apologies to Mike.
On Sun, Sep 26, 1999 at 05:10:30PM -0400, Bill Fumerola wrote
On Sun, Sep 26, 1999 at 02:23:18PM -0700, Mike Smith wrote:
> > Can you give me a few hints on what would be necessary to get the old
> > driver to work with the new PnP?
>
> As has already been explained to you (you _do_ read these messages in
> their entirety, right?), the old driver has been
Thanks. That is exactly what I have done. The AWE device cannot
work this way, but everything else is functional if I remove the
PnP controller from my kernel...
On Sun, Sep 26, 1999 at 10:04:38PM +0200, D. Rock wrote:
> "Donald J . Maddox" schrieb:
> > Is the new PnP code r
Ok, will do. Thanks.
This may be a silly question, but... The old PnP driver recognized
a lot of devices, including my AWE64. Isn't there a list of IDs it
was aware of that should be merged into newPnP ASAP?
On Mon, Sep 27, 1999 at 04:27:42AM +0800, Peter Wemm wrote:
> Please try the followin
On Sun, Sep 26, 1999 at 11:59:33AM -0700, Mike Smith wrote:
> > On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
> > >
> > > PnP is an infrastructure facility used by drivers to detect and
> > > configure hardware. The side-effect you were relying on was that the
> > > old code woul
I couldn't get my PnP Creative AWE64G to work with the new PnP
code, so I tried compiling a kernel with pcm instead. All I get is:
unknown0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0
unknown1: at port 0x200-0x207 on isa0
unknown2: at port 0x620-0x623 on isa0
It is my
On Sun, Sep 26, 1999 at 12:29:46PM -0700, Mike Smith wrote:
> >
> > But we do have a working driver for the AWE64. Or rather, it worked fine
> > before the new PnP code was comitted, now it doesn't. It seems to me that
> > this indicates a deficiency in the new PnP code. Isn't that correct?
>
On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
>
> PnP is an infrastructure facility used by drivers to detect and
> configure hardware. The side-effect you were relying on was that the
> old code would indiscriminately configure any and all PnP hardware
> regardless of whether a
I see that support has been added for demand-loading network
if drivers. I seem to recall that the last time I tried using
network drivers as klds, nothing that required bpf to work
was functional anymore, because bpf required that the device
existed at the time it was initialized. Is this still
ep 26, 1999 at 01:42:09PM -0400, Gary Palmer wrote:
> "Donald J . Maddox" wrote in message ID
> <[EMAIL PROTECTED]>:
> > Ummm... I'm not screaming anything, Gary. The intent of my message is
> > just to let the authors of this code know that it is *not* equal in
On Sun, Sep 26, 1999 at 01:11:55PM -0400, Gary Palmer wrote:
> "Donald J . Maddox" wrote in message ID
> <[EMAIL PROTECTED]>:
> > I'm just suggesting here that it would be nice if the authors of
> > this code would make it _equally functional_ to what w
On Sun, Sep 26, 1999 at 10:51:59AM -0700, Mike Smith wrote:
> > Sigh. Again, I didn't demand anything.
> >
> > I simply pointed out that functionality had been lost. If I
> > was the author of this code, I would *want* feedback on how
> > it was working out for people out here in userland. I a
The whole point is that I want to be able to use the wavetable
synthesis features of the card. Newpcm (or oldpcm, for that matter)
provides NO support for the AWE device whatsoever, as you can see
from your dmesg below.
It makes little sense to me that PnP functionality should be tied
down to a
The new PnP code just plain does not work for my PnP AWE64.
If I configure like this:
controller pnp0
controller snd0
device sb0
device sbxvi0
device sbmidi0
device awe0
device opl0
device joy0
Which is the way it *should* work, in
After last night's new kernel and 'make world', I find I am seeing
some interesting new warnings at boot time:
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #0:
On Mon, Mar 15, 1999 at 07:16:24PM +0900, Daniel C. Sobral wrote:
> "Donald J . Maddox" wrote:
> >
> > If you are *really* -current, /boot/loader.rc should probably
> > just contain something like:
> >
> > include /boot/loader.4th
> > st
After a 'make world' last night, everytime I use any of the AWE
utilities (as ported by Randall Hopper) I get this:
AWE32: unsupported ioctl -1064546046
AWE32: unsupported ioctl -1064546046
I remember seeing a couple of commits to some of the files in
sys/i386/isa/sound, but I don't remember exa
The answer depends on exactly how current you are...
With -current from a few days ago, I would have said:
Make sure you have a /boot/loader.rc file that contains at least
these lines:
load /kernel
load -t /boot.config
Then, make sure /boot.config contains all the stuff that you would
normally
As some of you may have noticed, apsfilter will no longer
compile on -current. The reason is that the configure
script checks for , and uses it if it exists;
but this file, as I understand it, is intended only for
use with C99, and unfortunately, if it is included by the
standard compiler, the re
After rebuilding World and kernel last night, I find that the behavior of
'netstat -a' has changed... Only UNIX domain sockets are shown in the
output, no inet stuff at all, e.g.:
# netstat -a
Active UNIX domain sockets
Address Type Recv-Q Send-QInode Conn Refs Nextref Addr
cbf67
It's defined in sys/boot/common/bootstrap.h. I think all you want to know
is in that file.
On Tue, Oct 12, 1999 at 09:46:12PM -0400, Chuck Robey wrote:
> I'm looking at sys/boot/common/pnp.c so I can find out how pnp is handled,
> and I found something called a COMMAND_SET, and I can't figure ou
case, the issue is easily resolvable. I will just build a kernel
with bpf and no tun0, and see if 'tun0 as kld' works with bpf :-)
On Mon, Sep 27, 1999 at 04:53:21PM -0700, John-Mark Gurney wrote:
> Donald J . Maddox scribbled this message on Sep 26:
> > I see that support has be
Thanks, Doug. Peter already provided an equivalent patch, and I am
happy to report that it works like a charm (of course :-)).
On Mon, Sep 27, 1999 at 10:35:46AM +0100, Doug Rabson wrote:
> On Sun, 26 Sep 1999, Donald J . Maddox wrote:
>
> > I couldn't get my PnP Creative AW
God knows, I'll second that one... :-) Hear, hear!
On Sun, Sep 26, 1999 at 07:39:27PM -0700, Darryl Okahata wrote:
> I want to publicly thank Peter Wemm for posting a reply that is
> courteous, informative, and useful. Recently, there has been too much
> noise in this and other FreeBSD lis
While your response seems a bit strong, to say the least, I confess
that the redirection was a real mistake... I thought Mike had replied
to me on the list and I had hit 'r' by accident, instead of 'g', in
mutt. My apologies to Mike.
On Sun, Sep 26, 1999 at 05:10:30PM -0400, Bill Fumerola wrote
On Sun, Sep 26, 1999 at 02:29:43PM -0700, Mike Smith wrote:
> > Again, thanks for the very helpful and informative answers. I would still
> > appreciate it if someone could give me a little bit more of a clue as to
> > what is necessary to add newPnP-awareness to the AWE driver, though.
> > (S
On Sun, Sep 26, 1999 at 02:23:18PM -0700, Mike Smith wrote:
> > Can you give me a few hints on what would be necessary to get the old
> > driver to work with the new PnP?
>
> As has already been explained to you (you _do_ read these messages in
> their entirety, right?), the old driver has been
On Mon, Sep 27, 1999 at 05:05:37AM +0800, Peter Wemm wrote:
>
> The old PnP code was matching on the card vendor ID. The new pnp code
> treats each logical device on it's own and matches by logical ID..
> (It's actually far more useful that way as most cards have their own
> manufacturer ID but
Ok, will do. Thanks.
This may be a silly question, but... The old PnP driver recognized
a lot of devices, including my AWE64. Isn't there a list of IDs it
was aware of that should be merged into newPnP ASAP?
On Mon, Sep 27, 1999 at 04:27:42AM +0800, Peter Wemm wrote:
> Please try the followin
Thanks again, Daniel... I'll take a look. If the ID isn't in there,
I'll submit a PR to get it added. (should only take about 10-12
months to actually get it comitted, if experience is a reliable guide :-/)
On Sun, Sep 26, 1999 at 10:09:58PM +0200, D. Rock wrote:
> "Don
Thanks. That is exactly what I have done. The AWE device cannot
work this way, but everything else is functional if I remove the
PnP controller from my kernel...
On Sun, Sep 26, 1999 at 10:04:38PM +0200, D. Rock wrote:
> "Donald J . Maddox" schrieb:
> > Is the new PnP code r
On Sun, Sep 26, 1999 at 12:29:46PM -0700, Mike Smith wrote:
> >
> > But we do have a working driver for the AWE64. Or rather, it worked fine
> > before the new PnP code was comitted, now it doesn't. It seems to me that
> > this indicates a deficiency in the new PnP code. Isn't that correct?
>
On Sun, Sep 26, 1999 at 11:59:33AM -0700, Mike Smith wrote:
> > On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
> > >
> > > PnP is an infrastructure facility used by drivers to detect and
> > > configure hardware. The side-effect you were relying on was that the
> > > old code woul
On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
>
> PnP is an infrastructure facility used by drivers to detect and
> configure hardware. The side-effect you were relying on was that the
> old code would indiscriminately configure any and all PnP hardware
> regardless of whether a
I see that support has been added for demand-loading network
if drivers. I seem to recall that the last time I tried using
network drivers as klds, nothing that required bpf to work
was functional anymore, because bpf required that the device
existed at the time it was initialized. Is this still
I couldn't get my PnP Creative AWE64G to work with the new PnP
code, so I tried compiling a kernel with pcm instead. All I get is:
unknown0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0
unknown1: at port 0x200-0x207 on isa0
unknown2: at port 0x620-0x623 on isa0
It is my
On Sun, Sep 26, 1999 at 10:51:59AM -0700, Mike Smith wrote:
> > Sigh. Again, I didn't demand anything.
> >
> > I simply pointed out that functionality had been lost. If I
> > was the author of this code, I would *want* feedback on how
> > it was working out for people out here in userland. I a
ep 26, 1999 at 01:42:09PM -0400, Gary Palmer wrote:
> "Donald J . Maddox" wrote in message ID
> <[EMAIL PROTECTED]>:
> > Ummm... I'm not screaming anything, Gary. The intent of my message is
> > just to let the authors of this code know that it is *not* equal in
On Sun, Sep 26, 1999 at 01:11:55PM -0400, Gary Palmer wrote:
> "Donald J . Maddox" wrote in message ID
> <[EMAIL PROTECTED]>:
> > I'm just suggesting here that it would be nice if the authors of
> > this code would make it _equally functional_ to what w
The whole point is that I want to be able to use the wavetable
synthesis features of the card. Newpcm (or oldpcm, for that matter)
provides NO support for the AWE device whatsoever, as you can see
from your dmesg below.
It makes little sense to me that PnP functionality should be tied
down to a
The new PnP code just plain does not work for my PnP AWE64.
If I configure like this:
controller pnp0
controller snd0
device sb0
device sbxvi0
device sbmidi0
device awe0
device opl0
device joy0
Which is the way it *should* work, in
After last night's new kernel and 'make world', I find I am seeing
some interesting new warnings at boot time:
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #0:
After a 'make world' last night, everytime I use any of the AWE
utilities (as ported by Randall Hopper) I get this:
AWE32: unsupported ioctl -1064546046
AWE32: unsupported ioctl -1064546046
I remember seeing a couple of commits to some of the files in
sys/i386/isa/sound, but I don't remember exac
On Mon, Mar 15, 1999 at 07:16:24PM +0900, Daniel C. Sobral wrote:
> "Donald J . Maddox" wrote:
> >
> > If you are *really* -current, /boot/loader.rc should probably
> > just contain something like:
> >
> > include /boot/loader.4th
> > st
Yeah, you're right on all counts, of course...
I've answered this question so many times in
the last 10 days that I'm starting to go on
autopilot :-/
Robert Nordier wrote:
>
> Donald J . Maddox wrote:
>
> > The answer depends on exactly how current you are...
&g
The answer depends on exactly how current you are...
With -current from a few days ago, I would have said:
Make sure you have a /boot/loader.rc file that contains at least
these lines:
load /kernel
load -t /boot.config
Then, make sure /boot.config contains all the stuff that you would
normally
Since building a new kernel and a full 'make world' on Jan 24,
I am seeing this at boot:
avail memory = 62210048 (60752K bytes)
Preloaded elf kernel "kernel" at 0xf02cc000.
Preloaded elf module "msdos.ko" at 0xf02cc09c.
Preloaded elf module "procfs.ko" at 0xf02cc13c.
Preloaded elf module "if_tun.k
On Sun, Jan 24, 1999 at 01:47:25PM -0600, Stingray wrote:
> I just CVSup'd 4.0-current and installed it, then made an elf kernel.
> The elf kernel seemed to boot up just fine, but when the file systems
> where being mounted, it couldn't mount /:
>
> Specified device does not match mounted de
On Sun, Jan 24, 1999 at 10:35:23AM -0500, Tom Torrance at home wrote:
> After a cvsup this AM, the boot process failed when attempting
> to mount the root partition, with the message:
> specified device does no match mounted device.
>
> I had to change the device specification in /etc/fstab from
>
88 matches
Mail list logo
