This is in followup to a missing patch for Mikrotik RB951g-2HnD, even though the patch has been around for > 3 years now:
I can perfectly compile some 18.06 image (initramfs/upgrade) and install, but when i do this, i can not install to me important packages, e.g.: openconnect:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for open:
* kernel (= 4.9.156-1-a700eaaf37477917a70a15d0be2dbf1e)
* opkg_install_cmd: Cannot install package openconnect.
How would i fix that ?
IMHO, the easiest solution is to simply create a patched version of the released 18.06.x version, but i have no idea how 18.06.2 was compiled. What i did is this:
git clone -b v18.06.2 https://www.github.com/openwrt/openwrt
wget https://downloads.openwrt.org/releases/18.06.2/targets/ar71xx/mikrotik/config.seed
cd openwrt
./scripts/feeds update -a
./scripts/feeds install -a
make defconfig ; make oldconfig
cp ../config.seed .config
make menuconfig # and save
make download
make -j12
Unfortunately, the final make runs into:
src-18.06.2/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/jool-9dfaf22e49f7905d94af9b73f9bee22c26d7dd4a/mod/stateful/fragment_db.c:96:14: error: 'INETFRAGS_HASHSZ' undeclared (first use in this function); did you mean 'INET_FRAG_LAST_IN'?
return c & (INETFRAGS_HASHSZ - 1);
^~~~~~~~~~~~~~~~
INET_FRAG_LAST_IN
How is this possible ? sigh
But anyhow. How coul i best get the patch committed so that RB951g-2HnD finally works from the next posted (fix-)release ?
Has, for me, almost always been successful. Beware of switching branches or significant jumps in time. I usually remove the entire build_dir in those cases.
Is jool an “official” package? If so, is it available in the package repo, to check build sanity?
I am a total novice on the structure of OpenWrt. i only gave the commands shown, so i would be surprised that a non-official package would show up. But i have no idea to figure out what's official and what not.
By selecting the exact config from buildbot config.seed, you selected to build ALL packages, also all non-mandatory add-on packages like jool.
Buildbot has no special config, except that it builds all kernel packages and all user-space packages.
You should do:
make clean
delete .config file
make menuconfig
(and select your device and include LuCI package for GUI and all other packages that you need)
make
Then you simply get the firmware for your device, and it includes the packages that you need.
It is difficult to install add-on kernel packages to private builds, or self-compiled kernel package to official builds. There is strict checksumming to prevent config mismatches.
Where would i find a more detailled explanation of the checksum mechanism ?
Any way to still install openwrt without overlay to make it easier to simply compile on the system a new kernel (like many other linux systems do it ?)
I agree that i don't need the problematic package, i just tried to compile the same as release image. Still wonder though why compilation fails for me but not in automated release build.
Like I said, you should compile your own personal firmware from the modified sources and include all needed packages in it. Installing kmods from the release repo into a private build is not advisable, and vice versa.
For a long list of reasons, starting with flash wear and not enough RAM, you can’t build or compile anything of any significant complexity on an OpenWrt box. For any architecture that on-device building is feasible that I can think of, there are other Linux-based distros that are more suitable.
phase1 buildbot builds just the core system and core packages, creates the firmware images, and compiles SDK.
So, extra add-on packages do not disturb core compilation & firmware generation
phase2 buildbot the uses the SDK created in phase1 to compile the add-on packages like jool. Failures of a single package here are ignored.
When you try to compile everything at once, the failing packages cause more disturbance. Normally nobody tries to compile all extra packages (including e.g. several VoIP telephone exchange variants)...
Can you outline how i would manually repeat that process ? Aka: whats the list of "core" packages (certainly not what was in config.see ?), and how would i do the second stage compile then ? And do i have a chance to put those second stage compiled packages into a place where my openwrt would pick them from when i use opkg ?
There is no need for that. That logic is needed for a general build-all buidlbot compilation.
When you compile for a single device, just start from empty config and select the device. That will select the needed packages. Additionally, select LuCI so that you have GUI, and possible other packages that you want.
(Also release builds are practically just device+LuCI.)
It depends by the device.
First build the plain firmware, then in the build binary directory you can find also a "manifest" file listing all included packages.
Please familiarize yourself at least a bit to the build system, before you try making patches and changes. First compile a vanilla firmware and learn the process and examine the produced files in bin/target/... directory.
jeff: my mikrotik routers have been running chaos chalmers forever, primarily also because of the imability to easily upgrade in the face of a patch required for the kernel that did not get included into OpenWrt for year. i still didn't get any answer of how to get this patch included into openwrt either, even though i raised this question in this thread sigh.
So, i am trying to understand how to most easilty run with self compiled kernels. Which seems difficult.
As much as i like the mikrotik routers, i may just want to push getting the patch committed to help others. For myself, i had to conclude that they are not sufficient anymore because i need IPsec/OpenVPN/HTTPs and now got 300 Mbps FTTH so i'll have to move to x86/AES-NI CPU.
What would be a better distro than OpenWrt for x86 ? I want the simplicity coming through LuCi and the ability to leverage all the setup/config recipes posted on OpenWRT wiki. To the best of my knowledge any other distro would not give me LuCi and its management benefits.
I would put debian for development into a separate partition and run debian via chroot as the development environment.