Install OpenWrt One as ubimage instead of static FIT

'traditional' uboot tftp boot works fine as well

THOUGHTS.txt

@@ -6795,42 +6795,3 @@ should be pure, so if we're going to timestamp anything we have to do
 that in the imperative step i.e. update.sh
 
 perhaps a symlink from /persist/configuration/yyyymmddtmmhhss -> /nix/store/eeee-blah
-
-
-Thu Jan  2 23:38:59 GMT 2025
-
-Stuff we should tidy up:
-
-1) all devices to set credible default output, rootfs, etc
-2) expunge remaining references to kexecboot
-3) dynamic uid assigment for users
-4) lessen logging noise from firewall
-5) update.sh --fast sends wlan services for a spin
-
-
-
-Fri Jan  3 16:05:10 GMT 2025
-
-* build actual rotuer config and install on rt3200
-* find usb ethernet dongle for laptop
-* plug it in?
-
-Sat Jan  4 15:32:03 GMT 2025
-
-didn't work so well, because the installer version is coupled with the
-dtb and the dtb can't be upgraded without upgrading the kenrel
-
-kernel 6.6.67 builds and boots but seems to have no wired ethernet.
-looking through the openwrt config changes ...
-
-+CONFIG_MTD_UBI_NVMEM=y
-+CONFIG_NVMEM_BLOCK=y
-+CONFIG_NVMEM_LAYOUT_ADTRAN=y
-+CONFIG_PHYLIB_LEDS=y
-+CONFIG_MTK_REGULATOR_COUPLER=y
-+CONFIG_FW_LOADER_SYSFS=y
-
-
-Sun Jan  5 12:58:52 GMT 2025
-
-We are running with rt3200 and everything appears to work :-)

ci.nix

@@ -11,7 +11,6 @@ let
     "qemu-aarch64"
     "qemu-armv7l"
     "tp-archer-ax23"
-    "openwrt-one"
     "zyxel-nwa50ax"
     "turris-omnia"
     "belkin-rt3200"

devices/belkin-rt3200/default.nix

@@ -93,8 +93,6 @@
     image if there are records in pstore, because that interferes with
     ``config.log.persistent``
 
-    .. code-block:: console
-
         root@OpenWrt:~# fw_setenv orig_boot_production $(fw_printenv -n boot_production)
         root@OpenWrt:~# fw_setenv orig_bootcmd $(fw_printenv -n bootcmd)
         root@OpenWrt:~# fw_setenv boot_production 'led $bootled_pwr on ; ubifsmount ubi0:liminix && ubifsload ''${loadaddr} boot/fit && bootm ''${loadaddr}'

devices/gl-ar750/default.nix

@@ -41,11 +41,10 @@
     :ref:`system-outputs-mtdimage` can be flashed using the
     vendor web UI or the U-Boot emergency "unbrick" routine.
 
-    Flashing over an existing Liminix system is not possible while
-    that system is running, otherwise you'll be overwriting flash
-    partitions while they're in use - and that might not end well.
-    Configure the system with :ref:`levitate` if you need to
-    make it upgradable.
+    For flashing from an existing Liminix system (we believe that) it
+    is necessary to first boot into a :ref:`system-outputs-kexecboot`
+    system, otherwise you'll be overwriting flash partitions while
+    they're in use - and that might not end well.
 
     Vendor web page: https://www.gl-inet.com/products/gl-ar750/
 

devices/gl-mt300a/default.nix

@@ -32,11 +32,10 @@
     binary created by :ref:`system-outputs-mtdimage` can be flashed
     using the vendor web UI or the U-Boot emergency "unbrick" routine.
 
-    Flashing over an existing Liminix system is not possible while
-    that system is running, otherwise you'll be overwriting flash
-    partitions while they're in use - and that might not end well.
-    Configure the system with :ref:`levitate` if you need to
-    make it upgradable.
+    For flashing from an existing Liminix system (we think) it
+    is necessary to first boot into a :ref:`system-outputs-kexecboot`
+    system, otherwise you'll be overwriting flash partitions while
+    they're in use - and that might not end well.
 
     Vendor web page: https://www.gl-inet.com/products/gl-mt300a/
 

devices/gl-mt300n-v2/default.nix

@@ -25,11 +25,10 @@
     binary created by :ref:`system-outputs-mtdimage` can be flashed
     using the vendor web UI or the U-Boot emergency "unbrick" routine.
 
