oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: openwrt

Add a New Dropdown Menu in OpenWRT LUCI

2023/10/17 No hi ha comentaris
Reading time: 3 – 5 minutes

OpenWRT, the popular open-source Linux operating system designed for embedded devices, offers the LUCI interface for easy configuration and management. LUCI is essentially the web interface for OpenWRT, and while it’s already feature-rich, sometimes you may want to extend its functionalities based on your needs.

Recently, I had a requirement to enhance my OpenWRT LUCI interface. Specifically, I wanted to introduce a new menu named “Apps” in the LUCI dashboard. The objective was to have each entry within this new menu link to different applications installed on my device. And not just that! I wanted these application pages to pop open in new tabs for ease of access.

The Solution

The changes were made in a single file located at:

/usr/lib/lua/luci/controller/apps.lua

Within this file, I implemented the following code:

module("luci.controller.apps", package.seeall)

function index()
    local page

    page = entry({"admin", "apps"}, firstchild(), _("Apps"), 60)
    page.dependent = false

    entry({"admin", "apps", "portainer"}, call("serve_js_redirect", "https", "9443"), _("Portainer"), 10).leaf = true
    entry({"admin", "apps", "nodered"}, call("serve_js_redirect", "http", "1880"), _("NodeRED"), 20).leaf = true
    entry({"admin", "apps", "grafana"}, call("serve_js_redirect", "http", "3000"), _("Grafana"), 30).leaf = true
    entry({"admin", "apps", "prometheus"}, call("serve_js_redirect", "http", "9090"), _("Prometheus"), 40).leaf = true
end

function serve_js_redirect(protocol, port)
    local ip = luci.http.getenv("SERVER_ADDR")
    local url = protocol .. "://" .. ip .. ":" .. port
    luci.http.prepare_content("text/html; charset=utf-8")
    luci.http.write("<!DOCTYPE html><html><head><meta charset='UTF-8'><title>Redirecting...</title></head><body>")
    luci.http.write("<script type='text/javascript'>")
    luci.http.write("window.onload = function() {")
    luci.http.write("  var newWindow = window.open('".. url .."', '_blank');")
    luci.http.write("  if (!newWindow || newWindow.closed || typeof newWindow.closed == 'undefined') {")
    luci.http.write("    document.getElementById('manualLink').style.display = 'block';")
    luci.http.write("    setTimeout(function() { window.location.href = document.referrer; }, 60000);")  -- Redirigir después de 60 segundos
    luci.http.write("  }")
    luci.http.write("}")
    luci.http.write("</script>")
    luci.http.write("<p id='manualLink' style='display: none;'>The window didn't open automatically. <a href='".. url .."' target='_blank'>Click here</a> to open manually.</p>")
    luci.http.write("</body></html>")
end

Key Points

  • The index function is responsible for defining the new menu and its entries.
  • The serve_js_redirect function creates a web page that uses JavaScript to automatically open the desired application in a new browser tab.
  • A failsafe mechanism is added in the form of a link. If, for any reason (like pop-up blockers), the new tab doesn’t open automatically, the user has the option to manually click on a link to open the application.
  • The script also includes a feature that will redirect the user back to the previous page after 60 seconds if the new tab doesn’t open.

This modification provides a seamless way to integrate external applications directly into the LUCI interface, making navigation and management even more convenient!

Resize Squashfs/Ext4 partition of OpenWRT in a Raspberry PI

2022/08/04 No hi ha comentaris
Reading time: < 1 minute

Quick cookbook for just doing what the subject of the post says:

