Project

General

Profile

Bug #23447

if_lagg and if_vlan need SIOCSIFCAP support for plugins to work properly

Added by Andrew McCann over 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Critical
Assignee:
Alexander Motin
Category:
OS
Target version:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

Seen on FreeNAS-9.10-MASTER-201704180409 (b713a96)

Installing Plex plugin on a clean system with no existing plugins/jails installed. Installed Plugins shows status as stopped, checking Jails shows plugin as running. Jails are running FreeBSD 11.

Apr 19 14:54:40 freenas uwsgi: jexec 3 /usr/pbi/plexmediaserver-amd64/control stop
Apr 19 14:54:40 freenas notifier: jexec 3 /usr/pbi/plexmediaserver-amd64/control start 192.168.1.60 12346
Apr 19 14:54:58 freenas uwsgi: [freeadmin.navtree:570] Couldn't retrieve http://192.168.1.50/plugins/plexmediaserver/1/_s/treemenu: timed out
Apr 19 15:01:06 freenas uwsgi: [plugins.utils:91] Couldn't retrieve http://192.168.1.50/plugins/plexmediaserver/1/_s/status: HTTP Error 503: Service Unavailable
Apr 19 15:04:41 freenas uwsgi: [plugins.utils:91] Couldn't retrieve http://192.168.1.50/plugins/plexmediaserver/1/_s/status: HTTP Error 503: Service Unavailable
Apr 19 15:17:03 freenas uwsgi: [plugins.utils:91] Couldn't retrieve http://192.168.1.50/plugins/plexmediaserver/1/_s/status: HTTP Error 503: Service Unavailable

Jails Status.PNG (7.22 KB) Jails Status.PNG Andrew McCann, 04/18/2017 10:54 PM
Plugin Status.PNG (6.77 KB) Plugin Status.PNG Andrew McCann, 04/18/2017 10:54 PM
Plugins Issue.PNG (68.9 KB) Plugins Issue.PNG Andrew McCann, 04/19/2017 06:24 PM
Working Plugins.PNG (64.1 KB) Working Plugins.PNG Andrew McCann, 04/20/2017 06:47 AM
10756
10757
10773
10778

Related issues

Is duplicate of FreeNAS - Bug #23649: Plugin tree view - configurationClosed: Duplicate2017-04-28
Has duplicate FreeNAS - Bug #23579: bridge0: error setting interface capabilities on lagg0Closed: Duplicate2017-04-25

Associated revisions

Revision 97e8dd58 (diff)
Added by Alexander Motin about 4 years ago

Allow some control over enabled capabilities for if_vlan. It improves interoperability with if_bridge, which may need to disable some capabilities not supported by other members. IMHO there is still open question about LRO capability, which may need to be disabled on physical interface. (cherry picked from commit 5fe43451950ccb1e74bf952ba0fb6dcd995afc9e) Ticket: #23447

Revision 97e8dd58 (diff)
Added by Alexander Motin about 4 years ago

Allow some control over enabled capabilities for if_vlan. It improves interoperability with if_bridge, which may need to disable some capabilities not supported by other members. IMHO there is still open question about LRO capability, which may need to be disabled on physical interface. (cherry picked from commit 5fe43451950ccb1e74bf952ba0fb6dcd995afc9e) Ticket: #23447

Revision aeaec58c (diff)
Added by Alexander Motin about 4 years ago

Propagate IFCAP_LRO from trunk to vlan interface. False positive here cost nothing, while false negative may lead to some confusions. (cherry picked from commit 9899f92afe52cc585c002f33f2b11c073e37bdc0) Ticket: #23447

Revision aeaec58c (diff)
Added by Alexander Motin about 4 years ago

Propagate IFCAP_LRO from trunk to vlan interface. False positive here cost nothing, while false negative may lead to some confusions. (cherry picked from commit 9899f92afe52cc585c002f33f2b11c073e37bdc0) Ticket: #23447

Revision 02c8d196 (diff)
Added by Alexander Motin about 4 years ago

Make if_bridge complain if it can't disable some capabilities. (cherry picked from commit 08f5e30a7cf6b3be2f5b82b2780940b8299cd1ea) Ticket: #23447

Revision 02c8d196 (diff)
Added by Alexander Motin about 4 years ago

Make if_bridge complain if it can't disable some capabilities. (cherry picked from commit 08f5e30a7cf6b3be2f5b82b2780940b8299cd1ea) Ticket: #23447

Revision bf532018 (diff)
Added by Alexander Motin about 4 years ago

