Divested-WRT: No-nonsense Linksys WRT builds

@digital_mystik

88W8864 is for WRT1900* and WRT1200AC
88W8964 is for WRT3200ACM and WRT32X
see the table here

1 Like

Sounds good, thanks.. looks like I accidentally picked the right one then haha

I just wonder how asking about the inclusion of a VPN solution on these builds became such an outrageous request. I do realize that these builds are nominally marked No-nonsense Linksys WRT builds However, to my knowledge - I have never known of any OpenWRT build where OpenVPN is not only not available - but God forgive if a body asks why or not not - then that person is publicly subject to derision. I came from Davidc502 OpenWrt Snapshots where I was for three to four years. Forgive me, but there - the ethos was one of community give and take. So, forgive me for assuming that there would be a similar atmosphere here. As a rule it would be best if the developer - in this case SkewedZeppelin
to answer questions which are posed to him directly. This would go a long way towards maintaining order and limiting rancor. I hope that these observations are deemed appropriate by whomever are the powers that be here on this Community thread.

1 Like

@directnupe
There is nothing wrong with asking questions.
I encourage people to ask about things they aren't fully sure about.
It is the only way we can truly learn.
Asking the same question over and over however is not reasonable, please don't do it.

--

These are ultimately built to my needs.
I already invested my resources (time, experience, compute) into making them.
Why not spend some more (time, hosting) and make them available for others?
That is what I chose to do.

If they don't meet your needs, I even made basic documentation and a video that details how to make customizations.

And there are also others providing images for these devices.

--

I see no reason to further devolve or meander about silly things like this.
I do not tolerate drama like this.
It is unacceptable and eats up all of our resources.

1 Like

I truly appreciate your thoughtful reply. I watched your video - thanks for that. By asking you about OpenVPN - a fellow member of this community was kind enough to modify your build along with components from hnyman;s build for WRT3200ACM - which includes OpenVPN. Personally, I am not the most skilled or knowledgeable OpenWRT firmware builder. So, I was trying to learn why you found the inclusion of OpenVPN to be so antithetical to your philosophy and / technical requirements. That was all. So, in ending - I do want to thank you for all you to advance the continued support of these WRT routers - it is much appreciated.

1 Like

@SkewedZeppelin

I see your change log has mention of something being resized: reference.

EDIT: I see references here: Increasing mamba and venom kernel partition to 6MB

I've also noticed your /patches directory is no longer visable on your webpage, but I do see them in your github repo: Divested-WRT/patches at master · divestedcg/Divested-WRT · GitHub

Which is authoritative?

@lamelogin
Seems I forgot to chmod /patches.
I try to keep the webserver directory in sync with the git repo.
If they aren't I either am in the process of copying or forgot to copy or forgot to fix permissions.

As for the resizing, that is still undecided.
Resizing is not needed for these current 5.4 based builds.
But will be needed for 5.10.
I can either switch to resized builds now, and you all will need to migrate if you are using a mamba/venom.
Or I can hold off until 5.10.
Switching now does let me add a few more things (like WireGuard) comfortably.

For migrating to resize builds:

  • check for compatibility first using the commands on the webpage
  • backup
  • flash the corresponding factory image via sysupgrade. make sure force is checked and keep settings is unchecked
  • restore your backup

I do not recommend you switch to them just yet. Like I said, still undecided to switch now or wait til 5.10.

As for the migration from resized builds: compatibility is unchanged with stock or other OpenWrt builds provided you use the factory images to flash and not the sysupgrade ones, and you do not keep settings if flashing via sysupgrade.

2 Likes

Hi @SkewedZeppelin that's awesome news! I see:
20210206-00-RESIZED
- resize mamba from 3MB to 4MB

then:
20210206-01-RESIZED
...
- kernel size still only 2.92MB
- Resized! Use with caution!

Is 2.92MB for mamba, and are we limited to 4MB kernel partition for now due to uncertainty surrounding whether its bootloader is able to cope with 6MB instead?