-    Flashing over an existing Liminix system is not possible while
-    that system is running, otherwise you'll be overwriting flash
-    partitions while they're in use - and that might not end well.
-    Configure the system with :ref:`levitate` if you need to
-    make it upgradable.
+    For flashing from an existing Liminix system (we think) it
+    is necessary to first boot into a :ref:`system-outputs-kexecboot`
+    system, otherwise you'll be overwriting flash partitions while
+    they're in use - and that might not end well.
 
     Vendor web page: https://www.gl-inet.com/products/gl-mt300n-v2/
 

examples/module-https-proxy.nix

@@ -21,16 +21,15 @@
 let
   inherit (pkgs.liminix.services)  longrun;
   inherit (pkgs) writeText;
-  nginx_uid = 62;
 in {
   config = {
     users.nginx = {
-      uid = nginx_uid; gid= nginx_uid;
+      uid = 52; gid= 52;
       dir = "/run/";
       shell = "/bin/false";
     };
     groups.nginx = {
-      gid= nginx_uid;
+      gid= 52;
       usernames = ["nginx"];
     };
 

modules/all-modules.nix

@@ -22,6 +22,7 @@
    ./outputs/ext4fs.nix
    ./outputs/initramfs.nix
    ./outputs/jffs2.nix
+   ./outputs/kexecboot.nix
    ./outputs/mtdimage.nix
    ./outputs/tftpboot.nix
    ./outputs/ubifs.nix

modules/outputs/kexecboot.nix

@@ -0,0 +1,65 @@
+{
+  config
+, pkgs
+, lib
+, ...
+}:
+let
+  inherit (lib) mkOption types concatStringsSep;
+in {
+  imports = [ ../ramdisk.nix ];
+  options.system.outputs = {
+    kexecboot = mkOption {
+      type = types.package;
+      description = ''
+        kexecboot
+        *********
+
+        Directory containing files needed for kexec booting.
+        Can be copied onto the target device using ssh or similar
+      '';
+    };
+    boot-sh = mkOption {
+      type = types.package;
+      description = ''
+        Shell script to run on the target device that invokes
+        kexec with appropriate options
+      '';
+    };
+  };
+  config = {
+    boot.ramdisk.enable = true;
+    system.outputs = {
+      kexecboot =
+        let o = config.system.outputs; in
+        pkgs.runCommand "kexecboot" {} ''
+          mkdir $out
+          cd $out
+          ln -s ${o.rootfs} rootfs
+          ln -s ${o.kernel} kernel
+          ln -s ${o.manifest} manifest
+          ln -s ${o.boot-sh} boot.sh
+          ln -s ${pkgs.kexec-tools-static}/bin/kexec ./kexec
+          ln -s ${o.dtb} dtb
+       '';
+
+      boot-sh =
+        let
+          inherit (config.system.outputs) rootfs;
+          cmdline = concatStringsSep " " config.boot.commandLine;
+        in
+          pkgs.buildPackages.runCommand "boot.sh.sh" {
+          } ''
+            rootfsStart=${toString (100 * 1024 * 1024)}
+            rootfsBytes=$(stat -L -c %s ${rootfs})
+            append_cmd="mtdparts=phram0:''${rootfsBytes}(rootfs) phram.phram=phram0,''${rootfsStart},''${rootfsBytes} memmap=''${rootfsBytes}\$''${rootfsStart}";
+            cat > $out <<EOF
+            #!/bin/sh
+            test -d \$1
+            cd \$1
+            ./kexec -f -d --map-file rootfs@$rootfsStart --dtb dtb --command-line '${cmdline} $append_cmd' kernel
+            EOF
+          '';
+    };
+  };
+}

modules/outputs/mtdimage.nix

@@ -34,8 +34,7 @@ in {
         This creates an image called :file:`firmware.bin` suitable for
         squashfs or jffs2 systems. It can be flashed from U-Boot (if
         you have a serial console connection), or on some devices from
-        the vendor firmware, or from Liminix when using
-        :ref:`levitate`
+        the vendor firmware, or from a Liminix kexecboot system.
 
         If you are flashing from U-Boot, the file
         :file:`flash.scr` is a sequence of commands

modules/ramdisk.nix

@@ -7,7 +7,8 @@ in {
       ramdisk = {
         enable = mkEnableOption ''
           reserving part of memory as
-          an MTD-based RAM disk.  Needed for TFTP booting
+          an MTD-based RAM disk.  Needed for TFTP booting or for
+          kexec-based revertable upgrade
         '';
       };
     };