RE: PXE Boot FreeBSD with Etherboot
It seems there are some problems with using pxeboot in combination with the network boot code from the etherboot project. I have tried many combinations of options with no success. The result is very similar to the following photo I found: http://photos.night-shade.org.uk/photo.php?photo=6364 I have tried it both on my local machine and in vmware with the same result. It seems that somehow etherboot is not setting up the environment the way pxeboot expects it too. Now the native pxe boot code in vmware does load pxeboot correctly and I have successfully booted freebsd in vmware, however I can't get the pxe boot code on my network card to load at all, hence my need for etherboot. Also, both pxeboot from FreeBSD 4.11 and 6.0-BETA2 crash the same way. I'm assuming this is really a bug in etherboot, but I'm not sure how to get a crash dump to play with. With vmware, it seems like I should be able to save a memory image to examine, but I'm not sure how to do that. Any ideas on a fix for this? Just my experience. I never handled to successfully pxeboot FreeBSD. Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Converting libfoo.so for linux to freebsd
Hi Warner, Norikatsu-san, : Linuxpluginwrapper(LPW) is a most famous killer application : of libmap.conf(5)! (I think:-) Definitely. While threading games are interesting, the linux plugin wrapper definitely is much more useful. Why don't import this in base system and wrap it in a user friendly tool ? Some kind of advanced Linux compatibility. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PXE Boot FreeBSD with Etherboot
It seems there are some problems with using pxeboot in combination with the network boot code from the etherboot project. I have tried many combinations of options with no success. The result is very similar to the following photo I found: http://photos.night-shade.org.uk/photo.php?photo=6364 I have tried it both on my local machine and in vmware with the same result. It seems that somehow etherboot is not setting up the environment the way pxeboot expects it too. Now the native pxe boot code in vmware does load pxeboot correctly and I have successfully booted freebsd in vmware, however I can't get the pxe boot code on my network card to load at all, hence my need for etherboot. Also, both pxeboot from FreeBSD 4.11 and 6.0-BETA2 crash the same way. I'm assuming this is really a bug in etherboot, but I'm not sure how to get a crash dump to play with. With vmware, it seems like I should be able to save a memory image to examine, but I'm not sure how to do that. Any ideas on a fix for this? Just my experience. I never handled to successfully pxeboot FreeBSD. pxeboot works fine! i have some 50 hosts pxeboot'ing that say so. it's etherboot loading pxeboot that does not work. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: PXE Boot FreeBSD with Etherboot
It seems there are some problems with using pxeboot in combination with the network boot code from the etherboot project. I have tried many combinations of options with no success. The result is very similar to the following photo I found: http://photos.night-shade.org.uk/photo.php?photo=6364 I have tried it both on my local machine and in vmware with the same result. It seems that somehow etherboot is not setting up the environment the way pxeboot expects it too. Now the native pxe boot code in vmware does load pxeboot correctly and I have successfully booted freebsd in vmware, however I can't get the pxe boot code on my network card to load at all, hence my need for etherboot. Also, both pxeboot from FreeBSD 4.11 and 6.0-BETA2 crash the same way. I'm assuming this is really a bug in etherboot, but I'm not sure how to get a crash dump to play with. With vmware, it seems like I should be able to save a memory image to examine, but I'm not sure how to do that. Any ideas on a fix for this? Just my experience. I never handled to successfully pxeboot FreeBSD. pxeboot works fine! i have some 50 hosts pxeboot'ing that say so. it's etherboot loading pxeboot that does not work. I did not try etherboot. I tried a pc104 board with bios's internal pxe function for the integrated intel 82551/9er chip. And it is reported that e.g. linux boots successfully on these boards. I manage to boot from disk with etherboot (5.2.4), but not using pxe. Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Diskless on FreeBSD 5.4-stable
hi : Anyone install and configure successfully on FreeBSD 5.x ?! I referenced the handbook of FreeBSD :http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-diskless.html then my installation step as: 1. clone whole system via 'clone_root' script. ( /usr/share/examples/diskless/clone_root ) 2. install isc-dhcp3-server port , and configure the dhcpd.conf 3. setup TFTP service and NFS service both. 4. get etherboot Image file via following web site, and 'dd' this image to floppy disk. http://rom-o-matic.net/5.2.6/build.php?version=5.2.6F=arch=i386nic=via-rhine%3Adlink-530tx+--+%5B0x1106%2C0x3065%5Dofmt=Floppy+bootable+ROM+Image+%28.zdsk%29A=Configure ( since the remote machine's network card isn't Intel , is VIA-Rhine VT3043 . so it can't boot via PXE. ) 5. Finally, I booted the remote machine via this floppy . then I saw nothing in remote machine. why ?! Did I miss something else ?! if the network has another dhcp server , whether it will impact ?! BTW, I re-configure the etherboot image with ALTERNATE_DHCP_PORTS_1067_1068 option, it still can't work . Regards! Jumbler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PXE Boot FreeBSD with Etherboot
On Fri, Aug 12, 2005 at 10:26:28AM +0300, Danny Braniss wrote: It seems there are some problems with using pxeboot in combination with the network boot code from the etherboot project. I have tried many combinations of options with no success. The result is very similar to the following photo I found: http://photos.night-shade.org.uk/photo.php?photo=6364 I have tried it both on my local machine and in vmware with the same result. It seems that somehow etherboot is not setting up the environment the way pxeboot expects it too. Now the native pxe boot code in vmware does load pxeboot correctly and I have successfully booted freebsd in vmware, however I can't get the pxe boot code on my network card to load at all, hence my need for etherboot. Also, both pxeboot from FreeBSD 4.11 and 6.0-BETA2 crash the same way. I'm assuming this is really a bug in etherboot, but I'm not sure how to get a crash dump to play with. With vmware, it seems like I should be able to save a memory image to examine, but I'm not sure how to do that. Any ideas on a fix for this? Just my experience. I never handled to successfully pxeboot FreeBSD. pxeboot works fine! i have some 50 hosts pxeboot'ing that say so. it's etherboot loading pxeboot that does not work. I do believe that the bugs in etherboot, and it should be fixed, but there may also be a workaround that could be added to pxeboot to make it work until etherboot is fixed. Now etherboot loading pxelinux has always worked find. pxelinux then uses the pxe environment to load it's configuration environment, plus your choice of a tagged kernel so it should have what it takes to load freebsd, even if it's not compliant with the spec. If I could just find a way to get a dump of the environment of etherboot+pxeboot, either using vmware or my pc, I think that would be the best clue as to the problem in etherboot. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: CEE1 AAE2 F66C 59B5 34CA C415 6D35 E847 0118 A3D2 pgpZs0PMufxbf.pgp Description: PGP signature
Re: PXE Boot FreeBSD with Etherboot
--+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 12, 2005 at 10:26:28AM +0300, Danny Braniss wrote: It seems there are some problems with using pxeboot in combination wi= th the network boot code from the etherboot project. I have tried many combinations of options with no success. The result is very similar = to the following photo I found: =20 http://photos.night-shade.org.uk/photo.php?photo=3D6364 =20 I have tried it both on my local machine and in vmware with the same result. It seems that somehow etherboot is not setting up the environment the way pxeboot expects it too. Now the native pxe boot code in vmware does load pxeboot correctly and I have successfully booted freebsd in vmware, however I can't get the pxe boot code on my network card to load at all, hence my need for etherboot. Also, both pxeboot from FreeBSD 4.11 and 6.0-BETA2 crash the same way. I'm assuming this is really a bug in etherboot, but I'm not sure how to g= et a crash dump to play with. With vmware, it seems like I should be ab= le to save a memory image to examine, but I'm not sure how to do that. Any ideas on a fix for this? =20 Just my experience. I never handled to successfully pxeboot FreeBSD. =20 pxeboot works fine! i have some 50 hosts pxeboot'ing that say so. =20 it's etherboot loading pxeboot that does not work. I do believe that the bugs in etherboot, and it should be fixed, but there may also be a workaround that could be added to pxeboot to make it work until etherboot is fixed. Now etherboot loading pxelinux has always worked find. pxelinux then uses the pxe environment to load it's configuration environment, plus your choice of a tagged kernel so it should have what it takes to load freebsd, even if it's not compliant with the spec. If I could just find a way to get a dump of the environment of etherboot+pxeboot, either using vmware or my pc, I think that would be the best clue as to the problem in etherboot. in my case it was etherboot which i couldn't get to work (it is a National something or other on a PCengine) danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
some rc.d cleanup
I've bene working on making src/sbin/chkconfig from NetBSD a more complete clone of chkconfig from IRIX as well as making it work on FreeBSD. In this task I have run into some nasty bugs in the implementation of some rc.d scripts in FreeBSD. Some of these bugs are minor, some are not. cleanvar and cleartmp are the worst culprits. These scripts if executed with the argument rcvar (which should only return the configuration value for the script) execute rm on a bunch of files. This action should only happen when the switch start is passed. abi also writes text outside of its start functions, which can be messy. I have a patch for cleartmp (breaking the x11 part of it out into a seperate file that is run by default) and a half patch for abi at: http://alex.complete-systems.net/freebsd-rc.d.patch /etc/rc.d/power_profile is also an issue. It's not a real rc.d script and therefore should not be in /etc/rc.d. Thanks, Alex Please CC as I am off list. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
5.4 -- bridging, ipfw, dot1q
Note: I posted this to questions@ earlier, but upon further investigation of the issue, I realize that I basically need a hack. Warning, long. My original question: [begin] I'm setting up a bridging firewall where the packets are passing through on dot1q trunks. Figure sixty or so. Too many to create separate interfaces. The bridge works. Packet counts in the default match rule work (so I assume the bridge at least sees the packets). Problem is, any reasonable rules (such as those which actually say to block traffic by ip or port or anything) aren't working at all. Not even logging counts. Setting the bridged flag doesn't seem to help. My only guess is that ipfw doesn't have the brains to look beyond the VLAN tags. Is this the case? Is this supported under 4.x (I'm using 5, but can downgrade), or is there any way AT ALL that I can get this to work? As a note, snort and trafshow and everything else work fine analyzing the bridge traffic, it seems only the kernel has an issue. [end] Now my plea to hackers@: From what I can see, the packet type is mac, and that's the only rules that match. I'm not 100 percent sure if this is because of the point at which this is being received, or because of the dot1q headers. I have to assume it's the headers because, well, otherwise putting ipfw on a bridge would seem pretty silly to me. I basically need minor mods done to the kernel code so that dot1q trunked traffic seen through a bridge is seen by ipfw rules (and matched by the same)... I basically assume this doesn't work because of this post made by Ted Middelstadt a couple years ago http://groups-beta.google.com/group/mailing.freebsd.questions/browse_frm/thread/79d023785ddc58ed/4e280a013b6325d4?tvc=1q=vlan+trunk+ipfw+bridge+tedhl=en#4e280a013b6325d4 Of course, he says this: The biggest loss of NOT having an Ethernet-specific ipfw-like filtering program, is that there's no convenient vehicle to use for adding in code for filtering based on MAC addresses, which is certainly the domain of a bridge. And ipfw2 basically addresses this. This is what I see on my bridged packets with log: Aug 11 23:38:43 fwi kernel: ipfw: 360 Accept MAC in via em1 I've tried every possible combination of arguments to ipfw which seem to match. None are hitting: 00305 00 count ip from any to 56.199.242.178 layer2 mac-type 0x8100 00305 00 count ip from any to 56.199.242.178 mac-type 0x8100 00305 00 count ip from any to 56.199.242.178 mac-type 0x8100 00305 00 count ip from any to 56.199.242.178 mac-type 0x8100 via em1 00305 00 count ip from any to 56.199.242.82 mac-type 0x8100 via em1 00305 00 count ip from any to 56.199.242.82 layer2 mac-type 0x If this is possible with standard vanilla bridging and standard ipfw, please let me know, of course. I'm guessing dot1q encapsulated traffic just doesn't match this. I can match traffic with an any to any mac-type vlan or an any to any layer2 rule. But I think I can't match on more specific criteria (like an IP address) because the ipfw layer sees it as non-ip traffic, and doesn't even attempt to match it (even though I'm telling it specifically to do so), so it falls into the silently passed portion. I don't know c. And this is a bad time and place to learn. The kernel code is also fairly streamlined, and I *really* don't have the time to learn structures and the like. It's on my long-term to-do list, I swear. Otherwise, I'm relatively sure this is less than an hour's worth of work, please someone let me know what it's worth to you and I'll make it happen. (While I'lll be happy with a quick hack, this really is something that should probably at least have a sysctl or hooks in ipfw or something -- assuming anyone else finds it useful). Thanks, Dan Mahoney -- We need another cat. This one's retarded. -Cali, March 8, 2003 (3:43 AM) Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal public alpha release
Ivan Voras wrote: Hi! I'm announcing the first public version of the gjournal GEOM class :) The code is here: http://ivoras.sharanet.org/gjournal.tgz, together with a README file (reproduced below). I'd like to hear as many testing and bug reports as possible :) [..snip..] Bug report: /dev/md0 is a mdconfig'ed 3gb drive sitting atop an IDE disk. md1 is a mdconfiged mmap'ed disk for the journal. bash-2.05b# ./gjournal label testjournal /dev/md0 /dev/md1 **Number of arguments: 3 bash-2.05b# dmesg GEOM_JOURNAL[0]: Creating device testjournal (id=3733383246). GEOM_JOURNAL[0]: Device testjournal created (id=3733383246). GEOM_JOURNAL[0]: Worker thread for testjournal created GEOM_JOURNAL[0]: Adding disk md0 to testjournal. GEOM_JOURNAL[0]: Disk md0 attached to testjournal (data). GEOM_JOURNAL[0]: Adding disk md1 to testjournal. GEOM_JOURNAL[0]: Disk md1 attached to testjournal (journal). GEOM_JOURNAL[0]: Device testjournal activated. malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 KDB: stack backtrace: kdb_backtrace(1,b82ed800,c21d5b40,3e7,e4147be8) at kdb_backtrace+0x29 witness_warn(5,0,c0871275,c298d39c,b82ed800) at witness_warn+0x18e uma_zalloc_arg(c21d5b40,0,2,b7fd4a00,0) at uma_zalloc_arg+0x41 hl_find_interval(c5293000,b82ed800,0,200,c28ad978) at hl_find_interval+0xbd g_journal_journal_read(c21a9a0c,c28ad948,0,152e5,5790b0f0) at g_journal_journal_read+0x47 g_journal_worker(c28ad900,e4147d38,c28ad900,c2989258,0) at g_journal_worker+0x9b2 fork_exit(c2989258,c28ad900,e4147d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4147d6c, ebp = 0 --- malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 KDB: stack backtrace: kdb_backtrace(1,0,c21d5b40,1,e4147be8) at kdb_backtrace+0x29 witness_warn(5,0,c0871275,c298d39c,0) at witness_warn+0x18e uma_zalloc_arg(c21d5b40,0,2,0,0) at uma_zalloc_arg+0x41 hl_find_interval(c5293000,0,0,200,c28ad978) at hl_find_interval+0xbd g_journal_journal_read(c21a9a0c,c28ad948,0,152e5,5790b0f0) at g_journal_journal_read+0x47 g_journal_worker(c28ad900,e4147d38,c28ad900,c2989258,0) at g_journal_worker+0x9b2 fork_exit(c2989258,c28ad900,e4147d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4147d6c, ebp = 0 --- malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 KDB: stack backtrace: kdb_backtrace(1,200,c21d5b40,0,e4147be8) at kdb_backtrace+0x29 witness_warn(5,0,c0871275,c298d39c,200) at witness_warn+0x18e uma_zalloc_arg(c21d5b40,0,2,2f2600,0) at uma_zalloc_arg+0x41 hl_find_interval(c5293000,200,0,200,c28ad978) at hl_find_interval+0xbd g_journal_journal_read(c21a9a0c,c28ad948,0,152e5,5790b0f0) at g_journal_journal_read+0x47 g_journal_worker(c28ad900,e4147d38,c28ad900,c2989258,0) at g_journal_worker+0x9b2 fork_exit(c2989258,c28ad900,e4147d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4147d6c, ebp = 0 --- malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 KDB: stack backtrace: kdb_backtrace(1,0,c21d5b40,1,e4147be8) at kdb_backtrace+0x29 witness_warn(5,0,c0871275,c298d39c,0) at witness_warn+0x18e uma_zalloc_arg(c21d5b40,0,2,0,0) at uma_zalloc_arg+0x41 hl_find_interval(c5293000,0,0,200,c28ad978) at hl_find_interval+0xbd g_journal_journal_read(c21a9a0c,c28ad948,0,152e5,5790b0f0) at g_journal_journal_read+0x47 g_journal_worker(c28ad900,e4147d38,c28ad900,c2989258,0) at g_journal_worker+0x9b2 fork_exit(c2989258,c28ad900,e4147d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4147d6c, ebp = 0 --- malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 KDB: stack backtrace: kdb_backtrace(1,0,c21d5b40,1,e4147be8) at kdb_backtrace+0x29 witness_warn(5,0,c0871275,c298d39c,0) at witness_warn+0x18e uma_zalloc_arg(c21d5b40,0,2,0,0) at uma_zalloc_arg+0x41 hl_find_interval(c5293000,0,0,400,c28ad978) at hl_find_interval+0xbd g_journal_journal_read(c21a9a0c,c28ad948,0,152e5,5790b0f0) at g_journal_journal_read+0x47 g_journal_worker(c28ad900,e4147d38,c28ad900,c2989258,0) at g_journal_worker+0x9b2 fork_exit(c2989258,c28ad900,e4147d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4147d6c, ebp = 0 --- malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0
Re: gjournal public alpha release
Eric Anderson wrote: Ivan Voras wrote: Hi! I'm announcing the first public version of the gjournal GEOM class :) The code is here: http://ivoras.sharanet.org/gjournal.tgz, together with a README file (reproduced below). I'd like to hear as many testing and bug reports as possible :) [..snip..] Bug report: /dev/md0 is a mdconfig'ed 3gb drive sitting atop an IDE disk. md1 is a mdconfiged mmap'ed disk for the journal. bash-2.05b# ./gjournal label testjournal /dev/md0 /dev/md1 **Number of arguments: 3 bash-2.05b# dmesg GEOM_JOURNAL[0]: Creating device testjournal (id=3733383246). GEOM_JOURNAL[0]: Device testjournal created (id=3733383246). GEOM_JOURNAL[0]: Worker thread for testjournal created GEOM_JOURNAL[0]: Adding disk md0 to testjournal. GEOM_JOURNAL[0]: Disk md0 attached to testjournal (data). GEOM_JOURNAL[0]: Adding disk md1 to testjournal. GEOM_JOURNAL[0]: Disk md1 attached to testjournal (journal). GEOM_JOURNAL[0]: Device testjournal activated. malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 KDB: stack backtrace: kdb_backtrace(1,b82ed800,c21d5b40,3e7,e4147be8) at kdb_backtrace+0x29 witness_warn(5,0,c0871275,c298d39c,b82ed800) at witness_warn+0x18e uma_zalloc_arg(c21d5b40,0,2,b7fd4a00,0) at uma_zalloc_arg+0x41 hl_find_interval(c5293000,b82ed800,0,200,c28ad978) at hl_find_interval+0xbd g_journal_journal_read(c21a9a0c,c28ad948,0,152e5,5790b0f0) at g_journal_journal_read+0x47 g_journal_worker(c28ad900,e4147d38,c28ad900,c2989258,0) at g_journal_worker+0x9b2 fork_exit(c2989258,c28ad900,e4147d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4147d6c, ebp = 0 --- malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 KDB: stack backtrace: kdb_backtrace(1,0,c21d5b40,1,e4147be8) at kdb_backtrace+0x29 witness_warn(5,0,c0871275,c298d39c,0) at witness_warn+0x18e uma_zalloc_arg(c21d5b40,0,2,0,0) at uma_zalloc_arg+0x41 hl_find_interval(c5293000,0,0,200,c28ad978) at hl_find_interval+0xbd g_journal_journal_read(c21a9a0c,c28ad948,0,152e5,5790b0f0) at g_journal_journal_read+0x47 g_journal_worker(c28ad900,e4147d38,c28ad900,c2989258,0) at g_journal_worker+0x9b2 fork_exit(c2989258,c28ad900,e4147d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4147d6c, ebp = 0 --- malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 KDB: stack backtrace: kdb_backtrace(1,200,c21d5b40,0,e4147be8) at kdb_backtrace+0x29 witness_warn(5,0,c0871275,c298d39c,200) at witness_warn+0x18e uma_zalloc_arg(c21d5b40,0,2,2f2600,0) at uma_zalloc_arg+0x41 hl_find_interval(c5293000,200,0,200,c28ad978) at hl_find_interval+0xbd g_journal_journal_read(c21a9a0c,c28ad948,0,152e5,5790b0f0) at g_journal_journal_read+0x47 g_journal_worker(c28ad900,e4147d38,c28ad900,c2989258,0) at g_journal_worker+0x9b2 fork_exit(c2989258,c28ad900,e4147d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4147d6c, ebp = 0 --- malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 KDB: stack backtrace: kdb_backtrace(1,0,c21d5b40,1,e4147be8) at kdb_backtrace+0x29 witness_warn(5,0,c0871275,c298d39c,0) at witness_warn+0x18e uma_zalloc_arg(c21d5b40,0,2,0,0) at uma_zalloc_arg+0x41 hl_find_interval(c5293000,0,0,200,c28ad978) at hl_find_interval+0xbd g_journal_journal_read(c21a9a0c,c28ad948,0,152e5,5790b0f0) at g_journal_journal_read+0x47 g_journal_worker(c28ad900,e4147d38,c28ad900,c2989258,0) at g_journal_worker+0x9b2 fork_exit(c2989258,c28ad900,e4147d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4147d6c, ebp = 0 --- malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 KDB: stack backtrace: kdb_backtrace(1,0,c21d5b40,1,e4147be8) at kdb_backtrace+0x29 witness_warn(5,0,c0871275,c298d39c,0) at witness_warn+0x18e uma_zalloc_arg(c21d5b40,0,2,0,0) at uma_zalloc_arg+0x41 hl_find_interval(c5293000,0,0,400,c28ad978) at hl_find_interval+0xbd g_journal_journal_read(c21a9a0c,c28ad948,0,152e5,5790b0f0) at g_journal_journal_read+0x47 g_journal_worker(c28ad900,e4147d38,c28ad900,c2989258,0) at g_journal_worker+0x9b2 fork_exit(c2989258,c28ad900,e4147d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4147d6c, ebp = 0 --- malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex
Re: 5.4 -- bridging, ipfw, dot1q
I am afraid the existing code cannot help you. The packets you see are encapsulated in 802.1q aka VLAN frames, and since ipfw2 does not try to decapsulate the packets, you don't get to see the IP headers. Your most reasonable option would be to write a new ipufw2 opcode, say something like 'vlan-decap x-y', which succeeds if the packet has a vlan header in the range x to y, and in this case skips the VLAN header, tries to re-parse the header fields as in the beginning of ip_fw_chk() after the section /* * Collect parameters into local variables for faster matching. */ and then continues. It's not a lot of code, in the worst case you can just cutpaste the relevant 50-60 lines from the beginning of the code (though of course it would be nice to rearrange the code to reduce duplication). By doing this you can do something like ipfw add skipto 1000 vlan-decap 1-50 and then process vlans 1 to 50 at line 1000. Maybe it is a good idea to split the vlan-id matching and the decapsulation. cheers luigi On Fri, Aug 12, 2005 at 05:07:13AM -0400, Dan Mahoney, System Admin wrote: Note: I posted this to questions@ earlier, but upon further investigation of the issue, I realize that I basically need a hack. Warning, long. My original question: [begin] I'm setting up a bridging firewall where the packets are passing through on dot1q trunks. Figure sixty or so. Too many to create separate interfaces. The bridge works. Packet counts in the default match rule work (so I assume the bridge at least sees the packets). Problem is, any reasonable rules (such as those which actually say to block traffic by ip or port or anything) aren't working at all. Not even logging counts. Setting the bridged flag doesn't seem to help. My only guess is that ipfw doesn't have the brains to look beyond the VLAN tags. Is this the case? Is this supported under 4.x (I'm using 5, but can downgrade), or is there any way AT ALL that I can get this to work? As a note, snort and trafshow and everything else work fine analyzing the bridge traffic, it seems only the kernel has an issue. [end] Now my plea to hackers@: From what I can see, the packet type is mac, and that's the only rules that match. I'm not 100 percent sure if this is because of the point at which this is being received, or because of the dot1q headers. I have to assume it's the headers because, well, otherwise putting ipfw on a bridge would seem pretty silly to me. I basically need minor mods done to the kernel code so that dot1q trunked traffic seen through a bridge is seen by ipfw rules (and matched by the same)... I basically assume this doesn't work because of this post made by Ted Middelstadt a couple years ago http://groups-beta.google.com/group/mailing.freebsd.questions/browse_frm/thread/79d023785ddc58ed/4e280a013b6325d4?tvc=1q=vlan+trunk+ipfw+bridge+tedhl=en#4e280a013b6325d4 Of course, he says this: The biggest loss of NOT having an Ethernet-specific ipfw-like filtering program, is that there's no convenient vehicle to use for adding in code for filtering based on MAC addresses, which is certainly the domain of a bridge. And ipfw2 basically addresses this. This is what I see on my bridged packets with log: Aug 11 23:38:43 fwi kernel: ipfw: 360 Accept MAC in via em1 I've tried every possible combination of arguments to ipfw which seem to match. None are hitting: 00305 00 count ip from any to 56.199.242.178 layer2 mac-type 0x8100 00305 00 count ip from any to 56.199.242.178 mac-type 0x8100 00305 00 count ip from any to 56.199.242.178 mac-type 0x8100 00305 00 count ip from any to 56.199.242.178 mac-type 0x8100 via em1 00305 00 count ip from any to 56.199.242.82 mac-type 0x8100 via em1 00305 00 count ip from any to 56.199.242.82 layer2 mac-type 0x If this is possible with standard vanilla bridging and standard ipfw, please let me know, of course. I'm guessing dot1q encapsulated traffic just doesn't match this. I can match traffic with an any to any mac-type vlan or an any to any layer2 rule. But I think I can't match on more specific criteria (like an IP address) because the ipfw layer sees it as non-ip traffic, and doesn't even attempt to match it (even though I'm telling it specifically to do so), so it falls into the silently passed portion. I don't know c. And this is a bad time and place to learn. The kernel code is also fairly streamlined, and I *really* don't have the time to learn structures and the like. It's on my long-term to-do list, I swear. Otherwise, I'm relatively sure this is less than an hour's worth of work, please someone let me know what it's worth to you and I'll make it happen. (While I'lll be happy with a quick hack, this really
Re: some rc.d cleanup
On Thursday 11 August 2005 03:18 pm, Alexander Botero-Lowry wrote:
I've bene working on making src/sbin/chkconfig from NetBSD a more complete
clone of chkconfig from IRIX as well as making it work on FreeBSD. In this
task I have run into some nasty bugs in the implementation of some rc.d
scripts in FreeBSD. Some of these bugs are minor, some are not. cleanvar
and cleartmp are the worst culprits. These scripts if executed with the
argument rcvar (which should only return the configuration value for the
script) execute rm on a bunch of files. This action should only happen when
the switch start is passed. abi also writes text outside of its start
functions, which can be messy. I have a patch for cleartmp (breaking the
x11 part of it out into a seperate file that is run by default) and a half
patch for abi at: http://alex.complete-systems.net/freebsd-rc.d.patch
/etc/rc.d/power_profile is also an issue. It's not a real rc.d script and
therefore should not be in /etc/rc.d.
I'm guessing this part is extra:
+ if checkyesno ${rcvar}; then
+echo sysv
+ else
+echo you suck
+ fi
in the abi script? :)
Also, why not just move the extra rm commands in cleartmp up into the
cleartmp_start() function instead of creating a whole separate script? I
also don't understand why it matters that one use start_precmd instead of
using echo in the foo_start() functions.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PXE Boot FreeBSD with Etherboot
On Fri, Aug 12, 2005 at 10:30:05AM +0200, Norbert Koch wrote: It seems there are some problems with using pxeboot in combination with the network boot code from the etherboot project. I have tried many combinations of options with no success. The result is very similar to the following photo I found: http://photos.night-shade.org.uk/photo.php?photo=6364 I have tried it both on my local machine and in vmware with the same result. It seems that somehow etherboot is not setting up the environment the way pxeboot expects it too. Now the native pxe boot code in vmware does load pxeboot correctly and I have successfully booted freebsd in vmware, however I can't get the pxe boot code on my network card to load at all, hence my need for etherboot. Also, both pxeboot from FreeBSD 4.11 and 6.0-BETA2 crash the same way. I'm assuming this is really a bug in etherboot, but I'm not sure how to get a crash dump to play with. With vmware, it seems like I should be able to save a memory image to examine, but I'm not sure how to do that. Any ideas on a fix for this? Just my experience. I never handled to successfully pxeboot FreeBSD. pxeboot works fine! i have some 50 hosts pxeboot'ing that say so. it's etherboot loading pxeboot that does not work. I did not try etherboot. I tried a pc104 board with bios's internal pxe function for the integrated intel 82551/9er chip. And it is reported that e.g. linux boots successfully on these boards. I manage to boot from disk with etherboot (5.2.4), but not using pxe. Some versions of the intel PXE support are broken and don't support the necessicary features for FreeBSD's pxeboot. The happen to support other methods, but are deficients. Upgrading the firmware on the chip can fix this. I've done it with fxp(4) cards in the past. -- Brooks -- 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 pgpJ9llqfid5P.pgp Description: PGP signature
Re: Converting libfoo.so for linux to freebsd
In message: [EMAIL PROTECTED] Jeremie Le Hen [EMAIL PROTECTED] writes: : Hi Warner, Norikatsu-san, : : : Linuxpluginwrapper(LPW) is a most famous killer application : : of libmap.conf(5)! (I think:-) : : Definitely. While threading games are interesting, the linux plugin : wrapper definitely is much more useful. : : Why don't import this in base system and wrap it in a user friendly : tool ? Some kind of advanced Linux compatibility. The wrapper is specific for each library or plug-in that it wraps. It might be hard to generalize enough to warrant inclusion in the base... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PXE Boot FreeBSD with Etherboot
Norbert Koch wrote: Just my experience. I never handled to successfully pxeboot FreeBSD. I have been completely successful with 4.8, 4.11, 5.4 and 6.0 using dhcpd and tftp(from inetd) and NFS for exporting the filesystem (i.e. the default setup) I've done it on Intel and IBM motherboards, and others with Intel NIC cards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
perl's tie problem
Hi all, Consider the following except from a perl program: tie(%foodb, 'MLDBM', $BAR_FILE, O_CREAT | O_RDWR, 0666) or die(Cannot open $BAR_FILE: $!\n); I expect it to create a new $BAR_FILE, if none existed, with 0666 permissions. But it doesn't. It creates a file with default umask specified permissions - 0644. So I have to manually do chmod on that file afterwards. Is there anything I don't understand? %uname -a FreeBSD doom.homeunix.org 4.11-STABLE FreeBSD 4.11-STABLE #0: Tue Jul 5 21:05:20 MSD 2005 [...] i386 Perl version is 5.8.7 Thanks, -ip -- Ignorance should be painful. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: perl's tie problem
On Friday 12 August 2005 03:49 pm, Igor Pokrovsky wrote: Hi all, Consider the following except from a perl program: tie(%foodb, 'MLDBM', $BAR_FILE, O_CREAT | O_RDWR, 0666) or die(Cannot open $BAR_FILE: $!\n); I expect it to create a new $BAR_FILE, if none existed, with 0666 permissions. But it doesn't. It creates a file with default umask specified permissions - 0644. So I have to manually do chmod on that file afterwards. Is there anything I don't understand? %uname -a FreeBSD doom.homeunix.org 4.11-STABLE FreeBSD 4.11-STABLE #0: Tue Jul 5 21:05:20 MSD 2005 [...] i386 Perl version is 5.8.7 Thanks, -ip I think this is expected behavior. Your umask setting affects all calls to open(2) with O_CREAT to create a file, and from tie()'s arguments it seems that it uses open(2) to create the destination file. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: perl's tie problem
In article [EMAIL PROTECTED] you write: Hi all, Consider the following except from a perl program: tie(%foodb, 'MLDBM', $BAR_FILE, O_CREAT | O_RDWR, 0666) or die(Cannot open $BAR_FILE: $!\n); I expect it to create a new $BAR_FILE, if none existed, with 0666 permissions. But it doesn't. It creates a file with default umask specified permissions - 0644. So I have to manually do chmod on that file afterwards. Is there anything I don't understand? %uname -a FreeBSD doom.homeunix.org 4.11-STABLE FreeBSD 4.11-STABLE #0: Tue Jul 5 21:05:20 MSD 2005 [...] i386 umask applies after the open call's permissions, and is used to remove bits from the value passed in to the open. That's the way POSIX says it works, and that's how it works on UNIX machines. Down in the guts of the open() syscall, there's a line that effectively says file_permissions = passed_in_permissions ~umask; It's working as designed. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
File create permissions, what am I missing?
In a directory with -rwxrwxrwx, any user can create files, but who should be the owner/group of this file? Long time ago in Unix history, the owner would be the user who created the file, and the group would be the users's primary group. Later, IIRC, if the directory group was one of the user's secondary groups, the file would also be from this group. A later modification defined that a setgid directory would effect in all files created belonging to the directory's user. Am I correct? But I have already tested 3 system, 2 with 5-stable and 1 with 4-stable, in which the created file inside a -rwxrwxrwx directory is created belonging to the directory's group, WITHOUT the setgid bit. What did I miss? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4 -- bridging, ipfw, dot1q
Hi, I am afraid the existing code cannot help you. The packets you see are encapsulated in 802.1q aka VLAN frames, and since ipfw2 does not try to decapsulate the packets, you don't get to see the IP headers. Your most reasonable option would be to write a new ipufw2 opcode, say something like 'vlan-decap x-y', which succeeds if the packet has a vlan header in the range x to y, and in this case skips the VLAN header, tries to re-parse the header fields as in the beginning of ip_fw_chk() after the section /* * Collect parameters into local variables for faster matching. */ and then continues. It's not a lot of code, in the worst case you can just cutpaste the relevant 50-60 lines from the beginning of the code (though of course it would be nice to rearrange the code to reduce duplication). By doing this you can do something like ipfw add skipto 1000 vlan-decap 1-50 and then process vlans 1 to 50 at line 1000. Maybe it is a good idea to split the vlan-id matching and the decapsulation. Isn't it posible to cheat using vlan(4) interface ? I think it's possible to create them in order to use its code to zap the VLAN header and then use ipfw to filter on these vlan(4) interfaces. This isn't more than a workaround, but it might help. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using sysarch specific syscalls in assembly?
On Thu Aug 11 05, alexander wrote: Hmm...very odd. Should I file a bug report about this problem? Alright. I submitted a PR and got a suggestion on how to solve the problem by Bruce Evans. Could somebody (apart from me) try out his workaround and see if it works? Thx a bunch. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File create permissions, what am I missing?
On Fri, Aug 12, 2005 at 06:34:34PM -0300, João Carlos Mendes Luis wrote: In a directory with -rwxrwxrwx, any user can create files, but who should be the owner/group of this file? Long time ago in Unix history, the owner would be the user who created the file, and the group would be the users's primary group. Later, IIRC, if the directory group was one of the user's secondary groups, the file would also be from this group. A later modification defined that a setgid directory would effect in all files created belonging to the directory's user. Am I correct? But I have already tested 3 system, 2 with 5-stable and 1 with 4-stable, in which the created file inside a -rwxrwxrwx directory is created belonging to the directory's group, WITHOUT the setgid bit. What did I miss? On BSD systems, the group of a file is always the group of the directory it is in. This differs from SysV UNIX. The resident grey-beard at work feels this is a new and annoying behavior. (i.e. it wasn't always this way. :) -- Brooks -- 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 pgproAfYHOSvF.pgp Description: PGP signature
Re: 5.4 -- bridging, ipfw, dot1q
On Sat, Aug 13, 2005 at 12:49:56AM +0200, Jeremie Le Hen wrote: Hi, I am afraid the existing code cannot help you. The packets you see are encapsulated in 802.1q aka VLAN frames, and since ipfw2 does not try to decapsulate the packets, you don't get to see the IP headers. Your most reasonable option would be to write a new ipufw2 opcode, say something like 'vlan-decap x-y', which succeeds if the packet has a vlan header in the range x to y, and in this case skips the VLAN header, tries to re-parse the header fields as in the beginning of ip_fw_chk() after the section /* * Collect parameters into local variables for faster matching. */ and then continues. It's not a lot of code, in the worst case you can just cutpaste the relevant 50-60 lines from the beginning of the code (though of course it would be nice to rearrange the code to reduce duplication). By doing this you can do something like ipfw add skipto 1000 vlan-decap 1-50 and then process vlans 1 to 50 at line 1000. Maybe it is a good idea to split the vlan-id matching and the decapsulation. Isn't it posible to cheat using vlan(4) interface ? I think it's possible to create them in order to use its code to zap the VLAN header and then use ipfw to filter on these vlan(4) interfaces. This isn't more than a workaround, but it might help. well it would be painful to configure, because the number of vlans is (according to what Dan says) is large, and he would have to define N vlan interfaces on each of the physical ones, then define N bridges between the corresponding vlans (and i think there is a limit on how large N can be). Additionally demuxing incoming packets would take O(N) time. cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File create permissions, what am I missing?
In [EMAIL PROTECTED], Brooks Davis [EMAIL PROTECTED] typed: On Fri, Aug 12, 2005 at 06:34:34PM -0300, João Carlos Mendes Luis wrote: In a directory with -rwxrwxrwx, any user can create files, but who should be the owner/group of this file? Long time ago in Unix history, the owner would be the user who created the file, and the group would be the users's primary group. Later, IIRC, if the directory group was one of the user's secondary groups, the file would also be from this group. A later modification defined that a setgid directory would effect in all files created belonging to the directory's user. Am I correct? But I have already tested 3 system, 2 with 5-stable and 1 with 4-stable, in which the created file inside a -rwxrwxrwx directory is created belonging to the directory's group, WITHOUT the setgid bit. What did I miss? On BSD systems, the group of a file is always the group of the directory it is in. This differs from SysV UNIX. The resident grey-beard at work feels this is a new and annoying behavior. (i.e. it wasn't always this way. :) SysV lets you toggle that behavior on a per-directory basis. Turn the setgid bit on in the directory, and files created in it will be owned by the group that owns the directory. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal public alpha release
On Fri, 12 Aug 2005, Eric Anderson wrote: Bug report: GEOM_JOURNAL[0]: Device testjournal activated. malloc(M_WAITOK) of gjournal.hl, forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex gjournal:rmap r = 0 (0xc28ad978) locked @ g_journal.c:748 Not to mention once I have the /dev/journeled/testjournal mounted, I get a streaming spewage of those messages in /var/log/messages, which causes syslogd to crank to 99% CPU, and the performance to be horrible as you'd expect with no CPU to do anything. Thanks for testing it! I'll make an updated version soon. -- Every sufficiently advanced magic is indistinguishable from technology - Arthur C Anticlarke ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