opkg update
opkg install cfdisk
cfdisk
# change partition size using the UI
opkg install losetup resize2fs
BOOT="$(sed -n -e "/\s\/boot\s.*$/{s///p;q}" /etc/mtab)"
DISK="${BOOT%%[0-9]*}"
PART="$((${BOOT##*[^0-9]}+1))"
ROOT="${DISK}0p${PART}"
LOOP="$(losetup -f)"
losetup ${LOOP} ${ROOT}
fsck.ext4 -y ${LOOP}
resize2fs ${LOOP}
reboot

Raspberry PI and OpenWRT flash partition proposal and rescue boot support for embedded systems

2015/12/23 1 comentari

Reading time: 4 – 7 minutes

Introduction

Main target of this post is describe how to organize flash partitions and how to modify default OpenWRT boot sequence to support a flexible and powerful rescue mode for Raspberry PI based projects. Just to clarify the explaination. When OpenWRT is build on a flash card for Raspberry, there are only two partitions.

The first one is vFat partition with kernel, firmware and other configuration files; the second one is a ext4 partition with root filesystem. Boot sequence loads the kernel and then mount root partition and run the init script. If ext4 filesystem is corrupted or could not be mounted boot sequence is stoped and there is no solution without extracting the flash card.

Features

In this blog entry I’m going to describe a partition table and boot sequence strategy to avoid this kind of problems. Of course, there are other solutions to get similar results but I think this one is simple and powerful at the same time.

Summarizing features of this solution:

  • reduce risk when using intensive writing app
  • reduce damage risk on flash memories
  • fail-safe mode pressing a button
  • support application upgrades using opkg packages
  • support operative system upgrades using opkg packages

This solution proposal assume:

  • wear leveling protection solved by flash card
  • button connected to GPIO pins

The idea

Raspberry PI requires a vfat partition as its first flash partition where there are several required files for booting process, this is a bootloader substitution. For example, in that partition there are files like: start*.elf and bootcode.bin which are the GPU firmware and bootloaders. Another key file is kernel.img; this is the kernel used for booting. Bootloader parameters for kernel booting are in a file called cmdline.txt and firmware parameters are set in config.txt.

At this point the most important think to take into account is kernel.img file and cmdline parameters. Because kernel is loaded and executed by default with cmdline parameters set. When kernel boot process finishes root filesystem and init process sequence will be figured out from cmdline parameters.

At this point take a look on proposed partition table could be useful: (spaces are just as a reference, use what you need)

p1 - vfat (~50MB)
p2 - ext4 - operative system base (read-only) (~150MB)
p3 - ext4 - operative system (read-write) (~250MB)
p4 - logical partition
  p4.1 - ext4 - your_application files (usually read-only)
  p4.2 - ext4 - your_application data (usually read-write)

Fail-safe boot process key is partition p2 where a minimal OpenWRT installation with a modified init sequence is found. Main idea here is detect if a GPIO shortcut is done, usually this is done just pressing a physical button and you can interact with the user emitting some beep, for example, you can tell the user when you are waiting for button press using a beep and then emit two beeps when button press is detected or nothing if no button is pressed in 3 seconds. Finally the idea is detect if you need a regular boot or a fail-safe boot.

My suggestion for minimal OpenWRT is a small footprint installation of OpenWRT without kernel modules, just the monolitic kernel loaded. Then reduce init sequence to the minimum and add fail-safe logic (GPIO button capture); if button is pressed stop boot sequence and give a shell to the user. Regular way will be invoke init file of the rootfs (p3 in the partition table).

I think the idea is simple and the complexity is reduced in two parts both of them are the init file. To be more precise the p2 partition table has its own init file and p3 the other one. p2 init file load the minimum hardware to control button and give rescue environment when it’s needed. And p3 init file mounts read-write partition and the regular filesystem with regular boot processes and all kind of stuff that you need.

Final notes

I know this is not a very practical post, but my intention is only share some ideas that I have in mind. I spend most of my time designing architectures and I think this is a very powerful architecture of a boot sequence for some professional projects based on Raspberry PI and OpenWRT.

The best way to do what I describe in this post is putting p2 in a initrd file which is referenced in kernel parameters. Because then all read-only system is a RAM partition and rootfs init file has the PID 1 dropping dual-init file complexity. But I decided to modify this part because in the past I had some problems creating initrd files specially when required space for that partition is bigger than RAM. Anyway it’s important to take in account that initrd files has the same purpose as the proposed p2 partition.

Useful links