@wally_walrus

So as @slh pointed out mamba uboot will load up to 4MB without any changes.
We also found out that venom uboot will load up to 6MB without any changes.

All of them share the same kernel, so the cap is the lowest common value unless the builder (in this case me) wants to maintain two sets of builds.

This is currently 3MB.

But with the patch to increase mamba to 4MB and venom to 6MB that becomes 4MB.

An extra megabyte is more then enough for now.
My kernels are only 2.92MB.
I want to add SELinux in the future, that is about 200KB.
The bump to 5.10 is also another 200KB or so.
That still leaves over 500KB left afterwards which should be more then enough for now.
If needed another 500KB can be freed by disabling -O2 (optimize for perf) and switching back to -OS (optimize for size).

It should be possible to bring mamba to 6MB if really needed in the future, however it complicates the migration process, reduces backwards compatibility, and adds more chance of brick (and having to be recovered over serial).

3 Likes

A note re. WG, it builds fine for me on 5.4.x kernel with no size issues. But, WG does not build at all with 5.10.x, it appears to just be the backported compatibility module, so might just be a simple Makefile change. There are a couple of other, not too important, gotcha's with 5.10.x.

2 Likes

@SkewedZeppelin, Re: switch now or later... Is the hesitation due to having to submit the resizing patch twice - ie both to 5.4 as well as 5.10 (thus more work for you)?

Firstly I want to say thank you for these builds I have been using them for around a week after making the move to DSA. I have both a wrt32x and wrt1900acs. Your builds have brought back my 1900acs into service! I had given up on this router 18 months ago as had nothing but problems with the stock firmware and openwrt builds.

A question about your resized builds. Can you or has anyone tried flashing these from the stock linksys firmware?

Cheers.

@wally_walrus
The patch is trivial.
I've already migrated my mamba to it, I don't mind migrating back and waiting til 5.10.
It is more up to you all if you want me to stick to normal or resized builds, as ultimately you all have to migrate. Longterm, you will have to migrate, unless you want to throw your router away.

@larrynz
awesome!
I have not tested flashing the resized ones from stock. They are likely to work, but are indeed untested.

@ everyone else

Migrate mamba and venom to resized builds...
  • right now
  • when 5.10 is released

0 voters

@SkewedZeppelin so I'll be the 1st to vote... Bring the resized builds now :grinning:

Short term pain for long term gain!

2 Likes

Ansible playbook to automate the build process if it helps anyone..


