Hi!
I've found easy way to make ipfw(8) to become unkillable even witk kill -9.
It is displayed as running and takes all CPU cycles.
Just run the following script with argument 122 for 8.3/i386
or with 121 for 8.3/amd64.
#!/bin/sh
args=add 60001 count ip from any to {
for i in `jot $1 1`
do
On 30.04.2012 23:14, Adam Strohl wrote:
da0 at tws0 bus 0 scbus0 target 0 lun 0
da0: LSI 9750-8iDISK 5.12 Fixed Direct Access SCSI-5 device
da0: 6000.000MB/s transfers
da0: 2860992MB (5859311616 512 byte sectors: 255H 63S/T 364725C)
Let me know anyone wants to see anything else/has
Thanks Andrey,
I've just recompiled /boot/gptboot after updating gpt.c and installed it
via:
gpart bootcode -p /boot/gptboot -i 1 da0
I still see gptboot: invalid backup GPT header on boot (but it does
still boot).
On 5/2/2012 12:58, Andrey V. Elsukov wrote:
On 30.04.2012 23:14, Adam
On 2. May 2012, at 05:11 , Jason Hellenthal wrote:
On Tue, May 01, 2012 at 09:01:33PM +, Bjoern A. Zeeb wrote:
On 1. May 2012, at 19:41 , David Thiel wrote:
Hello,
So, I've been trying to debug an issue running nmap scans within jails,
partially documented here:
hi,lists
for some reasons I need restart system but it suddenly boot failed today.
here is the error:
ZFS: i/o error - all block copies unavailable
ZFS: can't read object set for dataset 16
Can't find root filesystem - giving up
ZFS:unexcepted object set type 0
ZFS:unexcepted object set type 0
On Wed, May 2, 2012 at 5:03 AM, Adam Strohl
adams-free...@ateamsystems.com wrote:
Thanks Andrey,
I've just recompiled /boot/gptboot after updating gpt.c and installed it
via:
gpart bootcode -p /boot/gptboot -i 1 da0
I still see gptboot: invalid backup GPT header on boot (but it does still
On 5/2/2012 20:46, Mark Saad wrote:
Did you try to repair the header ? I saw a similar issue on upgraded
boxes that were 7-STABLE upgraded to 9-STABLE. and recovering made the
warning go away . I may be way off here but just my 2 cents .
% gpart recover da0
Good thought, but no dice:
$
On 02.05.2012 17:53, Adam Strohl wrote:
% gpart recover da0
Good thought, but no dice:
$ gpart recover da0
da0 recovering is not needed
I already saw several reports about gptboot's complains on 3ware
controllers, but don't know what is the problem.
The only guess is that a controller
On Tue, May 01, 2012 at 09:01:09PM +, Bjoern A. Zeeb wrote:
So, I've been trying to debug an issue running nmap scans within jails,
partially documented here:
http://seclists.org/nmap-dev/2012/q2/220
On further debugging, it's seeming like jails can't read routing
information
24.04.2012 23:10, Andreas Longwitz ?:
There is one limitation I would like to get over. From man 8 setkey:
System that do not perform the port check cannot support multiple
endpoints behind the same NAT. I think this is a FreeBSD kernel restriction:
For the first incoming L2TP packet the
On 2. May 2012, at 18:50 , Zmiter wrote:
24.04.2012 23:10, Andreas Longwitz ?:
There is one limitation I would like to get over. From man 8 setkey:
System that do not perform the port check cannot support multiple
endpoints behind the same NAT. I think this is a FreeBSD kernel
11 matches
Mail list logo