MFC r312979 (by loos): Do not update the lagg link layer address when destroying a lagg clone. This would enqueue an event to send the gratuitous arp on a dying lagg interface without any physical ports attached to it. Apart from that, the taskqueue_drain() on lagg_clone_destroy() runs too late, when the ifp data structure is already freed. Fix that too. (cherry picked from commit 2b7fc1d0908bde2aeb232deaac7a7d01eb2bc0c9) Ticket: #23447

Revision bf532018 (diff)
Added by Alexander Motin about 4 years ago

MFC r312979 (by loos): Do not update the lagg link layer address when destroying a lagg clone. This would enqueue an event to send the gratuitous arp on a dying lagg interface without any physical ports attached to it. Apart from that, the taskqueue_drain() on lagg_clone_destroy() runs too late, when the ifp data structure is already freed. Fix that too. (cherry picked from commit 2b7fc1d0908bde2aeb232deaac7a7d01eb2bc0c9) Ticket: #23447

Revision 90e298ff (diff)
Added by Alexander Motin about 4 years ago

Introduce sleepable locks into if_lagg. Before this change if_lagg was using nonsleepable rmlocks to protect its internal state. This patch introduces another sx lock to protect code paths that require sleeping, while still uses old rmlock to protect hot nonsleepable data paths. This change allows to remove taskqueue decoupling used before to change interface addresses without holding the lock. Instead it uses sx lock to protect direct if_ioctl() calls. As another bonus, the new code synchronizes enabled capabilities of member interfaces, and allows to control them with ifconfig laggX, that was impossible before. This part should fix interoperation with if_bridge, that may need to disable some capabilities, such as TXCSUM or LRO, to allow bridging with noncapable interfaces. MFC after: 2 weeks Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D10514 (cherry picked from commit 39f39609ab65adede5164ed385778905e039afd9) Ticket: #23447

Revision 90e298ff (diff)
Added by Alexander Motin about 4 years ago

Introduce sleepable locks into if_lagg. Before this change if_lagg was using nonsleepable rmlocks to protect its internal state. This patch introduces another sx lock to protect code paths that require sleeping, while still uses old rmlock to protect hot nonsleepable data paths. This change allows to remove taskqueue decoupling used before to change interface addresses without holding the lock. Instead it uses sx lock to protect direct if_ioctl() calls. As another bonus, the new code synchronizes enabled capabilities of member interfaces, and allows to control them with ifconfig laggX, that was impossible before. This part should fix interoperation with if_bridge, that may need to disable some capabilities, such as TXCSUM or LRO, to allow bridging with noncapable interfaces. MFC after: 2 weeks Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D10514 (cherry picked from commit 39f39609ab65adede5164ed385778905e039afd9) Ticket: #23447

Revision 32edbdab (diff)
Added by Alexander Motin about 4 years ago

MFC r312979 (by loos): Do not update the lagg link layer address when destroying a lagg clone. This would enqueue an event to send the gratuitous arp on a dying lagg interface without any physical ports attached to it. Apart from that, the taskqueue_drain() on lagg_clone_destroy() runs too late, when the ifp data structure is already freed. Fix that too. (cherry picked from commit 2b7fc1d0908bde2aeb232deaac7a7d01eb2bc0c9) Ticket: #23447 (cherry picked from commit bf532018d17bd18d7ff6c24b73821ae5ff6b9013)

Revision 32edbdab (diff)
Added by Alexander Motin about 4 years ago

MFC r312979 (by loos): Do not update the lagg link layer address when destroying a lagg clone. This would enqueue an event to send the gratuitous arp on a dying lagg interface without any physical ports attached to it. Apart from that, the taskqueue_drain() on lagg_clone_destroy() runs too late, when the ifp data structure is already freed. Fix that too. (cherry picked from commit 2b7fc1d0908bde2aeb232deaac7a7d01eb2bc0c9) Ticket: #23447 (cherry picked from commit bf532018d17bd18d7ff6c24b73821ae5ff6b9013)

Revision 324a20c2 (diff)
Added by Alexander Motin about 4 years ago

