Booting dragonfly cd from floppy?
Hi, A friend of mine wants to try DragonFly on his old P75 which doesnt have a bootable cdrom drive(It has a cd rom drive but cant boot from it). Is there a way to boot the cd from a floppy? Petr
Re: Booting dragonfly cd from floppy?
Petr Janda wrote: Hi, A friend of mine wants to try DragonFly on his old P75 which doesnt have a bootable cdrom drive(It has a cd rom drive but cant boot from it). Is there a way to boot the cd from a floppy? Unfortunately not. What I usually do in such a case is to plug the harddisk into another box and install from there. Sascha -- http://yoyodyne.ath.cx
Re: NFS locking issues? (where to go for info?)
:Has anyone had much success with NFS locking? (where would one :go if they wanted to understand the details?) : :I've read that it's been fixed for some time, that I need to run :rpc.statd and rpc.lockd (and in fact, mutt complains unless I run :these) I'm assuming 'statd' locks the local file and lockd talks :to statd when a remote wants a lock? It isn't going to work. The locks will be honored locally but we do not have a working lockd, and even FreeBSD which has spent a lot of time trying to get a working lockd doesn't have one that is reliable. NFS locking in general is not reliable and I would not recommend that anyone try to do it. Ultimately we will be able to support locking across DragonFly boxes as part of our clustering work, but I really doubt we will ever have reliable NFS locking across disparate operating systems. -Matt
Re: pthread-changes from 1.6 to 1.7?
Am Donnerstag, 14. September 2006 09:33 schrieb Joerg Sonnenberger: On Wed, Sep 13, 2006 at 01:34:34PM -0700, walt wrote: The basic problem is whether an OS uses libpthread or libc_r for the threading library. Unfortunately, I have no idea why developers choose one over the other -- maybe someone here could 'splain it to us? I get the feeling that there is a lot of history involved in this story. The basic problem you should be aware of is that loading a thread library as dependency only works during the initial linking. This is quite easy to understand when looking e.g. at the stdio locking inside libc, which is reduced to a nop otherwise. FreeBSD 4 originally shipped libc_r with included libc and we inherited that until it was fixed shortly after 1.2 (I think, haven't verified). For the very same reason, libtool explicitly drops libc_r from shared object creation calls. -pthread is handled slightly different -- it is recorded, but doesn't directly affect the linkage. A library can be used without linking the main program with -pthread as long as they don't call pthread_create. The patch replaces the hard-coded detection magic with a test for the *known* values in pkgsrc, but that's of course not portable and upstream ready. Testing for -pthread as thread linkage option is a good thing in general though, since it works on a lot of systems. Joerg Can this be the cause for kmymoney2 crashing, too? [..] [Switching to Process 858, Thread 1] 0x29f070c4 in poll () from /usr/lib/libc.so.6 #0 0x29f070c4 in poll () from /usr/lib/libc.so.6 #1 0x29eb1974 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 #2 0x29eb138b in _thread_kern_scheduler () from /usr/lib/libc_r.so.5 Thomas
Re: NFS locking issues? (where to go for info?)
In [EMAIL PROTECTED],
Matthew Dillon [EMAIL PROTECTED] mentions:
:Has anyone had much success with NFS locking? (where would one
:go if they wanted to understand the details?)
:
:I've read that it's been fixed for some time, that I need to run
:rpc.statd and rpc.lockd (and in fact, mutt complains unless I run
:these) I'm assuming 'statd' locks the local file and lockd talks
:to statd when a remote wants a lock?
It isn't going to work. The locks will be honored locally but we
do not have a working lockd, and even FreeBSD which has spent a lot
of time trying to get a working lockd doesn't have one that is
reliable. NFS locking in general is not reliable and I would not
recommend that anyone try to do it.
Ultimately we will be able to support locking across DragonFly boxes
as part of our clustering work, but I really doubt we will ever have
reliable NFS locking across disparate operating systems.
Hmm.. Thanks! Glad to know it's not going to work, so I can stop chasing
after it. :-)
Anyone recommend an alternate (fast) network filesystem? I'm not exactly
crazy about NFS, it's just that it's the default. Locks aren't a huge deal
I guess. (glad to know it's still a problem though)
One thing I used to do (before hearing I shouldn't) is:
if( symlink(pid,file.lock)){
# I have a lock, readlink() gives others the PID.
}
Are symlinks atomic across NFS?
Funny, seems like such a basic, simple thing yet it remains so illusive.
As far as the clustering, this should really be interesting to see, I have
this picture in my mind of a unified virtual filesystem that tries to
allocate physical space as close to the process that is generating/requesting
data as possible. Sort of transparently, with a file being possibly split
between several machines.
That seems like it'd really be tricky to do. Taking a machine down might involve
copying terrabytes of data, then freaking out when there isn't enough space
to on the other machines. Files might suddenly disappear and then reappear
later.
Very interesting problem. My head hurts just thinking about it!
Jamie
--
http://www.geniegate.comCustom web programming
[EMAIL PROTECTED] (rot13)User Management Solutions
printing problem
I did a fresh install of 1.6, then moved to preview, on a box that was running 1.2. I set up printing the same as was on 1.2, but no printing will occur. My /etc/printcap: lp|LaserJet|lj|LJ|lj|line|:\ :lp=/dev/lpt0:\ :af=/etc/foomatic/HP-LaserJet_1320-hpijs.ppd:\ :if=/usr/pkg/bin/foomatic-rip:\ :sd=/var/spool/lpd/LaserJet:\ :lf=/var/log/LaserJet.log:\ The error message is: lp: cannot execv(/usr/local/bin/foomatic-rip): No file or directory Any help greatly appreciated Bryan
Re: pkgsrc issues with custom mk.conf
On Wed, 13 Sep 2006, Gergo Szakal wrote: Hi again, I have build DF with SMP support on a dual PII-server. I have added the following options to mk.conf in order to enable compiling on 2 CUPs: WRAPPER_UPDATE_CACHE=no MAKE_FLAGS+=-j2 MAny pkgsrc packages (i. e. glib) won't build, while commenting these options makes the same packages build just fine. Are these options disrecommended, or do I have to enable this way of compiling with alternate methods? Thanks in advance for dealing with my countless support questions. I don't know about the WRAPPER_UPDATE_CACHE details, but I have used multiple make jobs. My pkgsrc is patched to support a MAKE_JOBS variable used in the build target. I also have a MAKE_JOBS_SAFE setting to skip this. I had to set it to NO for a few packages like www/lynx, graphics/MesaLib, graphics/netpbm and some others. What errors were you receiving?
Re: printing problem
Bryan Berch wrote: The error message is: lp: cannot execv(/usr/local/bin/foomatic-rip): No file or directory foomatic-rip is part of the foomatic-filters package. Do you have that installed?
Re: pkgsrc issues with custom mk.conf
Jeremy C. Reed wrote: What errors were you receiving? Here is the work.log for the erroneous gettext: http://rnrdoctor2.sytes.net/worklog
Re: printing problem
I installed /usr/pkgsrc/print/hpijs, as I have done before, then moved foomatic -rip and the filter file, /ppd/HP-LaserJet_1320-hpijs.ppd.gz, from the work directory and to printcap where to find them. This has always worked in FreeBSD and up to DragonFlyBSD 1.2. The print/hpijs, as far as I can tell, never has installed foomatic-filters. walt wrote: Bryan Berch wrote: The error message is: lp: cannot execv(/usr/local/bin/foomatic-rip): No file or directory foomatic-rip is part of the foomatic-filters package. Do you have that installed?
