Kernel Panic on 2/27 build with USG #97
Comments
|
Same issue after upgrading to the latest release. The device has been stuck in a reboot loop with occasional ping responses in between. Package: wireguard-e50-0.0.20190227-1 |
|
Same issue for me on a ER-6P, I upgraded remotely and now the unit it down, no Internet at the site. Once I get serial access I can post more info. What testing is done on these packages prior to being released? |
|
|
Seems to be quite an issue. Maybe pull this release until more is known why this is happening. |
|
@phillipmcmahon Agreed. I've pulled the 1.10 packages for now. As for testing before release - most of the time, there is none, as I don't really have equipment to test on. @NimlothPL Thanks for the stacktrace. Seems related to this commit. I'll ask Jason about it. |
|
I was able to fix this on a USG 4 Pro with the help of single user mode. I connected a serial console cable and then caught the U-Boot console by pressing a key before it continued booting. You should see something like: Once in the U-Boot console I ran I copied the value for The actual command I ran at the U-Boot console was: Once in single user mode I uninstalled the deb package using If you're on a Unifi-enabled board you'll get provisioning errors on when the Unifi controller tries to commit a config that specifies a WireGuard interface (assuming you persisted the WireGuard config using a |
|
Thanks for the report. I'll look into it. |
|
I'm happy to test basic install, reboot and simple functionality on the hardware I have. ER-X-SFP and an ERX-6P, these run the 1.10 branch of firmware. |
|
If you've got a working toolchain, would you building with this patch and let me know if that "fixes" it? diff --git a/src/compat/compat.h b/src/compat/compat.h
index 7a61e4c1..7c2d5125 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -466,11 +466,13 @@ static inline void *kvmalloc_ours(size_t size, gfp_t flags)
{
gfp_t kmalloc_flags = flags;
void *ret;
+#ifndef CONFIG_CAVIUM_OCTEON_IPFWD_OFFLOAD
if (size > PAGE_SIZE) {
kmalloc_flags |= __GFP_NOWARN;
if (!(kmalloc_flags & __GFP_REPEAT) || (size <= PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
kmalloc_flags |= __GFP_NORETRY;
}
+#endif
ret = kmalloc(size, kmalloc_flags);
if (ret || size <= PAGE_SIZE)
return ret; |
|
Same issue on my ER-4 with FW v2.0.0. I ran |
|
@zx2c4 I tried your patch but it didn't help on my ER-4 (v2.0.0, kernel 4.9.79). I changed your |
|
@Lochnair wireguard-v2.0-e300-0.0.20190227-1.deb from the 0.0.20190227 github release panics for me, you may want to pull the v2.0 binaries too. |
|
Alright let's take it a step further then and use an entirely different allocator and see if that makes the problem go away. Then at least we'll have some idea of what we're looking at: diff --git a/src/compat/compat.h b/src/compat/compat.h
index 7a61e4c1..cbf9427a 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -464,6 +464,7 @@ static inline __be32 our_inet_confirm_addr(struct net *net, struct in_device *in
#include <linux/slab.h>
static inline void *kvmalloc_ours(size_t size, gfp_t flags)
{
+#ifndef CONFIG_CAVIUM_OCTEON_IPFWD_OFFLOAD
gfp_t kmalloc_flags = flags;
void *ret;
if (size > PAGE_SIZE) {
@@ -474,6 +475,7 @@ static inline void *kvmalloc_ours(size_t size, gfp_t flags)
ret = kmalloc(size, kmalloc_flags);
if (ret || size <= PAGE_SIZE)
return ret;
+#endif
return __vmalloc(size, flags, PAGE_KERNEL);
}
static inline void *kvzalloc_ours(size_t size, gfp_t flags) |
|
Is this the right firmware for that stacktrace, btw? https://dl.ubnt.com/firmwares/edgemax/v2.0.x/ER-e300.v2.0.0.5155284.tar |
|
@zx2c4 Thanks, it looks like this patch works! For the 4.9 kernel I changed your patch slightly, since the _OCTEON was removed from the config name (and code was moved from arch/mips/cavium-octeon to drivers/net/ethernet/cavium/octeon) diff --git a/src/compat/compat.h b/src/compat/compat.h
index 7a61e4c..0131d22 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -464,6 +464,7 @@ static inline __be32 our_inet_confirm_addr(struct net *net, struct in_device *in
#include <linux/slab.h>
static inline void *kvmalloc_ours(size_t size, gfp_t flags)
{
+#if !defined(CONFIG_CAVIUM_OCTEON_IPFWD_OFFLOAD) && !defined(CONFIG_CAVIUM_IPFWD_OFFLOAD)
gfp_t kmalloc_flags = flags;
void *ret;
if (size > PAGE_SIZE) {
@@ -474,6 +475,7 @@ static inline void *kvmalloc_ours(size_t size, gfp_t flags)
ret = kmalloc(size, kmalloc_flags);
if (ret || size <= PAGE_SIZE)
return ret;
+#endif
return __vmalloc(size, flags, PAGE_KERNEL);
}
static inline void *kvzalloc_ours(size_t size, gfp_t flags)Yes, that's the right firmware for my stacktrace (but @NimlothPL's earlier in the thread is for a different firmware/kernel/hardware). Ubiquiti still hasn't updated their downloads page for v2.0, nor provided a final GPL archive, so I'm building with kernel source from |
|
Do you need |
|
I didn't touch that part of compat.h when building, but it looks like In |
Before I add it, I'd be very grateful if you could do some comparison to show that it's the right thing to do. Also, with regards to the real bug here, we now know there's something gravely wrong with the slab allocator (kmalloc_caches[15] is an invalid pointer), but we don't know why or how to mitigate that. Think you could send me the output of |
Woah woah are you saying that this bug is present on their 4.9 kernel too? Not just their 3.10? Or did you not actually try to trigger it on the 4.9 yet? |
Checking that now and doing some iperf3 benchmarking.
Yep, all of my building/testing today has been on the 4.9 kernel, I don't have 3.10 running on anything (and it'd probably be tricky to downgrade) |
|
Gotcha, thanks for clarifying. I've been looking at the wrong kernel sources! Awaiting |
|
Here's |
|
Rebuilt wireguard with iperf3 might be slightly faster when terminating wireguard in the ER4 and then forwarding to a LAN host with the |
|
This is a bit of a frustrating situation as I don't have things setup to keep trying stuff, so it's quite hard to debug, and the octeon kernel won't build for qemu. If you've got a lot of patience, there are a million things I'm curious about in trying to track this bug down. For example: diff --git a/mm/slab_common.c b/mm/slab_common.c
index 622f6b6ae..29861409a 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -980,6 +980,7 @@ static void __init new_kmalloc_cache(int idx, unsigned long flags)
{
kmalloc_caches[idx] = create_kmalloc_cache(kmalloc_info[idx].name,
kmalloc_info[idx].size, flags);
+ pr_err("SARU making cache %d is 0x%llx called %s size %lu flags 0x%x\n", idx, kmalloc_caches[idx], kmalloc_info[idx].name, kmalloc_info[idx].size, flags);
}
/*
@@ -992,6 +993,7 @@ void __init create_kmalloc_caches(unsigned long flags)
int i;
for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++) {
+ pr_err("SARU iteration %d, pre-state: 0x%llx\n", i, kmalloc_caches[i]);
if (!kmalloc_caches[i])
new_kmalloc_cache(i, flags);
Got IRC or something? Might be easier to work through it there, if you're up for that. |
|
I can dig up an IRC client, but I'm not super comfortable testing out kernel patches. When I soft-bricked at first, I wasn't able to break into a bootloader shell and don't know what would happen if I got stuck with an unbootable kernel. Happy to test out wireguard patches as long as my roommate's not using the internet. P.S. I sympathize with the struggle of debugging without hardware, and really appreciate your help on this issue! |
|
Okay what if you patch wireguard with the below and see at which point it crashes (i.e. send me the whole dmesg output): diff --git a/src/main.c b/src/main.c
index 4b5b58e8..cda15a94 100644
--- a/src/main.c
+++ b/src/main.c
@@ -20,8 +20,20 @@
static int __init mod_init(void)
{
+ unsigned long i;
+ void *ohnose;
int ret;
+ for (i = 0; i < ilog2(0x100000000); ++i) {
+ pr_err("About to allocate size %lu, index %d", 1UL << i, kmalloc_index(1UL << i));
+ ohnose = kmalloc(1UL << i, GFP_KERNEL);
+ if (!ohnose) {
+ pr_err("Allocation failed at size %lu\n", 1UL << i);
+ break;
+ }
+ kfree(ohnose);
+ }
+
if ((ret = chacha20_mod_init()) || (ret = poly1305_mod_init()) ||
(ret = chacha20poly1305_mod_init()) || (ret = blake2s_mod_init()) ||
(ret = curve25519_mod_init())) |
|
Sure, I can try that out (as soon as I can find a reasonable maintenance window). One issue is that systemd seems to capture most of the kernel output once it starts so the prints before the panic might get dropped. I'll play around with printk levels to see if I can make them hit the console unconditionally. |
|
Those are pr_err prints, so they should be somewhat unconditional. I wasn't aware edgemax had moved to systemd. |
|
Yeah, EdgeOS v2.0 switched to Debian Stretch with systemd. Here's the output after insmod with the kmalloc patch. Interestingly it didn't panic in this context. I did Here's the dmesg output starting after the insmod. Did you want the full log starting at boot? |
|
has there been any progress on this? I am happy to test packages (assuming no risk of bricking my ER-6P, it has a serial port on it but not sure how far I can screw things up) and if someone can point me in the right direction to setting up a compile toolchain I will gladly assist in this too. |
|
Quiet, yes, but not forgotten. Lots of unexpected travel precluding my access to the hardware right now. I'd suggest @Lochnair apply the workaround I posted above to his builds until I'm back home and can figure out what UBNT is doing to their kernels. |
|
Appreciate the response, and also to know at some point things will pick up again. There has been another release of WireGuard in the meantime, v0.0.20190406. |
|
Indeed. I'm the one who made that release :) I don't expect it will fix the kmalloc problem, though. |
|
haha, my bad. I should know whom I am talking with next time :) |
|
I can confirm 0406 still crashes without the patch |
|
I am willing to test on ER-4 EDGEOS FW 2.0.1 if deb packages go back up again. |
|
Fingers crossed, installing now on my 6P... Update: Installed, rebooted and it all came back up and within these first few minutes it looks ok. My WireGuard client connected without issue and traffic is-a-flowing. I will keep hammering it this evening and see if something "bad" happens. Early to call it, but thanks a lot. |
|
Several GB have passed through the multiple WG interfaces I have installed on my 6P. All looks pretty solid. No issues noted as of yet. |
|
Thanks for the build! The 2.0 package seems sane on my ER4 v2.0.1 |
|
Allen,
Can you share the relevant portions of your config? I can get the tunnel to
activate but the routes aren't getting pushed. This is my first time
setting up Wireguard, see config. Thanks in advance.
*Client config:*
[Interface]
PrivateKey = <removed>
Address = 192.168.10.2/32
[Peer]
PublicKey = <removed>
AllowedIPs = 0.0.0.0/0 ::/0
Endpoint = gw.freeblizz.com:*53922*
*ER4 config:*
name WAN_LOCAL {
default-action drop
description "WAN to router"
rule 31 {
action accept
description wireguard
destination {
port *53922*
}
log enable
protocol udp
state {
established enable
invalid disable
new enable
related enable
}
wireguard wg0 {
address 192.168.10.1/24
listen-port 53922
peer <removed> {
allowed-ips 192.168.10.2/32
}
private-key <removed>
route-allowed-ips true
nat {
rule 5011 {
description "Masquerade for wg0"
outbound-interface wg0
protocol all
type masquerade
}
Corey Hines
Systems Engineer
Arista Networks
m 612-209-6550
o 408-547-8075
chines@arista.com
TAC: support@arista.com
www.arista.com
Arista EOS: A Tale of Opposite Architectures
<https://www.youtube.com/watch?v=Hfwr6sY27hA&authuser=1>
Download the EOS Configuration Manual
<https://www.arista.com/assets/data/docs/Manuals/EOS-4.15.4F-Manual.pdf>
Install vEOS-lab for testing & training
<https://eos.arista.com/running-veos-on-esxi-5-5/>
…On Mon, Apr 15, 2019 at 6:25 PM Allen Wild ***@***.***> wrote:
Thanks for the build! The 2.0 package seems sane on my ER4 v2.0.1
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#97 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH5-LR5Dw6hitkvv9Ja_A3FmBtXgTYviks5vhQpygaJpZM4bZoHe>
.
|
|
Corey -- try your configuration for the peer without the ipv6 default network. I've had a problem with this the last few versions and have had to use a script to add it after the link is up using the wg command directly. For some reason on the ER's if the ::/0 (or 0::/0) is present in the saved config it doesn't work. |
|
Does it cause the ER to fail on boot? I just had to do a recovery and
restored from UNMS. I will try again tomorrow when the production home
streaming services are not critical.
On Mon, Apr 15, 2019 at 8:19 PM dc361 ***@***.***> wrote:
Corey -- try your configuration for the peer without the ipv6 default
network. I've had a problem with this the last few versions and have had to
use a script to add it after the link is up using the wg command directly.
For some reason on the ER's if the ::/0 (or 0::/0) is present in the saved
config it doesn't work.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#97 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH5-LbBs0Z5S8nTJaVRGAi8miKy-ge3Hks5vhSUxgaJpZM4bZoHe>
.
--
-Corey Hines (sent from mobile)
612-209-6550
chines@arista.com
|
|
Corey, in addition to removing IPv6, also set You might want to try the Ubiquity forum for further assistance. |
|
By the way, thanks for dropping the new build. I have been looking forward
to building a wireguard VPN to retire my OpenVPN setup. I appreciate the
work and hope to provide good news and testing feedback when I can test
again later today. I can say that the kernel module did not cause
instability while activating and deactivating the wireguard on the client
and the Edgeos CLI works correctly setting up the wg0 interface.
Thanks for the replies!
-Corey
On Mon, Apr 15, 2019 at 10:31 PM Corey Hines ***@***.***> wrote:
Does it cause the ER to fail on boot? I just had to do a recovery and
restored from UNMS. I will try again tomorrow when the production home
streaming services are not critical.
On Mon, Apr 15, 2019 at 8:19 PM dc361 ***@***.***> wrote:
> Corey -- try your configuration for the peer without the ipv6 default
> network. I've had a problem with this the last few versions and have had to
> use a script to add it after the link is up using the wg command directly.
> For some reason on the ER's if the ::/0 (or 0::/0) is present in the saved
> config it doesn't work.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#97 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AH5-LbBs0Z5S8nTJaVRGAi8miKy-ge3Hks5vhSUxgaJpZM4bZoHe>
> .
>
--
-Corey Hines (sent from mobile)
612-209-6550
***@***.***
--
-Corey Hines (sent from mobile)
612-209-6550
chines@arista.com
|
|
thanks for the update |
|
ok, I read that forum before (while researching), I see what I assume are
your posts regarding this advice, thanks I am going to do some testing now
and will reply in the ubnt forum.
Corey Hines
Systems Engineer
Arista Networks
m 612-209-6550
o 408-547-8075
chines@arista.com
TAC: support@arista.com
www.arista.com
Arista EOS: A Tale of Opposite Architectures
<https://www.youtube.com/watch?v=Hfwr6sY27hA&authuser=1>
Download the EOS Configuration Manual
<https://www.arista.com/assets/data/docs/Manuals/EOS-4.15.4F-Manual.pdf>
Install vEOS-lab for testing & training
<https://eos.arista.com/running-veos-on-esxi-5-5/>
…On Mon, Apr 15, 2019 at 11:25 PM Phillip ***@***.***> wrote:
Corey, in addition to removing IPv6, also set
route-allowed-ips to false.
You might want to try the Ubiquity forum for further assistance.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#97 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH5-LZSPZIGCkDf5f-odMaAYqk4IWzbiks5vhVDWgaJpZM4bZoHe>
.
|
|
Report: version 406 installed on EdgeRouter Lite-3 (e100) few days ago and operates OK since. |
|
I've been running it for two days now on my ERL-3 and all looks good. |
|
Looks like this might be good to formally push to a release. Thanks again for the work done to get the fix in and the packages out. |
|
I ran some traffic through it while at a coffee shop yesterday and it has
been fine for over 24 hours. I also have my IOS device using it for
On-Demand when I leave my SSID. Things appear to be fine.
If there are any specific logs or details to review, happy to look them
over.
Thanks, I spent time reading the Wireguard site's "interworkings" and thank
all of you for working on packages for ER users.
Corey Hines
Systems Engineer
Arista Networks
m 612-209-6550
o 408-547-8075
chines@arista.com
TAC: support@arista.com
www.arista.com
Arista EOS: A Tale of Opposite Architectures
<https://www.youtube.com/watch?v=Hfwr6sY27hA&authuser=1>
Download the EOS Configuration Manual
<https://www.arista.com/assets/data/docs/Manuals/EOS-4.15.4F-Manual.pdf>
Install vEOS-lab for testing & training
<https://eos.arista.com/running-veos-on-esxi-5-5/>
…On Tue, Apr 16, 2019 at 6:49 PM Corey Hines ***@***.***> wrote:
ok, I read that forum before (while researching), I see what I assume are
your posts regarding this advice, thanks I am going to do some testing now
and will reply in the ubnt forum.
Corey Hines
Systems Engineer
Arista Networks
m 612-209-6550
o 408-547-8075
***@***.***
TAC: ***@***.***
www.arista.com
Arista EOS: A Tale of Opposite Architectures
<https://www.youtube.com/watch?v=Hfwr6sY27hA&authuser=1>
Download the EOS Configuration Manual
<https://www.arista.com/assets/data/docs/Manuals/EOS-4.15.4F-Manual.pdf>
Install vEOS-lab for testing & training
<https://eos.arista.com/running-veos-on-esxi-5-5/>
On Mon, Apr 15, 2019 at 11:25 PM Phillip ***@***.***> wrote:
> Corey, in addition to removing IPv6, also set
> route-allowed-ips to false.
>
> You might want to try the Ubiquity forum for further assistance.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#97 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AH5-LZSPZIGCkDf5f-odMaAYqk4IWzbiks5vhVDWgaJpZM4bZoHe>
> .
>
|
|
I have an ER-X and an ER-Lite that are currently just sitting in a box. would this hardware be helpful for testing so this sort of thing doesn't occur again? If so, I'm more than happy to either donate them make them available in some other way. |
|
Nils,
Is there a chance you are able to put out a build for EdgeOS 2.0.3 of
Wireguard? The last stable build produces an error on insmod:
root@gw:/lib/modules/4.9.79-UBNT/kernel/net# insmod wireguard.ko
insmod: ERROR: could not insert module wireguard.ko: Unknown symbol in
module
Are there others that can build these binaries? Some say you may not be
using UBNT gear now. I need additional skills to understand how to setup a
build environment.
Thanks!
Corey Hines
Systems Engineer
Arista Networks
*612-209-6550chines@arista.com <chines@arista.com>*
*TAC: support@arista.com <support@arista.com>*
www.arista.com
Register NOW! for Arista Cloud Builders 2019 in Minneapolis!
<https://events.arista.com/2019-q2-acb-minnesota>
Arista EOS: A Tale of Opposite Architectures
<https://www.youtube.com/watch?v=Hfwr6sY27hA&authuser=1>
Download the EOS Configuration Manual
<https://www.arista.com/assets/data/docs/Manuals/EOS-4.15.4F-Manual.pdf>
Install vEOS-lab for testing & training
<https://eos.arista.com/running-veos-on-esxi-5-5/>
…On Fri, Apr 19, 2019 at 11:53 AM Corey Hines ***@***.***> wrote:
I ran some traffic through it while at a coffee shop yesterday and it has
been fine for over 24 hours. I also have my IOS device using it for
On-Demand when I leave my SSID. Things appear to be fine.
If there are any specific logs or details to review, happy to look them
over.
Thanks, I spent time reading the Wireguard site's "interworkings" and
thank all of you for working on packages for ER users.
Corey Hines
Systems Engineer
Arista Networks
m 612-209-6550
o 408-547-8075
***@***.***
TAC: ***@***.***
www.arista.com
Arista EOS: A Tale of Opposite Architectures
<https://www.youtube.com/watch?v=Hfwr6sY27hA&authuser=1>
Download the EOS Configuration Manual
<https://www.arista.com/assets/data/docs/Manuals/EOS-4.15.4F-Manual.pdf>
Install vEOS-lab for testing & training
<https://eos.arista.com/running-veos-on-esxi-5-5/>
On Tue, Apr 16, 2019 at 6:49 PM Corey Hines ***@***.***> wrote:
> ok, I read that forum before (while researching), I see what I assume are
> your posts regarding this advice, thanks I am going to do some testing now
> and will reply in the ubnt forum.
>
>
> Corey Hines
> Systems Engineer
> Arista Networks
> m 612-209-6550
> o 408-547-8075
> ***@***.***
> TAC: ***@***.***
> www.arista.com
> Arista EOS: A Tale of Opposite Architectures
> <https://www.youtube.com/watch?v=Hfwr6sY27hA&authuser=1>
> Download the EOS Configuration Manual
> <https://www.arista.com/assets/data/docs/Manuals/EOS-4.15.4F-Manual.pdf>
> Install vEOS-lab for testing & training
> <https://eos.arista.com/running-veos-on-esxi-5-5/>
>
>
>
> On Mon, Apr 15, 2019 at 11:25 PM Phillip ***@***.***>
> wrote:
>
>> Corey, in addition to removing IPv6, also set
>> route-allowed-ips to false.
>>
>> You might want to try the Ubiquity forum for further assistance.
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub
>> <#97 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AH5-LZSPZIGCkDf5f-odMaAYqk4IWzbiks5vhVDWgaJpZM4bZoHe>
>> .
>>
>
|
Full support for building wireguard for the UBNT e300 (ER-4/ER-6P/ER-12)
Git submodules:
* WireGuard 0.0.20190601
* libmnl 1.0.4
* musl 1.1.22
* vyatta-wireguard package and scripts v2.0 branch
Git LFS objects:
* Cavium Octeon gcc 4.7 toolchain (OCTEON-SDK-5.1-tools.tar.xz) from
OCTEON-SDK-5.1.tbz in https://github.com/Cavium-Open-Source-Distributions/OCTEON-SDK/
I repackaged only the toolchain into a tar.xz to save space and avoid
slow bzip2 decompression.
* Kernel source (e300_kernel_5174690-gbd11043d0ccc.tgz) from the
EdgeMAX v2.0.1 GPL release https://dl.ubnt.com/firmwares/edgemax/v2.0.x/GPL.ER-e300.v2.0.1.5174690.tar.bz2
I repackaged just the kernel source tarball to save space and avoid
slow bzip2 decompression.
Other:
* only-use-__vmalloc-for-now.patch from https://gist.github.com/Lochnair/805bf9ab96742d0fe1c25e4130268307
See Lochnair/vyatta-wireguard#97 for
context and history
Full support for building wireguard for the UBNT e300 (ER-4/ER-6P/ER-12)
Git submodules:
* WireGuard 0.0.20190601
* libmnl 1.0.4
* musl 1.1.22
* vyatta-wireguard package and scripts v2.0 branch
Git LFS objects:
* Cavium Octeon gcc 4.7 toolchain (OCTEON-SDK-5.1-tools.tar.xz) from
OCTEON-SDK-5.1.tbz in https://github.com/Cavium-Open-Source-Distributions/OCTEON-SDK/
I repackaged only the toolchain into a tar.xz to save space and avoid
slow bzip2 decompression.
* Kernel source (e300_kernel_5174690-gbd11043d0ccc.tgz) from the
EdgeMAX v2.0.1 GPL release https://dl.ubnt.com/firmwares/edgemax/v2.0.x/GPL.ER-e300.v2.0.1.5174690.tar.bz2
I repackaged just the kernel source tarball to save space and avoid
slow bzip2 decompression.
Other:
* only-use-__vmalloc-for-now.patch from https://gist.github.com/Lochnair/805bf9ab96742d0fe1c25e4130268307
See Lochnair/vyatta-wireguard#97 for
context and history
|
Hi Corey, UBNT hasn't released the GPL archive for v2.0.3, but the kernel hasn't changed enough since v2.0.1 to matter; the same WireGuard binaries/packages will work on v2.0.1 and v2.0.3, at least for my e300 ER-4. The "unknown symbol" error is due to the wireguard module's dependencies on For anyone wanting to build their own packages, I finally published and documented my build scripts: https://github.com/aswild/vyatta-wireguard-build. Only e300 v2.0.x is supported right now since that's what I use, but it should be straightforward to add other platforms. |
|
Sorry for the hijack, and thanks for the help despite. I am working on a
build environment, thanks for the build script docs and will modprobe
instead. Thanks again!
On Sun, Jun 9, 2019 at 5:53 PM Allen Wild ***@***.***> wrote:
Hi Corey,
It's probably best not to hijack this (already very long) issue thread
with unrelated questions about releases and builds, but we're here now so
I'll help anyway.
UBNT hasn't released the GPL archive for v2.0.3, but the kernel hasn't
changed enough since v2.0.1 to matter; the same WireGuard binaries/packages
will work on v2.0.1 and v2.0.3, at least for my e300 ER-4.
The "unknown symbol" error is due to the wireguard module's dependencies
on udp_tunnel and ip6_udp_tunnel. The best solution is to use modprobe
wireguard instead of insmod /path/to/wireguard.ko (since modprobe handles
module dependencies). Alternatively, modprobe udp_tunnel and
ip6_udp_tunnel before insmod-ing wireguard.
For anyone wanting to build their own packages, I finally published and
documented my build scripts:
https://github.com/aswild/vyatta-wireguard-build. Only e300 v2.0.x is
supported right now since that's what I use, but it should be
straightforward to add other platforms.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#97?email_source=notifications&email_token=AB7H4LL5Y7AHU3H5USV7VJ3PZWCWJA5CNFSM4G3GQHPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXIT3ZI#issuecomment-500252133>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB7H4LIP4ADVRKEFA5YQZBDPZWCWJANCNFSM4G3GQHPA>
.
--
-Corey Hines (sent from mobile)
612-209-6550
chines@arista.com
|
|
Please don't hijack this. I'm going to look into this eventually, but there's already way too much noise to keep straight in documenting what's going on. |
Hello, I have been using these releases with great success for months. I installed the 2/27 build yesterday and upon restart I receive a kernel panic with the updated version. I reset the device to defaults and installed again and received the same issue. I downgraded to the previous release and everything works as expected. Anyone got any pointers to help troubleshoot? Is it just a bad build for the USG3P? Any advice or assistance would be appreciated!
The text was updated successfully, but these errors were encountered: