On Tue, 17 Dec 2002 10:56:19 -0800
Does anyone know why this person is trying to (poorly)
impersonate MD?
Unfortunately not. We do not yet know who this fake Dillon
is (the guy posting from that backplane.com address)
I've been working hard on the new ipfw[2] patch for 5.0,
the new patch is
Thanks to my dear friend Warner Losh. I've decided to
leave FreeBSD and flame in another project. Maybe I could
join OpenBSD, the seem to share my views on how to deal
with other people.
I hereby give maintainership of all my code to Warner, or,
whoever wants it, for that matter.
Thank you,
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
-
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
-
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
-
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
-
Hey dudes, I want to apologize for being a total *asshole*
wrt the ipfw thingie. Sorry. I know my patch was shit
anyway, and that ipfw blows dead goats when compared to
ipf, but even with that in mind, I had to pull a deraadt,
sorry. I'm so sorry. I mean, I've had my commit bit taken
away many
:
:coredump() now usually creates empty core files for nfs filesystems.
:This seems to be caused by the changes in rev.1.132 (-current) and
:rev.1.72.2.9 (RELENG_4), and braindamage in nfs_dolock():
I think if we change it to an flock() equivalent it should work.
I'll play with it.
In regards to UUCP as a port, I think it's a good idea. There is
nothing preventing us from including the dist files in the CD
distribution so network connectivity is not needed for someone to
install it.
If someone else puts together the port I would be happy to provide
:
:I just cvsupped to the latest stable (from a -STABLE of 2 months ago) and now
:when I use vlc, or mplayer to play dvd's FreeBSD panics and reboots. I traced
:the panic but since I don't have a whole lot of time to sit here on the
:computer and trace kernel panics, I went the lazy man's rout
:
:Hi,
:
:-current from Sep 23.
:
:After a hard power off (because the system hung while switching from X
:to a virtual console) I got a panic while rebooting (background fsck
:enabled):
Disable background fsck.
-Matt
To Unsubscribe: send mai
This patch implements syscall wrappers for Giant around various
subsystems. It is intended to allow more developers to work on -current,
in the main tree, by allowing the various Giant pushdown works in
progress to be comitted to the main tree.
This patch implements sysctl va
This argument is just rehashing something that came up in June. Man
you people have short memories!
I comitted a fix to -current two months ago. It's still in my -stable
tree... if Jordan gives the O.K., I will MFC it to -stable.
(repost, it didn't like me cross-posting to the -alpha and -ia64 lists.
sigh).
I'm going to be comitting the following changes soon:
syscalls.master: (going in now)
Instead of having an MPSAFE keyword, existing keywords such as STD
can be augmented with an
Oh, two addendums.
/FreeBSD in my example is a big parition on my -stable box, not sitting
on the root partition obviously. I recommend at least 3 GB. In my
case I actually have the CVS tree itself, a broken-out -current
source tree, a broken-out -stable source tree, NetBSD
I'm posting this as an aid to everyone doing freebsd-current development
and testing and may not realize how easy it is to setup a development
environment.
The number one thing is: Don't put the CVS tree or source code on the
-current box itself, except for testing purposes.
:Hi,
:
:Just a quick note to say that my -current box has started dropping
:cores during make world again.
:
:I have a kernel from August 11 that works ok, and had one from August
:18 that was causing sig 4 at random places. I accidently overwrote
:my Aug 18 kernel.old, but Aug 25, 27 and 28
:I'm not fundamentally opposed to KSE: I would like to see it in the system
:as much as you, and am quite aware of the potential benefits. I just want
:to make sure we don't go three years without a stable release to get
:there. If the answer to the questions is either fine, or addressible,
:..
:> and preferably on more than the i386 platform. If we are going to
:> be serious about supporting more hardware platforms, then we have
:> to start treating them more seriously when major changes like this
:> come along. If we can't get some broader testing of this done in
:> the next few wee
Sheesh. Everyone is so negative! Well, I'm going to be too.
I think compared to some of the other things that have been thrown into
-current, the KSE stuff will be the LEAST disruptive. Don't go bashing
Julian for coming up with a reasoned approach to adding them, discussing
the
:Hello.
:cc -O -pipe -march=pentiumpro -I. -DDISASSEMBLER -DNO_X -I/usr/obj/usr/src/i38
:6/usr/include -c /usr/src/usr.bin/doscmd/ems.c
:/usr/src/usr.bin/doscmd/ems.c: In function `init_mapfile':
:/usr/src/usr.bin/doscmd/ems.c:1124: `MAP_INHERIT' undeclared (first use in this
:function)
:/usr/s
:pmap_pte_quick(pmap, va)
:register pmap_t pmap;
:vm_offset_t va;
:{
:unsigned pde, newpf;
:/*
: * Check if the appropriate PDE is valid. If not, we're done.
: */
:**A** if ((pde = (unsigned) pmap->pm_pdir[va >> PDRSHIFT]) !=
:0) {
:
:Yes, and no. Distributing the exact same sources (with an extra
:copyright part) that says somebody should not copy and distribute it,
:as if it were in the public domain, a few weeks after is probably
:fraud. Arguments like "but I put extra work in this second
:distribution, since I made this
:In the vmcore I just got, the panic occurred in the following
:fragment in exit1(), when dereferencing p_sigacts (which is
:p_procsig->ps_sigacts). I guess there is a race here if the parent
:is exiting or something?
:
:+ if ((p->p_pptr->p_procsig->ps_flag & PS_NOCLDWAIT)
:+ || p->p
:
:Firstly, I have no intention of committing this patch anytime soon,
:but I think you are mistaken in what it does. Unless I messed up,
:it will never allow "uninterruptible" mounts to be interrupted by
Oops, sorry about that. Today is not one of my better days.
Ian, please don't do this. The whole point of having an uninterruptable
mount is so the client can survive a server reboot or network failure.
Doing this destroys uninterruptable semantics.
If you want to flag uninterruptable mounts in a special way when someone
tries to umount th
Ok, Bruce... the symlink patch has been sitting in my tree for a week
now. I am going to let you decide whether I should commit it or not.
If not, into the trash heap it goes. This is likely to be the only
way the problem will be solved since creating an empty symlink via
the
:You can create an MD partition with wired memory - no swap backing
:at all, if you want. Obviously you can make such a partition as
:large as you might otherwise want to make it.
Er, I meant "can't", not "can"... with wired memory there are
some severe limitations to how
that code, but I would expect
:> that it would work with no swap space as well.
:>
:> Your man is probably Matt Dillon...
:
: -mi
You can create an MD partition with wired memory - no swap backing
at all, if you want. Obviously you can make such a partition as
large
:< said:
:
:>> > ./foo/ .//
:>> > ./foo/bar .//bar
:>>
:>> No, because the ``resulting filename'' begins with a slash.
:
:> It seems resulting filename (pathname?) begins with "./" (not a slash).
:
:No, it doesn't. The ``resulting filename'' is "/" in the first case,
:and "/b
Heh. We came up with virtually the same patch at the same time!
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:On Sun, Jun 17, 2001 at 21:16:24 -0400, Garance A Drosihn wrote:
:>
:> When I say this, I assume that the only change to make is how any
:> 'open' or 'stat' call will handle null symlinks. If I am reading
:> Andrey correctly, there will be no change to the 'ln' command or
:> the symlink() sy
:There is nothing to fix. Sometimes 'make install' instead 'make
:installworld' typed can produce this. Of course, install procedure can be
:complicated to make it foolprof, but I think the system must be fixed
:instead to not resolve illegal names. It is not good idea to
:produce workarounds of
:
:On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote:
:>
:> What cases? In all my years of programming I've never once 'accidently'
:> created an empty symlink.
:
:See initial Bruce comments. Sometimes when 'make hierarchy' step is
:missing, in
:
:On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote:
:> What cases? In all my years of programming I've never once 'accidently'
:> created an empty symlink.
:
:The next example is fts-like activity - wrong final destination
:appearse which is dangerous f
:On Sun, Jun 17, 2001 at 14:28:40 -0700, Matt Dillon wrote:
:
:> rather then trying to resolve it. I'm not sure it's worth it, though.
:> It just doesn't come up that often and there are a thousand other ways you
:> can hogtie yourself in the system that
:On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote:
:> It seems your argument to disallow null symlinks got somehow taken
:> as an argument to disallow all "invalid" symlinks then.
:
:
:To say it more clear: now I even not against ""-symlinks making ability,
:such strings are valid per
:...
:>
:>True. It would break phk's malloc debugging features to disable this,
:>for example.
:
:Not only that, but considerning that a symlink can point into a
:different filesystem even in normal use, there is no simple way to
:validate the valididty of the name.
... or be associated with
:...
:> It has been on evey platform I have ever used ln -s on.
:>
:> DW> One may well argue that this is "broken" in some way(s). Still, changing
:> DW> it at this point could well be considered a POLA violation, at best.
:>
:> I would argue loud and long that changing that *would*
There are several issues here:
* The process's descriptor table
* The struct file's referenced by that descriptor table
* The object underlying a struct file.
A process's descriptor table is not protected by the proc lock, because
the descriptor table can be shared acros
:> For some reason banning you from the irc channel hasn't convinced
:> you that complaining without providing patches isn't the way we do
:> things around here.
:
:How about first analysing the problem in detail and
:trying to fix it after we understand the problem ?
:
:The current stage is that
:>
:> A
:> load control system is something like... oh, the 20 second enforced swap
:> out that can be triggered when the VM system is under extreme memory
:> pressure.
:
:Yup. Too bad the 20 second enforced swap out isn't enforced...
:(at least, not by the code in vm_glue.c)
:
:I'
:Indeed, this is an interesting area. In the process of
:researching how to best implement this for Linux I have
:found various reasons why both FreeBSD's and NetBSD's
:load control systems cannot work in various realistic
:scenarios.
It's not a load control system. It's an emergency measure
:While that's a reasonable question when you're in a support role, I'd
:certainly like to hear whether "FreeBSD freezes on memory exhaustion" is
:something people "should just live with" or whether it's symptomatic of
:a bug that someone might one day want to fix but which folks should, for
:now,
: The malloc() and calloc() functions return a pointer to
: the allocated memory if successful; otherwise a NULL
: pointer is returned and errno is set to ENOMEM.
:
:I assert memory exhaustion is would return "unsuccessful" on the
:malloc() call, no?
malloc() returns NULL if t
:
:On Thu, 26 Apr 2001 14:26:46 -0700 (PDT)
:Matt Dillon <[EMAIL PROTECTED]> wrote:
:
:
:MD> There is a whole lot more to doing an efficient copy then simply checking
:MD> the mtime. It's silly to try to integrate it into 'cp'. Use cpdup
:MD> instead.
:You are one brave soul if the only precedent you have for this
:patch is GNU cp.
:
:Personally, I see nothing wrong with it.
The time check is broken, for one. Any adjustment to the system time
has the potential to screw up the feature. The time check must be
T1 != T2, not T1 < T2
:You are one brave soul if the only precedent you have for this
:patch is GNU cp.
:
:Personally, I see nothing wrong with it.
:
:With respect to how you short circuit the copy if
:the mtimes are 'ok', you probably need to return a value
:different than 1 so that your caller can distinquish betwee
:> set that default in stone and prevent us from being able to change
:> it with a new kernel rev. This being a *kernel* specific feature,
:> we need to have control over the default in the kernel itself.
:
:What about simple check in the kernel: if total memory is above 64Mb, then
:e
:But we already have sysctl.conf and appropriate rc.sysctl, haven't we? What's
:wrong with putting some useful payload into it?
:
:-Maxim
Let me explain a little more. If it's commented out, it's fine. But
if you are actually setting a value in there you will override whatever
is se
:But we already have sysctl.conf and appropriate rc.sysctl, haven't we? What's
:wrong with putting some useful payload into it?
:
:-Maxim
If it's commented out, it's fine.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebs
:
:What do you think about attached patch?
:
:-Maxim
mmm.. I think it would just confuse the issue and prevent us from
being able to change the kernel default trivially. 99.5% of the
FreeBSD boxes out there are just going to want it to be on by default.
We could provide a comment
:IIRC, didn't the NT driver for some NIC (Intel?) switch to polling,
:anyway, under heavy load? The reasoning being that you _know_ that you're
:going to get something... why bother an IRQ hit?
:
:That said, IRQ distribution sounds like a good thing for the general case.
Under a full load p
: Mutex creation can be expensive as it seems like each interrupt
: needs to register what sort of mutex it's interested in, when a
: mutex is created the list must be scanned and each interrupt
: updated.
The list is based in the interrupt structure. The cost is, what,
four or five
:
: You cannot be pre-empted by an interrupt if you are holding a spin
: mutex, AFAIK, even under present implementation.
Since spin mutexes are going to be held all over the place, this
type of restriction would seem to be detrimental. If you can do all
the checking up-front
:*sigh* Couldn't you have changed the subject line when discussing
:something of this importance?
:
:Greg
Sorry. Now I am so much in a huff I'm thinking about how all this
could be implemented from scratch with the 4.x base. I know, I know,
good luck Matt...
For example, this
:There seems to be some bad code in soo_close(), which looks like:
:
: int
: soo_close(fp, p)
: struct file *fp;
: struct proc *p;
: {
: int error = 0;
:
: fp->f_ops = &badfileops;
: if (fp->f_data)
:
:Once the mutexes are in place the underlying implementation can
:change pretty easily from task switching always to only task
:switching when the mutex is owned by the same CPU that I'm running
:on. (to avoid spinlock deadlock)
That makes *NO* *SENSE* Alfred! So the first step is to intro
:Oops.
:
:NOTE: I don't follow this lists for weeks at a time, so please
:include me directly in any responses. Thanks.
:
:Matt Dillon was looking at this, but I haven't heard from him
:for a while on it.
:
:Here is a patch to make it panic, instead of really, really
:trashing memory (
:
:You need to settle dude, pre-emption isn't a goal, it's mearly a
:_possible_ side effect.
:
:We're not aiming for pre-emption, we're aiming for more concurrancy.
A goal of having more concurrency is laudable, but I think you are
ignoring the costs of doing task switches verses the l
:
:There's actually very little code that non-premptable once we get the
:kernel mutexed. The least complex way to accomplish this is to only
:preempt kernel processes that hold no mutex (low level) locks.
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
I wish it were that
:
:Matt Dillon wrote:
:
:> It is not implying that at all. There is no black and white here.
:> This is a case where spending a huge amount of time and complexity
:> to get the efficiency down to the Nth degree is nothing but a waste
:> of time. What matters is w
:* Matt Dillon <[EMAIL PROTECTED]> [010415 23:16] wrote:
:>
:> For example, all this work on a preemptive
:> kernel is just insane. Our entire kernel is built on the concept of
:> not being preemptable except by interrupts. We v
:> It just seems inelegant to have a system that, on paper, is
:> so inefficient. Can't we do better?
:
:Sure. Don't discard buffer contents when recycling a B_MALLOC'ed buffer,
:but manage it using a secondary buffer cache that doesn't have as much
:overhead as the primary one (in particular,
:
:>I don't consider it inefficient. Sure, if you look at this one aspect
:>of the caching taken out of context it may appear to be inefficient,
:>but if you look at the whole enchilada the memory issue is nothing
:>more then a minor footnote - not worth the effort of worrying a
:
:>There's no downside, really.
:
:It just seems inelegant to have a system that, on paper, is
:so inefficient. Can't we do better?
:
:--
:Justin
I don't consider it inefficient. Sure, if you look at this one aspect
of the caching taken out of context it may appear to be inefficie
:It is my understanding that with the new directory layout strategies, this
:will be improved somewhat. ie: a single page is much more likely to cache
:up to 8 directories.
:
:Cheers,
:-Peter
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
:"All of this is for nothing if
:
: I notice that this option is off by default. Can you give a general idea
:of when it should be enabled, when it should be disabled, and what bad
:things might result with it on?
:
:Thanks,
:
:Doug
There's no downside, really. The directory cache is so tiny without
it that you
:on BSD, and we can do more finetuning than on Solaris itself. Also
:mountd and export seems to support more features than in Solaris,
:according to the manpage.
:
:Could this export restriction change in future with nfsv4, when nfs
:does get stateful (I've heard about that the stateless behaviour
:Hi,
:
:Of course you are right. Netgroup support got in some area broken
:when I did the IPv6 merge of NetBSD code. It will be fixed
:soon, sorry !
:
:Another issue with mountd is, that it allows still one set of flags
:for one mountpoint. This is done per radix entry in the kernel and tied
:to
:
:Any plan to MFC? I am interesting to see it in 4.3-RELEASE.
:
:--
:David Xu
It will definitely not go in until after the release. It's still
experimental (in our tree).
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubsc
:Why VMIO dir works better if directories are placed close to each other? I
:think it only makes the cache data of an individual directory stay in the
:memory longer. Is there a way to measure the effectiveness of the disk
:drive's cache?
:
:-Zhihui
I wasn't being clear enough. There are tw
:> I'm not 100% convinced about the algorithm to avoid clusters filling
:> up with directory-only entries (it looks like a worst-case would fill
:> a cluster with 50% directories and 50% files leaving a bad layout when
:> the directories are populated further), but then the non-dirpref
:> sche
:I hope you have commited it, or well soon, to -stable, as this one has
:surely been one to send many a young admin screaming from his cubicle
:yelling ``but it should work, it really should just work''.
Yah, it's in just under the wire. I was tearing my hair out today trying
to figure o
Ok guys. I just had to fix a problem with portmap in -stable related
to binding to specific IP addresses so replies to UDP packets come
'from' the proper IP address (for multi-homed hosts).
Question: Does the rpcbind program in -current have the same problem
or has it alrea
:* Kernel bcopy operation in case where no process switch occurs
: (i.e. current process was using the FP and while we went into
: kernel mode, we have not yet saved the FP state anywhere).
:
: if (process-A-using-FP) {
: push FP state for process A on stack
:
How about this:
* a per-process fp-in-use flag
* a per-cpu fp-save-block ID (incrementing serial number)
When a context switch from process A to process B occurs:
if (process-A-using-FP) {
increment ID
save FP state for process A and ID
:That was the sucking in of the /etc files. I'm referring to the
:following in rc.diskless1 where you check for host-specific files,
:followed by network, then a default config:
:
: if [ -d /conf/${bootp_ipa} ] ; then
: cp -Rp /conf/${bootp_ipa}/etc/* /conf/etc
: elif [ -d /conf/${boot
:>
:> On Mar 30, Falco Krepel wrote:
:> > I have implemented good ideas from Mike Smith in my
:> > rc.diskless{1,2} files and make some other changes:
:>
:> Hi,
:> I don't have access to hardware to test diskless but have a
:> few suggestions from looking at proposal.
:>
:>
: Hi guys,
:
: ok, sources cvsupped yesterday afternoon, just before my ffs_alloc.c
: commit [which I did, obviously, add myself locally].
:
: Box had been running for a while when all of a sudden it got into a
: panic:
:
: vm_page_alloc: free/cache page 0xc0776
:Matt Dillon <[EMAIL PROTECTED]> writes:
:> To date nearly all the reported corruption has been to directories
:> and not to file contents. Does this hold for you as well? Only
:> the directory was corrupted and not any files?
:
:Umm, the end of the cvsup log was pad
:Matt Dillon <[EMAIL PROTECTED]> writes:
:> How old a kernel are you running?
:
:Maybe five days old.
:
:DES
:--
:Dag-Erling Smorgrav - [EMAIL PROTECTED]
That has all of our fixes to date. It fits the M.O. of the problem I've
been trying to track down, but I have yet
:
:On Wed, Mar 14, 2001 at 04:39:53PM -0800, Matt Dillon wrote:
:
:> fsck all of your filesystems from single-user to remove the possibility
:> of 'old' corruption (as in 'fsck', not 'fsck -p').
:
:So if an fsck -f doesn't bomb out, the filesyste
:I was cvsupping the GNATS database (the *entire* GNATS database, that
:is - I didn't already have a copy) when I got this panic:
How old a kernel are you running?
Kirk and I have been attempting to locate the filesystem bitmap
corruption for months. We've fixed a number of bugs but
:This effectively happens.
:
:The harvest ring is a limited length, and any overflows are discarded.
:
:M
:--
:Mark Murray
:Warning: this .sig is umop ap!sdn
Are you resending this mail from 5 dats ago or is there a bounce
occuring somewhere on the list?
Currently the queue size do
Let me be clear about what I mean by interrupt rate limiting:
interrupt()
{
harvester(...)
}
harvester(...)
{
if (queue is not full) {
... add data to queue (reasonably sized queue, like 32 entries)
}
}
queue-runner(...)
{
for(
:> down and will work, SNAP, just like that?
:
:Because I need to make folks other than you happy.
:
:Lots of security minded people what _all_ the interrupt entropy
:they can get, and this method gives them that while allowing others
:to throttle the harvester back.
:
:M
:--
:Mark Murray
:Wa
:Matt,
:
:At it is very obvious to me that you have not even looked at the new
:code, let alone run it, I suggest that you do both before further
:engaging in this conversation.
:
:M
:--
:Mark Murray
:Warning: this .sig is umop ap!sdn
I looked at it. I'm sorry, I don't see how your adjustm
:
:> Please try this patch. This should solve all the random harvesting
:> performance issues no matter how efficient or inefficient the hash
:> function (untested as I do not have a -current box at the moment).
:
:Erm, you are behind :-)
:
:I have already committed something that do
Sorry, the last patch won't patch cleanly, I forget to update my
-current source before diffing. A new patch is attached, and it
also includes reducing the sdize of the entropy ring from 1024 to a
more reasonable 64.
Mark, what I said last month still holds... you need to ma
Please try this patch. This should solve all the random harvesting
performance issues no matter how efficient or inefficient the hash
function (untested as I do not have a -current box at the moment).
-Matt
Index: yarrow.c
:Hmm. Sounds doable. I'll play.
:
:> A 1/10 second sleep and a ring limit of 32 still gives you an effective
:> 320 seeds per second. Still overkill, but at least not the massive
:> overkill that its doing now.
:
:Event != seed. I'll juggle numbers and see if I can come up with any
:> I think it would be a much better idea to cap the number of interrupts
:> per second the reseeder accepts. e.g. have a sysctl to set the
:> max and default it to something reasonable, like 200. The seeder would
:> thus only run 200 times a second even if A person were gettin
:> causes 7750 interrupts/sec here (on a Celeron 366 overclocked to
:> 522). The random task takes 100% of the available cpu cycles. This
:> slows down cpu-bound processes by a factor of about 3.5. With a block
:> size of 64k instead of the default of 512, this causes only 300
:> interrupts/se
:> Any updates? My quick test involving running pkg_version on a system with 92
:> installed ports, which is very make-intensive operation if ports have origin
:> recorded, as pkg_version(1) runs `make -V' for each port, shown that
:> statically-compiled make is about 15% faster than dynamically-
:ok, added a comment about this.
:
:> nfsd -r is used if you already have nfsd's
:> running but somehow unregistered the nfs service
:> from the portmapper. For example, if you killed
:> the portmapper and restarted it. nfsd -r simply
:> reregisters the service that is alread
:
:
:Hi,
:
:nfsd.c has the following lines:
:
:(void)signal(SIGQUIT, SIG_IGN);
:(void)signal(SIGTERM, SIG_IGN);
:
:So nfsd(8) can only be killed by -9. Does this make
:sense ? Unregistering withing rpcbind or portmap is
:not possible, so one has to kill portmap(8) or rpcbind(8)
:and restart all t
:Are you aware of any recent changes that would have caused this
:problem? I do not believe that the soft updates changes would
:have caused this problem since they were all related to `under
:stress' conditions which are not applicable here.
:
: ~Kirk
I haven't made any commits to
:In message <[EMAIL PROTECTED]> Matt Dillon writes:
::Would compiling the tools -static help?
:
:No. The tools that are deployed today are not static, and it is those
:that we copy. It will also delay discovery of the incompatibility
:until after the installworld is complete. I'
Would compiling the tools -static help?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
1 - 100 of 164 matches
Mail list logo
