From f45326b9d32cdae7b961479325eee9df3c61cc63 Mon Sep 17 00:00:00 2001 From: Daniel Barlow Date: Sat, 18 Nov 2023 11:51:57 +0000 Subject: [PATCH] why we decided not to depend on kexec --- THOUGHTS.txt | 118 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 117 insertions(+), 1 deletion(-) diff --git a/THOUGHTS.txt b/THOUGHTS.txt index 5dc3dc9..036b080 100644 --- 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