Re: NFS locking: lockf freezes (rpc.lockd problem?)
On Sun, Aug 27, 2006 at 07:17:34PM +, Michael Abbott wrote: > On Sun, 27 Aug 2006, Kostik Belousov wrote: > >Make sure that rpc.statd is running. > Yep. Took me some while to figure that one out, but the first lockf test > failed without that. [...] > As for the other test, let's have a look. Here we are before the test > (NFS server, 4.11, is saturn, test machine, 6.1, is venus): > saturn$ ps auxww | grep rpc\\. > root48917 0.0 0.1 980 640 ?? Is7:56am 0:00.01 rpc.lockd > root 115 0.0 0.1 263096 536 ?? Is 18Aug06 0:00.00 rpc.statd [...] > Well, how odd: as soon as I start the test process 515 on venus goes away. > Now to wait for it to fail... (doesn't take too long): [...] > In conclusion: I agree with Greg Byshenk that the NFS server is bound to > be the one at fault, BUT, is this "freeze until reboot" behaviour really > what we want? I remain astonished (and irritated) that `kill -9` doesn't > work! The problem here is that the process is waiting for somthing, and thus not listening to signals (including your 'kill'). I'm not an expert on this, but my first guess would be that saturn (your server) is offering something that it can't deliver. That is, the client asks the server "can you do X?", and the server says "yes I can", so the client says "do X" and waits -- and the server never does it. Or alternatively (based on your rpc.statd dying), rpc.lockd on your client is trying to use rpc.statd to communicate with your server. And it starts successfully, but then rpc.statd dies (for some reason) and your lock ends up waiting forever for it to answer. I would recommend starting both rpc.lockd and rpc.statd with the '-d' flag, to see if this provides any information as to what is going on. There may well be a bug somewhere, but you need to find where it is. I suspect that it is not actually in rpc.statd, as nothing in the source has changed since January 2005. An alternative would be to update to RELENG_6 (or at least RELENG_6_1) and then try again. -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS locking: lockf freezes (rpc.lockd problem?)
On Sun, Aug 27, 2006 at 07:17:34PM +, Michael Abbott wrote: > On Sun, 27 Aug 2006, Kostik Belousov wrote: > >For debugging purposes, tcpdump of the corresponding communications > >would be quite useful. Besides this, output of ps auxww | grep 'rpc\.' > >may be interesting. > > Um. How interesting would tcpdump be? I'm prepared to do the work, but > as I've never used the tool, it may take me some effort and time to figure > out the right commands. Yes: `man tcpdump | wc -l` == 1543. Fancy > giving me a sample command to try? On server, tcpdump -p -s 1500 -w file -i host This is assuming you use ethernet with usual MTU, iface is interface where communication with client comes from. > > As for the other test, let's have a look. Here we are before the test > (NFS server, 4.11, is saturn, test machine, 6.1, is venus): > > saturn$ ps auxww | grep rpc\\. My fault, better use ps axlww. . > Well, how odd: as soon as I start the test process 515 on venus goes away. > Now to wait for it to fail... (doesn't take too long): Yes, this is very interesting. Does something appears in the logs ? Also, you shall use -d option of rpc.lockd (and show the output together with tcpdump output). pgpFxQQLM10xw.pgp Description: PGP signature
Re: NFS locking: lockf freezes (rpc.lockd problem?)
On Sun, 27 Aug 2006, Kostik Belousov wrote: Make sure that rpc.statd is running. Yep. Took me some while to figure that one out, but the first lockf test failed without that. For debugging purposes, tcpdump of the corresponding communications would be quite useful. Besides this, output of ps auxww | grep 'rpc\.' may be interesting. Um. How interesting would tcpdump be? I'm prepared to do the work, but as I've never used the tool, it may take me some effort and time to figure out the right commands. Yes: `man tcpdump | wc -l` == 1543. Fancy giving me a sample command to try? As for the other test, let's have a look. Here we are before the test (NFS server, 4.11, is saturn, test machine, 6.1, is venus): saturn$ ps auxww | grep rpc\\. root48917 0.0 0.1 980 640 ?? Is7:56am 0:00.01 rpc.lockd root 115 0.0 0.1 263096 536 ?? Is 18Aug06 0:00.00 rpc.statd venus# ps auxww | grep rpc\\. root 510 0.0 0.9 263460 1008 ?? Ss6:05PM 0:00.01 /usr/sbin/rpc.statd root 515 0.0 1.0 1416 1120 ?? Is6:05PM 0:00.02 /usr/sbin/rpc.lockd daemon 520 0.0 1.0 1420 1124 ?? I 6:05PM 0:00.00 /usr/sbin/rpc.lockd That's interesting. Don't know how significant the differences are... Ok, let's run the test: venus# cd /usr/src; make installworld DESTDIR=/mnt Well, how odd: as soon as I start the test process 515 on venus goes away. Now to wait for it to fail... (doesn't take too long): saturn$ ps auxww | grep rpc\\. root48917 0.0 0.1 980 640 ?? Is7:56am 0:00.01 rpc.lockd root 115 0.0 0.1 263096 536 ?? Is 18Aug06 0:00.00 rpc.statd venus# ps auxww | grep rpc\\. root 510 0.0 0.9 263460 992 ?? Ss6:05PM 0:00.01 /usr/sbin/rpc.statd daemon 520 0.0 1.0 1440 1152 ?? S 6:05PM 0:00.01 /usr/sbin/rpc.lockd venus# ps auxww | grep lockf ... root7034 0.0 0.5 1172 528 v0 D+6:51PM 0:00.01 lockf -k /mnt/usr/... (I've truncated the lockf call: the detail of the install call it's making is hardly relevant!) Note that now any call to lockf on this server will fail... Hmm. What about a different mount point? Bet I can't unmount ... venus# umount /mnt umount: unmount of /mnt failed: Device busy venus# umount -f /mnt venus# mount saturn:/tmp /mnt venus# lockf /mnt/test ls (Hangs) Now this is interesting: the file saturn:/tmp/test exists! And it appears to be owned by uid=4294967294 (-2?)! How very odd. If I reboot venus and try just a single lockf: venus# lockf /mnt/test stat -f%u /mnt/test 0 As one might expect, indeed. A hint as to who's got stuck (saturn, I'm sure), but beside the point, I guess. Note also that the `umount -f /mnt` *didn't* release the lockf, and also note that /tmp/test is still there (on saturn) after a reboot of venus. In conclusion: I agree with Greg Byshenk that the NFS server is bound to be the one at fault, BUT, is this "freeze until reboot" behaviour really what we want? I remain astonished (and irritated) that `kill -9` doesn't work! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 16M RAM enough for FreeBSD 6.1?
On Sunday 27 August 2006 09:13, Peter Jeremy wrote: > On Sun, 2006-Aug-27 03:46:52 +0200, Torfinn Ingolfsen wrote: > >I have an old laptop, a Compaq Armada 1580DMT, with 16M RAM, 2GB hd, > > ... > > >However, when I try the 6.1-release CD (CD1), it boots as far as > >loading the kernel, botting the kernel, and then reboots again?? > > The CD-ROMs create a RAMdisk and need a minimum of 24MB last I checked. > Once you have FreeBSD installed, it will limp along in 16MB (though > not very happily). I strongly suggest you find a SODIMM to expand it. A friend of mine installed 6.1 successfully on a pentium with 48MB ram. It runs quite well actually :) He didn't try to to install X however. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS locking: lockf freezes (rpc.lockd problem?)
On Sun, 27 Aug 2006, Greg Byshenk wrote: On Sun, Aug 27, 2006 at 11:24:13AM +, Michael Abbott wrote: I've been trying to make some sense of the "NFS locking" issue. I am trying to run # make installworld DESTDIR=/mnt where /mnt is an NFS mount on a FreeBSD 4.11 server, but I am unable to get past a call to `lockf`. I have just performed a test of what you describe, using 'smbtest' (6.1-STABLE #17: Fri Aug 25 12:25:19 CEST 2006) as the client and 'data-2' (FreeBSD 6.1-STABLE #16: Wed Aug 9 15:38:12 CEST 2006) as the server. ... Which is to say that it completed successfully. Which suggests that there is not a serious and ongoing problem. Hm. That's a useful data point: thanks for making the test! What about the non-interruptible sleep? Is this regarded as par for the course with NFS, or as a problem? I know that "hard" NFS mounts are treated as completely unkillable, though why `kill -9` isn't made to work escapes me, but a locking operation which (presumably) suffers a protocol error? Or is rpc.lockd simply waiting to hear back from the (presumably broken) NFS server? Even so: `kill -9` ought to work! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 16M RAM enough for FreeBSD 6.1?
16MB is enough to run FreeBSD for limited applications, with carefully crafted kernel. It is not enough to run sysinstall. Last I checked, sysinstall was pushing 24MB in size, with 32MB being really better. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.5 to 6.1 upgrade
Hello! On Sat, 26 Aug 2006, Doug Barton wrote: I've tried to use sysutils/portconf, but found that it still doesn't give an universal solution: I think we need to be careful what our expectations of "universal" are with a ports tree as large, and a userbase as diverse, as what we have. However ... Hmm, let me cite your letter in this thread: = From [EMAIL PROTECTED] Wed Aug 23 23:56:09 2006 Date: Wed, 23 Aug 2006 13:51:52 -0700 From: Doug Barton <[EMAIL PROTECTED]> To: Ruslan Ermilov <[EMAIL PROTECTED]> Cc: Vivek Khera <[EMAIL PROTECTED]>, "Todorov @ Paladin" <[EMAIL PROTECTED]>, freebsd-stable Subject: Re: 5.5 to 6.1 upgrade Ruslan Ermilov wrote: On Tue, Aug 22, 2006 at 11:07:45PM +0300, Todorov @ Paladin wrote: Also - why portupgrade is not always aware of previously chosen options for a port build? It depends. If options are OPTIONS (in the ports sense), they are saved and independent of portupgrade. If options are makefile options specified in pkgtools.conf, they are only taken into accont if the port is (re)build explicitly; they are not taken into account if a port is (re)built as a dependency of another port. In plain text: if port B has options in pkgtools.conf, and port A has B as its dependency, and you portinstall/portupgrade A, B will be built (if needs be) without pkgtools.conf options. Be careful. sysutils/portconf does not have that limitation. If you specify flags using that method, they will always be used. FYI, Doug = So, one can mistakenly think that "always" here really means ALWAYS (i.e., for every port). However many ports use that funny OPTIONS (in the ports sense) which completely ignore make's WITH_xxx / WITHOUT_xxx environment variables, so "always" isn't correct word here I suppose. 1) it doesn't work if /usr/ports is a link to another location. Sure it does. You just have to be smarter about how you specify the triggers in make.conf. :) I have the following: .if !empty(.CURDIR:M/mnt/slave/space/ports*) # Begin portconf settings ... Works like a charm. Sure this (changing the body of the "Do not touch these lines" block ;) works! However portconf's +DISPLAY message doesn't even suggest that trigger in /etc/make.conf should be changed according to the `realpath /usr/ports/`. BTW, can this trigger line be changed in order to work in both standard case (/usr/ports is a port directory itself) and case when /usr/ports is a symlink to the actual port tree? I don't know make's language enough to embed `realpath /usr/ports/` to the trigger, sorry. 2) it still doesn't affect OPTIONS (in the ports sense); try e.g. the following: If it's not working at all to start with (as you specified above), then this additional example of brokenness is meaningless. Additionally, OPTIONS ignores settings in the environment at all times to start with. It's easy enough to test this for yourself by placing something in make.conf. Yes, OPTIONS ignore settings in the make's environment, and it's confusing. At least option's default could follow WITH_xxx / WITHOUT_xxx, so I'd expect e.g. "SNMP support" to be checked when /etc/make.conf contains WITH_SNMP=yes To add even more confusion, OPTIONS _do_ obey shell's (not make's) environment variables: cd /usr/ports/net/quagga && WITH_SNMP=yes make rmconfig config correctly checks "SNMP support"! So (at least, from consistency POV) I think that OPTIONS should obey make's WITH_xxx / WITHOUT_xxx environment variables in the same way as they obey shell's variables. The more "perfect" solution, I think, would be to make those options (set via both make's and shell's WITH_xxx / WITHOUT_xxx variables) unchangeable in OPTIONS dialog (paint them grey as Windows does? Not so unreasonable I think). So in the case when _all_ menu items have appropriate WITH_xxx / WITHOUT_xxx settings, the entire menu dialog could be skipped and port installation could be made unattended. Wouldn't that be nice? hth, Doug Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: [EMAIL PROTECTED] nic-hdl: LYNX-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 16M RAM enough for FreeBSD 6.1?
On Sun, 27 Aug 2006 18:13:12 +0200 Fabian Keil <[EMAIL PROTECTED]> wrote: For information: I'm still trying to find a sodimm card for this machine, as everything would be easier if it had more memory. We'll see how I manage that; here in Norway it is not so easy to find things like that, and transport costs from the US are prohibitive for a hobby budget. > I moved the harddisk into a more powerful machine, > installed FreeBSD there, build a lighter kernel and > put the disk back. Are there any FAQ's arounf for things I can safely remove from a 6.1 kernel? > NFS mounting needed a work around: I won't need NFS, so that's not a problem. > In your case it's probably easier to create a disk image > in Qemu, copy it to a CD and then use something that Hmm, I'm not very familiar with Qemu. A quick web search didn't turn up any obvious pointers on how to create a ISO image from a qemu image, or how to make an ISO image from the (currently running) Qemu image. Do you have any pointers to a HowTo for this? > boots from a floppy, supports the CD-Rom drive and brings > dd with it, to "install" the image. Yes, this sounds like a good plan. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 16M RAM enough for FreeBSD 6.1?
Torfinn Ingolfsen <[EMAIL PROTECTED]> wrote: > I have an old laptop, a Compaq Armada 1580DMT, with 16M RAM, 2GB hd, > floppy and CD-rom. It doesn't have built in networking, neither wired > nor wireless. It does have PC card slots. It has had FreeBSD 4.9-release > installed a long time, and was recently upgraded to 4.11-release from > CD, sucessfully. > However, when I try the 6.1-release CD (CD1), it boots as far as > loading the kernel, botting the kernel, and then reboots again?? > Are 16 Megs of RAM to little to install FreeBSD 6.0 or newer? With the default configuration yes. I recently tried to install FreeBSD 6.1-PRERELEASE on a Pentium 90 with 16 MB RAM, and hit the rebooting problem as well. I moved the harddisk into a more powerful machine, installed FreeBSD there, build a lighter kernel and put the disk back. NFS mounting needed a work around: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/94830 but the rest worked out of the box. In your case it's probably easier to create a disk image in Qemu, copy it to a CD and then use something that boots from a floppy, supports the CD-Rom drive and brings dd with it, to "install" the image. Depending on your partition layout you may even be able to use your old FreeBSD installation to do that. (I'm not sure if it's possible to use FreeBSD to overwrite the partition it's running from). Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: 16M RAM enough for FreeBSD 6.1?
On 8/27/06, Peter Jeremy <[EMAIL PROTECTED]> wrote: On Sun, 2006-Aug-27 11:00:30 +0200, Torfinn Ingolfsen wrote: >On Sun, 27 Aug 2006 17:13:29 +1000 >Peter Jeremy <[EMAIL PROTECTED]> wrote: > >> The CD-ROMs create a RAMdisk and need a minimum of 24MB last I >> checked. > >And I guess that the floppies work in the same way? Yes. >> Once you have FreeBSD installed, it will limp along in 16MB >> (though not very happily). > >Hmm, I see. I'm planning to run X on this old box (it's going to be a >PictureFrame project), perhaps that will not work. I think you would be thrashing if there was any actual activity. I'll prod a friend with the same setup to comment tomorrow. >> I strongly suggest you find a SODIMM to >> expand it. > >Ok. Are all SODIMMs equal (ie. a real standard), or do I hvae to look >specifically for memory upgrades for the Armada 1580 (or 1500 series)? I'm 99% certain that you can't use anything bigger than 64MB (at least a 128MB Cpq Armada SODIMM that I had wouldn't work in any of the 15xx machines I tried it in - that included a 1580). I'm not sure how interchangeable they are. Max mem size and chip density is a function of the MCH, If you post a copy of dmesg here I can look it up for you. From the service manual: "The computer supports optional 8-, 16-, 32-, and 64-MB memory boards. The memory boards are 60 ns EDO RAM without parity. System memory can be expanded to 80-MB of DRAM depending on the model." The Service Manual is here: http://h2.www2.hp.com/bizsupport/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDF&prodSeriesId=96219&targetPage=http%3A%2F%2Fh2.www2.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2Fc00139858%2Fc00139858.pdf And Addendum to the service manual is here: http://h2.www2.hp.com/bizsupport/TechSupport/CoreRedirect.jsp?redirectReason=DocIndexPDF&prodSeriesId=96219&targetPage=http%3A%2F%2Fh2.www2.hp.com%2Fbc%2Fdocs%2Fsupport%2FSupportManual%2Fc00139129%2Fc00139129.pdf -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD/xbox live/installcd's available
Hello everyone, In order to aid people installing FreeBSD on their xbox, I have created combined install/livecds to aid those willing to give FreeBSD/xbox a try. The images can be used to boot a full multi-user FreeBSD environment, but you can also boot directly into sysinstall to install FreeBSD on your Xbox. As I've recently merged Xbox support back to -STABLE, an ISO for 6-STABLE is also provided. The images are hosted by MCGV Stack (http://www.stack.nl), and can be retrieved from ftp://ftp.stack.nl/pub/freebsd-xbox/. A list of the files and checksums is: xbox-6stable-20060821.iso.bz2 - install/livecd for FreeBSD 6-STABLE MD5= 9afbab92bbb43a797753a941737ef0bb SHA1 = 26908c6301484c133f23875a8136c2dbeb336e88 SHA256 = d67e51c2a37e14193a5cbfb49903899f60784e39f91888f8e0a48c85ee3eee46 xbox-7current-20060517.iso.bz2 - install/livecd for FreeBSD 7-CURRENT MD5 = 82108c6112f8b39fb82e71fdc727704a SHA1 = 83e40e292ac8ace395fcf199f1bb16b0a34531c5 SHA256 = 2176904283707273e7d62e31c516bc81c9a2021556bb84adbe23071ba9b8dd83 Some important points of attention: (1) The loader used is Cromwell; the Cromwell version on the images has special patches which do not appear in any official releases build [1]. Therefore, if you already use Cromwell on your Xbox, please chain-load the Cromwell on the images beforing attempting to boot FreeBSD. (2) 'patched' dashboard (the Xbox 'operating system') versions can directly boot the /DEFAULT.XBE file on the CDROM. The official Dashboard will fail to boot this, however, as the DEFAULT.XBE file is not signed with any Microsoft-approved key. Booting this file will directly start the FreeBSD-enabled Cromwell. (3) There is no loader support. Any tunables must be set using kernel options (such as the root device to use) (4) The xbox is very picky on the media used. If you get random panics or hangs during installation, try another brand of media. (5) If you keep experiencing DMA errors or timeouts, please use a 80 pin UDMA IDE cable. As there is no loader support, there is no way to force ata(4) to use only UDMA2 modes. (6) You currently need an USB keyboard; I'm planning to add dhclient(8) and sshd(8) automatic startup to the liveCD later. Anyway, feel free to give this a try and report any problems back to me. I intend to clean up the script used to build the ISO images in a short while. [1] Cromwell from xbox-linux.org CVS contains all patches required to be able to boot the recent FreeBSD kernels. However, it does not support direct booting from UFS partitions. Regards, -- Rink P.W. Springer- http://rink.nu "When will the internet move from 64Kb max .com domains to .exe domains which can use much more memory?" - Edwin Groothuis pgpI30RVJMrKs.pgp Description: PGP signature
Re: NFS locking: lockf freezes (rpc.lockd problem?)
On Sun, Aug 27, 2006 at 11:24:13AM +, Michael Abbott wrote: > I've been trying to make some sense of the "NFS locking" issue. I am > trying to run > # make installworld DESTDIR=/mnt > where /mnt is an NFS mount on a FreeBSD 4.11 server, but I am unable to > get past a call to `lockf`. > > On this mailing list I've seen a thread starting with this message: > > http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027561.html > and elsewhere I've seen this thread: > http://www.gatago.com/mpc/lists/freebsd/stable/21851805.html > > The gist seems to be that rpc.lockd is badly behaved and broken and nobody > knows how to fix it. So, in case my experience is any help, here is what > I can report. > > 1. I have installed a fresh installation of FreeBSD 6.1 from the CD, > 6.1-RELEASE-i386-disc1.iso, and have run `cd /usr/src; make buildworld; > make buildkernel` successfully (takes nearly 8 hours, but then it is a > fanless machine). The full distribution (as installed by sysinstall) is > present, but nothing else. > > 2. Intending to experiment with network booting, I've attempted > `make installworld DESTDIR=/mnt`, where /mnt is an NFS mount point on my > master server, running FreeBSD 4.11-RELEASE-p11. > > 3. This fails when invoking lockf. To work around this, I have started > rpc.lockd on the 4.11 server and configured all of the following lines in > rc.conf: > rpcbind_enable="YES" > nfs_client_enable="YES" > rpc_lockd_enable="YES" > rpc_statd_enable="YES" > > 4. Now here is the behaviour: > > # mount $MY_SERVER:$MY_PATH /mnt > # lockf /mnt/test ls > This works just fine > # cd /usr/src; make installworld DESTDIR=/mnt > This hangs in lockf, and is unkillable (even `kill -9` is no good, and ps > shows state = D+). So let's start another shell (Alt-F2): > # lockf /mnt/test ls > Also hangs. > > Rebooting the test machine clears the problem, returning to the state at > the start of point (4), and the problem is completely repeatable in my > configuration. > > > Some observations: > > - Hanging in "uninterruptible sleep" is not good. No doubt it's quite > possible that my 4.11 server has a broken rpc.lockd (or maybe I've not > configured it right: I just started rpc.lockd, rather than restarting the > server), but the behaviour of 6.1 is exceptionally unfriendly. In > particular, unkillable processes look like outright bugs to me. > > - The conversation on mpc.lists.freebsd.stable (and elsewhere) looks > alarming. I get the impression that this part of FreeBSD 6.1 is really > rather broken and that there's no real sense of what to do about it. Make sure that rpc.statd is running. For debugging purposes, tcpdump of the corresponding communications would be quite useful. Besides this, output of ps auxww | grep 'rpc\.' may be interesting. pgpvRfK1jAiLS.pgp Description: PGP signature
Re: NFS locking: lockf freezes (rpc.lockd problem?)
On Sun, Aug 27, 2006 at 11:24:13AM +, Michael Abbott wrote: > I've been trying to make some sense of the "NFS locking" issue. I am > trying to run > # make installworld DESTDIR=/mnt > where /mnt is an NFS mount on a FreeBSD 4.11 server, but I am unable to > get past a call to `lockf`. I have not closely followed the discussion, as I have not experienced the problem. I am currently running FreeBSD6 based fileservers in an environment that includes FreeBSD, Linux (multiple flavors), Solaris, and Irix clients, and have experienced no nfs locking issues (I have one occasional problem with 64-bit Linux clients, but it is not locking related and appears to be due to a 64-bit Linux problem). Further, (though there may well be problems with nfs locking) I cannot recreate the problem you described -- at least in a FreeBSD6 environment. I have just performed a test of what you describe, using 'smbtest' (6.1-STABLE #17: Fri Aug 25 12:25:19 CEST 2006) as the client and 'data-2' (FreeBSD 6.1-STABLE #16: Wed Aug 9 15:38:12 CEST 2006) as the server. data-2 # mkdir /export/rw/bsd6root/ ## /export/rw is already exported via NFS smbtest # mount data-2:/export/rw/bsd6root /mnt smbtest # cd /usr/src smbtest # make installworld DESTDIR=/mnt [...] makewhatis /mnt/usr/share/man makewhatis /mnt/usr/share/openssl/man rm -rf /tmp/install.2INObZ3j smbtest # Which is to say that it completed successfully. Which suggests that there is not a serious and ongoing problem. There may well be a problem with FreeBSD4, but I no longer have any NFS servers running FreeBSD4.x, so I cannot confirm. Alternatively, there may have been a problem in 6.1-RELEASE that has since been solved in 6.1-STABLE that I am using. Or there could be a problem with the configuration of your server. Or there could be something else going on (in the network...?). But to see what exactly is happening in your case, you would probably want to look at what exactly is happening on the client, the server, and the network between them. -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS locking: lockf freezes (rpc.lockd problem?)
I've been trying to make some sense of the "NFS locking" issue. I am trying to run # make installworld DESTDIR=/mnt where /mnt is an NFS mount on a FreeBSD 4.11 server, but I am unable to get past a call to `lockf`. On this mailing list I've seen a thread starting with this message: http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027561.html and elsewhere I've seen this thread: http://www.gatago.com/mpc/lists/freebsd/stable/21851805.html The gist seems to be that rpc.lockd is badly behaved and broken and nobody knows how to fix it. So, in case my experience is any help, here is what I can report. 1. I have installed a fresh installation of FreeBSD 6.1 from the CD, 6.1-RELEASE-i386-disc1.iso, and have run `cd /usr/src; make buildworld; make buildkernel` successfully (takes nearly 8 hours, but then it is a fanless machine). The full distribution (as installed by sysinstall) is present, but nothing else. 2. Intending to experiment with network booting, I've attempted `make installworld DESTDIR=/mnt`, where /mnt is an NFS mount point on my master server, running FreeBSD 4.11-RELEASE-p11. 3. This fails when invoking lockf. To work around this, I have started rpc.lockd on the 4.11 server and configured all of the following lines in rc.conf: rpcbind_enable="YES" nfs_client_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" 4. Now here is the behaviour: # mount $MY_SERVER:$MY_PATH /mnt # lockf /mnt/test ls This works just fine # cd /usr/src; make installworld DESTDIR=/mnt This hangs in lockf, and is unkillable (even `kill -9` is no good, and ps shows state = D+). So let's start another shell (Alt-F2): # lockf /mnt/test ls Also hangs. Rebooting the test machine clears the problem, returning to the state at the start of point (4), and the problem is completely repeatable in my configuration. Some observations: - Hanging in "uninterruptible sleep" is not good. No doubt it's quite possible that my 4.11 server has a broken rpc.lockd (or maybe I've not configured it right: I just started rpc.lockd, rather than restarting the server), but the behaviour of 6.1 is exceptionally unfriendly. In particular, unkillable processes look like outright bugs to me. - The conversation on mpc.lists.freebsd.stable (and elsewhere) looks alarming. I get the impression that this part of FreeBSD 6.1 is really rather broken and that there's no real sense of what to do about it. I hope I've sent this mail to the right place and that it's of some help. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 16M RAM enough for FreeBSD 6.1?
On Sun, 2006-Aug-27 11:00:30 +0200, Torfinn Ingolfsen wrote: >On Sun, 27 Aug 2006 17:13:29 +1000 >Peter Jeremy <[EMAIL PROTECTED]> wrote: > >> The CD-ROMs create a RAMdisk and need a minimum of 24MB last I >> checked. > >And I guess that the floppies work in the same way? Yes. >> Once you have FreeBSD installed, it will limp along in 16MB >> (though not very happily). > >Hmm, I see. I'm planning to run X on this old box (it's going to be a >PictureFrame project), perhaps that will not work. I think you would be thrashing if there was any actual activity. I'll prod a friend with the same setup to comment tomorrow. >> I strongly suggest you find a SODIMM to >> expand it. > >Ok. Are all SODIMMs equal (ie. a real standard), or do I hvae to look >specifically for memory upgrades for the Armada 1580 (or 1500 series)? I'm 99% certain that you can't use anything bigger than 64MB (at least a 128MB Cpq Armada SODIMM that I had wouldn't work in any of the 15xx machines I tried it in - that included a 1580). I'm not sure how interchangeable they are. -- Peter Jeremy pgphED8wKMZpV.pgp Description: PGP signature
Re: 16M RAM enough for FreeBSD 6.1?
On Sun, 27 Aug 2006 17:13:29 +1000 Peter Jeremy <[EMAIL PROTECTED]> wrote: > The CD-ROMs create a RAMdisk and need a minimum of 24MB last I > checked. And I guess that the floppies work in the same way? > Once you have FreeBSD installed, it will limp along in 16MB > (though not very happily). Hmm, I see. I'm planning to run X on this old box (it's going to be a PictureFrame project), perhaps that will not work. > I strongly suggest you find a SODIMM to > expand it. Ok. Are all SODIMMs equal (ie. a real standard), or do I hvae to look specifically for memory upgrades for the Armada 1580 (or 1500 series)? -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 16M RAM enough for FreeBSD 6.1?
On Sat, 26 Aug 2006 22:44:24 -0500 Nikolas Britton <[EMAIL PROTECTED]> wrote: > How do you know it has CardBus / PCMCIA 2.1 / JEIDA 4.2? have you > checked? This standard was introduced in 1995. I don't *know* it, but all evidence seems to point in that direction. :-) Quote from chapter 7 of the user guide: "Important: the PC Card slots on the computer are CardBus slots that support 16- and 32-bit PC Cards. They support the newer generation of 32-bit (CardBus) designed to take advantage of audio, video, multifunction and high-speed LAN capabilities". BTW, first edition of the User Guide is from March 1997, I also tested with a CardBus card, and it fits into the slot. > Yep. Try DragonFly BSD, it's based on FreeBSD 4.x code so it should be Ok, So DragonFlyBSD supports CardBus cards? I'll try it. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPFW + NATD rules
Hi! I'm a junior in FreeBSD, and I faced with problem. I've a FreeBSD 6.1-stable box as a gate+firewall, and I want to divert incoming requests to my web-server, placed in DeMilitarized Zone (DMZ). To do this I wrote down settings in /etc/rc.conf as shown above: natd_flags="-redirect_port tcp 80 192.168.1.234 80" natd_flags="-redirect_port tcp 443 192.168.1.234 443" I think, that all packets incoming from Internet will be diverted from the External interface via DMZ interface to my We-server. Is it right? If not, why not, and what the way to make it working? Thanks a lot, yours sincerely Eugene Orlov, Russia, Izhevsk [EMAIL PROTECTED] +7 3412 43-12-12 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 16M RAM enough for FreeBSD 6.1?
On Sun, 2006-Aug-27 03:46:52 +0200, Torfinn Ingolfsen wrote: >I have an old laptop, a Compaq Armada 1580DMT, with 16M RAM, 2GB hd, ... >However, when I try the 6.1-release CD (CD1), it boots as far as >loading the kernel, botting the kernel, and then reboots again?? The CD-ROMs create a RAMdisk and need a minimum of 24MB last I checked. Once you have FreeBSD installed, it will limp along in 16MB (though not very happily). I strongly suggest you find a SODIMM to expand it. -- Peter Jeremy pgp8Sla873Ncg.pgp Description: PGP signature