Introduce sleepable locks into if_lagg. Before this change if_lagg was using nonsleepable rmlocks to protect its internal state. This patch introduces another sx lock to protect code paths that require sleeping, while still uses old rmlock to protect hot nonsleepable data paths. This change allows to remove taskqueue decoupling used before to change interface addresses without holding the lock. Instead it uses sx lock to protect direct if_ioctl() calls. As another bonus, the new code synchronizes enabled capabilities of member interfaces, and allows to control them with ifconfig laggX, that was impossible before. This part should fix interoperation with if_bridge, that may need to disable some capabilities, such as TXCSUM or LRO, to allow bridging with noncapable interfaces. MFC after: 2 weeks Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D10514 (cherry picked from commit 39f39609ab65adede5164ed385778905e039afd9) Ticket: #23447 (cherry picked from commit 90e298ff50a6f5186942e0e8b59a6f603080d8b9)

Revision 324a20c2 (diff)
Added by Alexander Motin about 4 years ago

Introduce sleepable locks into if_lagg. Before this change if_lagg was using nonsleepable rmlocks to protect its internal state. This patch introduces another sx lock to protect code paths that require sleeping, while still uses old rmlock to protect hot nonsleepable data paths. This change allows to remove taskqueue decoupling used before to change interface addresses without holding the lock. Instead it uses sx lock to protect direct if_ioctl() calls. As another bonus, the new code synchronizes enabled capabilities of member interfaces, and allows to control them with ifconfig laggX, that was impossible before. This part should fix interoperation with if_bridge, that may need to disable some capabilities, such as TXCSUM or LRO, to allow bridging with noncapable interfaces. MFC after: 2 weeks Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D10514 (cherry picked from commit 39f39609ab65adede5164ed385778905e039afd9) Ticket: #23447 (cherry picked from commit 90e298ff50a6f5186942e0e8b59a6f603080d8b9)

Revision 4a4a7765 (diff)
Added by Kris Moore about 4 years ago

Unbreak the build after 90e298ff50a6f5186942e0e8b59a6f603080d8b9 Ticket: #23447

Revision 4a4a7765 (diff)
Added by Kris Moore about 4 years ago

Unbreak the build after 90e298ff50a6f5186942e0e8b59a6f603080d8b9 Ticket: #23447

Revision 27a07a29 (diff)
Added by Kris Moore about 4 years ago

Unbreak the build after 90e298ff50a6f5186942e0e8b59a6f603080d8b9 Ticket: #23447 (cherry picked from commit 4a4a7765efd6550a2a19e210fb0bf6e39474610b)

Revision 27a07a29 (diff)
Added by Kris Moore about 4 years ago

Unbreak the build after 90e298ff50a6f5186942e0e8b59a6f603080d8b9 Ticket: #23447 (cherry picked from commit 4a4a7765efd6550a2a19e210fb0bf6e39474610b)

Revision 147a1a2c (diff)
Added by Alexander Motin about 4 years ago

Revert "Unbreak the build after 90e298ff50a6f5186942e0e8b59a6f603080d8b9" This reverts commit 4a4a7765efd6550a2a19e210fb0bf6e39474610b. Ticket: #23447

Revision 147a1a2c (diff)
Added by Alexander Motin about 4 years ago

Revert "Unbreak the build after 90e298ff50a6f5186942e0e8b59a6f603080d8b9" This reverts commit 4a4a7765efd6550a2a19e210fb0bf6e39474610b. Ticket: #23447

Revision 4960ad8a (diff)
Added by Alexander Motin about 4 years ago

Fix r317696 build without debug. Ticket: #23447

Revision 4960ad8a (diff)
Added by Alexander Motin about 4 years ago

Fix r317696 build without debug. Ticket: #23447

Revision e068cb49 (diff)
Added by Alexander Motin about 4 years ago

Revert "Unbreak the build after 90e298ff50a6f5186942e0e8b59a6f603080d8b9" This reverts commit 4a4a7765efd6550a2a19e210fb0bf6e39474610b. Ticket: #23447 (cherry picked from commit 147a1a2c083008ecaa0e70c547e54ded2d760539)

Revision e068cb49 (diff)
Added by Alexander Motin about 4 years ago

Revert "Unbreak the build after 90e298ff50a6f5186942e0e8b59a6f603080d8b9" This reverts commit 4a4a7765efd6550a2a19e210fb0bf6e39474610b. Ticket: #23447 (cherry picked from commit 147a1a2c083008ecaa0e70c547e54ded2d760539)

Revision 3f7f2032 (diff)
Added by Alexander Motin about 4 years ago

Fix r317696 build without debug. Ticket: #23447 (cherry picked from commit 4960ad8a678d554673ed30c9167d23bcb9b8aaaf)

Revision 3f7f2032 (diff)
Added by Alexander Motin about 4 years ago

