Re: FreeBSD NFS server benchmarks vs. OpenBSD, NetBSD?
Terry makes some very excellent points that I've tested and documented in Real Life. Two years ago I did a bunch of extensive testing between three NFS servers (Sun, FreeBSD, NetApp) and one set of NFS clients (FreeBSD). Anyone that knows NFS really well would have predicted our test results that demonstrated the FreeBSD NFS server as being the best performer. The FreeBSD system was a home build with a GigE card, tuned MTU, large window, etc... running on a Cisco GigE switch. It solidly outperformed every other NFS server. If you were to have used Solaris clients, it's quite likely that one of the other two servers would have outperformed the FreeBSD server. Tuning the NFS server and the clients also has enormous potential for improvement. It took dozens of iterations to find the ideal combination of MTU size, nfsiod clients, nfsd servers, in the mail cluster I build. However, the engineering effort held large dividends. That mail system is still in use, seldom touched by human hands. It's withstood mail storms, DoS attacks, and many other network events that have been catastrophic to some of our other mail systems. Your best bet is to take a look at each of the platforms and determine which suits your needs best. Once you've etched that in stone, install your OS of choice and start tuning it to best suit your environment. The above is all unbiased. I personally have used quite a few NFS systems, a few more than I'd like to have. Many others will have opinions but here are mine: BSDI has, IMHO, one of the finest NFS implementations anywhere. I've used it extensively with NT, Mac OS, Mac OS X, BSDI, FreeBSD, Linux, and Solaris clients. As of BSDI 4.0/4.1 (IIRC) it supported NFS locking and worked VERY, VERY well with BSDI clients (as should be expected). I don't know how it's doing these days, I've dropped off the BSDI mailing lists and stopped using it in favor of FreeBSD. FreeBSD has very solid NFS code in addition to being a very robust, versatile, and downright fun operating system. It's very easy to do everything I want to with FreeBSD. It's NFS is missing locking support but it's very fast and works very well with FreeBSD and Mac OS X clients. I haven't used it with anything else. OpenBSD and NetBSD both fall into the same category in my book. Both OS's attack a niche that is too narrow for my purposes. I've installed NetBSD on a HP 9000, Mac IIci, and Intel hardware and, it works, but I couldn't ever easily do anything useful with them. OpenBSD is OpenBSD and life is too short to fight some battles. Sun wrote the book on NFS. They also missed the boat. NFS on Sun is reliable and works well with Sun NFS clients. Good luck with anything else. Performance has never been a feature of Sun's NFS implementation so keep shopping if you care about it. Linux NFS sucks. Some will point out that it's made LOTs of progress. They should also note there's a long ways to go. Linux NFS interaction with NetApp, FreeBSD, and Sun NFS servers is very problematic and never achieves good performance. Matt On Thursday, June 20, 2002, at 11:15 PM, Terry Lambert wrote: Dan Ellard wrote: Has anyone done a side-by-side benchmark of the FreeBSD, OpenBSD, and NetBSD NFS servers on the same hardware? Note that I'm interested in server performance, not client performance. I'm particularly interested in read performance, but anything would be interesting. In lieu of actual data, which system do people think makes the best NFS server for heavily-loaded systems? I don't think anyone has benchmarked this; if they had, color me astonished. Your best bet would be to compare them yourself, since it's not that hard to install them. FWIW, You can't seperate server and client performance. If you have two clients and two servers, the first client caches operation X, and the second client does not, and you have two servers, one where operation X is very fast, and reads are OK, and the other where operation X is very slow, but reads are slightly faster than just OK, which one shows up as being better is going to depend in the client you use in the benchmarks. If you're asking about a server and not a client, then you would be better of asking about the particular client by name vs. each of the possible server choices. PS: Your answers are going to differ based on UDP vs. TCP and rsize/wsize. In particular, if you need to have an rsize/wsize larger than the MTU, make sure you are using TCP, not UDP, or you will be shooting yourself in the foot (most Linux clients wonder why when they use UDP, their nubers go to hell; that's why). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message `` Matt Simerson [EMAIL PROTECTED] Unix Systems Engineer Interland, Inc. -- I drive too
Re: Hardware for FreeBSD
On Friday, May 17, 2002, at 10:23 AM, Nathan Hawkins wrote: For years, I've had the best luck with building my own systems, or having built to my specifications. Have comp delivered mostly assembled, but without hard drive installed, I can usually avoid having to buy Windows, too. Going this route, I pick all the parts, and can generally eliminate OS incompatibilities. I also don't buy lowest bidder parts, or try to save money on motherboards. That said, I've had pretty good luck with Dell hardware. At least the Optiflex line, don't know about PowerEdges. The Optiflex's I've bought all run both Linux and FreeBSD with no problems. (Local computer store has had used ones very cheap.) Years ago (~4) I used and loved the PowerEdge servers. They were always well engineered, solid servers that i could safely recommend to clients as well as using myself. I've used the Compaq DL380 with Linux, and would recommend it as quite good and reliable hardware. Looks like the Compaq RAID controller is supported on FreeBSD, but I don't have access to one anymore, so can't try it. Yup, Compaq DL380's work just fine with FreeBSD, I have several of them in production. I also have some of the Compaq 1850R. They suck. They'll work with FreeBSD but under heavy load, I've had all sorts of reliability problems with them. Matt ---Nathan Bogdan TARU wrote: Hi hackers, I am in a big dillema (and great hurry/pressure). I need to buy some hardware for some firewalls for my company. And so the blues started. First, I went to Dell. Almost signed the papers for two PowerEdges 2550, (everything in them seemed to be compatible with FreeBSD) when I found out they are longer then the rack!!! And not only the 2550, but most of their cases. So I went to IBM. A little more expensive, but what the hack? It's IBM. So, almost made a system, and when coming to checking the compatibility list, IBM ServeRaid is not supported under FreeBSD. WTF??? So my question is: if you'd have to buy good/reliable hardware now, which is the vendor you'd choose (considering the facts above)? I looked on the FreeBSD's site for some hardware vendors in Germany (where I live), but none found. And I'd go for a brand name, anyways. Thank you, bogdan iCom Media AG Kirchweg 36 Koln, 50858 Germany Phone: +49-(0)221-485-689-16 Fax : +49-(0)221-485-689-20 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message `` Matt Simerson [EMAIL PROTECTED] Unix Systems Engineer Interland, Inc. If you keep an open mind people will throw a lot of garbage in. `` To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, freebsd 4.5
I'm interested too. I've seen this problem (quite a few times) on a large system (1k-10k+) users. It only happens on systems being provisioned to via pw. Matt On 5/2/02 4:27 PM, Geoffrey C. Speicher [EMAIL PROTECTED] wrote: On Sat, 9 Mar 2002 04:52:25 -0600, Matthew D. Fuller wrote: [in regard to multiple concurrent pw(8) processes hosing master.passwd] The reason for this is that the only file pw(8) locks is /etc/master.passwd.new when it copies into it. [snip] If anybody's interested, I could take a stab at hacking something together for this sometime over the next week or so. I'm interested. How did the stab go? I'm browsing archives and I can't find any more followups. Geoff -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Is natd the right tool?
For starters, I don't use named. Furthermore, it wouldn't matter because
this is for a cluster of load balanced name servers. There is a series
of public interfaces (VIPs) that all of the boxes share. That series of
Virtual addresses is on each real servers loopback interface. However,
since it's on loopback I can't query it directly unless I'm on the box.
So, I'm fishing for a clean way to test each VIP on each server remotely.
Matt
On Friday, April 12, 2002, at 02:01 AM, Crist J. Clark wrote:
Why don't you just have each named(8) listen on the different port?
See 'listen-on' in named.conf(5).
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
On Thu, Apr 11, 2002 at 09:24:24AM -0400, Matt Simerson wrote:
Natd is a very cool tool for doing stuff like redirecting
connections from an external network to an internal one but I'm have a
slightly different problem. I have a single host with one public
interface:
host - fxp0 = 192.168.7.251
Also on this same host is a bunch more IP's on the loopback interface:
host - lo0 = 127.0.0.1
127.0.0.2
.
On each of the loopback addresses I have a DNS server listening. This
part works just fine:
matt@matt: {101} % dig www.foo.com @127.0.0.2
verbosity snipped
;; ANSWER SECTION:
www.foo.com.1D IN A 207.89.154.94
What I want to be able to do is send a dns query to the external
interface of the machine on a non-standard port and have it redirect
the query to a loopback address/port and return the query the
appropriate query result to me.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Is natd the right tool?
Natd is a very cool tool for doing stuff like redirecting connections from an external network to an internal one but I'm have a slightly different problem. I have a single host with one public interface:
host - fxp0 = 192.168.7.251
Also on this same host is a bunch more IP's on the loopback interface:
host - lo0 = 127.0.0.1
127.0.0.2
.
On each of the loopback addresses I have a DNS server listening. This part works just fine:
matt@matt: {101} % dig www.foo.com @127.0.0.2
verbosity snipped>
;; ANSWER SECTION:
www.foo.com.1D IN A 207.89.154.94
What I want to be able to do is send a dns query to the external interface of the machine on a non-standard port and have it redirect the query to a loopback address/port and return the query the appropriate query result to me.
So, after reading the man page several times, I've tried using natd like this:
natd -n fxp0 -redirect_port udp 127.0.0.2:53 192.168.7.251:55
However, doing so simply get's me a connection refused when I send it a query like this:
matt@matt: {102} % dig -p 55 @192.168.7.251 www.foo.com
; >> DiG 8.3 >> -p @192.168.7.251 www.foo.com
; (1 server found)
;; res options: init recurs defnam dnsrch
;; res_nsend to server 192.168.7.251: Connection refused
matt@matt: {103} %
I'm not exactly certain why it's failing. Is this the best approach to solving this problem? Is there a better way to go about this?
Matt
Re: Is natd the right tool?
My apologies, I didn't realize the default format on my new client was rich text format. Matt On Thursday, April 11, 2002, at 01:17 PM, Asenchi wrote: could you please not send emails to the list in html. thank you. asenchi. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[no subject]
Natd is a very cool tool for doing stuff like redirecting connections from an external network to an internal one but I'm have a slightly different problem. I have a single host with one public interface:
host - fxp0 = 192.168.7.251
Also on this same host is a bunch more IP's on the loopback interface:
host - lo0 = 127.0.0.1
127.0.0.2
.
On each of the loopback addresses I have a DNS server listening. This part works just fine:
matt@matt: {101} % dig www.foo.com @127.0.0.2
verbosity snipped>
;; ANSWER SECTION:
www.foo.com.1D IN A 207.89.154.94
What I want to be able to do is send a dns query to the external interface of the machine on a non-standard port and have it redirect the query to a loopback address/port and return the query the appropriate query result to me.
So, after reading the man page several times, I've tried using natd like this:
natd -n fxp0 -redirect_port udp 127.0.0.2:53 192.168.7.251:55
However, doing so simply get's me a connection refused when I send it a query like this:
matt@matt: {102} % dig -p 55 @192.168.7.251 www.foo.com
; >> DiG 8.3 >> -p @192.168.7.251 www.foo.com
; (1 server found)
;; res options: init recurs defnam dnsrch
;; res_nsend to server 192.168.7.251: Connection refused
matt@matt: {103} %
I'm not exactly certain why it's failing. Is this the best approach to solving this problem? Is there a better way to go about this?
Matt
Re: Is natd the right tool?
On Thursday, April 11, 2002, at 01:39 PM, Julian Elischer wrote: check out ipfw's 'fwd' command Cool, never realized that was there. So, I tried it: I recompiled my kernel after adding IPFIREWALL_FORWARD to it. Then: ipfw add fwd 127.0.0.2,53 udp from any to 192.168.7.251 55 ipfw add fwd 127.0.0.2,53 tcp from any to 192.168.7.251 55 matt# ipfw show 00100 4 228 fwd 127.0.0.2,53 udp from any to 192.168.7.251 55 00200 00 fwd 127.0.0.2,53 tcp from any to 192.168.7.251 55 65535 528096 456266843 allow ip from any to any (I use DEFAULT_TO_ACCEPT) xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=3rxcsum,txcsum inet 192.168.7.251 netmask 0xfe00 broadcast 192.168.7.255 ether 00:01:02:38:2b:c7 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 inet 127.0.0.2 netmask 0x DNS server still serves happily off 127.0.0.2: matt# dig www.foo.com @127.0.0.2 ; DiG 8.3 www.foo.com @127.0.0.2 snip ;; ANSWER SECTION: www.foo.com.1D IN A 207.89.154.94 snip But it still won't serve off my external interface: matt# dig -p55 www.foo.com @192.168.7.251 ; DiG 8.3 -p55 www.foo.com @192.168.7.251 ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend to server 192.168.7.251: Connection refused What am I missing? Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: technical comparison
-Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 22, 2001 10:59 AM To: [EMAIL PROTECTED] Subject: Re: technical comparison ] I work in an environment consisting of 300+ systems, all FreeBSD ] and Solaris, along with lots of EMC and F5 stuff. Our engineering division ] has been working on a dynamic content server and search engine for the ] past 2.5 years. They have consistently not met up to performance and ] throughput requirements and have always blamed our use of FreeBSD for it. You may wish to point out to them that their F5 boxes are running FreeBSD. Terry Lambert [EMAIL PROTECTED] When did that change? As of March which was the last time I had my grubby little hands all over a F5 BigIP box in our lab, it was NOT running FreeBSD. It runs a tweaked version of BSDI's kernel. Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Quota reporting is inaccurate.
I have an streaming server that does a mere three things in life. It accepts FTP connections from users with local accounts and streams the files back via Real streaming server or Darwin Streaming Server. That's it, other than some log file processing and backups, that's all this machine does. In the last 8 months of service, a few anomolies related to quotas have popped up. Every time it happens, the quota mechanism reports that the user is using more space than they really are. I've dug through the mailing list archives and found another user with this same problem so I'm going to add a little fuel that fire and hope a resolution to this can be found. On this machine all users get a fixed quota size which they are obliged not to exceed. Quota's are set up as follows: real1# more /etc/fstab # DeviceMountpoint FStype Options Dump Pass# /dev/mlxd0s1b noneswapsw 0 0 /dev/mlxd0s1a / ufs rw 1 1 /dev/mlxd1s1e /usrufs rw,userquota2 2 /dev/mlxd0s1e /varufs rw 2 2 proc/proc procfs rw 0 0 Quotas are enabled at boot time: real1# grep quota /etc/rc.conf enable_quotas="YES" For the most part, quota's work just fine. I build this machine on FreeBSD 4.1.1-STABLE shortly after 4.1.1 was released. The server has been humming along, doing it's streaming thing quite nicely. It's only reboot in the last 8 months was last month when I upgraded from 4.1.1 to 4.2-STABLE (4.3-BETA) hoping for a fix to the quota problem. FTP connections are chrooted to the users home directory so the user cannot write files outside it. We can see how much space is in use as follows: real1# du -d1 ~dahl 190827 /usr/home/dahl So the user is only using 190MB of space on /usr. We can verify this by checking the entire /usr filesystem and verifying all results are in ~dahl which I have done as follows: real1# find /usr -user dahl So, the only files owned by dahl that exist live in his home dir as expected. Doing a long list on the files confirms the file sizes and du's count of 190MB: real1# ll ~dahl total 190826 -rw-r--r-- 1 dahl user 628 Mar 27 15:10 .cshrc -rw-r--r-- 1 dahl user 299 Mar 27 15:10 .login -rw-r--r-- 1 dahl user 160 Mar 27 15:10 .login_conf -rw--- 1 dahl user 371 Mar 27 15:10 .mail_aliases -rw-r--r-- 1 dahl user 331 Mar 27 15:10 .mailrc -rw-r--r-- 1 dahl user 722 Mar 27 15:10 .profile -rw--- 1 dahl user 276 Mar 27 15:10 .rhosts -rw-r--r-- 1 dahl user 852 Mar 27 15:10 .shrc -rwxr-xr-x 1 dahl user 108 Mar 27 15:10 .xinitrc -rwxr-xr-x 1 dahl user 108 Mar 27 15:10 .xsession -rw-r--r-- 1 dahl user 35826182 Apr 9 20:26 Mon040901.rm -rw-r--r-- 1 dahl user 47932775 Apr 9 12:03 Phish.rm -rw-r--r-- 1 dahl user 35451065 Apr 10 17:33 Tue041001.rm -rw-r--r-- 1 dahl user 37613531 Mar 30 17:40 best0f5.rm -rw-r--r-- 1 dahl user 38383851 Mar 30 08:17 bestof4.rm We verify our quota settings noting that quota's think that dahl is using 345MB when in reality it should be reporting 190MB: real1# quota dahl Disk quotas for user dahl (uid 4639): Filesystem blocks quota limit grace files quota limit grace /usr 345659 358400 358400 2110002000 OK, so somehow our quota consistency got maligned. Running quotacheck should fix this right? So, we run quotacheck on our /usr filesystem: real1# quotacheck -v /usr *** Checking user quotas for /dev/mlxd1s1e (/usr) unknown uid: 1751 root fixed: blocks 2508870 - 2508868 real fixed: blocks 197062 - 197046 So, quotacheck doesn't discover or fix the discrepancy. :-( Any ideas why this behavior would occur? Better yet, any idea how to fix it? Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Quota reporting is inaccurate.
Actually, I believe it reports based upon the contents of the BLOCKSIZE environment variable which is 1k or 1024 bytes for the purposes of this discussion. In either case, you'll notice that the reporting shown below accurately shows that the users quota is very near the limit and the quota is set at 350MB. Interestingly enough, I added check_quotas="YES" to /etc/rc.conf and rebooted. That fixed that users quota problem. I'm not sure if it was the rebooting (and clearing the kernels idea of what the quota should be) or if running quotacheck in single user mode did it. I have to guess the former because quotacheck's results should not vary dependent on whether the machine is single user or not. Matt -Original Message- From: Ken Stox [mailto:[EMAIL PROTECTED]] Sent: Friday, April 13, 2001 12:40 PM To: Matt Simerson Subject: Re: Quota reporting is inaccurate. If memory serves correct, I think you will find quota reports 512byte block, not 1k blocks. On Fri, 13 Apr 2001, Matt Simerson wrote: I have an streaming server that does a mere three things in life. It accepts FTP connections from users with local accounts and streams the files back via Real streaming server or Darwin Streaming Server. That's it, other than some log file processing and backups, that's all this machine does. In the last 8 months of service, a few anomolies related to quotas have popped up. Every time it happens, the quota mechanism reports that the user is using more space than they really are. I've dug through the mailing list archives and found another user with this same problem so I'm going to add a little fuel that fire and hope a resolution to this can be found. On this machine all users get a fixed quota size which they are obliged not to exceed. Quota's are set up as follows: real1# more /etc/fstab # DeviceMountpoint FStype Options Dump Pass# /dev/mlxd0s1b noneswapsw 0 0 /dev/mlxd0s1a / ufs rw 1 1 /dev/mlxd1s1e /usrufs rw,userquota2 2 /dev/mlxd0s1e /varufs rw 2 2 proc/proc procfs rw 0 0 Quotas are enabled at boot time: real1# grep quota /etc/rc.conf enable_quotas="YES" For the most part, quota's work just fine. I build this machine on FreeBSD 4.1.1-STABLE shortly after 4.1.1 was released. The server has been humming along, doing it's streaming thing quite nicely. It's only reboot in the last 8 months was last month when I upgraded from 4.1.1 to 4.2-STABLE (4.3-BETA) hoping for a fix to the quota problem. FTP connections are chrooted to the users home directory so the user cannot write files outside it. We can see how much space is in use as follows: real1# du -d1 ~dahl 190827 /usr/home/dahl So the user is only using 190MB of space on /usr. We can verify this by checking the entire /usr filesystem and verifying all results are in ~dahl which I have done as follows: real1# find /usr -user dahl So, the only files owned by dahl that exist live in his home dir as expected. Doing a long list on the files confirms the file sizes and du's count of 190MB: real1# ll ~dahl total 190826 -rw-r--r-- 1 dahl user 628 Mar 27 15:10 .cshrc -rw-r--r-- 1 dahl user 299 Mar 27 15:10 .login -rw-r--r-- 1 dahl user 160 Mar 27 15:10 .login_conf -rw--- 1 dahl user 371 Mar 27 15:10 .mail_aliases -rw-r--r-- 1 dahl user 331 Mar 27 15:10 .mailrc -rw-r--r-- 1 dahl user 722 Mar 27 15:10 .profile -rw--- 1 dahl user 276 Mar 27 15:10 .rhosts -rw-r--r-- 1 dahl user 852 Mar 27 15:10 .shrc -rwxr-xr-x 1 dahl user 108 Mar 27 15:10 .xinitrc -rwxr-xr-x 1 dahl user 108 Mar 27 15:10 .xsession -rw-r--r-- 1 dahl user 35826182 Apr 9 20:26 Mon040901.rm -rw-r--r-- 1 dahl user 47932775 Apr 9 12:03 Phish.rm -rw-r--r-- 1 dahl user 35451065 Apr 10 17:33 Tue041001.rm -rw-r--r-- 1 dahl user 37613531 Mar 30 17:40 best0f5.rm -rw-r--r-- 1 dahl user 38383851 Mar 30 08:17 bestof4.rm We verify our quota settings noting that quota's think that dahl is using 345MB when in reality it should be reporting 190MB: real1# quota dahl Disk quotas for user dahl (uid 4639): Filesystem blocks quota limit grace files quota limit grace /usr 345659 358400 358400 21 10002000 OK, so somehow our quota consistency got maligned. Running quotacheck should fix this right? So, we run quotacheck on our /usr filesystem:
RE: Quota reporting is inaccurate.
-Original Message- From: Richard Hodges [mailto:[EMAIL PROTECTED]] Sent: Friday, April 13, 2001 1:23 PM To: Matt Simerson Cc: '[EMAIL PROTECTED]' Subject: RE: Quota reporting is inaccurate. On Fri, 13 Apr 2001, Matt Simerson wrote: Interestingly enough, I added check_quotas="YES" to /etc/rc.conf and rebooted. That fixed that users quota problem. I'm not sure if it was the rebooting (and clearing the kernels idea of what the quota should be) or if running quotacheck in single user mode did it. I have to guess the former because quotacheck's results should not vary dependent on whether the machine is single user or not. A while ago, I wanted to be sure that quotas were working and did some tests (on 3.4 release I think). In general, they worked as expected, except that when root changed a file's ownership, the quotas did not seem to reflect the change. I thought this was fixed in 4.x (when I did some more tests), but maybe this is still an issue? Are there file ownership changes going on? There shouldn't be anything like that happening. Every username is an unique user on the box and the only poeple with the ability to interactively login are employees are I log everything they do. Another thought is that this user may have had files still open. Even if you "remove" a file, it really does not go away until the last open handle is closed. That seems like the most likely possibility. However, only one daemon can add or delete files and that's FreeBSD's built in FTP daemon. If the deamon isn't running (and it wasn't) then the file shouldn't be open (in theory). I just installed lsof and we'll see if that doesn't reveal anything next time I see this crop up. Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: 4.3-BETA world crashing 4.2-RELEASE kernel ?
-Original Message- From: David O'Brien [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 8:41 PM To: Matt Simerson Cc: [EMAIL PROTECTED] Subject: Re: 4.3-BETA world crashing 4.2-RELEASE kernel ? First let me say to anyone reading the email I am replying to: don't do this On Wed, Mar 21, 2001 at 12:58:04PM -0700, Matt Simerson wrote: # cd /usr/src # make buildkernel KERNEL=KERNEL_CONFIG_FILE_NAME # cd /usr/src; make buildworld # make installworld # make installkernel # mergemaster # reboot The order or "make buildworld" and "make buildkernel" are 100% totally BACKWARDS. Actually, they aren't backwards. You've gone and snipped the parts of my original message that show that the commands are being executed at the same time. If either fails (for one reason or another as may happen) then I'll be able to plainly see why the build failed and correct it or go about fixing it manually. Lets explain why: There are times when the kernel source is changed to use constructs of newer compiler/assembler/linker tools. Thus the kernel will not build with an older set of tools. The what "make buildkernel" does is use the tools (ie, those built from the most up to date sources) that are built during "make buildworld" to compile a new kernel. Thus "make buildworld" must PROCEED "make buildkernel". Maybe I'm understanding you incorrectly here but according to what you just said, a "make buildkernel" will fail unless you have a set of compiler/assembler/linker tools in /usr/obj that were built from the make buildworld process. This is inaccurate at best and I suspect it's just plain wrong. I can "rm -r /usr/obj/*", "cd /usr/src; make clean", and then "make buildkernel KERNEL=BLAH" and it will succeed and build a happy little fully functionaly kernel. I've done this hundreds of times with success. So, I guess I'm not understanding your logic here. Would you care to explain further why this doesn't work? Second, the install order above is not the conservative, careful approach. One should issue "make installkernel reboot" after the "make buildkernel" to ensure the new kernel works sufficiently well. Maybe that's _YOUR_ method for installing but it's not necessarily the best one. Kernel's are not guaranteed to be backwards compatible and I've installed a shiny new kernel that worked just fine and allowed my machine to come up single user but because of some rude change in /etc/rc, ipfw, or any of a number of places the machine couldn't make it to multi-user and allow me to get back in (via the network). When most of your servers are in a data-center 50 miles away and the rest are thousands of miles away, you'd rather not spend the next two hours talking a NOC monkey through a 10 minute process (if you have console). I prefer to do everything possible to make sure the system is going to boot correctly the first time and let me regain access. Success at building and installing the kernel, world, AND running mergemaster gives me a reasonably good chance that when I issue the reboot, it'll come up nice and happy. Second, if I'm going through the bother of compiling a buildworld it's because I want the latest version of world on my system. If there are some problems with the new kernel, I'm not going to revert back to world.old. I'll fix whatever is screwed up with kernel and proceed. Last, but not least, is that I don't have a warm body near all of my servers. I often want to do the make buildworld kernel, installworld kernel, and mergemaster and NOT reboot. Then I'll pop an email off to a warm body nearby and, at his leisure, have him give it a CTRL-ALT-DEL on the console and watch it to make sure it comes back up. If not, one can always fall back to ``kernel.old''. One can fall back to kernel.old regardless. Even if I happen to have world.new installed, kernel.old will still work. There may be issues but if there is, they are surely no worse than running kernel.new with world.old. So, which is worse, the cart without a horse or a horse without a cart? Since there is no ``world.old''; after one does the "make installworld" backup tapes are the only way of taking the system back to its previous state. I don't know many people who do buildworlds just for fun. If I'm doing a buildworld it's because I want the newer world installed. If I'm doing it on a server, it's because I've tested it on a dev box and I know it works the way I want. At that point, I have no reason to fall back to the previous world. Matt -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
The right way to build a new world WAS: 4.3-BETA worldcrashin g 4.2-RELEASE kernel ?
- From: David O'Brien [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 12:56 PM To: Matt Simerson Cc: '[EMAIL PROTECTED]' Subject: Re: 4.3-BETA world crashing 4.2-RELEASE kernel ? On Thu, Mar 22, 2001 at 12:51:00PM -0700, Matt Simerson wrote: Actually, they aren't backwards. You've gone and snipped the parts of my original message that show that the commands are being executed at the same time. I read you message twice and came away with the same idea. You should write more clearly. I wrote the commands exactly as they would be issued, how much more clear can one possibly get? Because you lack familiarity with the tool I was using (screen) doesn't make my writing unclear. Your ignorance != my unclarity. To make matters worse, you snipped out all the parts you didn't understand and then reposted it with my name attached AND criticized it's behaviour which you had incorrectly interpreted. Maybe that's _YOUR_ method for installing but it's not necessarily the best one. Kernel's are not guaranteed to be backwards compatible and I've installed a shiny new kernel that worked just fine and allowed my machine to come up single user but because of some rude change in /etc/rc, ipfw, or any of a number of places the machine couldn't make it to multi-user and allow me to get back in (via the network). That you're doing this remotely is your problem. Ask any of the developers living on -CURRENT where often one wants to back out of a newly compiled world. I'm not running on -CURRENT and I certainly would never run -current on a machine that I didn't have ready access to the console of. I've tracked 5.0-current months ago when I needed a feature that wasn't in the 4-stable tree yet (dare I admit it was support for a sound card?). I find it to be highly annoying when I have to babysit the buildworld process and manually fix things to get a clean compile. The method I gave is the most sure and careful way. That you don't have consoles on your machines so you could do this properly doesn't mean what I posted isn't the safest and should be followed unless has special needs. I'm happy for you. But you have major flaws in your method where problems can bite you hard. How so? If the buildkernel fails, odds are really good that it won't successfully finish the compile, I won't get a kernel, I can't install a kernel that isn't compiled, and there isn't a problem other than that I don't have the new kernel I wanted. I can address this problem very easily and it's not likely to cause any further pain. As I said, I want users to know and use the safest method. I've seen enough email from users that were all confused about the right steps -- often getting confused from posts such as yours where you [hopefully] understand the consequences of your method and can deal with them. Many do not want to or cannot. OK then, the safest (and recommended) way to build 4-STABLE world is: make buildworld make kernel reboot (into single user) make installworld mergemaster reboot Many sysadmins will find this doesn't work in their environment (for a variety of reasons). The most obvious is that they need some custom features in their kernel. So, make a copy of GENERIC in /sys/i386/conf/, edit it accordingly (adding support for your sound card, x10 controller, IPFW, GB ether card, quotas, and whatever else). The procedure will likely work exactly that same: make buildworld make kernel KERNCONF=NEW_KERNEL_NAME (1) reboot make installworld mergemaster reboot 1. /usr/src/UPDATING Second, if I'm going through the bother of compiling a buildworld it's because I want the latest version of world on my system. Want != ability. I want a latest version of 5-CURRENT on my laptop, but CardBus is broken right now, so I am living with a Dec world. Such is life. Such is life on -current. I think this is the majority of our desparity. You live in a -current world where you're content to live with hacking and tweaking source as a "normal" part of the buildworld process. It's nice that you have console on all your boxes. I live in -stable where I can't remember the last time a make buildworld failed. In fact, it's been quite some time since building a kernel the new way "make buildkernel" failed and I think that was on a 4.1.1-release machine that I was upgrading to 4.3-stable. It required building via ./config KERNEL; cd ../../compile/KERNEL/; etc In my world where uptime matters, I don't normally have the luxury of installing world in single user mode either. I have a Portmaster at home so I can access console on my own machines but my "console" for all the machines that live in our datacenters is a portable KVM and a NOC monkey. Ouch. :-( If there are some problems with the new kernel, I'm not going to revert back to world.old. I'll fix whatever is screwed up with kern
RE: What is the latest known-good PXE build ?
I have a "magic floppy" which is nothing more than a DOS boot floppy with the fboot.exe program on it and a BIOS image. This works like a charm for my netbooting purposes: Intel (R) Boot Agent Version 4.0.12 PXE 2.0 Build 082 (Wfm 2.0), RPC v2.7.3 Press Ctrl+S to enter the Setup Menu I've written a rather lengthy document on the process at: http://matt.simerson.net/computing/freebsd.netboot.shtml I also have links to Alfreds PXE Jumpstart guide at http://matt.simerson.net/computing/unix.shtml#freebsd Anyway, that should help you out considerably. If I could legally give away a floppy with WIN-98 MSDOS installed and the fboot.exe program I would but I think doing so violates a software license or two. Matt -Original Message- From: Paul Saab [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 3:23 PM To: Mike Smith Cc: Luigi Rizzo; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: What is the latest "known-good" PXE build ? Mike Smith ([EMAIL PROTECTED]) wrote: The BIOS trace says the PXE is revision 2.0, build 68 : is there some other, perhaps better version of it ? (the on-board NIC on the machine is an fxp) Build 068 is a disaster; you ideally want 082 or later. is there some standard way to upgrade the pxe code on the cards ? in case, where do i get it from ? You should be able to get updates from Intel, or if you have access to a Windows development system you can grab the PXE reference implementation kit and build your own. You still need the code to drive the nic, and noone gives this out. I have the latest stuff at: http://people.freebsd.org/~ps/pxeroms/ Unfortunately you need windows to extract the files.. I can put up a few more of the files later when I get back from Munich which wont require you to use windows. -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FreeBSD doesn't recognize keyboard unless is plugged in atbo ot t ime.
Heeey, thank you guys. That is very useful information. I just got off the phone with Belkin and my replacement KVM is on the way Thanks, Matt -Original Message- From: Chris Shenton [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 24, 2001 10:11 AM To: Jos Backus Cc: [EMAIL PROTECTED] Subject: Re: FreeBSD doesn't recognize keyboard unless is plugged in at boot t ime. On Tue, 23 Jan 2001 23:21:46 -0800, Jos Backus [EMAIL PROTECTED] said: Jos I have the same problem with a Win2k system and a FreeBSD system Jos connected to an OmniCube 4-port switch, at rev. 1.5 (see the Jos bottom of the unit). Belkin says it's fixed in rev. 1.9 and is Jos willing to exchange the unit for a newer one. I recently got a Belkin OmniCube 4-port and it seems to allow FreeBSD machines to boot fine, even if the machine in question is NOT selected. A glance at the bootom indicates "V 1.9". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD doesn't recognize keyboard unless is plugged in at boott ime.
OK, one of my biggest pet peeves of late is that unless you have the PS/2 keyboard plugged in at boot time, it's not recognized. In a world of workstations where every machine has a keyboard, this would never really be a problem but in our data center, where we have rows of racks full of machines without keyboards, this is quite the annoyance. If a machine has problems, the NOC monkeys wheel over a KVM cart, plug it in, and when the machines doesn't respond to keyboard activity, assume it's locked up and power cycle it. We've got the NOC monkeys trained NOT to do that now (without trying a few other things) but it's still a real bugger when you want to get onto a box via console. You have to go plug in a KVM, reboot the machine, and then you can get console access. Long ago, a bright SUNny OS has this same problem and they found some clever workaround. I know that my BSDI systems don't suffer from this affliction either. Is there already a kernel option for this? Is there some other workaround? On a few machines I've build PS/2 connectors with a resistor that I plug in so that FreeBSD _thinks_ there is a keyboard there at boot time. Then we just unplug the PS/2 plug, plug in a keyboard, and all is happy. Oddly enough, this behavior is also manifested when said server is plugged into a Belkin OmniCube KVM switch unless the KVM is set to that machine. This too is highly annoying because I have to sit and watch a computer boot if I want to have console access to it. I can't be the only one having this problem can I? Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Link up/down events
While it can be done (I do it), using MRTG/rateup/Cricket/etc. without SNMP is much like pushing a car down the street. Sometimes it's The Right Thing to do but for the other 99.4% of the time, it's far preferable to use the engine to power it. UCD-SNMP is more than just the UCD SNMP daemon. It's also the client programs and a collection of SNMP utilities. With them you can do most of what you'd ever want to use SNMP for. MRTG is simply a data graphing utility. It uses SNMP to collect the data points but that's pretty much all of the relationship between the two. Matt -Original Message- From: Chuck Rock [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 10, 2001 11:17 AM To: FreeBSD Hackers Subject: RE: Link up/down events Has anyone looked into using SNMP with MRTG or some of the other utilities that comes with UCD-SNMP? I think this would be very easy this way. We use Castle Rock's SNMPc running on NT to montior our servers and connections. UCD-SNMP is a daemon and SNMP utilities for Linux and FreeBSD flavors that work well too. http://ucd-snmp.ucdavis.edu/ http://www.mrtg.org http://www.castlerock.com Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Samuel Tardieu Sent: Wednesday, January 10, 2001 11:07 AM To: Robert Watson Cc: Josef Karthauser; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Link up/down events On 10/01, Robert Watson wrote: | Presumably at some point in the stack, that notification is translated | from a hardware event, which might be associated with devd in some manner | (and possibly also exposed there). This is the ideal situation. The other one being that the status can be read, which would require some polling to monitor the link status. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Silent FreeBSD
I know your pain. At home I have a good sized collection of hardware and the noise level in my office was getting unbearably high. I used to have the mp3 player (xmms) turned up loud enough that I couldn't hear the doorbell ring. I had been drooling over the G4 cube just because they're silent and MacOS X really is nice. Some additional ideas to think about. If you've got another Unix server on the LAN, you could netboot the gateway. Rather than having a local file system (and consequently hard drive), use a Intel EtherExpress+ and PXE netboot it. It works surprisingly well. I have a stack of old PPro 200's with 128MB of RAM each, one Intel NIC card, and they all netboot off one FreeBSD server. I have them fetch a 25MB root file system which gets mounted as a MFS. You just need to have enough RAM in the machine to accomodate their root file system and nfs mount the /usr and anything else you want. If not, yet another option might be enabling the power management in BIOS so that the drive spins down when not in use. If the machine is just a gateway, it's file system probably isn't all that busy. Some machines also support having their fan speeds slow when in a power savings mode. Alas that wasn't enough for me so I worked around the problem in the following manner. First I replaced the drives in my G3 and FreeBSD X server with IBM GXP75 series UDMA drives. I had tested a few at work and was impressed. Not only are they wicked fast but they're cheap ($150 for 30GB), oh-so-quiet, and run very cool. Cool enough in fact that the internal temperature in my G3 case dropped enough that I was able to remove the CPU cooling fan I installed back when I overclocked it. That was two significant noise reductions. The G3 is very quiet now with only the power supply fan making a little noise. It's quiet enough that it sits on my desk without annoying me. My Dell PII450 on the other hand, that runs FreeBSD is not very silent. Despite the much quieter drive, the cooling fans are still fairly noisy. Rather than disabling one of the fans (without a good way to measure it's effect) I chose to instead get a longer set of KVM and sound cables and shove it into the not-so-far-away closet where it's whirring isn't offending my ears. I can then access the server via the KVM switch and run X programs via a SSH connection from the HP 9000 which is also be left out without offending my ears. The last step in silencing the office was running cat 5 to the garage, buying a 19" rack and rackmounting the pile of FreeBSD servers and networking hardware I had sitting in the office. I only turned on machines as I needed them in the office but since they're 2U rackmount servers, the fans are in the front and they're noisy. The garage has additional power drops and since it's only partially heated, it's always cooler and therefore a better location for the machines. Good luck to you and and may your silence be golden. Matt -Original Message- From: Renaud Waldura [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 27, 2000 11:00 AM To: [EMAIL PROTECTED] Subject: Silent FreeBSD I've got that FreeBSD gateway in a corner at my house, it works fine dandy but the constant noise (whirring fans, hard drives) gets on my nerves. What solutions have people explored to quiet down a computer system? (actual experience will be preferred over wild speculations). I'm already aware of PicoBSD, but I need more storage than just a floppy. Has anybody experimented with RAM cards? How about noise-proof enclosures? --Renaud To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: hardware Dell or BSDi
We've got a couple BSDI machines in our lab in addition to Micron's, HP's, and some black boxes we build ourselves. The BSDI box is by far the most economical (as far as buying rackmount) and perform as well as anything else. They are also using good "standard" parts which means you can find replacement components at CompUSA, Fryes, or wherever. The BSDI boxes are made by Telenet systems, a most respected hardware company (in many unix circles) who was recently purchase by BSDI. I'm pleased to say that even after the purchase they still make mighty fine servers. Matt On Wed, 13 Dec 2000, you wrote: Hello all, We are going to buy our first 1U 19" rack server (pizzacarton size), and probably there will be more in the future, they have to run FreeBSD 4.1-stable. Normally we buy all our hardware at Dell, they also have this kind of servers, for instance the PowerApp Web 100, we have also seen this kind of servers form BSDi.com, they have FreeBSD preinstalled, and say they are completely optimized. But they are considerably more expensive. Can anyone tell me more about both these servers, how good is the BSDi machine (and the organization), does FreeBSD install on the Dell and so on? tia Jeroen Heijungs Het Muziektheater Amsterdam, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: very big mail spool directory
I do it a little bit differently for my million user mail server. Rather than perform any (more) hackery on my MTA/MDA than necessary, I set up each mail domain as it's own UID/GID on the system. This approach has some limits but so far it's working great for me. With FreeBSD's pw tool and a bit of scripting it's pretty simple to build yourself a /usr/home/a/aa/aar/aardvark.com style tree. This type of solution has some great advantages. Since DNS (and consequently email addresses) is a hierarchy, it makes sense to keep the highest level (the domain name) mapping in one database. Qmail does this for us via it's users mechanism so we use that. When mail arrives qmail checks the /var/qmail/users/assign.cdb file and find's the username and home directory of domain owner. Qmail-local then mosies over to that directory (/usr/home/a/aa/aar/aardvark.com/) and obeys the contents of that domains .qmail processing. From there you can do whatever you'd like with mail for that domain. I use the vpopmail (http://www.inter7.com/vpopmail) package which includes a vdelivermail program that gets called. So, your .qmail-default has a call to vdelivermail which checks the username and does a lookup in the vpasswd.cdb that's contained in the domains home dir. There it finds the mail users actual mail directory and then drops it in there (subject to quota and other configurable limitations). The vpopmail package also has some mechanisms built on so that if the number of users for a domain exceeds a given limit (I can't remember exactly how many) then it builds a hash tree. Other than some compile time tuning, I leave the /var/qmail/queue untouched. So, you end up with something like this: #grep test /etc/passwd test:*:1454:88:test.com:/usr/home/t/te/test:/sbin/nologin #grep test.com /var/qmail/users/assign +test.com-:test.com:1454:88:/usr/home/t/te/test/domains/test.com:-:: #more /usr/home/t/te/test/domains/test.com/vpasswd test:*:1:0:testing:/usr/home/t/te/test/domains/test.com/test:100 test2:*:1:0:TEST2:/usr/home/t/te/test/domains/test.com/test2:1000 Every mail message ends up with two database lookups (assign.cdb vpasswd.cdb) but the databases are fairly compact and easy to replicate across an array of machines. It also means every authentication request (POP, IMAP, webmail) also has two database lookups but again, the lookups are from small databases, very fast, and distributed across an array of machines. This is a very simplistic overview of how it works but so far it's been a good solution. Best of luck to you. Matt -Original Message- From: Gustavo Vieira Goncalves Coelho Rios [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 12, 2000 12:50 PM To: [EMAIL PROTECTED] Subject: very big mail spool directory Hi folks, i am planning a very big email server, currently i am planning for about 8*2^16 users. I known that ufs has not good performance for very big directories, i.e., using a single directory to hold too many entries may lead to a low level performance.Since, my approach is to hash the spool mail dir for my users. Every user will have a single id that will map it's email address into a unique directory, this later will hold the user maildir. My spool mail dir is: /var/qmail/mail and all directory will be created within' it. The functions that will hash the id, accepts an id as input and returns a string for the user dir, like: IdString returned 0 0/0/0/0/0/0/0/0 1 0/0/0/0/0/0/0/1 . ./././././././. 150/0/0/0/0/0/0/f 160/0/0/0/0/0/1/0 170/0/0/0/0/0/1/1 . ./././././././. 320/0/0/0/0/0/2/0 . ./././././././. Got the ideia ? This allow me to perform at most 8*16 lookup_dir routine to get the users mails. So, my approach only works better for a number of users bigger than 96 in traditional /var/mail (that creates one file for each user, what can make performance drop down for a large amount of users). I believe my approach is very good, since if you have (for instance) 2^32 users, seeking the user dir would not take too much time! Any way i would really enjoy your comments. What you wizard have to say about my approach? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Optimal UFS parameters
That's because any "consensus" would be inappropriate for mass consumtion. It really depends on a lot of fun things like the average file size and the number of files that the drives will be storing. For example, a mail server might want more inodes than a database server. The mail server will likely have a lot of tiny files where the database server would have a collection of much larger (a few k vs several mb's each). What makes you think the defaults are unreasonable? I set up a 300GB filesystem a few months ago. I ran a few numbers, calculated my average file size, compared it to the defaults and found they were very close to reasonable. When I get a couple hundred gig's of data on there I'll know better but I think my guess-timates are very good. Matt -Original Message- From: A G F Keahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 06, 2000 7:53 PM To: [EMAIL PROTECTED] Subject: Optimal UFS parameters What parameters should I choose for a large (say, 60 or 80Gb) filesystem? I remember a while ago someone (phk?) conducted a survey, but nothing seems to have come of it. In the meantime, the capacity of an average hard drive has increased tenfold, and the defaults have become even less reasonable. What's the current consensus of opinion? newfs -b ? -f ? -c ? Thanks Alex Keahan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: PXE boot problem. - SOLVED
That was it. Updating the flash on the Intel NIC and she booted right up. Thanks, Matt -Original Message- From: Mathew KANNER [mailto:[EMAIL PROTECTED]] Sent: Friday, December 01, 2000 8:54 AM To: Matt Simerson Cc: '[EMAIL PROTECTED]' Subject: Re: PXE boot problem. On Nov 30, Matt Simerson wrote: [...] Intel UNDI, PXE-2.0 (build 067) Copyright (c) 1997, 1998 Intel Corporation [...] Get the flash upgrade from intel. Mine reads: Intel(R) Boot Agent Version 4.0.14 and it works well. --Mat -- Mathew Kanner [EMAIL PROTECTED] SOCS McGill University Obtuse quote: He [not me] understands: "This field of perception is void of perception of man." -- The Quintessence of Buddhism To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PXE boot problem.
Hi Folks,
I've been trying hard to get a FreeBSD system booted via PXE with only
limited success. Maybe someone can have a look at my configs and shed a
little light on this for me.
Here's what happens at boot time:
Intel UNDI, PXE-2.0 (build 067)
Copyright (c) 1997, 1998 Intel Corporation
DHCP MAC ADDR
CLIENT ID: 192.168.254.133 MASK: 255.255.255.0 DHCP IP: 192.168.254.3
GATEWAY IP: 192.168.254.1
PXE Loader 1.00
Building the boot loader arguments
Relocating the loader and the BTX
Starting the BTX loader
BTX loader 1.00 BTX Version 1.01
Console: internal video/keyboard
BIOS drive A: is disk0
PXE Version 2.1, real mode entry point @9db3:0106
BIOS 639kB/392180kB available memory
FreeBSD/i386 bootstrap loader, Revision 0.8
([EMAIL PROTECTED], Thu Nov 30 11:45:41 PST 2000)
pxe_open: server addr: 192.168.254.3
pxe_open: server path: /tftpboot
pxe_open: gateway ip: 192.168.254.1
\
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [kernel]...
\ (if using pxeboot)
can't load 'kernel' (if using pxeboot.tftp)
Because it'll be fetching the pxeboot file via tftp, it's set up as follows:
# grep tftp /etc/inetd.conf
tftpdgram udp waitnobody /usr/libexec/tftpd tftpd -l
/tftpboot
Since I've also tried to get it to work using TFTP for the kernel (as
opposed to NFS) I run inetd with the -R0 flag so that connections to inetd
services aren't rate limited.
# ps ax | grep inetd
1088 ?? Ss 0:00.01 inetd -wW -R0
My /tftpboot is set up as follows:
# ll /tftpboot/*
-rw-r--r-- 1 root wheel 2034 Nov 12 09:12 /tftpboot/install.cfg
-r-xr-xr-x 1 root wheel 2441176 Nov 30 11:54 /tftpboot/kernel
-rw-r--r-- 1 root wheel 2949120 Nov 30 11:57 /tftpboot/mfsroot
-rw-r--r-- 1 root wheel 165888 Nov 30 11:46 /tftpboot/pxeboot
-rw-r--r-- 1 root wheel 165888 Nov 30 11:47 /tftpboot/pxeboot.tftp
/tftpboot/boot:
-r--r--r-- 1 root wheel 512 Nov 11 16:57 boot1
-r--r--r-- 1 root wheel7680 Nov 11 16:57 boot2
-r-xr-xr-x 1 root wheel 163840 Nov 11 16:57 loader
-rw-r--r-- 1 root wheel 190 Nov 30 12:51 loader.rc
-rw-r--r-- 1 root wheel 190 Nov 11 18:42 loader.rc.custom
-rw-r--r-- 1 root wheel 136 Nov 30 12:21 loader.rc.flp
All the files in the boot directory are off the 4.1-stable boot floppy. The
loader.rc.custom is the same as the example given on Alfred's page and the
.flp one is off the floppy.
The pxeboot and pxeboot.tftp are exactly what you'd expect. The pxeboot file
is the default pxeboot with NFS support and the pxeboot.tftp was generated
by editing the /etc/make.conf file, setting the TFTP flag and recompiling
pxeboot. The files definately are different because I can change the DHCP
file to point to the other file and get different results at boot time.
NFS is configured as follows:
matt# more /etc/exports
/-alldirs -ro
/usr -alldirs -ro
/cdrom -alldirs -maproot=root -ro
matt# mount
/dev/ad0s2a on / (ufs, NFS exported, local)
/dev/ad0s2e on /usr (ufs, NFS exported, local)
/dev/acd0c on /cdrom (cd9660, NFS exported, local, read-only)
The DHCP server is a FreeBSD 4.2-stable system (make buildworld on
11/29/00). The DHCP server is isc-dhcp 3.0b2pl9 and is configured as shown:
option broadcast-address 192.168.254.255;
option domain-name-servers 192.168.254.3;
option domain-name "domain.com";
option routers 192.168.254.1;
option subnet-mask 255.255.255.0;
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
server-name "DHCPserver";
server-identifier 192.168.254.3;
subnet 192.168.254.0 netmask 255.255.255.0 {
option routers 192.168.254.1;
option root-path "/tftpboot";
filename "pxeboot";
#filename "pxeboot.tftp";(compiled for TFTP boot support vs
standard NFS)
range 192.168.254.32 192.168.254.99;
}
host c3.domain.com {
hardware ethernet 00:02:b3:1c:c6:02;
next-server 192.168.254.3;
fixed-address 192.168.254.133;
default-lease-time -1;
class "pxeclients"
{ match if substring (option vendor-class-identifier, 0, 9) =
"PXEClient";
option vendor-class-identifier "PXEClient";
option PXE.mtftp-ip 0.0.0.0;
vendor-option-space PXE;
}
}
So, what am I missing?
Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
