PureFusion - wrt3200acm, wrt32x, wrt1200ac, wrt1900acs, wrt1900acV1, wrt1900acV2 Builds

RaZi3L · 2021-08-08T16:12:51.729Z

I don't know how to help you either. My last compilation with your template is from August 5 and it works as expected. Why don't you try to generate the firmware with my repo and my wrt32x.config file? Just change the hw from menuconfig:

Firmware Version: OpenWrt SNAPSHOT r17263+9-46a65f927c / LuCI Master git-21.216.73469-39cc16d
Kernel Version: 5.10.54

I imagine you have checked the logs...

Eliminater74 · 2021-08-08T21:12:19.946Z

send me a link and ill check that out//

RaZi3L · 2021-08-08T21:22:55.943Z

GitHub

GitHub - ferboiar/wrt32x

Contribute to ferboiar/wrt32x development by creating an account on GitHub.

Eliminater74 · 2021-08-08T22:09:53.810Z

Problem SOLVED: https://forum.openwrt.org/t/building-snapshot-linksys-wrt3200acm-wifi-not-working/103274/8?u=eliminater74

Eliminater74 · 2021-08-10T04:31:57.842Z

Made a few changes to the GIT ACTIONS SCRIPTING BUILD:

removed the extra buildlog that is truly not needed if your building with logs enabled anyhow..
because it will have the build.log from there.. 2nd.. the extra make debug about Entering Directory and so on when it encounters first error, removed that because you only have 6 hours to build.. after 6 hours it will auto cancel everything and thats that.. leaving that in there doesnt help with debugging.. because no LOGS are ever uploaded for one to see.. If you want to ompile with debugging enabled you need to set it in config of action script.

env:
  FEEDS_CONF: feeds.conf.default
  DIY_P1_SH: diy-part1.sh
  DIY_P2_SH: diy-part2.sh
  BEFORE_BUILD: before_build.sh
  AFTER_BUILD: after_build.sh
  KERNEL_VERSION: kernel_version.sh
  EXT_INIT_ENV: environment.sh
  USE_FILES: true
  USE_DIYP2: true
  USE_PATCHES: true
  USE_DEVOPENWRT: true
  USE_COOLSNOWWOLF: true
  USE_SIRPDBOY: true
  ### ------------------------------------------------------------------ ###
  ## Disabling any of these will still build said section,
  ## Just wont be debugable showing. Enabling them will add,
  ## more time to final completion.
  BUILD_KMODS: true
  BUILD_PACKAGES: true
  INSTALL_PACKAGES: true
  INDEX_PACKAGES: true
  ### ------------------------------------------------------------------ ###
  DEBUG_COMPILE: false
  IGNORE_COMPILE: false
  KMODS: true
  ACL_LUCI: true
  GITLOGA: true
  GITLOGB: true
  RUN_BEFORE_BUILD: false
  RUN_AFTER_BUILD: false
  UPLOAD_BUILD_LOGS: true
  UPLOAD_PACKAGES: false
  UPLOAD_BIN_DIR: false
  UPLOAD_FIRMWARE: true
  UPLOAD_RELEASE: true
#############################
  UPLOAD_GOFILE: false
  UPLOAD_LITTERBOX: false
  UPLOAD_CATBOX: false
  UPLOAD_FILEIO: false
#############################

  TZ: America/New_York

Otherwise just compile normal. and if it fails you can download logs and find out what error then fix it.. and try again..

I removed the !canceled() from the upload BUILD_LOGS section so that it will upload regardless of cancel or not. Not sure its going to work as I expected but anyhow.. Worth a try.

I am also, slimming down the wrt3200acm.config Trying to remove fully not needed stuff.
and add in the missing stuff that is needed.

So there will be changes to the GITHUB Repo.

Also, if you forked it, you will most likely have to delete the FORK and refork it.
Sorry, I forced push a few times to fix some stuff, Only way for you to get my newest changes is to FORK a new copy...

RaZi3L · 2021-08-11T11:13:30.652Z

I think you already know, but it seems to me that something has broken when building the kmods:

