Ucode Openwrt

[Giacometta Fritchman]

Largeparts of LuCI have been moved to client side rendering throughout the last few years leaving mostly request routing (dispatcher) as well as ubus request gateway functionality and a few assorted template rendering and session management tasks on router side.

The Lua parts required to retain compatibility with older LuCI apps or apps that already do client side rendering but still rely on Lua code in the backend (e.g. for custom controllers or rpcd exec plugins) were factored out into a new luci-lua-runtime package.

Storage footprint - since 22.03 now ships with two scripting languages (Lua and ucode) by default I wanted to eliminate the use of Lua in the default images at least to gain back some previously lost space. In early tests here the complete removal of Lua and related libraries saved about 120KB on the x86/64 rootfs after gzip compression.

LuCI is stuck on an outdated version 5.1 of Lua and upgrading to the latest version would require significant refactoring of the code, so I figured I could as well spend the extra effort to port it entirely to another environment.

Simpler implementation - since ucode has several required functionalities directly built in, mainly templating and JSON support as well as uci, ubus, uloop and filesystem bindings, we require less extra libraries to achieve the same result. Another hope is that the closely JavaScript related syntax will make the code more accessible to future contributors

Hopefully none LuCI should function just as before. It should behave and look the same but with a smaller storage footprint. It should also seamlessly support existing LuCI applications still using Lua through the optional luci-lua-runtime package.

Once I got some wider testing coverage and can assert the stability of the implementation I would proceed with merging the rewrite into LuCI mainline and start with converting remaining LuCI application Lua code, beginning with the most popular applications.

Once merged, I will also start working on LuCI precompilation support which allows compiling plain ucode sources to packed bytecode at build time. This speeds up the application startup times and further reduces required storage footprint.

E.g. luci-app-ddns was converted to JS by @Ansuel in 2019, but the JS implementation kept the practice of fetching the ddns-scripts package version via an ipkg call. Not sure if that info (ddns version is 2.8.2-26) is actually needed.

Yeah, the logic is quite naive atm, it simply checks if there's a luasrc/ directory in a package. If there is, a dependency on luci-lua-runtime is added. Independently of this LuCI ucode rewrite we could already start converting rpcd backend scripts to ucode or shell (whatever is preferred).

Once I got it working again I thought it would be nice to post how I resolved it so that the next person hopefully finds something a bit more useful than "just factory reset" when they have the same problem. Good luck, unknown future person!

luci-error1668671 18.9 KB

Same exact error for me on ramips/mt7621 platform after using attended sysupgrade to 23.05-rc4. Also in order to fix this you don't need to install uhttpd, stuff that fixes this error is in luci-compat package so for the fix opkg install luci-compat is sufficient and you don't have that uhttpd tab in luci in the end.

Installing only luci-app-uhttpd didn't work for me as OP suggested. I did something similar like @adworacz did. I removed some package and I kept "Automatically remove unused dependencies" checked while doing it. That might have removed essential packages for luci.

heh i did this to myself a few weeks ago removing a luci theme i was trying, then again today removing a bunch of unbound packages. killed everything lol. so i swapped to my backup flash card and flashed my main lol...

I also just ran into this issue after removing packages for unbound (including luci-app-unbound, which has luci-compat as a dependency) along with [x] Automatically remove unused dependencies. I found this thread after running a few remove/install combinations on my own and getting nowhere. [SOLVED] I fixed it as OP @iacvlvs did with opkg install luci-app-uhttpd and that fixed it for me.

