why we decided not to depend on kexec
This commit is contained in:
parent
f9f4d97bb8
commit
f45326b9d3
1 changed files with 117 additions and 1 deletions
118
THOUGHTS.txt
118
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
|
- we don't have any way to do a tftpboot ubifs
|
||||||
- ext4 doesn't care
|
- ext4 doesn't care
|
||||||
|
|
||||||
|
|
||||||
3) the rootfstype needs thought.
|
3) the rootfstype needs thought.
|
||||||
|
|
||||||
- for all but squashfs it implies an initramfs
|
- 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.
|
tarball and an informative README containing the instructions.
|
||||||
Although we also want the instructions in the manual where people
|
Although we also want the instructions in the manual where people
|
||||||
can read them before building anything.
|
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
|
||||||
|
|
Loading…
Reference in a new issue