Re: Two problems still present in RC3

2011-12-11 Thread Johan Hendriks

Jeremy Chadwick schreef:

On Fri, Dec 09, 2011 at 10:30:43AM -0700, Brett Glass wrote:

At 03:10 AM 12/9/2011, Johan Hendriks wrote:


After a /etc/netstart, i get the following:
ifconfig: create: bad value.

I get the "create: bad value" messages as well. What's more, if I
change rc.conf to assign variables of the form ifconfig_*, such as

ifconfig_re0_1="inet 192.168.0.1"
ifconfig_re0_1_alias0="inet 192.168.0.2"
...

instead of using an ip_addrs_* variable, I still get those messages.

I have confirmed that if I run /etc/netstart after booting, I lose
connectivity just as you do.

I recognize the challenge of specifying the network configuration in
a declaratory rather than a procedural environment, because there
are so many contingencies and possible combinations of parameters.
But there doesn't seem to be any combination of variables I can
assign in rc.conf that doesn't cause errors when I try to create
VLANs.

I would advise everyone experiencing ""those messages"" or any anomalies
of this sort to please set rc_debug="yes" in /etc/rc.conf and make sure
they have serial or firewire console set up.  If you don't have some
form of remote console, then this is going to be difficult to debug.
See rc.conf(5) for what the option does and therefore why serial console
will be needed.

The information that's needed is what ifconfig commands are being issued
on your systems.  This cannot be easily determined from rc.conf variables
like ifconfig_snakes_in_the_grass="rocks moss", hence the above request.

"Your" means Brett Glass and Johan Hendriks.

Finally, please keep in mind the possibility that both of you are
experiencing different problems.  I have no evidence at this point to
support or refute that claim, but it's something that needs to be
considered.

Ok did some test on the backup machine, i must do it remotely, so no 
serial access.


Lagg0 consist of two interfaces em0 and em1.
The machine booted with the following in /etc/rc.conf, and all is fine 
this way.


ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 192.168.100.1/24"


I changed the ip adress from 192.168.100.1 to 192.168.100.2 in 
/etc/rc.conf, and added rc_debug="yes"

ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 192.168.100.2/24"

I did a /etc/netstart
nas01-bw ~ # /etc/netstart
/etc/rc.d/devd: DEBUG: checkyesno: devd_enable is set to YES.
devd already running? (pid=1767).
/etc/rc.d/hostid: DEBUG: checkyesno: hostid_enable is set to YES.
/etc/rc.d/hostid: DEBUG: run_rc_command: doit: hostid_start
/etc/rc.d/hostid: DEBUG: checkyesno: rc_startmsgs is set to YES.
Setting hostuuid: 9abf4e13-9a77-b31d-9a77-b31d9fbfee13.
/etc/rc.d/hostid: DEBUG: checkyesno: rc_startmsgs is set to YES.
Setting hostid: 0xf505f6a8.
/etc/rc.d/hostname: DEBUG: run_rc_command: doit: hostname_start
/etc/rc.d/ipmon: DEBUG: checkyesno: ipmon_enable is set to NO.
/etc/rc.d/ipfilter: DEBUG: checkyesno: ipfilter_enable is set to NO.
/etc/rc.d/ipnat: DEBUG: checkyesno: ipnat_enable is set to NO.
/etc/rc.d/ipfs: DEBUG: checkyesno: ipfs_enable is set to NO.
/etc/rc.d/sppp: DEBUG: run_rc_command: doit: sppp_start
/etc/rc.d/netif: DEBUG: run_rc_command: doit: network_start
ifconfig: create: bad value
/etc/rc.d/netif: DEBUG: Cloned:
/etc/rc.d/netif: DEBUG: checkyesno: ipv6_activate_all_interfaces is set 
to NO.
/etc/rc.d/netif: DEBUG: checkyesno: ipv6_activate_all_interfaces is set 
to NO.
/etc/rc.d/netif: DEBUG: checkyesno: ipv6_activate_all_interfaces is set 
to NO.
/etc/rc.d/netif: DEBUG: checkyesno: ipv6_activate_all_interfaces is set 
to NO.
/etc/rc.d/netif: DEBUG: checkyesno: ipv6_activate_all_interfaces is set 
to NO.
/etc/rc.d/netif: DEBUG: checkyesno: ipv6_activate_all_interfaces is set 
to NO.

ifconfig: SIOCSLAGGPORT: Device busy
/etc/rc.d/netif: DEBUG: checkyesno: ipv6_activate_all_interfaces is set 
to NO.

Starting Network: lo0 em0 em1 bge0 pflog0 pfsync0 lagg0.
/etc/rc.d/netif: DEBUG: checkyesno: rc_startmsgs is set to YES.
lo0: flags=8049 metric 0 mtu 16384
options=3
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0xe
inet 127.0.0.1 netmask 0xff00
nd6 options=21
em0: flags=8843 metric 0 mtu 1500