I was unable to recreate the issue. I tried removing luci-app-uhttpd... no luci.ucodebridge error. Tried removing luci-compat... still no error. Tried reinstalling the unbound packages I had before and removing them as I did before (though I didn't run any of the setup on the unbound stuff)... still no error. So I'm still not sure what did it but I'd have to assume removing my unbound packages happened to remove some config file or package that the luci admin console thing required.

Thanks @szero . I discovered this issue today when attemting to login to my Edgerouter X to perform a sysupgrade to v23.05.3. Not sure what caused it since it was working find 71 days ago (uptime). I may have removed a package via cli at some point ... hard to remember!

From a user-experience perspective it is egregiously bad to have a package-maintenance activity (such as uninstalling an unrelated package) completely BREAK basic administrative functionality on a device.

For example, in OPNsense & pfsense there are default "anti-lockout" firewall rules that are hard to disable, to prevent people from accidentally cutting off their own https & SSH administrative access to their own routers.

The ucode language is a tiny general purpose scripting language featuring a syntax closely resembling ECMAScript. It can be used in a stand-alone manner by using the ucode command line interpreter or embedded into host applications by linking libucode and utilizing its C language API. Additionally, ucode can be invoked in template mode where control flow and expression logic statements are embedded in Jinja-like markup blocks.

Besides aiming for small size, the major design goals of ucode are the ability to trivially read and write JSON data, good embeddability into C applications, template capabilities for output formatting, extensiblity through loadable native extension modules and a straightforward set of built-in functions mimicking those found in the Perl 5 language.

In spring 2021 it has been decided to rewrite the OpenWrt firewall framework on top of nftables with the goal to replace the then current C application with a kind of preprocessor generating nftables rulesets using a set of templates instead of relying on built-in hardcoded rules like its predecessor.

That decision spurred the development of ucode, initially meant to be a simple template processor solely for the OpenWrt nftables firewall but quickly evolving into a general purpose scripting language suitable for a wider range of system scripting tasks.

Despite OpenWrt predominantly relying on POSIX shell and Lua as system scripting languages already, a new solution was needed to accomodate the needs of the new firewall implementation; mainly the ability to efficiently deal with JSON data and complex data structures such as arrays and dictionaries and the ability to closely interface with OpenWrt's ubus message bus system.

The ucode repository contains build recipes for Debian packages, to build .deb packages for local installation, first install required development packages, then clone the repository and invoke dpkg-buildpackage to produce the binary package files:

All is working very good but I have no wlan interface, when I use "ifconfig" I get an br-lan, eth0 and lo interface. No wlan0. The same by "iwconfig".

So I started to google and get a hint for a "iwlwifi" driver and firmware. I put the firmware file ("iwlwifi-5000-1.ucode") into the folder /lib/firmware, but it won't work. So I think about it and get the conclusion the driver is still missing, with google I founded a package called "backports" wich includes the driver. To use this package I need "make" so I installed "make" on OpenWRT and try it, but I get 127 error's so I cannot install the driver.

k, makes sense then, but the OpenWrt default x86 build doesn't boot. Not sure how to get it going, I installed it to an internal SATA and external USB using dd if=image of=/dev/sdX but neither wanted to boot past grub. Would really like to turn my brick laptop to something useful.

Any ideas which wireless card I should buy to get the full set of possible features?

Processor manufacturers release stability and security updates to the processor microcode. These updates provide bug fixes that can be critical to the stability of your system. Without them, you may experience spurious crashes or unexpected system halts that can be difficult to track down.

All users with an AMD or Intel CPU should install the microcode updates to ensure system stability. In virtual machines and containers, the microcode updates belongs on the host, not in the guest system.

Microcode updates are usually shipped with the motherboard's firmware and applied during firmware initialization. Since OEMs might not release firmware updates in a timely fashion and old systems do not get new firmware updates at all, the ability to apply CPU microcode updates during boot was added to the Linux kernel. The Linux microcode loader supports three loading methods:

The early initramfs image can be combined with the main initramfs image into one file and passed as a single initramfs to the kernel (via the initrd= kernel command line option by your boot loader or when packed in a unified kernel image) or it can exist as a separate file in which case multiple initrd= kernel command line options need to be used. In both cases, the uncompressed CPIO archive with the microcode must be placed before the main initramfs.

In order for early loading to work in custom kernels, "CPU microcode loading support" needs to be compiled into the kernel, not compiled as a module. This will enable the "Early load microcode" prompt which should be set to Y.

The uncompressed microcode CPIO can be prepended into the initramfs and used as a single initramfs file. This method is preferred over #Microcode in a separate initramfs file since no additional boot parameter configuration is necessary.

3a8082e126