Re: Updated ATAPI/CAM patches
hi, there! On Thu, Feb 28, 2002 at 09:58:00PM +0100, Søren Schmidt wrote: Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did patches for this long ago, but noone picked it up as a port... what about cdrdao? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project -- What I have so far...
Let's take another example. The REQUIREMENT line in a script cannot be made conditional. It requires a modification of rcorder(8) to do so. So, if one of NetBSD's services has a requirement that we don't have, it automatically means we need two separate scripts with different REQUIREMENT lines regardless of whether the rest of the script is identical. BTW, from a quick glance at the rcorder(8) source, modifying it to eliminate this problem is not going to be a trivial task. [...] - I think on some things, the two projects may agree to disagree on, which means the majority of the code base will probably be 'identical', but there will be differences in things like, boot order, requirements, etc. What we should probably do is, have mostly identical infrastructure; after that, if the scripts differ mostly in requirements, boot orders etc, this is going to be very clear from any diff. If we have the NetBSD scripts committed and the we only change these variables, it's going to be very clear what we changed and why. Please also note that, after your work is done, I plan on trying to modify it based on Mac OS X startup scripts. I feel OS X is going to be a much bigger player than *BSD, so it would make sense for both us and NetBSD to converge on that standard. I think this change could easily be integrated into the NetBSD startup scripts. Bye, Andrea -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Too big egos?
I've been following the flame between John and Matt, and the one about P4 some days ago. Matt, you're an excellent coder, I've been following your work since the Amiga days with DICE. Same to you John, your work on SMPng is excellent. Do you guys want to know what the problem is? There's a TOTAL LACK of communication between you, and I don't mean only Matt and John, but most kernel developers. Why don't you try to solve the communication problem first? The problem is not P4, it's not who's patches are right, it's that nobody seems to know what the other is working on. Use this mail list, use irc, set up some regular meetings, but keep all the rest of the developers informed on what you do or are going to. God knows how many duplicate work and flame wars this can save. All this flaming can only hurt the project and gives a very bad impression to external viewers. Just my $0.02 Charles. __ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Max Khon wrote: On Thu, Feb 28, 2002 at 09:58:00PM +0100, S?ren Schmidt wrote: Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did patches for this long ago, but noone picked it up as a port... what about cdrdao? Since cdrdao uses the cdrecord backend (at least it did last time I looked), that should be an easy one... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current broken in lukemftpd
/flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:324: size of ar ray `remotehost' has non-integer type /flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:327: syntax err or before `transflag' /flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:327: warning: d ata definition has no type or storage class ls-unmain.c: In function `ls_main': ls-unmain.c:370: `revnamecmp' undeclared (first use in this function) ls-unmain.c:370: (Each undeclared identifier is reported only once ls-unmain.c:370: for each function it appears in.) ls-unmain.c:372: `revacccmp' undeclared (first use in this function) ls-unmain.c:374: `revstatcmp' undeclared (first use in this function) ls-unmain.c:376: `revmodcmp' undeclared (first use in this function) ls-unmain.c:379: `namecmp' undeclared (first use in this function) ls-unmain.c:381: `acccmp' undeclared (first use in this function) ls-unmain.c:383: `statcmp' undeclared (first use in this function) ls-unmain.c:385: `modcmp' undeclared (first use in this function) ls-unmain.c:390: `printscol' undeclared (first use in this function) ls-unmain.c:392: `printlong' undeclared (first use in this function) ls-unmain.c:394: `printcol' undeclared (first use in this function) ls-unmain.c: In function `mastercmp': ls-unmain.c:750: `namecmp' used prior to declaration *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
According to Thomas Quinot: is one known pending issue with this code: on *some* machines, patched kernels hang at boot time, immediately after registering Thomas knows it already but I'd to mention that one of these machines is a dual PIII/800 running 4.4-STABLE/SMP. I haven't tried the patch recently but will do soon. I wasn't able to give a backtrace as DDB is not reachable when the machine hangs. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current broken in lukemftpd
From: Poul-Henning Kamp [EMAIL PROTECTED] Date: Fri, 01 Mar 2002 15:07:48 +0100 /flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:324: size of ar ray `remotehost' has non-integer type /flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:327: syntax err or before `transflag' ... Confirmed. Looks as if setjmp.h (at least) was intended to have been #included (somehow), but wasn't. It's #included by contrib/lukemftpd/lukemftpd.h, but lukemftpd.h doesn't seem to be #included from anything in ls-unmain.c. Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
Matthew Dillon wrote: My patches have been tested, they work, and they ARE going to be committed as soon as I am able to do so. Tut, tut, looks like rain! -- Winnie the Pooh; A. A. Milne If you guys spent as much energy documenting your designs as you do bitching at each other, everyone would now have a clear idea of which side they should be on, or if there were even sides to begin with -- since the worst thing John has said about the patches is that they'd be a premature optimization that he expects to be needed later, but inappropriate now. There are already hacks in the trampoline/fork_exit and ast code that seriously pollutes the MD/MI boundry, all of which you've flicked off your shoulder and explained away as being allowed by your API, and Peter added a third hack with his pmap commit (which got backed-out when he backed out the commit). Peter's pmap code was good work, but he ran head on into an undocumented processor bug that FreeBSD had escaped earlier by serendipity. Remember the whole AMD/Intel/AGP discussion? You have so many balls in the air constructed in a fine mesh that you can't seem to accept a single change to your perfectly meshing subsystems, half of which are going stale in P4. This is greatly restricting your ability to consider deviation. Whether deviation is called for or not is still an open question, to my mind. However, you have a point about the uncommitted work. On the other hand, it was you who have been arguing so strenously that the size of the patches that need to go in in one go make them too dangerous. And John has a point about the uncommitted work, in that the SMP system doesn't make it to single user mode with the preemption patches. I think the right thing to do is to commit the cred changes, and stabilize them, if there's even a problem, as you expect from your comments about dangerous. I think the right thing to do on the cred front, *after* that, is to commit the patches -- John, if it won't boot to SMP afterward, you will have the eyes of everyone who uses SMP -current to help you discover why, and to correct the problems, which will happen *much faster* with a large number of eyes on it. I will repeat, if you want to discuss specific technical issues related to these commits after I put them in, I am all ears. I will repeat, I see nothing in this code that prevents you from accomplishing anything that you've brought up to date (which so far as just been the non-working preemption code you have sitting in P4). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
On Fri, 1 Mar 2002, Terry Lambert wrote: I think the right thing to do is to commit the cred changes, and stabilize them, if there's even a problem, as you expect from your comments about dangerous. John already committed a majority of all the cred changes. I never saw a commit message for it but the changes have appeared in the tree. My guess is that somethign went wrong with mail at that time if you didn't see the commit either.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usb product identified as ugen
On 28-Feb-2002 (19:33:04/GMT) Riccardo Torrini wrote: port 2 addr 2: full speed, power 400 mA, config 1, \ product 0x07d1(0x07d1), ScanLogic(0x04ce), rev 1.05 ugen0 [...] port 2 addr 2: full speed, self powered, config 1, \ USB to IDE(0x0002), USB to IDE(0x04ce), rev 2.60 umass0 Do you know why 'power 400 mA' changed to 'self powered' ? Is this important? External HD case has only USB cable... And why product changed from 0x07d1 to 0x0002? If I understand correctly those numbers are product ID and manufacturer, and the object attacched is the same from wed. Any other idea? In the meantime I make a new world :) ...FreeBSD 5.0-CURRENT #19: Fri Mar 1 03:57:49 CET 2002 Riccardo. PS: Next week I must return this device to my friend :( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more -current testers
On Wed, Feb 20, 2002 at 10:56:05AM +0200, Maxim Sobolev wrote: Michael Lucas wrote: I understand that we're getting to that stage where we need more -current testers. We all agree that the optimal thing would be to have hordes of very sophisticated users who can debug problems on their own and submit patches to fix all their issues. I would guess that we all also agree that that's not going to happen. It seems that the best we can hope for is to educate some of the braver users who are ready to take the next step and are willing to donate some time to us. I'm considering doing a series of articles on testing FreeBSD-current, including: setting up for kernel dumps, what to type at the debugger prompt after a crash, filing a decent bug report, what to expect from -current, and so on. I would also make it clear when to not bother filing a bug report (i.e., You crashed, but had no WITNESS? Sorry, enable WITNESS try again.). This would be (I suspect) three articles, running about a month and a half. The last time I checked, I get 12-15 thousand readers for each article. One half of one percent uptake would (hopefully) be quite a few bug reports. Has some kind of conclusion been arrived at on this ? It has gone quiet since Feb 20th, I am definitely interested. -- Regards Cliff Sarginson -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more -current testers
I have spent several months figuring how to do diskless mounts for test kernels, run debuggers from serial terminals and do remote kernel debugging with gdb, and spent lots and lots of time doing is as well. Some 'up to date' How To's are really needed to support this kind of debugging and testing efforts, the material in the FreeBSD manual is helpful to a point, but much 'key' information on such subjects is just not there and has to be dug out of mailing list archives and just sending e-mails to various people who have done such things in the past and ask for help, taking up their time...which could be saved with some up-to-date documentation :)) GG At 10:34 PM 3/1/2002 +0100, Cliff Sarginson wrote: On Wed, Feb 20, 2002 at 10:56:05AM +0200, Maxim Sobolev wrote: Michael Lucas wrote: I understand that we're getting to that stage where we need more -current testers. We all agree that the optimal thing would be to have hordes of very sophisticated users who can debug problems on their own and submit patches to fix all their issues. I would guess that we all also agree that that's not going to happen. It seems that the best we can hope for is to educate some of the braver users who are ready to take the next step and are willing to donate some time to us. I'm considering doing a series of articles on testing FreeBSD-current, including: setting up for kernel dumps, what to type at the debugger prompt after a crash, filing a decent bug report, what to expect from -current, and so on. I would also make it clear when to not bother filing a bug report (i.e., You crashed, but had no WITNESS? Sorry, enable WITNESS try again.). This would be (I suspect) three articles, running about a month and a half. The last time I checked, I get 12-15 thousand readers for each article. One half of one percent uptake would (hopefully) be quite a few bug reports. Has some kind of conclusion been arrived at on this ? It has gone quiet since Feb 20th, I am definitely interested. -- Regards Cliff Sarginson -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: changes to rc.diskless*
On Thu, Feb 21, 2002 at 08:00:51PM -0800, David O'Brien wrote:
The use of an MFS /var should also be settable Otherwise installing
ports(packages) is just a total PITA
Below is a patch I'd like to commit that may solve this problem in
most cases This patch does the following:
- Makes creation of MFS /tmp and /var dependent on them being read-only
It might be useful to make this configurable in rcconf, but I'm
having a hard time coming up with a reasionable configuration this
test will break
- Add pre and post hooks to the file in the spirit of the ones in
/sbin/dhclient-script I'm using the pre hook to automaticly decide
if the local disk on my machines has the right layout and using
Warner's diskprep script to rebuild it if needed
Any comments, suggestions, objections? I'd like to commit in a couple
days
-- Brooks
Index: rcdiskless2
===
RCS file: /usr/cvs/src/etc/rcdiskless2,v
retrieving revision 117
diff -u -r117 rcdiskless2
--- rcdiskless223 Feb 2002 01:49:20 - 117
+++ rcdiskless21 Mar 2002 21:53:54 -
-55,8 +55,20
/etc/rcconf
fi
-echo +++ mount_md of /var
-mount_md ${varsize:=32m} /var 1
+# Invoke an optional pre mount script
+if [ -r /etc/rcdiskless2_pre ]; then
+/etc/rcdiskless2_pre
+fi
+
+mount -a # chown, chgrp, and touch are in /usr
+
+# Create /var as a memory file system if needed
+if /usr/bin/touch /var/_writable_test; then
+ rm /var/_writable_test
+else
+ echo +++ mount_md of /var
+ mount_md ${varsize:=32m} /var 1
+fi
echo +++ populate /var using /etc/mtree/BSDvardist
/usr/sbin/mtree -deU -f /etc/mtree/BSDvardist -p /var
-70,8 +82,6
echo +++ create lastlog
/usr/bin/touch /var/log/lastlog
-mount -a # chown and chgrp are in /usr
-
# Since we are starting with a very fresh /etc on an MFS:
if [ -d /conf/default/etc ]; then
newaliases
-81,13 +91,14
# XXX make sure to create one dir for each printer as requested by lpd
#
-# If /tmp is a symlink, assume it points to somewhere writable, like
-# /var/tmp, otherwise, use a small memory filesystem for /tmp
+# If /tmp is not writable, use a small memory filesystem for /tmp
#
# XXX: mtree runs too early to create any directories needed in /tmp,
# so if /var/tmp == /tmp, then you don't get a virecover
#
-if [ ! -h /tmp ]; then
+if /usr/bin/touch /tmp/_writable_test; then
+ rm /tmp/_writable_test
+else
mount_md ${tmpsize:=64m} /tmp 2
chmod 01777 /tmp
fi
-100,4 +111,9
(cd /; find -x dev | cpio -o -H newc) /tmp/devtmp
mount_md 4096 /dev 3 512
(cd /; cpio -i -H newc -d /tmp/devtmp)
+fi
+
+# Invoke an optional post mount script
+if [ -r /etc/rcdiskless2_post ]; then
+/etc/rcdiskless2_post
fi
--
Any statement of the form X is the one, true Y is FALSE
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
msg35567/pgp0.pgp
Description: PGP signature
Re: more -current testers
On Fri, 1 Mar 2002, Glenn Gombert wrote: I have spent several months figuring how to do diskless mounts for test kernels, run debuggers from serial terminals and do remote kernel debugging with gdb, and spent lots and lots of time doing is as well. Some 'up to date' How To's are really needed to support this kind of debugging and testing efforts, the material in the FreeBSD manual is helpful to a point, but much 'key' information on such subjects is just not there and has to be dug out of mailing list archives and just sending e-mails to various people who have done such things in the past and ask for help, taking up their time...which could be saved with some up-to-date documentation :)) So you are the PERFECT person to write it right? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more -current testers
There is a 'diskless' manual page, /usr/src/share/man/man8/diskless.8. It is somewhat out of date and it would be nice if it had a dhcpd.conf example. It would be great if someone did a major rewrite of it. -Matt Matthew Dillon [EMAIL PROTECTED] :On Fri, 1 Mar 2002, Glenn Gombert wrote: : :I have spent several months figuring how to do diskless mounts for : test kernels, run debuggers from serial terminals and do remote kernel : debugging with gdb, and spent lots and lots of time doing is as well. : Some 'up to date' How To's are really needed to support this kind of : debugging and testing efforts, the material in the FreeBSD manual is : helpful to a point, but much 'key' information on such subjects is just : not there and has to be dug out of mailing list archives and just : sending e-mails to various people who have done such things in the past : and ask for help, taking up their time...which could be saved with some : up-to-date documentation :)) : :If you want to start writing that stuff up for inclusion in the FreeBSD :Handbook or some related location, I'd be happy to review it for content, :since I use what sounds like a very similar development environment. : :In my environment, I have a central build and file server, and then a :series of network booted crash machines. The central server has two :ethernet cards, one going to the outside world for some definition of :outside, and the other a dedicated development network. The server runs a :DHCP server for the development network, a TFTP server to server copies of :pxeboot(8) for the development network, and NFS exports of a /usr/netboot :tree where I store the diskless roots, kernels, et al for the crash boxes. :Typically, I'll use : : /usr/netboot/crash1.decoverly.watson.org : /usr/netboot/crash2.decoverly.watson.org : :as the roots for each environment, point tftpd(8) at /usr/netboot as its :root, and appropriately configure the DHCP server to point each host at :the right root directory to pull down pxeboot, and for its later NFS root. :I also hook up serial consoles for each box; currently working on remote :power. : :Depending on what I'm working on, I may use the crash boxes in different :ways. Frequently, I'll boot them entirely from the network, with a :complete installkernel and installworld into their roots under :/usr/netboot. However, if I'm doing filesystem related work, I may do :more disk-centric installation mechanisms. I haven't tried the modified :install floppy trick. : :Some cute tricks.. : :newfs is faster than fsck. If you need to use local filesystems on the :box, and don't care about persistent data, it's a lot faster to newfs the :file systems than do the file system check :-). If that's true for even :one file system, it's an improvement. Sometimes I wonder if that wouldn't :be a good change for all installs :-). : :Some boxes appear to have broken serial break support. There's a kernel :option for an alternative break key that can be quite useful. I have this :problem with two SGI boxes I'm using for various TrustedBSD-related :things. : :I can configure the hard disks as dump devices, and by swapping back and :forth between kernels, I can pull the dump over to the development server. :It may be you can dump over the network, but perhaps not :-). : :It's possible to replace the kernel out from under a machine while still :crashing/dumping/rebooting. This can dramatically reduce the :develop/compile/install/test/crash/repeat cycle by coallescing the test :and crash bits with the other bits, since you can compile while still :testing or crashing. : :If you have multiple machines, you can easily allocate them to various :projects, etc, etc. I have a couple of scripts that help populate a :system the first time, by chrooting and running cap_mkdb, pwd_mkdb, etc, :etc. I generally also tweak the rc.diskless[12] scripts a bit based on :what I need. I also tend to enable remote root login and empty passwords :for the crash box in sshd_config so that I can login into the machines :once they come up very easily. : :Occasional PXE bugs can be very frustrating. Some machines I've used have :no problem loading pxeboot from a different machine than the DHCP server. :A couple of others ignore the server specification in the DHCP response :and insist on trying to tftp pxeboot from the DHCP server. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :[EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more -current testers
I would be happy to help with this, I will revise a section at a time in Developers Handbook on Kernel Debugging and then post it for review. I hope it helps others (and can save some precious time of other busy folks as well), I will try and have a section done by the end of next week :) At 06:58 PM 3/1/2002 -0500, Robert Watson wrote: On Fri, 1 Mar 2002, Glenn Gombert wrote: I have spent several months figuring how to do diskless mounts for test kernels, run debuggers from serial terminals and do remote kernel debugging with gdb, and spent lots and lots of time doing is as well. Some 'up to date' How To's are really needed to support this kind of debugging and testing efforts, the material in the FreeBSD manual is helpful to a point, but much 'key' information on such subjects is just not there and has to be dug out of mailing list archives and just sending e-mails to various people who have done such things in the past and ask for help, taking up their time...which could be saved with some up-to-date documentation :)) If you want to start writing that stuff up for inclusion in the FreeBSD Handbook or some related location, I'd be happy to review it for content, since I use what sounds like a very similar development environment. In my environment, I have a central build and file server, and then a series of network booted crash machines. The central server has two ethernet cards, one going to the outside world for some definition of outside, and the other a dedicated development network. The server runs a DHCP server for the development network, a TFTP server to server copies of pxeboot(8) for the development network, and NFS exports of a /usr/netboot tree where I store the diskless roots, kernels, et al for the crash boxes. Typically, I'll use /usr/netboot/crash1.decoverly.watson.org /usr/netboot/crash2.decoverly.watson.org as the roots for each environment, point tftpd(8) at /usr/netboot as its root, and appropriately configure the DHCP server to point each host at the right root directory to pull down pxeboot, and for its later NFS root. I also hook up serial consoles for each box; currently working on remote power. Depending on what I'm working on, I may use the crash boxes in different ways. Frequently, I'll boot them entirely from the network, with a complete installkernel and installworld into their roots under /usr/netboot. However, if I'm doing filesystem related work, I may do more disk-centric installation mechanisms. I haven't tried the modified install floppy trick. Some cute tricks.. newfs is faster than fsck. If you need to use local filesystems on the box, and don't care about persistent data, it's a lot faster to newfs the file systems than do the file system check :-). If that's true for even one file system, it's an improvement. Sometimes I wonder if that wouldn't be a good change for all installs :-). Some boxes appear to have broken serial break support. There's a kernel option for an alternative break key that can be quite useful. I have this problem with two SGI boxes I'm using for various TrustedBSD-related things. I can configure the hard disks as dump devices, and by swapping back and forth between kernels, I can pull the dump over to the development server. It may be you can dump over the network, but perhaps not :-). It's possible to replace the kernel out from under a machine while still crashing/dumping/rebooting. This can dramatically reduce the develop/compile/install/test/crash/repeat cycle by coallescing the test and crash bits with the other bits, since you can compile while still testing or crashing. If you have multiple machines, you can easily allocate them to various projects, etc, etc. I have a couple of scripts that help populate a system the first time, by chrooting and running cap_mkdb, pwd_mkdb, etc, etc. I generally also tweak the rc.diskless[12] scripts a bit based on what I need. I also tend to enable remote root login and empty passwords for the crash box in sshd_config so that I can login into the machines once they come up very easily. Occasional PXE bugs can be very frustrating. Some machines I've used have no problem loading pxeboot from a different machine than the DHCP server. A couple of others ignore the server specification in the DHCP response and insist on trying to tftp pxeboot from the DHCP server. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more -current testers
I would be happy to try and revise it as well, I think that many people would find booting diskless kernels (for debugging development purposes) quite useful as well :) At 04:08 PM 3/1/2002 -0800, you wrote: There is a 'diskless' manual page, /usr/src/share/man/man8/diskless.8. It is somewhat out of date and it would be nice if it had a dhcpd.conf example. It would be great if someone did a major rewrite of it. -Matt Matthew Dillon [EMAIL PROTECTED] :On Fri, 1 Mar 2002, Glenn Gombert wrote: : :I have spent several months figuring how to do diskless mounts for : test kernels, run debuggers from serial terminals and do remote kernel : debugging with gdb, and spent lots and lots of time doing is as well. : Some 'up to date' How To's are really needed to support this kind of : debugging and testing efforts, the material in the FreeBSD manual is : helpful to a point, but much 'key' information on such subjects is just : not there and has to be dug out of mailing list archives and just : sending e-mails to various people who have done such things in the past : and ask for help, taking up their time...which could be saved with some : up-to-date documentation :)) : :If you want to start writing that stuff up for inclusion in the FreeBSD :Handbook or some related location, I'd be happy to review it for content, :since I use what sounds like a very similar development environment. : :In my environment, I have a central build and file server, and then a :series of network booted crash machines. The central server has two :ethernet cards, one going to the outside world for some definition of :outside, and the other a dedicated development network. The server runs a :DHCP server for the development network, a TFTP server to server copies of :pxeboot(8) for the development network, and NFS exports of a /usr/netboot :tree where I store the diskless roots, kernels, et al for the crash boxes. :Typically, I'll use : : /usr/netboot/crash1.decoverly.watson.org : /usr/netboot/crash2.decoverly.watson.org : :as the roots for each environment, point tftpd(8) at /usr/netboot as its :root, and appropriately configure the DHCP server to point each host at :the right root directory to pull down pxeboot, and for its later NFS root. :I also hook up serial consoles for each box; currently working on remote :power. : :Depending on what I'm working on, I may use the crash boxes in different :ways. Frequently, I'll boot them entirely from the network, with a :complete installkernel and installworld into their roots under :/usr/netboot. However, if I'm doing filesystem related work, I may do :more disk-centric installation mechanisms. I haven't tried the modified :install floppy trick. : :Some cute tricks.. : :newfs is faster than fsck. If you need to use local filesystems on the :box, and don't care about persistent data, it's a lot faster to newfs the :file systems than do the file system check :-). If that's true for even :one file system, it's an improvement. Sometimes I wonder if that wouldn't :be a good change for all installs :-). : :Some boxes appear to have broken serial break support. There's a kernel :option for an alternative break key that can be quite useful. I have this :problem with two SGI boxes I'm using for various TrustedBSD-related :things. : :I can configure the hard disks as dump devices, and by swapping back and :forth between kernels, I can pull the dump over to the development server. :It may be you can dump over the network, but perhaps not :-). : :It's possible to replace the kernel out from under a machine while still :crashing/dumping/rebooting. This can dramatically reduce the :develop/compile/install/test/crash/repeat cycle by coallescing the test :and crash bits with the other bits, since you can compile while still :testing or crashing. : :If you have multiple machines, you can easily allocate them to various :projects, etc, etc. I have a couple of scripts that help populate a :system the first time, by chrooting and running cap_mkdb, pwd_mkdb, etc, :etc. I generally also tweak the rc.diskless[12] scripts a bit based on :what I need. I also tend to enable remote root login and empty passwords :for the crash box in sshd_config so that I can login into the machines :once they come up very easily. : :Occasional PXE bugs can be very frustrating. Some machines I've used have :no problem loading pxeboot from a different machine than the DHCP server. :A couple of others ignore the server specification in the DHCP response :and insist on trying to tftp pxeboot from the DHCP server. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :[EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Glenn Gombert [EMAIL PROTECTED] To
