commit f45326b9d32cdae7b961479325eee9df3c61cc63
parent f9f4d97bb88e75766160a51c3e26ebd48196bd19
Author: Daniel Barlow <dan@telent.net>
Date: Sat, 18 Nov 2023 11:51:57 +0000
why we decided not to depend on kexec
Diffstat:
| M | THOUGHTS.txt | | | 118 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- |
1 file changed, 117 insertions(+), 1 deletion(-)
diff --git a/THOUGHTS.txt b/THOUGHTS.txt
@@ -2913,7 +2913,6 @@ ourselves somehow which seems silly when qemu already does it
- we don't have any way to do a tftpboot ubifs
- ext4 doesn't care
-
3) the rootfstype needs thought.
- for all but squashfs it implies an initramfs
@@ -2955,3 +2954,120 @@ is that the turris output is a directory with a symlink to the
tarball and an informative README containing the instructions.
Although we also want the instructions in the manual where people
can read them before building anything.
+
+Fri Nov 10 21:27:50 GMT 2023
+
+Realising now that outputs and installers aren't the same thing.
+
+e.g. flashimage can be installed from u-boot or from kexecboot
+
+perhaps we distinguish between the
+
+"installation image":
+- firmware.bin
+- tarball
+- ubifs image
+- kernel + rootfs
+
+and "installer"
+- kexecboot script
+- u-boot script to flash squashfs image
+
+Sun Nov 12 17:17:30 GMT 2023
+
+What TODO?
+
+- "does the kernel live on the filesystem" depends on the bootloader
+ not the filesystem
+ - could we implement this with a module that adds to config.filesystem ?
+ it would depend on whether the bootloader can follow symlinks to
+ files not in /boot (probably fine unless crossing filesystems)
+ - the other question is how much futzing around in u-boot can/do we do
+ to tell u-boot how to boot? for grown-up u-boot it's not a
+ problem as we can saveenv but are there broken u-boots that would
+ prevent this?
+
+- kexecboot is unloved and documented in the wrong place. do we have a
+ test for it even?
+ - it won't work on aarch64 because it needs memmap=
+ - hardcodes memory size, which we should probably work out dynamically
+
+- how to put device name into the device docs
+ maybe devices
+
+- make config.boot.commandLine a single string
+- finish omnia
+- for installation on turris omnia we need tarball not ext4 image
+ (but keep the ext4 image anyway for tftpboot and possibly kexecboot)
+[done] - now we have lim.parseInt should we use it consistently?
+- usefulness tiers for devices ("stable", "experimental", "wip")
+- params for ubi(fs) are a mess
+- create an l2tp configuration
+- iperf and tuning
+- wlan country code
+
+
+Fri Nov 17 17:30:39 GMT 2023
+
+kexec is fraught. I spent some time trying (unsuccesfully) to get a
+kexecboot test running, but it doesn't work in qemu for the reason
+that the kernel I built for qemu has SMP support but does not have
+kexec_nonboot_cpu_func() - which is the needed function to stop
+non-boot CPUs before jumping into the new kernel. That this code is
+all MIPS-specific (I have to assume that other architectures have
+entirely different ways to stop non-boot CPUs?) is a bit worrisome: how
+many other ways is kexec hardware-dependent?
+
+We have two scenarios where we may want to use it:
+
+1) the "installer": e.g. for UBI platforms, we want to plonk
+a new ubifs on the device without clobbering the erase counters, which
+means either doing it from U-Boot - needs serial connection -
+or doing it from a Linux of some kind that is not running on the
+filesystem we're toasting.
+
+2) reinstalling after the initial install - this is a big deal for
+squashfs where there is no other way to change data, and an only slightly
+smaller deal for jffs2, where there isn't much room to change much
+data.
+
+Maybe instead of kexec we could do this by stopping services and then
+pivot_root into a ramfs. We would, I assume, need to stop any processes
+that have open files on the root fs, but we would need to have network
+interfaces running. So we need a subset of services that run in recovery:
+can make this a bundle
+
+* mount a ramfs
+* copy the closure of the bundle into the ramfs
+* stop all processes (including init?)
+
+sending pid 1 a signal FOO will cause it to run .s6-svscan/SIGFOO
+
+Fri Nov 17 23:53:43 GMT 2023
+
+So we need to extend .s6-svscan/finish to
+
+if test -e /maintenance/bin/init
+ cd /maintenance
+ mount --bind /maintenance/ /
+ chroot .
+ exec /bin/init -D maintenance
+fi
+
+
+foreground {
+ if { test -e /maintenance/bin/init }
+ cd /maintenance
+ foreground { mount --move /maintenance/ / }
+ foreground { chroot . }
+ redirfd -r 0 /dev/console
+ redirfd -w 1 /dev/console
+ fdmove -c 2 1
+ emptyenv /bin/init -D maintenance
+}
+${s6-linux-init}/bin/s6-linux-init-hpr -fr
+
+
+
+
+https://openwrt.org/docs/techref/sysupgrade
