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 St
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
F
On Wed, May 2, 2012 at 5:03 AM, Adam Strohl
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
> boot).
>
>
> On 5/2
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:
$ gp
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 control
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
>
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 IPSE
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 rest