Test CONFIG_DEBUG_VIRTUAL feature (TEST_DEBUG_VIRTUAL) [N/m/y/?] (NEW)
Error in reading or end of file.

make[6]: *** [scripts/kconfig/Makefile:71: syncconfig] Error 1
make[5]: *** [Makefile:603: syncconfig] Error 2
make[4]: *** [Makefile:712: include/config/auto.conf.cmd] Error 2
make[4]: Leaving directory '/workdir/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linux-5.10.56'
make[3]: *** [Makefile:20: /workdir/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linux-5.10.56/.modules] Error 2
make[3]: Leaving directory '/workdir/openwrt/target/linux/mvebu'
make[2]: *** [Makefile:11: compile] Error 2
make[2]: Leaving directory '/workdir/openwrt/target/linux'
time: target/linux/compile#25.38#8.34#30.09
ERROR: target/linux failed to build.
make[1]: *** [target/Makefile:25: target/linux/compile] Error 1
make[1]: Leaving directory '/workdir/openwrt'
make: *** [/workdir/openwrt/include/toplevel.mk:230: target/compile] Error 2
Error: Process completed with exit code 2.

Eliminater74 · 2021-08-11T11:38:13.000Z

It's from openwrt one of their commits causes the broken on perpus

Eliminater74 · 2021-08-11T11:39:14.000Z

This one https://github.com/openwrt/openwrt/commit/eaa9c94c75748265b9260691d5f59c9d3711f7d4

Eliminater74 · 2021-08-12T20:30:37.086Z

Anyone have any luck building firmware now? I still cant get past the fricken kmods now..

RaZi3L · 2021-08-13T06:03:02.659Z

no, same problem here

directnupe · 2021-08-13T09:08:50.571Z

Yo - the latest Kabuli Chan builds " borks " my Unbound Stubby GetDns setup. Can you leave the unbound package out of install image please ? I have no issues when I install unbound from online Openwrt snapshot repository. The error l get with preinstalled unbound package reads " segmentation fault ". This same error exists on Kong's builds which also feature preinstalled unbound package. Thanks and Peace

Eliminater74 · 2021-08-13T11:34:18.425Z

@ RaZi3L

I turned on Before_build.sh and added a git reset --hard HASH (which will reset before that one commit)
there are 2 other ways to tackle this issue. can also revert the commit.. but using git actions.. I am not
sure I can revert cleanly without it opening a editor on me........... Have yet to try that..
if it does.. there is way #2, Just clone it locally, then revert it.. then
git format-patch HEAD~
then add that patch to the patch dir in configs..

but either way.. I think its the stupidest merge I have ever seen anyone add to source.
Most people try to avoid errors and so on, Not openwrt.. bent on creating errors.

I understand what they are trying to do, but what I dont understand is this, Finish the full patch of configs before adding that one commit that is bent on ruining everyone's day...........

they kinda went backwords on this merge.

Eliminater74 · 2021-08-13T11:43:46.911Z

Now reply to your comment.. I wish this forums allowed multi reply backs.. anyhow.
Yes.. I will keep that in mind. right now I was just trying to get past the issue we had above.. and testing things out.. Thank you for your feedback.. I will adjust the config accordingly... When I get the time to
do so.. Still but no big deal.. I will see what I can do on that..

btw, Most likely all the prebuilt unbond packages are failing because we devs think
compiling with the latest greatest GCC makes that big of a different. In fact, it only
introduces more problems 90% of the time.............

OpenWRT always compiles with GCC 8.x.x and cant remember what bin utils they use..
but they always go for stable..
just because something compiles doesnt mean it will work as intended.........

I been down this road many times when I was building Nebula Kernel back in the days under my
LG G3, I learned alot that year............

Not to mention I created a whole Android OS from scratch pretty much.. and learned alot about compiling under many diff ways........... even with Clang.. Took me long time to learn to use the clang to compile.. and Wow that made a big Diff............

So yes this is a road I have been down before.. but dont get me wrong.. The devs out there are awesome for OpenWRT buils.. Specially KONG, I know his work well.. one of the top best there is..
and you know hes from the DD-WRT days...........

