From 90faeb1772ac30007e3ea2cdf9f287193c11af11 Mon Sep 17 00:00:00 2001 From: Rune Morling Date: Wed, 1 May 2024 11:04:53 +0200 Subject: [PATCH] May blogpost: Suggestions for fixing nits Signed-off-by: Rune Morling --- docs/blog/posts/calm-before-the-storm.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/blog/posts/calm-before-the-storm.md b/docs/blog/posts/calm-before-the-storm.md index 4e8b56a..6d1a90a 100644 --- a/docs/blog/posts/calm-before-the-storm.md +++ b/docs/blog/posts/calm-before-the-storm.md @@ -21,7 +21,7 @@ for the project as a whole. For some time now we've served as a technical beacon and technical solutions whilst awaiting a situation where a rebase is feasible. While we still look forwards to that future, the present day is the most important to us. Serpent OS must now transition from -a collection of tools and promises into a daily driver with actual users. We still aim to cater the more developer/technical oriented +a collection of tools and promises into a daily driver with actual users. We still aim to cater to the more developer/technical oriented end of the spectrum rather than a "desktop distro", and want to start this journey yesterday. The boot management code is currently landing over the coming days, and will be immediately followed by an incredibly rudimentary @@ -59,18 +59,18 @@ In simple terms, one "state" == "one kernel candidate" (per type..) so all we *r way of the [Boot Loader Interface](https://systemd.io/BOOT_LOADER_INTERFACE/) and any `XBOOTLDR` partition. Then, map our "boot environment" into something `moss-boot` can convert into boot entries, and voila.. -At a more technical level it: +At a more technical level, moss-boot will handle the following: - form candidate `cmdline` from filesystem snippets - auto-generate the `root=` parameter by probing the `/` partition (LVM2, etc) - record the `initrd` needed - - compare and atomically write "missing" files in FAT-respective fashion (copy/unlink/rename) - - garbage collect unused entries + - compare and atomically write "missing" files in FAT-respecting fashion (copy/unlink/rename) + - garbage collect unused boot entries ### Live atomic updates and kernels... An interesting, perhaps not widely considered result of upgrading a kernel, is filesystem path changes. If for any reason the kernel's module -tree becomes inaccessible (say, updating to a new version) then it becomes impossible to load kernel modules. To remedy this, distributions will +tree becomes inaccessible (say, due to updating to a new version) then it becomes impossible to load the old kernel modules. To remedy this, distributions will tend to leave multiple versions of the kernel on disk, invariably within mounted `/boot`. The approach Serpent OS is taking will mean that like Solus, `/boot` will not need to be premounted nor will any package ship files in that directory. @@ -79,7 +79,7 @@ they are used. To solve the "missing version" issue, we will have `moss` record the qualified snapshot path (in `/.moss`) within the `/run` tree so that once the `/usr` tree has been swapped with a new transaction atomically, a patched `kmod` package will fall back to probing the suddenly orphaned kernel tree in the cached -location. +`/run` location. This will mean that the `/lib/modules` tree may not have the current kernel version, but the OS will still be usable while having had a live atomic update. Of course, to *use* the new kernel you must reboot. Unlike other atomic OS implementations, it will be up to *you* when you do so: no more deferred updates! @@ -88,4 +88,4 @@ Of course, to *use* the new kernel you must reboot. Unlike other atomic OS imple We are _aiming_ to get back to monthly blogs on the 19th, but the cycle for the coming 6 weeks may be quite interesting. Expect out of schedule posts looking for testers and volunteers while we use Serpent OS to build Serpent OS, enabling a community of pioneers benefiting from the unique design of -our architecture: a full-featured OS featuring hermetic `/usr`, offline rollbacks, and live atomic upgrades with containerised system triggers. \ No newline at end of file +our architecture: a full-featured OS featuring hermetic `/usr`, offline rollbacks, and live atomic upgrades with containerised system triggers.