Alfred Perlstein wrote:
What's really needed is some warning sort of like what we
did when the AOUT-ELF convertion happened, there has
to be a simple way to test this as part of installworld.
Yes, that's exactly what I had in mind. Details still need to be worked
out, though.
--
Marcel
[cc list trimmed]
John-Mark Gurney wrote:
actually, no, I would like this fixed... I will be unable to develope
FreeBSD if the tools target doesn't work!! I do all of my compiles on
a 3.0-R box (yes, that's right, 3.0-R) and it will basicly stop me from
doing any of that...
I'm not sure
Marcel Moolenaar scribbled this message on Sep 30:
[cc list trimmed]
John-Mark Gurney wrote:
actually, no, I would like this fixed... I will be unable to develope
FreeBSD if the tools target doesn't work!! I do all of my compiles on
a 3.0-R box (yes, that's right, 3.0-R) and it will
I know this is not topic related, so appologies in advance ...
Sometimes people deserve a pat on the back.
This is the best thing since Chocolate Chip cookies :)
We're running things like myth2_demo, and it opens the doors
to a whole bunch of applications ... e.g. C++ Builder to follow
next
Without proper linux support we are dead .
Now I have to get off my soap box and let the work continue 8)
Best Regards
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Amancio Hasty wrote:
BTW: I think that what you are doing is really great !!
Thanks!
Hmm... I wonder if the volume in the list will increase with cool
apps such as IBM's ViaVoice which needs your mods to work.
Already Linux binaries have been tested and confirmed working with the
new
Richard Wackerbarth wrote:
There is nothing fundamental in the toolset which SHOULD care about the
underlying kernel. Compilers, loaders, etc. are just programs that operate on
the contents of files. Think of compiling the 4.0 system on a 3.3 system as a
simpler case of cross compiling. I
John-Mark Gurney wrote:
but I'm developing for -current... I do a buildworld on my 3.0-R box
and move it over to the box after it's complete... I'm not sure about
you, but doing a buildworld over nfs w/ a processor that is sub p133
is not something that really works to well...
Ah, now I
On Thu, Sep 30, 1999 at 01:41:41PM +1000, Peter Jeremy wrote:
On Thu, Sep 30, 1999 at 01:29:40AM +1000, Marcel Moolenaar wrote:
Before attempting to build world, you must make and install a new
kernel. The new kernel will contain new syscalls that are needed during
build world. doscmd is
At 9:10 pm +0100 29/9/99, Josef Karthauser wrote:
On Wed, Sep 29, 1999 at 04:58:34PM +, Bob Bishop wrote:
[...]
I now suspect that cvsup.uk.freebsd.org isn't up-to-date. Anyone know
anything?
[...]
In summary - sorry, try again. 'Tis working now :)
Yup, looks like we're back in business
On Wed, 29 Sep 1999 14:20:25 GMT, Bob Bishop wrote:
=== usr.sbin/lpr/filters.ru
=== usr.sbin/lpr/filters.ru/koi2alt
make: don't know how to make koi2alt.c. Stop
Looks like you haven't updated in a while.
Apparently because...
moved to koi2alt
...never made it
It wasn't a problem in -current due to a different way that things
were done there.
What things, exactly? I haven't noticed any differences in
vfs_cache.c or vfs_subr.c that should affect the caching behavior, so
it must just be that the system survives a large amount of wired down
memory
On Thu, Sep 30, 1999 at 09:19:47AM +0200, Marcel Moolenaar wrote:
Alfred Perlstein wrote:
What's really needed is some warning sort of like what we
did when the AOUT-ELF convertion happened, there has
to be a simple way to test this as part of installworld.
Yes, that's exactly what I
At 10:17 PM + 1999/9/29, Adam Strohl wrote:
Furthermore, for when 4.0 becomes a -R or -S, ftping in a compiled kernel
shouldn't be that hard of a price to pay for going from 3.2.
/stand/sysinstall based upgrades could easily seemlessly take care of
this, too.
I must confess
Hi,
In the recent discussion about the breakage of the upgrade path from
-stable to -current numerous suggestions and other kinds of remarks have
been made. In this light I have the following proposal. Please share
your thoughts...
NOTE: This proposal only discusses upgrading from -stable to
Since the new sound code has been committed, my cheapo Opti931
sound card hasn't been working. Hopefully with the dmesg and
pnpinfo output which is attached, somebody can add the proper
vendor IDs. Much appreciated.
Neal
Checking for Plug-n-Play devices...
Card assigned CSN #1
Vendor ID
On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote:
The problem
---
When doing a make world, tools are being built that are used by the
build process. This is to make sure that the tools are appropriate for
doing a make world. The problem we now face is that the
Marcel Moolenaar wrote:
Pros
o It increases inoperability between -stable and -current.
I mean decreases inoperability or increases operability of course :-/
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking Databases
On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote:
So, the problem can be split into:
A) New syscalls using the new sigset_t (sigaction and so on)
B) A new sigframe (new siginfo, no sigcontext but ucontext_t)
"I'm probably missing something, but..." (TM)
The new syscall
On Thu, 30 Sep 1999, Marcel Moolenaar wrote:
Sub-problem B (sigframe) doesn't need to be handled, because:
1. none of the tools require ...
Correct, this is a "non-problem".
Sub-problem A (syscalls) can be easily handled if the syscalls are added
to a -stable kernel.
Wrong. I CANNOT
As a fresh idea (probably stupid, but anyway):
Why we can't load compile and small KLD with all necessary syscalls (even
probably stubs) to build 4.0 world when someone trying to build it on top
of 3.*?
-Maxim
--
"We believe in the Power and the Might!"
(Manowar, 1996)
Hi,
In the recent discussion about the breakage of the upgrade path from
-stable to -current numerous suggestions and other kinds of remarks have
been made. In this light I have the following proposal. Please share
your thoughts...
NOTE: This proposal only discusses upgrading from
Maxim Sobolev wrote:
Why we can't load compile and small KLD with all necessary syscalls (even
^^^
I mean ".load and compile small". Cut and paste technology sometimes
plays bad jokes with us.;)
-Max
To Unsubscribe: send mail to [EMAIL
Fry´s was out of Intel 100/10 ethernet cards, so I bought a Linksys
LNE100TX remembering that I there was a driver for it.
I added
device pn0
to my kernel configuration and compiled the kernel. It was not detected
during boot. I added the mii_bus0 controller just in case. Recompiled
Ilya Pekshev wrote:
seems that something wrong went with last updates made to
signal.h, param.h and user.h in 4.0-CURRENT
after last cvsup can't compile ps, vmstat and libkvm.
Any thoughs what's wrong?
Do a make world. Make a new kernel before doing that. You need the new
libraries and
Marcel Moolenaar wrote:
As for AMD, I don't use it. I'll dig into manpages, source code and
whatsnot. If possible I'll reconfigure something here so that I can test
it on a i386.
Thanks. I'll try to get you a stack trace from it today if I can
find time.
BTW: I'm sorry, that a simple bug
I've installed -current on an x86 laptop, and ran cvsup to update
all sources. I build and booted a new kernel (PCCARD). The
buildworld dies at:
cc -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include
-D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale
Kenneth Wayne Culver wrote:
commit. But even then I still ran into problems, although I'm not sure how
closely related they are to the changes made. My problems seem to be with
the Soren's ata drivers.
I'm using Soren's ATA drivers myself without problems. Admitted, I'm
only using it to play
Hmmm...I believe mine is s LNE100TX...I know it's a Linksys, and it's a
10/100 PCI..and it's runnin fine under Current (last make world was about a
week ago), as pn0
in my config:
device pn0 # Lite-On 82c168/82c169 (``PNIC'')
and from dmesg | grep pn0 :
pn0: 82c169 PNIC 10/100BaseTX
Bill Paul wrote:
Of all the gin joints in all the towns in all the world, Edwin Culp had
to walk into mine and say:
Fry´s was out of Intel 100/10 ethernet cards, so I bought a Linksys
LNE100TX remembering that I there was a driver for it.
No, you bought an LNE100TX v2.0, forgetting that
Leonard Sitongia wrote:
I've installed -current on an x86 laptop, and ran cvsup to update
all sources. I build and booted a new kernel (PCCARD). The
buildworld dies at:
cc -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include
-D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE
I would have to agree with that. I have never seen such a well documented
commit. But even then I still ran into problems, although I'm not sure how
closely related they are to the changes made. My problems seem to be with
the Soren's ata drivers. The good old "lost contact with device" messages
Maxim Sobolev scribbled this message on Sep 30:
[-- Warning: koi8-r is not compatible with your display.]
Maxim Sobolev wrote:
Why we can't load compile and small KLD with all necessary syscalls (even
^^^
I mean ".load and compile small". Cut
I don't seem to see (after not looking very hard) any ASSERT macros for
the kernel in FreeBSD. It'd be pretty easy to add them, and they're
awfully useful. They're different from INVARIANT support in that they
encapsulate (and panic if the assertion is triggered) more inline types of
conditions.
Marcel Moolenaar scribbled this message on Sep 30:
Try -DNOTOOLS. I don't know if the -current sources depend specifically
on -current tools (such as egcs).
well, this may work, but it still doesn't produce a "clean" system to
build with... I don't know the number of times that I've used the
Douglas Kuntz wrote:
Hmmm...I believe mine is s LNE100TX...I know it's a Linksys, and it's a
10/100 PCI..and it's runnin fine under Current (last make world was about a
week ago), as pn0
in my config:
device pn0 # Lite-On 82c168/82c169 (``PNIC'')
and from dmesg | grep pn0 :
"Rodney W. Grimes" wrote:
IMHO, the only ``correct'' fix for the latest incarnation of the
problem is to finally once and for all fix the cross compilation
environment instead of using a half cooked tools: target to deal
with certain problems.
brainstorm:
Upgrading cannot be solved if it
On Thu, 30 Sep 1999, Marcel Moolenaar wrote:
The upgrading from -stable to -current is currently being tested by Bill
Fumerola. I can imagine that some might be broken in that case. This I
will attempt to fix, then...
As others have mentioned 3.3-STABLE right now cannot build 4.0-CURRENT
Hi!
I have bought the official version of FreeBSD
3.2 and tried to get the sound to work but it doesn't. I tried 4Front's
software but that doesn't work either. I get messages that I can't
configure /dev/dsp: device is busy all of the time. Somtimes I can't
allocate 32768 M problems.
"Rodney W. Grimes" wrote:
1. A compiler C running on machine 1 and capable of generating code
for machine 2 (the compiler includes headers and libraries),
2. Source code compatible with compiler C, but also with machine 2.
And also compatible with machine 1, that is the bugger right
I'm trying to digest the recent signal changes and get a handle on
what I need to do to make Modula-3 work. There is code in the runtime
currently which catches SIGBUS and uses the sigcontext's "sc_err"
member to find out the faulting address. That should be replaced
by the siginfo_t's
I'm trying to digest the recent signal changes and get a handle on
what I need to do to make Modula-3 work. There is code in the runtime
currently which catches SIGBUS and uses the sigcontext's "sc_err"
member to find out the faulting address. That should be replaced
by the siginfo_t's
hi,
we're working on a small mod to sysinstall, and we're seeing
the following with the unmodified source since the signal code
going in:
cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog
-I/usr/obj/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys
John-Mark Gurney wrote:
[..]
might as well say goodbye to ever getting freebsd's userland running
under NetBSD which is how our nice Alpha port got started... this
NEEDS to be fixed...
NetBSD have just done exactly the same sort of thing. And for that matter
it makes no difference for that
Anyway, all good to know. There are almost certainly more perl
speakers than awk speakers these days, so it probably makes sense
to do these things in perl rather than awk.
I think that's sort of in the grey area. There are also many Hardened
Traditionalists(tm) like myself who don't know
:I don't seem to see (after not looking very hard) any ASSERT macros for
:the kernel in FreeBSD. It'd be pretty easy to add them, and they're
:awfully useful. They're different from INVARIANT support in that they
:encapsulate (and panic if the assertion is triggered) more inline types of
Actually, the last time I looked the Modula-3 run-time system determined
the faulting address from the undocumented (except on SunOS 4) 4th argument
that most BSD-derived systems passed to the signal handler. There was
a time in fact when sc_err wasn't included in the sigcontext on FreeBSD
and
Oh, I forgot to email current on this...
I've #if 0'd out the NFSERR_BAD_COOKIE code that is partially responsible
for the solaris interoperability problems
I went through the code very carefully and determined that my previous
understanding was just plain wrong. As far as
Marcel Moolenaar wrote:
That's right, it's not implemented yet. The work-around is to use
ucontext. uc_mcontext contains the trapframe which has tf_err
(uc.uc_mcontext.mc_tf.tf_err).
Thanks.
I haven't paid any attention to implement any of the fields in siginfo_t
because that may only
Alan Cox wrote:
Actually, the last time I looked the Modula-3 run-time system
determined the faulting address from the undocumented (except on
SunOS 4) 4th argument that most BSD-derived systems passed to the
signal handler.
Yep, I have fixed that in the PM3 release (which is the one that's
Jordan K. Hubbard wrote in list.freebsd-current:
Anyway, all good to know. There are almost certainly more perl
speakers than awk speakers these days, so it probably makes sense
to do these things in perl rather than awk.
I think that's sort of in the grey area. There are also many
Why are the tools being built using new syscalls? What causes this?
Mainly historical bugs. Includes are installed too early and they only
match the new syscalls. Tools are built using the new includes, so they
need new libraries to be consistent. Therefore the new libraries are
built
Alan Cox wrote:
I guess this discussion means that the 4th argument is gone too...
Yes. ucontext_t (3rd argument) already contains that information and
siginfo_t *should* contain that information. There's not need for a 4th
argument anymore.
--
Marcel Moolenaar
On Thu, 30 Sep 1999, Brad Knowles wrote:
At 10:17 PM + 1999/9/29, Adam Strohl wrote:
Furthermore, for when 4.0 becomes a -R or -S, ftping in a compiled kernel
shouldn't be that hard of a price to pay for going from 3.2.
/stand/sysinstall based upgrades could easily seemlessly take
John-Mark Gurney wrote:
the reason I was on Marcel's back was because of his statement that he
WOULD NOT do ANYTHING to fix the problem, and that as far as he was
considered, that's life and deal w/ it... if he had said, oh, I'll look
for a solution to the problem, I wouldn't of been so
Mainly historical bugs. Includes are installed too early and they only
match the new syscalls. Tools are built using the new includes, so they
need new libraries to be consistent. Therefore the new libraries are
built before the new tools. These bugs were implemented in FreeBSD-1 by
Matthew Dillon wrote:
Oh, I forgot to email current on this...
I've #if 0'd out the NFSERR_BAD_COOKIE code that is partially responsible
for the solaris interoperability problems
I'd like to know if anyone has contacted Sun about this, which looks
like a bug in their code.
--
Alan Cox wrote:
/* kludge to pass faulting virtual address to sendsig */
frame-tf_err = eva;
return((rv == KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV);
}
Up until this point, frame-tf_err tells me details about the page
fault, such as whether it was a read or a
On Sep 30, 11:24pm, Marcel Moolenaar wrote:
} Subject: Re: HEADS UP: sigset_t changes committed
} As for me, I'm trying to define the problem as detailed and consise as
} possible. I already have some specific thoughts and ideas. I'm thinking
} large here: real cross-compilation capabilities and
look at gcc's behaviour. This has left me somewhat confused. I
appear to have two complete copies of gcc - one in src/contrib/gcc and
another in src/contrib/egcs/gcc.
WIP. src/contrib/egcs is the current home. It is moving to
src/contrib/{gcc,libio,libstdc++,etc.}. After the move, it
At 03:14 PM 9/28/99 +0930, Greg Lehey wrote:
And the preferred method is...
a) /dev/da0
b) /dev/da0s1
c) /dev/da0s1e
(-current and -stable I hope :)
(b) or (c). (a) isn't a slice. Note that it won't take slice c,
either.
Thanks for the clarification. Was recalling a past dicussion on
Hi!
I´ve updated to the latest 4.0-CURRENT on Monday and discovered
today, that my Linux emulation is broken. The emulation is loaded
as a kernel module alright, but when I start anything really using
the emulation (e.g. acroread4) my system hangs completely and requires
a reboot.
I deinstalled
Don Lewis scribbled this message on Sep 30:
On Sep 30, 11:24pm, Marcel Moolenaar wrote:
} Subject: Re: HEADS UP: sigset_t changes committed
} As for me, I'm trying to define the problem as detailed and consise as
} possible. I already have some specific thoughts and ideas. I'm thinking
}
I'm trying to digest the recent signal changes and get a handle on
what I need to do to make Modula-3 work. There is code in the runtime
Sigcontext will have to come back, since it is a standard BSD interface.
Recent signal changes break even its source-level compatibility. Previous
signal
Thomas Schuerger wrote:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
This happens when the install script wants to call {PREFIX}/sbin/ldconfig
(the Linux-ldconfig).
I rebuilt and reinstalled the linux emulation module, but that
didn_t help either.
Installing the above port
On Fri, Oct 01, 1999 at 08:48:34AM +1000, David O'Brien wrote:
On Thu, Sep 30, 1999 at 06:25:56AM -0700, Rodney W. Grimes wrote:
Cons
o Upgrading from 3.3 and before to -current is only possible after
an upgrade to post 3.3.
Not good.
We recommend that 2.2.x people upgrade to
Marcel Moolenaar scribbled this message on Sep 30:
John-Mark Gurney wrote:
the reason I was on Marcel's back was because of his statement that he
WOULD NOT do ANYTHING to fix the problem, and that as far as he was
considered, that's life and deal w/ it... if he had said, oh, I'll look
On Fri, Oct 01, 1999 at 09:20:53AM +1000, Jeffrey J. Mountin wrote:
At 12:59 PM 9/28/99 +1000, Peter Jeremy wrote:
On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote:
Good software shouldn't panic.
I wish _I_ could convince some people of this :-(.
It can be difficult to consider what
you don't under stand, we are NOT talking about upgrades, we are talking
about how to make a buildable system on -stable...
There are essentially the same problem. In order to do an upgrade, you
have to be able to build on -stable. :)
=== libgcc
echo '#include i386/xm-i386.h' config.h
On Sep 30, 4:14pm, John-Mark Gurney wrote:
} Subject: Re: HEADS UP: sigset_t changes committed
}
} In this particular case, the only thing cross-compilation would buy us
} is the ability to build (but not install) 4.x binaries on a machine
} running 3.x. It sounds like some folks would be
On Fri, Oct 01, 1999, you wrote:
On Sep 30, 4:14pm, John-Mark Gurney wrote:
} Subject: Re: HEADS UP: sigset_t changes committed
}
} In this particular case, the only thing cross-compilation would buy us
} is the ability to build (but not install) 4.x binaries on a machine
} running 3.x. It
Don Lewis scribbled this message on Sep 30:
On Sep 30, 4:14pm, John-Mark Gurney wrote:
} Subject: Re: HEADS UP: sigset_t changes committed
}
} In this particular case, the only thing cross-compilation would buy us
} is the ability to build (but not install) 4.x binaries on a machine
}
Nate Williams scribbled this message on Sep 30:
you don't under stand, we are NOT talking about upgrades, we are talking
about how to make a buildable system on -stable...
There are essentially the same problem. In order to do an upgrade, you
have to be able to build on -stable. :)
At 09:44 AM 10/1/99 +1000, Peter Jeremy wrote:
I was thinking of some `production' code (written by a sister company)
that I used to provide customer support for. It would regularly core
dump (but was automatically restarted). After a few years they did
manage to fix the core dump, but that
On Thursday, 30 September 1999 at 18:20:53 -0500, Jeffrey J. Mountin wrote:
At 12:59 PM 9/28/99 +1000, Peter Jeremy wrote:
On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote:
Good software shouldn't panic.
I wish _I_ could convince some people of this :-(.
It can be difficult to
P.S. It is really hard for me to not make personal attacks against you
after all of the above and completely ignoring the rest of my message.
No, I didn't. My statement was that your 'confrontational' style of
email wasn't making things any better.
Mellow it out, and instead of attacking
At 10:19 AM 10/1/99 +0930, Greg Lehey wrote:
This is -CURRENT. Expect work in progress. From the commit log:
replaceobject: Add preliminary code. This is not yet complete.
Add keyword 'hotspare'.
Yessir. Read -current, track commits, eat my veggies, get a bit of sun
every other week, but
On Thu, Sep 30, 1999 at 06:25:56AM -0700, Rodney W. Grimes wrote:
Cons
o Upgrading from 3.3 and before to -current is only possible after
an upgrade to post 3.3.
Not good.
We recommend that 2.2.x people upgrade to the latest 2.2-STABLE offering
before trying to jump
On Thursday, 30 September 1999 at 19:37:23 -0500, Jeffrey J. Mountin wrote:
At 09:44 AM 10/1/99 +1000, Peter Jeremy wrote:
I was thinking of some `production' code (written by a sister company)
that I used to provide customer support for. It would regularly core
dump (but was automatically
The ata driver seems to be having problems staying in contact with my
disks again. Let me know what details are needed to fix the problem, and
I'll get in touch with you.
=
| Kenneth Culver | FreeBSD: The best OS
At 10:57 AM 10/1/99 +0930, Greg Lehey wrote:
You're not typical. But you *can* grow concatenated plexes. You just
can't expand UFS to use the space. That's not a Vinum issue, but
somebody's working on it.
Yes, I realized that and donned a pointy hat.
Root (/) and OS specific files are of
I am still getting this error when trying to compile using libc_r.so.4:
/usr/lib/libc_r.so: undefined reference to `_thread_sys_sigprocmask'
Kenneth Culver
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Bruce Evans wrote:
Sigcontext will have to come back, since it is a standard BSD interface.
I think so too. I bet there are several ports besides Modula-3 that
use it. Probably boehm-gc does.
BTW, struct sigcontext seems to be documented only in sigreturn.2, and
that documentation is more
On Thursday, 30 September 1999 at 20:54:39 -0500, Jeffrey J. Mountin wrote:
At 10:57 AM 10/1/99 +0930, Greg Lehey wrote:
You're not typical. But you *can* grow concatenated plexes. You just
can't expand UFS to use the space. That's not a Vinum issue, but
somebody's working on it.
Yes, I
Nate Williams scribbled this message on Sep 30:
P.S. It is really hard for me to not make personal attacks against you
after all of the above and completely ignoring the rest of my message.
No, I didn't. My statement was that your 'confrontational' style of
email wasn't making things any
On Thu, 30 Sep 1999, Luke wrote:
On 01-Oct-99 Kenneth Wayne Culver wrote:
The ata driver seems to be having problems staying in contact with my
disks again. Let me know what details are needed to fix the problem, and
I'll get in touch with you.
Hi I don't know if it is the
Hi.
dumpon -v /dev/da0s1b
is failing here with
dumpon: sysctl: kern.dumpdev: No space left on device
Alright, it doesn't have minor number 1 as it is supposed to have
from the manpage, but using /dev/da0b (supposed to be the same device)
brings me to the same error.
What am I doing wrong ?
On Friday, 1 October 1999 at 8:27:20 +0200, German Tischler wrote:
Hi.
dumpon -v /dev/da0s1b
is failing here with
dumpon: sysctl: kern.dumpdev: No space left on device
Alright, it doesn't have minor number 1 as it is supposed to have
from the manpage, but using /dev/da0b (supposed to
It seems Kenneth Wayne Culver wrote:
On Thu, 30 Sep 1999, Luke wrote:
On 01-Oct-99 Kenneth Wayne Culver wrote:
The ata driver seems to be having problems staying in contact with my
disks again. Let me know what details are needed to fix the problem, and
I'll get in touch with you.
John-Mark Gurney wrote:
if people are interested, I can take a look at it... it'd be interesting
to be able to do something like; make prep-installworld; rm -rf
/usr/{sbin,bin,lib} /{bin,sbin}; make installworld and have it
complete... :)
Yes, please. Don't forget to install the newly
90 matches
Mail list logo