options=219b

ether 00:1b:21:d4:77:fb
inet6 fe80::21b:21ff:fed4:77fb%em0 prefixlen 64 scopeid 0x5
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
em1: flags=8843 metric 0 mtu 1500

options=219b

ether 00:1b:21:d4:77:fb
inet6 fe80::21b:21ff:fed4:749b%em1 prefixlen 64 scopeid 0x6
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active
bge0: flags=8843 metric 0 mtu 1500

options=c01db

ether 00:23:7d:f4:4a:55
inet6 fe80::223:7dff:fef4:4a55%bge0 prefixlen 64 scopeid 0x7
inet 192.168.1.17 netmask 0xff00 broadcas

Re: Two problems still present in RC3

2011-12-11 Thread Ben Kaduk
On Fri, Dec 9, 2011 at 4:13 AM, Brett Glass  wrote:
> Secondly, there's still some strangeness in the sc terminal emulation. When
> I run jove, the status line at the bottom of the screen isn't entirely in
> reverse video as it should be. Only parts of it are, and the highlighting
> changes -- seemingly at random -- as I work.

Did you take the change to /etc/ttys going from cons25 to xterm 'type'?

-Ben Kaduk
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


stable/9 preferring IPv4 over IPv6, what changed?

2011-12-11 Thread Ulrich Spörlein
Hello

long story short: telnet foo on stable/8 will first try connecting via
IPv6, then via IPv4 (foo has A and  records). On stable/9 it's the
other way round.

This trips up my setup, where a bunch of hosts (some behind NAT) can all
talk to each other over their IPv6 addresses (some are tunneled), but
cannot do so via IPv4.

Is this due to changes in bind or the resolver?

Cheers,
Uli
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: stable/9 preferring IPv4 over IPv6, what changed?

2011-12-11 Thread Dimitry Andric
On 2011-12-11 23:33, Ulrich Spörlein wrote:
> long story short: telnet foo on stable/8 will first try connecting via
> IPv6, then via IPv4 (foo has A and  records). On stable/9 it's the
> other way round.
> 
> This trips up my setup, where a bunch of hosts (some behind NAT) can all
> talk to each other over their IPv6 addresses (some are tunneled), but
> cannot do so via IPv4.
> 
> Is this due to changes in bind or the resolver?

Most likely due to changes in the IPv6 startup scripts and rc.conf
settings.  The behaviour seems to be determined by multiple settings in
rc.conf, first of all:

  ip6addrctl_policy={ipv4_prefer|ipv6_prefer|AUTO}

where the default value is AUTO.  Values of ipv4_prefer and ipv6_prefer
do what you expect them to.

In case of AUTO, and if you don't have /etc/ip6addrctl.conf with
explicit settings, /etc/rc.d/ip6addrctl checks the value of
ipv6_activate_all_interfaces.  If it is YES, IPv6 is preferred, if it is
NO or unset, IPv4 is preferred.

What are your IPv6-related settings in rc.conf?

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: stable/9 preferring IPv4 over IPv6, what changed?

2011-12-11 Thread Detlef Peeters

Am 11.12.2011 23:33, schrieb Ulrich Spörlein:

long story short: telnet foo on stable/8 will first try connecting 
via
IPv6, then via IPv4 (foo has A and  records). On stable/9 it's 
the

other way round.

This trips up my setup, where a bunch of hosts (some behind NAT) can 
all

talk to each other over their IPv6 addresses (some are tunneled), but
cannot do so via IPv4.

Is this due to changes in bind or the resolver?


You can change this via ip6addrctl_policy="ipv6_prefer" in /etc/rc.conf

regards,

Detlef
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: mfi(4) issues in 9.0-RC3

2011-12-11 Thread Jan Mikkelsen
On 10/12/2011, at 3:03 AM, John Baldwin wrote:

> On Friday, December 09, 2011 8:38:51 am Jan Mikkelsen wrote:
>> Hi,
>> 
>> Can rev 227562 be merged into 9.0?
>> [...]
> 
> It is probably too late to make 9.0 at this point as they've already cut the 
> final release candidate.

OK; I'll maintain the patch myself until it gets merged.

The MegaRAID 9261-8i requires hw.mfi.msi=1 to be set by hand for a boot to 
successfully complete. It it worth adding a check for that device?

Thanks,

Jan.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Two problems still present in RC3

2011-12-11 Thread Brett Glass
At 11:36 AM 12/11/2011, Ben Kaduk wrote:
 
>Did you take the change to /etc/ttys going from cons25 to xterm 'type'?

I didn't have to change it; it was that way when the OS was installed.

Problem seems to be that the behavior (specifically, reverse video on the
25th line) doesn't quite match the xterm termcap entry.

--Brett

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"