RaZi3L · 2021-08-13T11:56:02.696Z

I do not know if it is worth doing all that right now, I would wait until monday to see if they answer in the thread, it is not normal so many builds with compilation problems ...

Eliminater74 · 2021-08-13T12:00:43.398Z

my last 3 builds worked perfectly. by doing that I said above.. and it works.. easy as ABC.. not alot..
Just had to turn on the script then add the git revert --no-edit and HASH commit.

now it works.

to be honest, I only tested the git reset --hard HASH commit way..
the git revert --no-edit HASH commit is a new way im testing now.. but should by all means work.

Eliminater74 · 2021-08-13T12:42:42.371Z

I guess it worked:

Run chmod +x scripts/$BEFORE_BUILD
Removing target/linux/generic/hack-5.4/205-kconfig-exit.patch
Removing target/linux/generic/hack-5.10/205-kconfig-exit.patch
[master 3115873767] Revert "generic: Kconfig: exit on unset symbol"
 Date: Fri Aug 13 08:04:39 2021 -0400
 3 files changed, 23 deletions(-)
 delete mode 100644 target/linux/generic/hack-5.10/205-kconfig-exit.patch
 delete mode 100644 target/linux/generic/hack-5.4/205-kconfig-exit.patch

anomeome · 2021-08-13T15:00:16.800Z

@Eliminater74 , I am not seeing any issue compiling from the OpenWrt master, the issue appears to be occurring because whatever it is that is being built in this thread has created an unset Kconfig. I would suggest the better solution would be to just set the Kconfig by adding a file

target/linux/mvebu/cortexa9/cconfig-5.10

that sets the Kconfig being complained about.

@directnupe I do not use stubby, but I am seeing no segfauilt with unbound which I do have in play.

Eliminater74 · 2021-08-13T20:07:14.462Z

yeah but I would still need to know what needs to be placed in the config.. I really have no clue, because when build fails.. my logs do not makeup.. I guess I could ssh into the VM and see for my self that way..
I know you build same devices, what do you use?

PS: guess I could run make kernel_menuconfig w/subtarget and run the configs.. then use that as a patch.

anomeome · 2021-08-14T00:44:28.502Z

As stated, this is not happening for me on master (and I assume no one else, or there would be some voices), from the above I took is to be something to do with:

Summary

/home/kc/wrtpac/source/target$ grep -r DEBUG_VIRTUAL
linux/bcm53xx/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/x86/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/oxnas/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/oxnas/config-5.10:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/mxs/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/apm821xx/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/omap/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/gemini/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/ipq807x/config-default:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/at91/sam9x/config-default:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/at91/sama5/config-default:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/mediatek/mt7629/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/generic/config-5.4:# CONFIG_DEBUG_VIRTUAL is not set
linux/generic/config-5.10:# CONFIG_DEBUG_VIRTUAL is not set
linux/sunxi/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/octeontx/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
linux/zynq/config-5.4:CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y

so maybe from the the generic

# CONFIG_DEBUG_VIRTUAL is not set

but I really do not know as I am not encountering said issue.

directnupe · 2021-08-14T02:06:14.731Z

Dear Eliminater74,
Hello and thanks for the update about the fix for the UNBOUND issue - here is my tutorial DNS Privacy aka DNS OVER TLS - I just installed PureFusion r17328+10 20210813 aka 2021.08.13-1046 Now first - thanks and kudos for getting the factory image down to size where it will flash with no issues due to being oversized. However, the 5GHZ radio does not come up for me at all. This may be due to the fact that I am attempting to connect using my Android devices. I read somewhere in these forum threads that there may be some issues with Android connecting to router. It may be in the DivestedWRT thread. Anyway, this is the first time I ever had this problem occur on any of your builds. I will look forward towards the next build and see if the 5GHZ radio persists. Peace and I am out

Edit :
I am running latest DivestedWRT right now and 5GHZ runs without issue with Android clients - so I do not know what to make of this. However, thanks for your overall great builds and do please keep up the outstanding work on OpenWRT