Re: Building a custom kernel in 4.1
Hello, Did you follow these steps? http://snad.ncsl.nist.gov/itg/nistswitch/install.html According to 1.1, support for versions of Freebsd 3.3 is 'in the works'. -mrh On Mon, 30 Oct 2000, Hao Zhang wrote: Hello, I am familiar with the procedure of building a custom kernel under FreeBSD3.3 but having a lot of difficulty when trying to follow the procedure for FreeBSD4.1. Can anyone summarize the exact steps to build a custom kernel under FreeBSD4.1(the documentation is a little confusing)? I am trying to build a custom kernel with a label module (from NIST) and the build fails while trying to link with some of the function pointers of that module. Below are the errors I get: * c -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmiss ing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -an si -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL -i nclude opt_global.h -elf -mpreferred-stack-boundary=2 config.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmis sing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -a nsi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL - include opt_global.h -elf -mpreferred-stack-boundary=2 setdef1.c touch hack.c cc -elf -shared -nostdlib hack.c -o hack.So rm -f hack.c sh /usr/src/sys/conf/newvers.sh MPLS cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmis sing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -a nsi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL - include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c linking MPLS if_ethersubr.o: In function `ether_demux': if_ethersubr.o(.text+0x666): undefined reference to `lt_find_by_label_ptr' if_ethersubr.o(.text+0x68c): undefined reference to `lt_find_by_label_ptr' if_ethersubr.o(.text+0x6fd): undefined reference to `lt_find_by_label_ptr' rtsock.o: In function `route_output': rtsock.o(.text+0x8c6): undefined reference to `lt_add_ptr' rtsock.o(.text+0x8d6): undefined reference to `lt_add_ptr' rtsock.o(.text+0x8e6): undefined reference to `lt_rm_ptr' rtsock.o(.text+0x8f6): undefined reference to `lt_rm_ptr' rtsock.o(.text+0x909): undefined reference to `PrintLabelTable_ptr' rtsock.o(.text+0x912): undefined reference to `PrintLabelTable_ptr' *** Error code 1 Stop in /usr/obj/usr/src/sys/MPLS. *** Error code 1 Stop in /usr/src. *** Error code 1 * Any quick help would be really appreciated. Syed Kamran Raza Nortel Networks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Installation Problems on Dell PowerEdge 6100/200
On Tue, 8 Aug 2000, Mike Smith wrote: If it is worth anything, I tried installing on a poweredge 2450 once and to make a long story short couldn't get the onboard RAID to work or the SMP to work. I hear it got sent back for something else (that wasn't a dell!) Onboard RAID will be working shortly (waiting for someome to lend me hardware), SMP works as of 4.1-RELEASE. I'm psyched. I just finished an order for a dual p3/866 2450 with 1GB RAM and 4x36GB (Perc 2/DC). Thanks to amr, the West Coast is getting another cvsup server (at least, that's my plan ;). -mrh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Driver for Adaptec/Dell/HP PCI:SCSI RAID adapters available
On Sun, 23 Jul 2000, Mike Smith wrote: These adapters are OEMed by Dell as the PERC 2/QC and by HP as the HP NetRAID-4m. FWIW, I've got a plethora of 2450's and 4350's at work... I think some have the PERC 3, but I'll check tomorrow... and grab any with the PERC 2 (or are the 2/3 models closely enough related to both be supported?). I'm definately up for some testing... Up to now, we've been using Linux on these with a Dell-provided, binary kernel module - ick (the PERC stuff isn't in Linux' standard RAID support)! Thanks for making my weekend. -mrh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
On Sat, 31 Jul 1999, Alex Zepeda wrote: The easiest way I can think of would be to add them to /etc/passwd and set their shell and home dir to /nonexistant. Ideally you wouldn't be running any other daemons, so there'd be no real way for them to access files; but the stock ftpd, as well as sshd offer ways to disable access to specific users. Dealing with "real" users IMO is quite a bit less hackish. I like the 'keeping it real' idea as well. Then again, doesn't 3.2R+ support SecureRPC? Isn't this the sort of thing NIS+ was invented for? A centralized db of users that you can then export to various machines with differing characteristics? I.e. couldn't you import the NIS db to your mail box(es) with /nonexistent home directory and /sbin/nologin shell? Name and password pairs would still exist, allowing any SMTP/POP3 daemons I know of to work without change. If NIS sends chills down your spine, I guess you could also do a bit of non-daemon-based hackage... make a script replace the home directory and shell fields with appropriate values in a copied passwd and rsync the thing to your mail boxes... Then again, SQL seems to be the current buzz... Having SQL-based access is cool/manageable (a friend generates the MySQL db from his Radius users file). As usual, there's more than one way to skin a cat. Later, --mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
On Sat, 31 Jul 1999, Alex Zepeda wrote: The easiest way I can think of would be to add them to /etc/passwd and set their shell and home dir to /nonexistant. Ideally you wouldn't be running any other daemons, so there'd be no real way for them to access files; but the stock ftpd, as well as sshd offer ways to disable access to specific users. Dealing with real users IMO is quite a bit less hackish. I like the 'keeping it real' idea as well. Then again, doesn't 3.2R+ support SecureRPC? Isn't this the sort of thing NIS+ was invented for? A centralized db of users that you can then export to various machines with differing characteristics? I.e. couldn't you import the NIS db to your mail box(es) with /nonexistent home directory and /sbin/nologin shell? Name and password pairs would still exist, allowing any SMTP/POP3 daemons I know of to work without change. If NIS sends chills down your spine, I guess you could also do a bit of non-daemon-based hackage... make a script replace the home directory and shell fields with appropriate values in a copied passwd and rsync the thing to your mail boxes... Then again, SQL seems to be the current buzz... Having SQL-based access is cool/manageable (a friend generates the MySQL db from his Radius users file). As usual, there's more than one way to skin a cat. Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Port install trouble
On Thu, 29 Jul 1999, Rod Ebrahimi wrote: # make install /usr/ports/Mk/bsd.port.subdir.mk, line 0: Cannot open /usr/ports/Mk/bsd.port.subdir.mk make: fatal errors encountered -- cannot continue How old is the ports collection? Is it complete? Have you tried re-sup'ing your collection? Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
On Mon, 26 Jul 1999, Sue Blake wrote: If nobody understands how this sandbox thing works, we should change the named.conf that we supply. If somebody does, then they or someone Understanding a sandbox only requires the ability to read on the part of the user (something anyone in charge of named administration has hopefully learned, else they don't need to be administrating anything). As for the current named.conf format... I agree that it should be changed. Rc.conf currently references the fact that 'it may be possible to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a sandbox'. Saying FreeBSD does something one place while saying it may be possible to do it in another is... silly. The actual use is up to the administrator, so it seems logical to have named.conf examples for sandbox and non-sandbox configs. Mike Hoskins [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
On Mon, 26 Jul 1999, Sue Blake wrote: If nobody understands how this sandbox thing works, we should change the named.conf that we supply. If somebody does, then they or someone Understanding a sandbox only requires the ability to read on the part of the user (something anyone in charge of named administration has hopefully learned, else they don't need to be administrating anything). As for the current named.conf format... I agree that it should be changed. Rc.conf currently references the fact that 'it may be possible to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a sandbox'. Saying FreeBSD does something one place while saying it may be possible to do it in another is... silly. The actual use is up to the administrator, so it seems logical to have named.conf examples for sandbox and non-sandbox configs. Mike Hoskins m...@adept.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Fri, 23 Jul 1999, Daniel C. Sobral wrote: Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. Alas, since Solaris doesn't overcommit... :-) This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. -- Mike Hoskins [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Fri, 23 Jul 1999, Daniel C. Sobral wrote: Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. Alas, since Solaris doesn't overcommit... :-) This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. -- Mike Hoskins m...@adept.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
