Dear Pesa,
Just saw that you updated 24.10.mtk.next-r1.0.0
Wondering if we can use this to compile a Build at this time ?
No big deal - just curious to try this new branch is all.
Thanks for all your great work
Peace
1 Like
please wait guys I'll let you know when
it's still on testing
7 Likes
Howdy, been lurking in this thread for a long while. I've been bashing my head for a couple days now try getting _FailSafe's container to compile r4.3.6 successfully using pesa1234's default .config. I think I finally got it working after tweaking a fair amount of the prescribed procedure. It's still compiling but hasn't errored out yet which is a good sign so I'm gonna share what I found.
First thing is the container build environment set out in _FailSafe's Dockerfile is missing a key dependency, zstd. The compile would fail at the "make download" stage when it would try to compile the "linux-firmware-20241019" package without zstd. Granted pesa1234 doesn't have this dependency listed in his OP either. In my troubleshooting also I added all the missing dependencies listed in the OP into _FailSafe's Dockerfile. If and when my current compile succeeds I'll do more fiddling on what actually needs to be added.
Next thing is the order of operations described in _Failsafe's container documentation and scripts is a bit out of sorts. "setup_pesa1234_repo.sh" downloads the default .config and adds that missing bit. The next step you are told to do is update and install the feeds. This overwrites the .config the setup script just made. The default .config should be downloaded and fixed after running the feeds scripts.
Annnnd the compile succeeded as I was typing this. Just flashed it to my router and it took. Restored my settings and at first blush nothing is obviously broken. Thanks to _FailSafe and pesa1234 for doing the hard work. I just bumbled around through a lot of console logs.
Thank you my Brother - In my older days I have learned that " Patience is truly a virtue "
God Bless Always In Peace
1 Like
@pesa1234 sorry for q in case it's obvious - this branch (your builds) contain some backports patches specific to this device (and its chipset family) - are these exclusive to your builds or do they also go in 24 main?
I'm throwing up my end Dockerfile which was just tweaked from _Failsafe's original Dockerfile. I've now compiled r4.3.6 from fresh build environments (nuking the container volume and rebuilding the container image) a few times now with no errors of note. The changes are as follows:
-
Changed base image from Ubuntu 23.10 to 22.04 as 22.04 is recommended in the OP and 22.04 has well defined prerequisites in OpenWRT's documentation.
-
Added gcc-multilib and g++-multilib as was missing from OpenWRT's prerequisite list for Ubuntu 22.04
-
Changed libncurses5-dev to libncurses-dev as above
-
Added llvm as was missing from OP's prerequisite list
-
Added zstd as was needed from my own compile failures
For the time being I recommend forgoing using the setup script that is used to pull pesa1234's repo and manually running all commands once inside the container.
# Copyright (C) 2024 Mark Baker <mark@vpost.net>
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <https://www.gnu.org/licenses/>.
FROM ubuntu:22.04
ARG DEBIAN_FRONTEND="noninteractive"
ARG GO_VERSION=1.22.5
ENV TZ="America/New_York"
ENV USER="user"
ARG USER_HOME="/home/$USER"
# Install build base
RUN apt-get update \
&& apt-get upgrade -y \
&& apt-get install -y --no-install-recommends \
bison \
build-essential \
ca-certificates \
clang \
cmake \
curl \
file \
flex \
g++ \
gcc-multilib \
g++-multilib \
gawk \
gettext \
git \
gnupg \
less \
libelf-dev \
libfdt-dev \
libncurses-dev \
libssl-dev \
llvm \
lsb-release \
nano \
ncdu \
openssh-client \
python3-distutils \
python3-setuptools \
quilt \
rsync \
software-properties-common \
squashfs-tools \
sudo \
swig \
tree \
tzdata \
unzip \
vim \
wget \
zip \
zlib1g-dev \
zstd \
&& rm -rf /var/lib/apt/lists/*
RUN wget --ca-directory=/etc/ssl/certs/ https://go.dev/dl/go${GO_VERSION}.linux-arm64.tar.gz \
&& tar -C /usr/local -xzf go${GO_VERSION}.linux-arm64.tar.gz \
&& rm -f go${GO_VERSION}.linux-arm64.tar.gz
ENV PATH=$PATH:/usr/local/go/bin
RUN bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)"
RUN llvm_host_path="/usr/lib/$(ls /usr/lib/ | grep llvm | sort -r | head -1 | cut -d' ' -f11)" \
&& echo "export LLVM_HOST_PATH=$llvm_host_path" >> /etc/bash.bashrc
RUN useradd -m $USER \
&& echo "${USER} ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/${USER} \
&& chown -R $USER:$USER "$USER_HOME" \
&& chmod g+s "$USER_HOME"
COPY ./assets/quiltrc "$USER_HOME/.quiltrc"
COPY ./assets/gitconfig "$USER_HOME/.gitconfig"
COPY ./assets/setup_pesa1234_repo.sh /tmp/setup_pesa1234_repo.sh
RUN chmod +x "/tmp/setup_pesa1234_repo.sh"
USER user
WORKDIR /home/user/openwrt
CMD ["bash"]
1 Like
Welcome to the Openwrt community!
Im not an advanced user on building openwrt images, but, i think the main difference is that you use ubuntu and the configuration shared by Failsafe is for MacOS.
In my case, using macos 0 issues out of the box compiling pesa1234 builds.
BR
90% of them are device specific.
Some like these can be for every device, :
Hmm - those patches tell me that those limits should be configurable somehow. But that's a challenge for another day.
Although the device specific patches: are those planned to get merged to main after we have guinea-pigged them?
1 Like
I think you might have misunderstood how Failsafe's container works. I'm on a Windows machine. Failsafe has written a Dockerfile (a recipe on how to build a new docker container image) along with some scripts that creates a Docker container that serves as an OpenWRT build environment. At the risk of being called reductive, a docker container is essentially a fancy virtual machine. When you use Failsafe's container you are actually using Ubuntu. It's just containerized in your machine.
A given Docker container image should create an identical container (think virtual machine) no matter where you run it. Now, something obviously has failed to translate/be generalized otherwise the container would have worked on the first go with me on Windows since it sounds like MacOS users have had no issues. Maybe it has something to do with Docker Desktop hooking into WSL2 on my side? Maybe we are actually building slightly different Docker images given the same Dockerfile on different OS's/Docker environments. Dunno enough about how the Docker Engine works. Much less Docker Desktop. If I understand right Docker Desktop by design spins up a Linux VM (Or uses WSL2 if on Windows) just to run the Docker Engine on top that VM's kernel. When you are already in a Linux environment you can just not use Docker Desktop and go straight to using the Docker Engine.
In any case, all I know is the changes I made to the Dockerfile now results in a container that works for me, using Docker Desktop on Windows 10 using WSL2.
I'd be interested in hearing from MacOS users if my tweaks now break compiling on their machines and how native Linux users using Docker are faring.
1 Like
I suspect it might come down to the CPU architecture. On Apple Sillicon you'd get an aarch64 container, but on Windows it's probably amd64. You need *multilib to be able to compile for ARM on amd64, but not on aarch64.
3 Likes
They are, for example:
for phy in $(find /sys/kernel -name 'phy[0-9]'); do
(cd $phy
l=1500
h=8000
echo 0 $l $h > "$phy/aql_txq_limit"
echo 1 $l $h > "$phy/aql_txq_limit"
echo 2 $l $h > "$phy/aql_txq_limit"
echo 3 $l $h > "$phy/aql_txq_limit"
echo 12000 > "$phy/aql_threshold"
# Increase the FQ-CoDel buffer
echo "fq_limit 8192" > "$phy/aqm"
echo "fq_quantum 256" > "$phy/aqm"
echo "fq_memory_limit 67108864" > "$phy/aqm"
);
done
You can dump more tunables @
grep . /sys/kernel/debug/ieee80211/phy*/*
2 Likes
What would this look like if simply added to rc.local? I have the AQL l/h limits added in there, and would like to add aql_threshold as well.
I have edited my post to show the version that I am using on my "Local Startup" on SNAPSHOT.
Kudos to Pesa and others on tuning these values empirically. It is good the tunables are there for us to use regardless of build.
there's been some questions about GL-Inet's u-boot source...
5 Likes
Ah, thanks. A patch file is likely simpler to implement. Your script is an illustrative POC. Might make sense to have something more modular so it would correctly apply only to specified devices, similarly to how devices set stuff like lan ports in a script in the rom today.
Maybe instead of cd in the script, use pushd and popd. Seems cleaner for the environment 
1 Like
What might this new u-boot open up that we don't already have? UBI? Not like we're short on space or anything. (aside from the obvious secure boot)
This u-boot drop is from GL-Inet directly to allay concerns about potential backdoors...
Folks can review and comment...
given that these days there are some geopolitics that unfortunately do involve even communities that support free and open software...
3 Likes
@pesa1234 hi, please give us the updated link for openwrt_core updates, the old one was: "src/gz openwrt_core https://raw.githubusercontent.com/pesa1234/MT6000_cust_build/refs/heads/main/2024.10.11_r27835_6.6.56_next-r4.3.3.mtk/targets/mediatek/filogic/packages"
What we should do on 6.6 shapshots builds with taking into account the following news " The APK package manager is now the default package manager in OpenWrt main."