Fix r317696 build without debug. Ticket: #23447 (cherry picked from commit 4960ad8a678d554673ed30c9167d23bcb9b8aaaf)

Revision 3efcb4b3 (diff)
Added by Alexander Motin about 4 years ago

Relax r317696 locking to not drain taskqueue under the lock. (cherry picked from commit d332b8edc8a25aa80b72d43950667ee419996390) Ticket: #23447

Revision 3efcb4b3 (diff)
Added by Alexander Motin about 4 years ago

Relax r317696 locking to not drain taskqueue under the lock. (cherry picked from commit d332b8edc8a25aa80b72d43950667ee419996390) Ticket: #23447

Revision a529a706 (diff)
Added by Alexander Motin about 4 years ago

Relax r317696 locking to not drain taskqueue under the lock. (cherry picked from commit d332b8edc8a25aa80b72d43950667ee419996390) Ticket: #23447 (cherry picked from commit 3efcb4b363864e0bf0110386ccb64046f125f9bb)

Revision a529a706 (diff)
Added by Alexander Motin about 4 years ago

Relax r317696 locking to not drain taskqueue under the lock. (cherry picked from commit d332b8edc8a25aa80b72d43950667ee419996390) Ticket: #23447 (cherry picked from commit 3efcb4b363864e0bf0110386ccb64046f125f9bb)

History

#1 Updated by Andrew McCann over 4 years ago

Its seems all plugins are affected, even though they are running, the plugins are not accessible. Will upload debug files if required.

Apr 19 21:29:46 freenas uwsgi: [freeadmin.navtree:570] Couldn't retrieve http://192.168.1.50/plugins/plexmediaserver/1/_s/treemenu: timed out
Apr 19 21:29:46 freenas uwsgi: [freeadmin.navtree:570] Couldn't retrieve http://192.168.1.50/plugins/transmission/2/_s/treemenu: timed out
Apr 19 21:29:46 freenas uwsgi: [freeadmin.navtree:570] Couldn't retrieve http://192.168.1.50/plugins/bacula-sd/3/_s/treemenu: timed out
Apr 19 21:31:02 freenas uwsgi: [plugins.utils:91] Couldn't retrieve http://192.168.1.50/plugins/plexmediaserver/1/_s/status: HTTP Error 503: Service Unavailable
Apr 19 21:31:02 freenas uwsgi: [plugins.utils:91] Couldn't retrieve http://192.168.1.50/plugins/bacula-sd/3/_s/status: HTTP Error 503: Service Unavailable
Apr 19 21:31:02 freenas uwsgi: [plugins.utils:91] Couldn't retrieve http://192.168.1.50/plugins/transmission/2/_s/status: HTTP Error 503: Service Unavailable

#2 Updated by Bonnie Follweiler over 4 years ago

  • Assignee set to Kris Moore

#3 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

  • Assignee changed from Kris Moore to William Grzybowski

William - Something easily fixable?

#4 Updated by William Grzybowski over 4 years ago

  • Status changed from Unscreened to 15

I think unfortunately you were hit by the bug of wrong plugin jail architecture.

Can you please post the output of:

jexec plexmediaserver_1 uname -m

#5 Updated by Andrew McCann over 4 years ago

Hi, result was - amd64

Thanks

#6 Updated by William Grzybowski over 4 years ago

Andrew McCann wrote:

Hi, result was - amd64

Thanks

How about:

jexec plexmediaserver_1 /usr/pbi/plexmediaserver-amd64/control start 192.168.1.60 12346
jexec plexmediaserver_1 sockstat -4

What is the output of these.

#7 Updated by Andrew McCann over 4 years ago

1st command executed with no output, copied results directly from command window

root@freenas ~]# jexec plexmediaserver_1 /usr/pbi/plexmediaserver-amd64/control
start 192.168.1.60 12346
[root@freenas ~]# jexec plexmediaserver_1 sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root syslogd 8098 7 udp4 :514 *:
root python2.7 7506 3 tcp4 192.168.1.60:12346 *:*
[root@freenas ~]#

#8 Updated by Andrew McCann over 4 years ago

10773

Just adding another screenshot, hopefully might help?

Notice the corrupt icon at each plugin, plus the tree view of the plugins on the left hand side does not have the + to expand the 3 plugin installed.

And finally, this box will be rebuilt when 9.10.3 comes out, so if you need me to delete jails, test anything that could break jails am happy to do so....

#9 Updated by William Grzybowski over 4 years ago

Andrew McCann wrote:

Just adding another screenshot, hopefully might help?

