Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0
On 09/08/2016 03:23, Jeffrey Bouquet wrote:
> Will/could there be some kind of UPDATING announcement re which files
> explicitly to switch out/remove/replace/checkfor etc the deprecated
> lines and precisely the steps to replace with new or some other
> suitable action? Action required for both the sshd and client?
> Subdirectories involved? etc... Unclear here, but I don't use SSH
> hardly yet... despite having bought the book.
As far as managing sshd on your own systems, you should not need to make
massive changes to the /etc/ssh/sshd_config when upgrading to 11.0 or
12.0 -- the normal mergemaster or etcmerge procedures will probably
cover things. On an upgraded system, you will have still have
/etc/ssh/ssh_host_dsa_key{,.pub} but these will be ignored by sshd and
would not be generated on a new machine.
Optionally, you may choose to replace /etc/ssh/ssh_host_rsa_key{,.pub}
if that key has a short bit-length.
You may find that you get 'Key mismatch' warnings -- ssh may use a
different type of host key on connection to a machine after this update,
and it will alert you if this does not match what it has in
~/ssh/known-hosts from previous connections. If you're satisfied that
the warning is explained by this configuration change, then you can edit
known-hosts to eliminate the warning message.
As a ssh user, you will need to review the ssh keys you are using, and
what is listed in the ~/.ssh/authorized_keys files of any machines you
want to login to. You can add a new key of and alternate type in
parallel to your existing keys, and load multiple keys into ssh-agent --
this allows you to phase in a new key with minimal risk that you will
lock yourself out of a remote machine. Doing this *before* you upgrade
any systems is just common sense.
The default configuration of sshd provided with FreeBSD provides good
security and a good level of interoperability with other ssh
implementations, and you can use it with confidence. Depending on local
requirements you may want to impose a stricter policy. In that case,
the following references will be interesting to you:
https://wiki.mozilla.org/Security/Guidelines/OpenSSH
https://stribika.github.io/2015/01/04/secure-secure-shell.html
These are, however, rather more than most people will really find necessary.
Cheers,
Matthew
signature.asc
Description: OpenPGP digital signature
Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts
On Sat, Jul 23, 2016 at 08:46:49PM +0100, Miguel C wrote: > Just as a note using netgraph (with jng script as a workaround) works > > Also manually creating a bridge in the domu and adding xn0 as a member > makes this fail so the issue is indeed related to the bridge. > > I'll open a PR later in case someone want to look into it, but I'm happy it > works with netgraph. I seem to be able to use xn* interfaces with bridges without problems: xn0: flags=8943 metric 0 mtu 1500 options=3 ether 00:16:3e:74:3d:76 nd6 options=29 media: Ethernet manual status: active bridge0: flags=8843 metric 0 mtu 1500 ether 02:77:3d:4a:18:00 inet 172.16.1.140 netmask 0xff00 broadcast 172.16.1.255 nd6 options=9 groups: bridge id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: xn0 flags=143 ifmaxaddr 0 port 2 priority 128 path cost 200 Is this a GENERIC kernel or are you using some custom configuration/patches? Can you provide some more information about how to reproduce this? Roger. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel panic caused by virtualbox(?)
On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: > On 8 Aug, Konstantin Belousov wrote: > > On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: > >> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: > >> > Reposted to -current to get some more eyes on this ... > >> > > >> > I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. > >> > The host is: > >> > FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 > >> > The virtualbox version is: > >> > virtualbox-ose-5.0.26 > >> > virtualbox-ose-kmod-5.0.26_1 > >> > > >> > The panic message is: > >> > > >> > panic: Unregistered use of FPU in kernel > >> > cpuid = 1 > >> > KDB: stack backtrace: > >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >> > 0xfe085a55d030 > >> > vpanic() at vpanic+0x182/frame 0xfe085a55d0b0 > >> > kassert_panic() at kassert_panic+0x126/frame 0xfe085a55d120 > >> > trap() at trap+0x7ae/frame 0xfe085a55d330 > >> > calltrap() at calltrap+0x8/frame 0xfe085a55d330 > >> > --- trap 0x16, rip = 0x827dd3a9, rsp = 0xfe085a55d408, rbp = > >> > 0xfe085a55d430 --- > >> > g_pLogger() at 0x827dd3a9/frame 0xfe085a55d430 > >> > g_pLogger() at 0x8274e5c7/frame 0x3 > >> > KDB: enter: panic > >> > > >> > Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is > >> > the trigger. > >> > > >> > There are no symbols for the virtualbox kmods, possibly because I > >> > installed them as an upgrade using packages (built with the same source > >> > tree version) instead of by using PORTS_MODULES in make.conf, so ports > >> > kgdb didn't have anything useful to say about what happened before the > >> > trap. > >> > > >> > This panic is very repeatable. I just got another one when starting the > >> > same VM., but this time the two calls before the trap were > >> > null_bug_bypass(). Hmn, that symbol is in nullfs ... > >> > > >> > I don't see this with a Windows 7 VM. > >> > > >> > All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse > >> > -msoft-float -mno-aes -mno-avx > > Your disassemble listed fxrstor instruction that failing, or did I > > mis-remembered ? This is most likely some context switch code, either > > by virtual machine or erronously executed guest code. It is not a > > spontaneous use of FPU, but more likely something different. Can you > > confirm ? > > > > In either case, I do not remember any KBI changes around PCB layout or > > fpu_enter() KPI recently. > > > >> > >> I suspect head packages are quite likely built against the a "wrong" KBI > >> and are too fragile to use for kmods vs compiling from ports. :-/ I would > >> try a built-from-ports kmod to see if the panics go away. > > > > FWIW, I will commit the following change shortly. Since third-party > > modules break the invariant, either due to bugs (ndis wrappers) or > > possibly due to KBI breakage, it is worth to have the detection enabled > > for production kernels. > > Interesting ... I tried running virtualbox on recent 10.3-STABLE with a > GENERIC kernel and the guest seemed to operate properly. Then I enabled > INVARIANTS and got the panic. I suspect that is why nobody has stumbled > across this before. > This is yet another reason to promote KASSERT to the full panic. I expect that the vbox source lacks fpu_kern_enter() calls around the FPU state restoration. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts
Melhores Cumprimentos // Best Regards --- *Miguel Clara* *IT - Sys Admin & Developer* On Tue, Aug 9, 2016 at 9:55 AM, Roger Pau Monné wrote: > On Sat, Jul 23, 2016 at 08:46:49PM +0100, Miguel C wrote: > > Just as a note using netgraph (with jng script as a workaround) works > > > > Also manually creating a bridge in the domu and adding xn0 as a member > > makes this fail so the issue is indeed related to the bridge. > > > > I'll open a PR later in case someone want to look into it, but I'm happy > it > > works with netgraph. > > I seem to be able to use xn* interfaces with bridges without problems: > > xn0: flags=8943 metric 0 > mtu 1500 > options=3 > ether 00:16:3e:74:3d:76 > nd6 options=29 > media: Ethernet manual > status: active > bridge0: flags=8843 metric 0 mtu > 1500 > ether 02:77:3d:4a:18:00 > inet 172.16.1.140 netmask 0xff00 broadcast 172.16.1.255 > nd6 options=9 > groups: bridge > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: xn0 flags=143 > ifmaxaddr 0 port 2 priority 128 path cost 200 > > Is this a GENERIC kernel or are you using some custom > configuration/patches? > Can you provide some more information about how to reproduce this? > > GENERIC + VIMAGE, but that's just it, no other custom changes or patches. Note however that this is under a NetbBSD Dom0, and I see the "vifXX" interface disappear in the Dom0 side when the bridge is create on FreeBSD DomU. I'm actually happy with netgraph, although I've never played with it, and seems more complex, the script provide in /share/examples is perfect to use with "jail.conf" and pf seems happy in FreeBSD-11 (which is not CURRENT, should we move this to a different mailing list!?) too, no panics so far. I suspect the main issue, since it works fine for you is the fact that this is in a NetBSD Dom0. > Roger. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: lengthy sdhci timeouts on KBL-Y tester
This is pre-production hardware and this type of behavior is generally expected due the hardware debugging that is enabled in both the HW itself and UEFI/IFWI. Thanks, Jeff -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of O. Hartmann Sent: Monday, August 08, 2016 9:57 PM To: K. Macy Cc: FreeBSD Current Subject: Re: lengthy sdhci timeouts on KBL-Y tester On Mon, 8 Aug 2016 18:43:42 -0700 "K. Macy" wrote: > I have a KBL-Y "Software Development Platform" for purposes of getting > the i915 KMS working on that system on FreeBSD. I've just installed 11 > BETA4. sdhci timeouts add several minutes to boot time. The dmesg > output follows: [...] A very similar situation here with a Intel NUC5CPYH. I circumvent the problem by setting in /boot/device.hints "hint.sdhci_pci.0.disabled=1" as a workaround. [...] > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-BETA4 #0 r303759: Fri Aug 5 02:26:47 UTC 2016 > r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on > LLVM 3.8.0) > VT(efifb): resolution 2560x1440 > CPU: Intel(R) Core(TM) m5-7Y54 CPU @ 1.20GHz (1608.05-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x806e9 Family=0x6 Model=0x8e Stepping=9 > > Features=0xbfebfbff > > Features2=0x7ffafbbf > AMD Features=0x2c100800 > AMD Features2=0x121 > Structured Extended > Features=0x29c67af > XSAVE Features=0xf > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > real memory = 8589934592 (8192 MB) > avail memory = 8160288768 (7782 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads > random: unblocking device. > ioapic0 irqs 0-119 on motherboard > random: entropy device external interface > kbd1 at kbdmux0 > netmap: loaded module > module_register_init: MOD_LOAD (vesa, 0x81018940, 0) error 19 > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > ACPI Error: No handler for Region [ECF2] (0xf800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xf800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xf800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xf800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xf800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160527/exfldio-320) ACPI Error: Method parse/execution failed > [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0), > AE_NOT_EXIST (20160527/psparse-559) > ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] > (Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111) > ACPI Error: No handler for Region [ECF2] (0xf800063cb000) > [EmbeddedControl] (20160527/evregion-180) > ACPI Error: Region EmbeddedControl (ID=3) has no
Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts
On Tue, Aug 09, 2016 at 12:12:34PM +0100, Miguel C wrote: > Melhores Cumprimentos // Best Regards > --- > *Miguel Clara* > *IT - Sys Admin & Developer* > > On Tue, Aug 9, 2016 at 9:55 AM, Roger Pau Monné > wrote: > > > On Sat, Jul 23, 2016 at 08:46:49PM +0100, Miguel C wrote: > > > Just as a note using netgraph (with jng script as a workaround) works > > > > > > Also manually creating a bridge in the domu and adding xn0 as a member > > > makes this fail so the issue is indeed related to the bridge. > > > > > > I'll open a PR later in case someone want to look into it, but I'm happy > > it > > > works with netgraph. > > > > I seem to be able to use xn* interfaces with bridges without problems: > > > > xn0: flags=8943 metric 0 > > mtu 1500 > > options=3 > > ether 00:16:3e:74:3d:76 > > nd6 options=29 > > media: Ethernet manual > > status: active > > bridge0: flags=8843 metric 0 mtu > > 1500 > > ether 02:77:3d:4a:18:00 > > inet 172.16.1.140 netmask 0xff00 broadcast 172.16.1.255 > > nd6 options=9 > > groups: bridge > > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > member: xn0 flags=143 > > ifmaxaddr 0 port 2 priority 128 path cost 200 > > > > Is this a GENERIC kernel or are you using some custom > > configuration/patches? > > Can you provide some more information about how to reproduce this? > > > > GENERIC + VIMAGE, but that's just it, no other custom changes or patches. > > Note however that this is under a NetbBSD Dom0, and I see the "vifXX" > interface disappear in the Dom0 side when the bridge is create on FreeBSD > DomU. > > I'm actually happy with netgraph, although I've never played with it, and > seems more complex, the script provide in /share/examples is perfect to use > with "jail.conf" and pf seems happy in FreeBSD-11 (which is not CURRENT, > should we move this to a different mailing list!?) too, no panics so far. > > I suspect the main issue, since it works fine for you is the fact that this > is in a NetBSD Dom0. Oh, from your previous email I thought that it was the interface inside of the DomU that disappeared. Does then same happen on a NetBSD Dom0 with a NetBSD DomU? Roger. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts
On Tuesday, August 9, 2016, Roger Pau Monné wrote: > On Tue, Aug 09, 2016 at 12:12:34PM +0100, Miguel C wrote: > > Melhores Cumprimentos // Best Regards > > --- > > *Miguel Clara* > > *IT - Sys Admin & Developer* > > > > On Tue, Aug 9, 2016 at 9:55 AM, Roger Pau Monné > > > wrote: > > > > > On Sat, Jul 23, 2016 at 08:46:49PM +0100, Miguel C wrote: > > > > Just as a note using netgraph (with jng script as a workaround) > works > > > > > > > > Also manually creating a bridge in the domu and adding xn0 as a > member > > > > makes this fail so the issue is indeed related to the bridge. > > > > > > > > I'll open a PR later in case someone want to look into it, but I'm > happy > > > it > > > > works with netgraph. > > > > > > I seem to be able to use xn* interfaces with bridges without problems: > > > > > > xn0: flags=8943 > metric 0 > > > mtu 1500 > > > options=3 > > > ether 00:16:3e:74:3d:76 > > > nd6 options=29 > > > media: Ethernet manual > > > status: active > > > bridge0: flags=8843 metric 0 > mtu > > > 1500 > > > ether 02:77:3d:4a:18:00 > > > inet 172.16.1.140 netmask 0xff00 broadcast 172.16.1.255 > > > nd6 options=9 > > > groups: bridge > > > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > > > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > > member: xn0 flags=143 > > > ifmaxaddr 0 port 2 priority 128 path cost 200 > > > > > > Is this a GENERIC kernel or are you using some custom > > > configuration/patches? > > > Can you provide some more information about how to reproduce this? > > > > > > GENERIC + VIMAGE, but that's just it, no other custom changes or > patches. > > > > Note however that this is under a NetbBSD Dom0, and I see the "vifXX" > > interface disappear in the Dom0 side when the bridge is create on FreeBSD > > DomU. > > > > I'm actually happy with netgraph, although I've never played with it, and > > seems more complex, the script provide in /share/examples is perfect to > use > > with "jail.conf" and pf seems happy in FreeBSD-11 (which is not CURRENT, > > should we move this to a different mailing list!?) too, no panics so far. > > > > I suspect the main issue, since it works fine for you is the fact that > this > > is in a NetBSD Dom0. > > Oh, from your previous email I thought that it was the interface inside of > the DomU that disappeared. Does then same happen on a NetBSD Dom0 with a > NetBSD DomU? > > Sorry I should have explained better, and no it does not happen with other guests not even FreeBSD 9 or 10, but VIMAGE has major issues there and some have been fixed in 11 (panics while using of for example), and I also needed a patch for xn to even work (also related to NetBSD dom0) but bridge did not give any issues. It seems with 11 when I add xn0 to the bridge the dom0 thinks the interface was disconnected, and when that happens I guess the vif bridge script ( on dom0 ) destroys the interface. Roger. -- Miguel Clara, Sent from Gmail Mobile ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 11 - BETA-1 Xen DOMU loses network when jail (VIMAGE) starts
On Tue, Aug 09, 2016 at 03:09:37PM +0100, Miguel C wrote: > On Tuesday, August 9, 2016, Roger Pau Monné wrote: > > > On Tue, Aug 09, 2016 at 12:12:34PM +0100, Miguel C wrote: > > > Melhores Cumprimentos // Best Regards > > > --- > > > *Miguel Clara* > > > *IT - Sys Admin & Developer* > > > > > > On Tue, Aug 9, 2016 at 9:55 AM, Roger Pau Monné > > > > > wrote: > > > > > > > On Sat, Jul 23, 2016 at 08:46:49PM +0100, Miguel C wrote: > > > > > Just as a note using netgraph (with jng script as a workaround) > > works > > > > > > > > > > Also manually creating a bridge in the domu and adding xn0 as a > > member > > > > > makes this fail so the issue is indeed related to the bridge. > > > > > > > > > > I'll open a PR later in case someone want to look into it, but I'm > > happy > > > > it > > > > > works with netgraph. > > > > > > > > I seem to be able to use xn* interfaces with bridges without problems: > > > > > > > > xn0: flags=8943 > > metric 0 > > > > mtu 1500 > > > > options=3 > > > > ether 00:16:3e:74:3d:76 > > > > nd6 options=29 > > > > media: Ethernet manual > > > > status: active > > > > bridge0: flags=8843 metric 0 > > mtu > > > > 1500 > > > > ether 02:77:3d:4a:18:00 > > > > inet 172.16.1.140 netmask 0xff00 broadcast 172.16.1.255 > > > > nd6 options=9 > > > > groups: bridge > > > > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > > > > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > > > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > > > member: xn0 flags=143 > > > > ifmaxaddr 0 port 2 priority 128 path cost 200 > > > > > > > > Is this a GENERIC kernel or are you using some custom > > > > configuration/patches? > > > > Can you provide some more information about how to reproduce this? > > > > > > > > GENERIC + VIMAGE, but that's just it, no other custom changes or > > patches. > > > > > > Note however that this is under a NetbBSD Dom0, and I see the "vifXX" > > > interface disappear in the Dom0 side when the bridge is create on FreeBSD > > > DomU. > > > > > > I'm actually happy with netgraph, although I've never played with it, and > > > seems more complex, the script provide in /share/examples is perfect to > > use > > > with "jail.conf" and pf seems happy in FreeBSD-11 (which is not CURRENT, > > > should we move this to a different mailing list!?) too, no panics so far. > > > > > > I suspect the main issue, since it works fine for you is the fact that > > this > > > is in a NetBSD Dom0. > > > > Oh, from your previous email I thought that it was the interface inside of > > the DomU that disappeared. Does then same happen on a NetBSD Dom0 with a > > NetBSD DomU? > > > > Sorry I should have explained better, and no it does not happen with other > guests not even FreeBSD 9 or 10, but VIMAGE has major issues there and some > have been fixed in 11 (panics while using of for example), and I also > needed a patch for xn to even work (also related to NetBSD dom0) but bridge > did not give any issues. > > It seems with 11 when I add xn0 to the bridge the dom0 thinks the interface > was disconnected, and when that happens I guess the vif bridge script ( on > dom0 ) destroys the interface. Can you paste the output of `xenstore-ls -fp` on the Dom0 when that happens? Also are there any messages in the Dom0 dmesg? You might want to modify src/sys/arch/xen/xen/xennetback_xenbus.c (on the NetBSD sources) to define XENDEBUG_NET, so that you get verbose output. Roger. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r303890 breaks build
The switch to device_t breaks the user-space compilation with .. Building /usr/obj/usr/src/lib/libkvm/kvm.o --- kvm.o --- In file included from /usr/src/lib/libkvm/kvm.c:50: /usr/obj/usr/src/tmp/usr/include/sys/pcpu.h:163:2: error: unknown type name 'device_t' device_tpc_device; ^ 1 error generated. *** [kvm.o] Error code 1 imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r303890 breaks build
On 09/08/2016 23:24, Michael Butler wrote: > The switch to device_t breaks the user-space compilation with .. Ye, I saw that. I'm waiting for buildworld to finish before committing. I'm sorry, I was sure only the kernel used this structure. Thank you for the report! And sorry for the breakage. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
