Closed tapper82 closed 5 years ago
In my opinion, there's no point updating until the remerge hits. Any adjustments today would require redefining a lot of the build code. If we wait until it merges back under Openwrt then it is less rework.
Eric is the lead though. And much more seasoned at kernel updates than I.
It won't make Gargoyle throughput faster.
The plan to keep the LEDE code base should meen just small build changes after the remerge to OpenWRt. This next relece of LEDE is on K4.4 but the one after that is ameing for K4.9. LEDE seems to be mooving along a lot faster than OpenWRt ever has. :-)
I think Tapper has a good point.
Both OpenWrt and LEDE are based on the OpenWRT Chaos Calmer codebase Gargoyle is now based on. Gong to LEDE isn't like moving the code to an entirely new platform.
I was hoping OpenWRT and LEDE would re-merge but so far it hasn't happened, and it may be time for another update. I don't want to be dependent on whether OpenWRT is dragging its feet. If LEDE does another release without any release from OpenWRT we'll definitely be moving to that codebase. It's possible that I will start to migrate sooner than that, depending on how long it is before such a release. I don't know about LEDE's proposed timeline for their next release (and I haven't heard anything in a while about a potential re-merge), but I may have missed something. Do you know what their timeline looks like?
Tapper, I may have misread that -- you mentioned an upcoming point release in three weeks, but that isn't going to be rebased on 4.9, is it? At least in OpenWRT point releases don't switch kernels.
In my first post I was referring to next major release with a kernel bump, not a point/incremental release.
I will say though, LEDE's speed of releasing point releases is really refreshing compared to OpenWRT.
Hi eric no the next relece will not be jumping to 4.9. That is said to be for 17.07 You can read more about what will be in the next point relece here: https://lede-project.org/releases/17.01/changelog-17.01.2 I like that LEDE has such good changelogs. In the email i had it says that: On 25 May 2017 at 04:34, Jo-Philipp Wich jo@mein.io wrote: Hi,
I'd like to start preparing the v17.01.2 release during the upcoming weekend with the goal to release final binaries within the next week (~May 29th till June 3rd).
Changes that shall be part of 17.01.2 should be merged until Sunday, the 28th.
Ok, 17.07 suggests that this next LEDE release will come out in July. If they haven't re-merged with OpenWRT by then, I'm going to rebase on LEDE 17.07.
It seems it will be releced in les than 3 weeks. My bad!
Hmm, they refer to 17.06 (so june, just a few weeks) on their site. If they're doing 6 month release cycles, that's actually really good. So, I'm going to stand by this -- when 17.06 comes out (and I'm going to guess OpenWRT will not have gotten around to merging by then), I'll rebase Gargoyle on that.
Hi I asked for more info on IRC.
Tapper Hi am i rite in thinking that 17.07 will be out in July.?
I am asking because i am chatting to eric the leed dev of gargoyle Tapper we are chatting about rebacing gargoyle on lede
Borromini Tapper: i think it will be june rather Borromini http://lists.infradead.org/pipermail/lede-dev/2017-May/007727.html
are you following the ML? Tapper Yes mate and i didn't meen the 17.01.2 relece Borromini apologies, i misread Tapper I ment the 17.06 or what ever it will be
it's ok Borromini well you know the merge talks are on, so i'm not sure if 17.06 or 17.07 will be released
a lot of arches are still on 4.4 as well or with only partial 4.9 suppor etc. Tapper o rite Justanick Borromini: How will the merge with openwrt influence the release cycle? Borromini Justanick: no clue. i'm a bystander just like you :) Hauke Tapper: 17.07 is planned for July, but we are not good at delivering in time ;-) Justanick Borromini: Okay, I love the regular release cycle of lede. Borromini Tapper: i asked jow about 4.9 and he didn't know either, so...
Borromini Justanick: i think most of us do Tapper OK thanks Hauke based on the current state of master I would think it will be pretty easy to switch from lede 17.01.X to the next release if it willl come this summer
LEDE isn't Chaos Calmer. It's closer to Designated Driver than anything else.
Remerge discussion has come to the conclusion that it is happening. There is legal and other things happening now. http://lists.infradead.org/pipermail/lede-adm/2017-May/date.html
All I'm saying is it would be annoying to repoint the build scripts to Git.lede-project only to have them shutdown after remerge to Openwrt. That means we would have a point in time Gargoyle code which can't be reliably reproduced.
What does make sense is getting patches rebased to K4.4 (IMQ for example). Relayd patch needs reworking (they no longer use the file I patched).
Oh, and also dumping 4mb support once and for all. Kernel has grown again
Perhaps a more prudent move in the meantime would be to get Layer7 and WebURL working again which have been broken for a while.
I've already done the legwork on Layer7 (moving it to nDPI), and weburl probably just needs an SSL decryptor built in.
If you send me a pull request for nDPI, I'll merge it, and I can get started porting the modules to the latest kernel.
SSL decryptor... there's no such thing. The entire point of SSL is that you can't decrypt it. If you can, it's broken. The only way to deal with the issue of SSL is to monitor and block DNS requests (which are typically not encrypted) rather than the http connections themselves.
Sorry, it looks like nDPI looks at the certificate
The trend of Internet traffic is going towards encrypted content often using SSL. In order to let nDPI support encrypted connections, we have added a decoder for SSL (both client and server) certificates, thus we can figure out the protocol using the encryption certificate. This allows us to identify protocols such as Citrix Online and Apple iCloud that otherwise would be undetected.
I think what nDPI is doing is using the certificate used to initiate the connection to identify what sort of connection it is, even though you can't decrypt the content of the connection.
Certificates are exchanged when the connection is initiated, and can be analyzed, (e.g. if the certificate is Apple's it may be an Applie iCloud connection) but you can't decrypt the content of a connection given the certificates, because each side holds the private key that corresponds to their own certificate and that never hits the wire.
http://lists.infradead.org/pipermail/lede-adm/2017-June/000533.html
Planning v17.01.2
Jo-Philipp Wich jo at mein.io Sun Jun 4 12:01:51 PDT 2017 Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi,
I decided to delay 17.01.2 by another week to wait for Kernel 4.4.71 getting released which will fix a number of networking related vulnerabilities.
The currently projected release date is Saturday, the 10th.
Regards, Jo
Hi I was just wondering, if we are going to wait could the gargoyle branch built on CC be bumped to kernel 3.18.56? CC is still on 3.18.45. Would it be worth it? I looked through the changelog for 3.1856 and there is not much, but i cant find the logs for changes from 45 to 56.
Here is the log: https://cdn.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.18.56 I don't know if any of those changes are any good for gargoyle.
Final vote (again) http://lists.infradead.org/pipermail/lede-dev/2017-June/007960.html
Hi I was talking to jow in the LEDE irc on Thursday and he told me that there will not be a 17.6 of LEDE now they are going to concentrate on merging the LEDE and OpenWRT codebases. So for the next relece it's how long is a piece of string! No work on the merg of the codebases has bin started so far.
So after the merge is a perfect time to do it because then the build code hardly has to change :)
The merge is not technically complicated. It is politically complicated as they hand over rights and ownership of assets.
So how long do you leave it? LEDE is now on k4.4 the next release of OpenWRT will be jumpping to k4.9 or k4.12 There mite not be a release of OpenWRT for the rest of the year.
Once the two codebases are merged, then it is easy to move to what was the last release "LEDE 17.01.2" because it will be present in the repo we are pointing at. you just point the build at a particular commit and off we go. You don't need to wait for a new one.
So for any body coming across this work has started on moving to building on LEDE. https://github.com/ericpaulbishop/gargoyle/commits/lede On the LEDE IRC Jow says that there will be a 17.1.3 reel soon. hopeful before the end of September.
LEDE v17.01.3 Here's a changelog: https://lede-project.org/releases/17.01/changelog-17.01.3
LEDE v17.01.4 is available, with WPA2 fixes. Also, kernel 4.9 is now available for Archer V2, which should enable TCP_BBR. Any (updated) plan for Gargoyle?
remerge is underway
All of the git repos are getting mangled at the moment. I expect we’re going to have to point to /openwrt/archive/chaos_calmer for 1.10, and god knows where for future. It’s a bit of a mess right now.
Could move to using this: https://github.com/openwrt
Archived branches are in there. Can also pull 17.01 from there too. I might make up a patch set to do this
Hi people I am seeing a lot of work going on the move over to the newer branch of OpenWRT. I just wanted to ask how it's going? I am guessing we will have to have one more relece on the cc branch. nice work on the web interface btw.
Currently appears to be up to the “fixing packages” stage. Packages are compiled alphabetically, and Eric’s latest change was to “ntfs-3g”, so half way?
Once all packages are compiling properly, a firmware image can be generated. At that point bug testing to make sure all features still work and are stable. If I had to guess I’d still say it’s a month away. It would be nice to see the 18.xx release from Openwrt first, but Eric has planned for this already.
Thanks for the update mate. Sounds like it is going good. As soon as you need any testing give me a shout.
Actually, you can start testing now if you want. Only the ar71xx target will build, but that target should build now, and you can start testing.
However... there's a LOT that's going to be broken. Posting here about anything on the (long, long) list of what's actually broken, though would be helpful so I know what to fix and don't have to find it all myself.
Also, the profile_images files haven't been updated yet so images for newer router models won't be copied yet to the images/ar71xx directory, though you will be able to find them in ar71xx-src/bin/targets/[appropriate sub-target directory]
I produced and loaded an image last night on my WNDR3800 and it booted fine. DHCP on WAN didn’t work without a reboot, but I think that has happened to that device before.
I’ll start testing this afternoon and pushing fixes to what I come across. I quickly had time to fix switchinfo before bed. I noticed webmon not working well I think. The rules weren’t showing up in iptables. Will need to investigate more.
My Build failed
include -I/home/user/gargoyle/ar71xx-src/staging_dir/host/include -I/home/user/gargoyle/ar71xx-src/staging_dir/host/include -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7. 3.0_musl/gcc-7.3.0/gcc/../libdecnumber -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/user/gargoyle/ar7 1xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../libbacktrace -o generic-match.o -MT generic-match.o -MMD -MP -MF ./.deps/generic-match.TPo generic-match.c
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wov erloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/home/user/gargoyle/ar71xx-src/build_dir/toolchai n-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/build -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mi ps_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../include -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../libcpp/include \
-o build/genattrtab.o /home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/genattrtab.c
g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverl oaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -no-pie -o build/genattrtab \
build/genattrtab.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/hash-table.o build/read-md.o build/errors.o ../ build-x86_64-pc-linux-gnu/libiberty/libiberty.a
build/genattrtab /home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/common.md /home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/g cc-7.3.0/gcc/config/mips/mips.md insn-conditions.md \
-Atmp-attrtab.c -Dtmp-dfatab.c -Ltmp-latencytab.c
/bin/bash /home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../move-if-change tmp-attrtab.c insn-attrtab.c
/bin/bash /home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../move-if-change tmp-dfatab.c insn-dfatab.c
/bin/bash /home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../move-if-change tmp-latencytab.c insn-latencytab.c
echo timestamp > s-attrtab
g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attri bute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0 _musl/gcc-7.3.0/gcc -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/. -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gc c-7.3.0/gcc/../include -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../libcpp/include -I/home/user/gargoyle/ar71xx-src/staging_dir/host/include -I/ home/user/gargoyle/ar71xx-src/staging_dir/host/include -I/home/user/gargoyle/ar71xx-src/staging_dir/host/include -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gc c-7.3.0/gcc/../libdecnumber -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/user/gargoyle/ar71xx-src/bui ld_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../libbacktrace -o insn-attrtab.o -MT insn-attrtab.o -MMD -MP -MF ./.deps/insn-attrtab.TPo insn-attrtab.c
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wov erloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/home/user/gargoyle/ar71xx-src/build_dir/toolchai n-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/build -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mi ps_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../include -I/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/../libcpp/include \
-o build/genautomata.o /home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/genautomata.c
g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverl oaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -no-pie -o build/genautomata \
build/genautomata.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/hash-table.o build/read-md.o build/errors.o .. /build-x86_64-pc-linux-gnu/libiberty/libiberty.a -lm
build/genautomata /home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/common.md /home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/ gcc-7.3.0/gcc/config/mips/mips.md \
insn-conditions.md > tmp-automata.c
/bin/bash: line 1: 15611 Killed build/genautomata /home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/common.md /home/user/gargoyle/ar71xx- src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/config/mips/mips.md insn-conditions.md > tmp-automata.c
Makefile:2278: recipe for target 's-automata' failed
make[6]: *** [s-automata] Error 137
make[6]: Leaving directory '/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0-initial/gcc'
Makefile:4210: recipe for target 'all-gcc' failed
make[5]: *** [all-gcc] Error 2
make[5]: Leaving directory '/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0-initial'
Makefile:36: recipe for target '/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0-initial/.built' failed
make[4]: *** [/home/user/gargoyle/ar71xx-src/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/gcc-7.3.0-initial/.built] Error 2
make[4]: Leaving directory '/home/user/gargoyle/ar71xx-src/toolchain/gcc/initial'
toolchain/Makefile:96: recipe for target 'toolchain/gcc/initial/compile' failed
make[3]: *** [toolchain/gcc/initial/compile] Error 2
make[3]: Leaving directory '/home/user/gargoyle/ar71xx-src'
toolchain/Makefile:94: recipe for target '/home/user/gargoyle/ar71xx-src/staging_dir/toolchain-mips_24kc_gcc-7.3.0_musl/stamp/.toolchain_compile' failed
make[2]: *** [/home/user/gargoyle/ar71xx-src/staging_dir/toolchain-mips_24kc_gcc-7.3.0_musl/stamp/.toolchain_compile] Error 2
make[2]: Leaving directory '/home/user/gargoyle/ar71xx-src'
/home/user/gargoyle/ar71xx-src/include/toplevel.mk:216: recipe for target 'world' failed
make[1]: *** [world] Error 2
make[1]: Leaving directory '/home/user/gargoyle/ar71xx-src'
find: ‘bin’: No such file or directory
find: ‘’: No such file or directory
find: ‘’: No such file or directory
ls: cannot access 'bin/targets': No such file or directory
user@Gar:~/gargoyle$
New Build OS Ubuntu server 16.04.x updated to latest
user@Gar:~/gargoyle$ nodejs -v
v6.13.1
user@Gar:~/gargoyle$ npm -v
3.10.10
user@Gar:~/gargoyle$
sudo apt-get install build-essential asciidoc binutils bzip2 gawk gettext git libncurses5-dev libz-dev patch unzip zlib1g-dev lib32gcc1 libc6-dev-i386 subversion flex uglifyjs git-core gcc-multilib p7zip p7zip-full msmtp libssl-dev texinfo
git clone git://github.com/ericpaulbishop/gargoyle.git
git checkout base_on_openwrt_remerge
make FULL_BUILD=true ar71xx
ispyisail: I'm not sure what's wrong, but you may wish to try on a newer version of Ubuntu as 16.04 is almost two years old now. I've been developing on a Debian Testing, and have not been able to reproduce the problem.
are you work in VPS? some vps host may limited your hight cpu usage process. (I also get this promble in my vps host)
Another data point (build successful):
Ubuntu 16.04 LTS
NodeJS v6.13.1
NPM v5.7.1
:(
I've now tried Ubuntu Server 17.10.1 Ubuntu Server pre 18.04
All with the same fail :(
I'm building with HyperV inside Windows Server 12 (good internet connection)
I notice you used NPM 5.7.1
The highest I've used is NPM 3.10.10 via instructions on the wiki
NPM shouldn’t cause a fail. It will only fail to compress the JavaScript and/or CSS files.
I’m updating to 17.04 to see if another build still works.
Build fine on 17.04 and 17.10
[root@localhost ~]# uname -a Linux localhost.localdomain 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
A lot of errors “too big" build.log.txt.zip
....Only the ar71xx target will build....
I've been running through some features this evening to ensure they work. I haven't spotted any show stoppers thus far.
Appears something is selecting GNUTLS_CRYPTO (and forcing a dependency on kmod-cryptodev) and causing a warning? Doesn't cause any other targets to fail just that one so may not be related. That's all i can gather from that logfile.
usb_large_nand doesn't build at all actually, fails prereq
oh, it's pretty simple afterall. Patch incoming @ispyisail
Many times like:
dd if=/root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/ap91-5g-kernel.bin >> /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/openwrt-ar71xx-generic-ap91-5g-squashfs-sysupgrade.bin
2730+1 records in
2730+1 records out
1398258 bytes (1.4 MB) copied, 0.0209413 s, 66.8 MB/s
WARNING: Image file /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/openwrt-ar71xx-generic-ap91-5g-squashfs-sysupgrade.bin is too big
/root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/staging_dir/host/bin/mktplinkfw -H 0x04440101 -W 0x1 -F 8Mlzma -N OpenWrt -V r6489-d11aa1d -m 1 -k /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/antminer-s1-kernel.bin -r /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/openwrt-ar71xx-generic-antminer-s1-squashfs-sysupgrade.bin -o /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/openwrt-ar71xx-generic-antminer-s1-squashfs-sysupgrade.bin.new -j -X 0x40000 -a 0x4 -s && mv /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/openwrt-ar71xx-generic-antminer-s1-squashfs-sysupgrade.bin.new /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/openwrt-ar71xx-generic-antminer-s1-squashfs-sysupgrade.bin || rm -f /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/openwrt-ar71xx-generic-antminer-s1-squashfs-sysupgrade.bin
[mktplinkfw] rootfs offset aligned to 0x1398528
[mktplinkfw] *** error: images are too big by 2650713 bytes
/root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/staging_dir/host/bin/mkfwimage -B LS-SR71 -v LS-SR71.ar7100.v6.0.0-OpenWrt-r6489-d11aa1d -k /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/ubnt-ls-sr71-kernel.bin -r /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/openwrt-ar71xx-generic-ubnt-ls-sr71-squashfs-factory.bin -o /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/openwrt-ar71xx-generic-ubnt-ls-sr71-squashfs-factory.bin
board = LS-SR71
ERROR: Failed creating firmware layout description - error code: -2
make[6]: [/root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/openwrt-ar71xx-generic-ubnt-ls-sr71-squashfs-factory.bin] Error 253 (ignored)
/root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/staging_dir/host/bin/trx -o /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/image.tmp -f /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/vmlinux-wrt160nl.uImage -F /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/empty.bin -x 32 -a 0x10000 -x -32 -f /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/root.squashfs-64k && /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/staging_dir/host/bin/addpattern -B wrt160nl -v v1.00.01 -i /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/image.tmp -o /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/bin/targets/ar71xx/generic/openwrt-ar71xx-generic-wrt160nl-squashfs-sysupgrade.bin
mjn3's trx replacement - v0.81.1
fread failure or file "/root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/root.squashfs-64k" too large
make[7]: [legacy-image-WRT160NL] Error 1 (ignored)
if [ -e "/root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/bin/targets/ar71xx/generic/openwrt-ar71xx-generic-zcn-1523h-2-8-squashfs-sysupgrade.bin" ]; then /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/staging_dir/host/bin/mkzcfw -B zcn-1523h-2-8 -k /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/tmp/vmlinux-zcn-1523h-2-8.uImage -r /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/root.squashfs-64k -o /root/Gargoyle/gargoyle-base_on_openwrt_remerge/ar71xx-src/bin/targets/ar71xx/generic/openwrt-ar71xx-generic-zcn-1523h-2-8-squashfs-factory.img; fi ; echo ""
[mkzcfw] *** error: rootfs image is too big
Hi I just wanted to ask if Gargoyle is going to moov to building on top of lede.
On the LEDE dev email list there is a email about the remirge of OpenWRT and LEDE. In the remirge it has bin agreed upon keeping the LEDE codebase and cherry picking any good bits from the OpenWRT trunk. The CC branch is getting a bit old in the tooth now. There is a fue advantages to updating the base of Gargoyle. Newer safer Kernel. Support of new devices Some new Wifi drivers will not build on older Kernels EG the driver for the WRT3200 ACM Make WI-FI faster code in the LEDE code base for ATH10 and ATH9 New ATH10 drivers for C7 and the like. Better builds on X86
LEDE is now on it's therd point relece due to be out in about 3 weeks and has prooven to be verry stable. All so I am hoping that the moov to a newer Kernel will aleveate some of the slow down that Gargoyle can have on verry fast connections.
I know it's not a simple thing to do so pleas don't think I am just having a winge lol but I would like to know what to say to people who mesage me asking about this because i am so simple to find on twitter and IRC I get asked stuff all the time about Gargoyle. Thanks