Notice the corrupt icon at each plugin, plus the tree view of the plugins on the left hand side does not have the + to expand the 3 plugin installed.

And finally, this box will be rebuilt when 9.10.3 comes out, so if you need me to delete jails, test anything that could break jails am happy to do so....

Can you "telnet 192.168.1.60 12346"?

Does that work? Also, are you running within a VM? Can you attach the debug (System - Advanced - Save Debug)?

#10 Updated by Andrew McCann over 4 years ago

  • File debug-freenas-20170420224901.tgz added

Telnet timed out, was pingable though. Running on bare metal, no vm. Attached debug.

[root@freenas ~]# telnet 192.168.1.60 12346
Trying 192.168.1.60...

telnet: connect to address 192.168.1.60: Operation timed out
telnet: Unable to connect to remote host
[root@freenas ~]#
[root@freenas ~]# ping 192.168.1.60
PING 192.168.1.60 (192.168.1.60): 56 data bytes
64 bytes from 192.168.1.60: icmp_seq=0 ttl=64 time=0.098 ms
64 bytes from 192.168.1.60: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 192.168.1.60: icmp_seq=2 ttl=64 time=0.042 ms

#11 Updated by William Grzybowski over 4 years ago

  • Status changed from 15 to Investigation

I see you're using lagg, I am thinking this might be a issue with FreeBSD bridge and lagg. I'll look further. Thanks for the fast reply.

#12 Updated by William Grzybowski over 4 years ago

Can you do the following:

ifconfig igb0 -rxcsum -txcsum
ifconfig igb1 -rxcsum -txcsum
ifconfig lagg0 -rxcsum -txcsum

And then try the telnet command again?

#13 Updated by Andrew McCann over 4 years ago

ok, first two command worked, third failed -

[root@freenas ~]# ifconfig lagg0 -rxcsum -txcsum
ifconfig: -rxcsum: Invalid argument

If you like, i can disable lagg to see if this resolves issue as well....

#14 Updated by William Grzybowski over 4 years ago

  • Status changed from Investigation to Unscreened
  • Assignee changed from William Grzybowski to Alexander Motin
  • Priority changed from No priority to Critical

Andrew McCann wrote:

ok, first two command worked, third failed -

[root@freenas ~]# ifconfig lagg0 -rxcsum -txcsum
ifconfig: -rxcsum: Invalid argument

If you like, i can disable lagg to see if this resolves issue as well....

Even though, can you try the telnet command again?

I am reassigning the ticket to our FreeBSD expert.

Thanks

#15 Updated by Andrew McCann over 4 years ago

Sorry forgot that, yes, telnet worked this time.

[root@freenas ~]# telnet 192.168.1.60 12346
Trying 192.168.1.60...
Connected to plexmediaserver_1.
Escape character is '^]'.

#16 Updated by Andrew McCann over 4 years ago

10778

And that fixed the plugins issues I was having, they start correctly and can be accessed from there respective webpages.

#17 Updated by Alexander Motin over 4 years ago

  • Category changed from 33 to 137
  • Status changed from Unscreened to Fix In Progress

OK. The picture seems clear now. Thanks for diagnostics. You may probably add those options into interfaces configuration, while I'll think about the proper fix.

#18 Updated by Alexander Motin over 4 years ago

Just a note for myself: 78b31fbde6c5a9be65fcd0e2a3a83094fbba6388

#19 Updated by William Grzybowski over 4 years ago

  • Target version set to 11.0

#20 Updated by Damon Hagerstrom over 4 years ago

  • Category changed from 137 to 33
  • Seen in changed from Master - FreeNAS Nightlies to 11.0

#21 Updated by Alexander Motin over 4 years ago

  • Seen in changed from 11.0 to Master - FreeNAS Nightlies

Closer investigation of if_lagg and conversation with other FreeBSD developers shown multiple locking issues in if_lagg. Patch we used in FreeNAS 9.10.2 and before aggravates it even more. That why, I suppose, it was not upstreamed. I am trying to rework if_lagg locking to fix that problem first, that should make this problem easier to fix correctly.

#23 Updated by Alexander Motin about 4 years ago

This my patch for if_lagg should address this problem among others: https://reviews.freebsd.org/D10514 .

#24 Updated by Alexander Motin about 4 years ago

  • Subject changed from Installed Plugins show incorrect status to if_lagg and if_vlan need SIOCSIFCAP support for plugins to work properly
  • Category changed from 33 to 137

I found the same problem with if_vlan. Working on the fix there too.