- name:  "Build OpenWRT from SRC"
  hosts:  localhost
  gather_facts: yes
  vars:
    src_path: "/home/testing"
    git_url:
      - { url: "https://git.openwrt.org/openwrt/openwrt.git", path: "{{ src_path}}/openwrt" }
      - { url: "https://github.com/divestedcg/Divested-WRT.git", path: "{{ src_path}}/patch" }
    space_check: "20G"

  tasks:

  - name: "Ensure you're on a RedHat distrobution"
    assert:
      that:
        - ansible_os_family == "RedHat"

  - name: "Ensure the Pre-REQs are installed:  https://openwrt.org/docs/guide-developer/build-system/install-buildsystem"
    yum:
      name:
        - bash-completion
        - bzip2
        - gcc
        - gcc-c++
        - git
        - make
        - ncurses-devel
        - patch
        - perl-Data-Dumper
        - perl-Thread-Queue
        - python2
        - python3
        - rsync
        - tar
        - unzip
        - wget
        - perl-base
        - perl-File-Compare
        - perl-File-Copy
        - perl-FindBin
        - diffutils
        - which
      state: latest
      validate_certs: no
      lock_timeout: 180
    become: yes
    become_user: root

  - name: "GIT Clone - {{ git_url }}"
    git:
      repo: "{{ item.url }}"
      dest: "{{ item.path }}"
    with_items: "{{ git_url }}"

  - name: "git config pull.rebase true"
    command: "git config pull.rebase true"
    args:
      chdir: "{{ item.path }}"
    with_items: "{{ git_url }}"

  - name: "Update Feeds - update"
    command: "{{ item.path }}/scripts/feeds update -a -f"
    args:
      chdir: "{{ item.path }}"
      removes: "{{ item.path }}/scripts/feeds"
    with_items: "{{ git_url }}"

  - name: "Update Feeds - install"
    command: "{{ item.path }}/scripts/feeds install -a -f"
    args:
      chdir: "{{ item.path }}"
      removes: "{{ item.path }}/scripts/feeds"
    with_items: "{{ git_url }}"

  - name: "Identify which config file to use in {{ git_url[1].path }}"
    find:
      paths: "{{ git_url[1].path }}"
      file_type: file
      patterns: "config"
      contains: ".*mvebu.*"
      recurse: yes
    register: files_matched

  - name: "Copy config file from {{ files_matched.files[-1].path }} to {{ git_url[0].path }}/.config"
    copy:
     src: "{{ files_matched.files[-1].path }}"
     dest: "{{ git_url[0].path }}/.config"

  - name: "make defconfig && make clean"
    shell: "make defconfig && make clean"
    args:
      chdir: "{{ item.path }}"
      removes: "{{ item.path }}/scripts/feeds"
    with_items: "{{ git_url }}"

  - name: "make download -j{{ ansible_processor_vcpus }}"
    command: "make download -j{{ ansible_processor_vcpus }}"
    args:
      chdir: "{{ item.path }}"
      removes: "{{ item.path }}/scripts/feeds"
    with_items: "{{ git_url }}"

  - name: "make -j{{ ansible_processor_vcpus }}"
    command: "make -j{{ ansible_processor_vcpus }}"
    args:
      chdir: "{{ item.path }}"
      removes: "{{ item.path }}/scripts/feeds"
    with_items: "{{ git_url }}"
3 Likes

@lamelogin
That is awesome!
but it misses the step to apply the patches? :upside_down_face:

Very nice, i am completely out of the loop so now going to google Ansible playbook.
However using bash scripting for me is my thing.

But as @SkewedZeppelin pointed out no patch applying is happening in that.

@SkewedZeppelin my vote is in with the same opinion as @wally_walrus. So long there is a warning/readme of how to do it, it should be fine.

Hi @SkewedZeppelin sorry I need to ask this after voting for the change :slight_smile: My previous method of upgrading was:

  • boot the alternate / OEM (yes I kept the Linksys factory image on the 1st partition)
  • flash your “factory” image from there
  • reboot into OpenWRT on the 2nd partition
  • restore config.

Now with a resized kernel partition, it means I won’t be able to return to OEM by simply rebooting into the 1st partition due to the mismatched size in UBoot env variables. Is my understanding correct here?

So what this means, is I’ll have to change my strategy... I should be able to use my previous method ONCE but from then on will have to always flash your newer build straight from the currently running your previous build / partition. No biggie, I know this is how most folks upgrade their WRTs I just needed to confirm my thinking

Many thanks,

1 Like

@wally_walrus

This patch as it is should not break that process/compatibility.
As uboot wasn't touched

OK, I probably used the term “partition” as in “OEM partition” or “OpenWRT partition” somewhat loosely to refer to each half of the Flash memory on these devices as managed by uBoot.

If I may try and explain the process in my own words - resizing the kernel “partition” is literally changing a few uBoot environment variables, and there is one set of these variables for the “primary partition” (OEM) and another set for the “alternate partition” (OpenWRT). So every time uBoot starts it looks at the Primary/Alternate flag and depending on its value it uses either the “primary set” or the “alternate set” of env variables but they are totally independent and uBoot can start either a kernel in a 3M partition (when booting OEM) or another kernel in a 4M partition (when booting OpenWRT).

So that’s why I can still keep an OEM “partition” and follow the same update method

Thanks @SkewedZeppelin for forcing me to think this through