#25 Updated by Alexander Motin about 4 years ago

if_vlan should (mostly?) be fixed now. Changes for if_lagg are more significant, so have to wait some time for review.

#26 Updated by Andrew McCann about 4 years ago

I see the if_lagg is in review with the BSD team, will this make the the 11 release, or will 11 be delayed till this is approved?

Thanks

#27 Updated by Alexander Motin about 4 years ago

As marked in the ticket, I expect it to get into 11.0 release, since the regression is quite significant.

#28 Updated by Andrew McCann about 4 years ago

Thanks Alexander, appreciate all the hard work to get this issue resolved!!

#29 Updated by Alexander Motin about 4 years ago

Further experiments shown that if_vlan indeed may still have some problems (probably not significant for jails, but potentially affecting VMs) if NIC supports LRO and has it enabled. There is a pressure from FreeBSD committers against letting vlan to control physical port capabilities, which is what if_bridge tries to do. I made few patches to make the problem visible in logs. Will see if it is enough.

#30 Updated by Anthony Takata about 4 years ago

Watching this. I think this might be part of why I can't get much more than 20 kbps throughput (if at all) on my VMs, but all other systems seem to be working fine...

Edit: Maybe something weird on my VM's config. Something seems to have broken from leftovers, when I deleted all the NIC drivers from Device Manager (and let it reboot) and reset winsock (among other things), it seems things are starting to look a bit better? We'll see.

#31 Updated by William Grzybowski about 4 years ago

  • Is duplicate of Bug #23649: Plugin tree view - configuration added

#32 Updated by Alexander Motin about 4 years ago

  • Status changed from Fix In Progress to 19

I gave up waiting for review, so after rereading patch once more I committed it to both FreeBSD head and FreeNAS 11 nightly. Testers are welcome to try it on next nightly build.

#33 Updated by Vaibhav Chauhan about 4 years ago

Sasha: where are the FIX- branches for this change I can't seem to locate them?

#34 Updated by Matt Wall about 4 years ago

Having read through the fix I believe this may also potentially resolve https://bugs.freenas.org/issues/19544 which started occurring after 9.10.1-U4.

I will test the next nightly and report back once I have time.

#35 Updated by Vaibhav Chauhan about 4 years ago

latest changes have been cherry-picked in freenas/11.0-stable, no need to create fix branches. this change will be out in freenas11-rc

#36 Updated by Vaibhav Chauhan about 4 years ago

  • Status changed from 19 to Ready For Release

#37 Updated by Vaibhav Chauhan about 4 years ago

  • Status changed from Ready For Release to Unscreened
  • Priority changed from Critical to Blocks Until Resolved

#38 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Status changed from Unscreened to Needs Developer Review

Mav - I threw in a patch to un-break the build for now. Needs your review, not sure if this was the correct way to do it:

https://github.com/freenas/os/commit/4a4a7765efd6550a2a19e210fb0bf6e39474610b

Also, I didn't see your lagg fix go into freenas/svn_head, were you waiting for it to hit upstream FBSD first?

#39 Updated by Vaibhav Chauhan about 4 years ago

  • Priority changed from Blocks Until Resolved to Critical

this fix is a workaround, I will mark this ticket as a critical as 'fix' needs to be fixed, but not as a blocker as it will not break a build.
$ git cherry-pick -x 4a4a7765efd6550a2a19e210fb0bf6e39474610b
[freenas/11.0-stable 27a07a29046] Unbreak the build after 90e298ff50a6f5186942e0e8b59a6f603080d8b9
Author: Kris Moore <>
Date: Tue May 2 19:33:36 2017 -0400
1 file changed, 5 insertions(+)

#40 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Status changed from Needs Developer Review to Resolved

#41 Updated by Vaibhav Chauhan about 4 years ago

  • Target version changed from 11.0 to 11.0-RC

#42 Updated by Andrew McCann about 4 years ago

Just an update, most of my plugins have been working on last 2 builds, there seems to be some weird issues with Firefly and Bacula-sd, but believe this is a separate issue and will log another ticket.

#43 Updated by Anthony Takata about 4 years ago

Thumbs up for me, My VMs can now talk to the host proper. :)

#44 Updated by Dru Lavigne over 3 years ago

  • Has duplicate Bug #23579: bridge0: error setting interface capabilities on lagg0 added

#45 Updated by Dru Lavigne over 3 years ago

  • File deleted (debug-freenas-20170420224901.tgz)

Also available in: Atom PDF