From 3194262eb30032409442c49215cb3352b2d2d6fc Mon Sep 17 00:00:00 2001 From: Daniel Barlow Date: Fri, 31 Mar 2023 23:44:49 +0100 Subject: [PATCH] it has not been a production-ready week --- THOUGHTS.txt | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/THOUGHTS.txt b/THOUGHTS.txt index ccf3adff..b2a7bcbb 100644 --- a/THOUGHTS.txt +++ b/THOUGHTS.txt @@ -1372,3 +1372,63 @@ config.system.outputs. The more general question here is whether it's good to be augmenting a variable called "config" with all this generated stuff that is patently not configuration - perhaps putting it under a "system" key will keep it all in one place + +Tue Mar 28 13:32:30 BST 2023 + +how should we handle filesystem state? e.g. resolvconf service + +if a service provides a file at a known global pathname, it can't be +parametrised - it must be a singleton. + +Tue Mar 28 20:25:20 BST 2023 + +wondering if we should swap phases 2 and 3. We can't really address +modules without addressing services, which is phase +n, whereas we +can tackle overlay/ubi whenever + +nand flash may have bad blocks +nor flash (supposedly) doesn't + +ubi provides erase counts and bad block remapping on top of the mtd +interface. this means we should avoid flashcp of a ubi image straight +onto (nand) mtd as we will lose the erase counts and bad block information +that UBI tracks. + +overlayfs works on a filename basis, so might not be very effective : +any change that results in a new store path will mean the entire package +appears in two places. I think it's reasonable to offer squashfs or +ubifs without overlay. + +open questions: + +1) if uboot doesn't support UBI, we can't boot a kernel on a ubifs +so we need reserved space for the kernel. + +- unless we add some padding after the kernel, every new kernel +that's bigger than its predecessor will trash the start of the +ubi space (and wipe out its erase count) +- This suggests we should build more stuff as modules and less as +compiled-in + +2) once a device has had a ubi volume created on it, probably we want +to use ubi-aware tools to update that volume in future instead of a +whole new flash, because we wish to preserve erase counts. This means +running ubiformat --image-file=foo.ubi on the device instead of flashcp + +we can add a "ubi-flashable" output that creates a .ubi image and +a flashcp image that wraps it, with instructions on which to use. + +Fri Mar 31 22:13:54 BST 2023 + +Error: too small LEB size 3968, minimum is 15360 + +> This error means that you are trying to mount too small UBI +volume. Probably because your flash is too small? Try to use JFFS2, +then, because it suits small flashes better since it has much lower +space overhead. Indeed, UBIFS stores much more indexing information on +the flash media than JFFS2, so it has much higher overhead. Also, UBI +has some overhead (see here). Thus, if you have a small flash device +(e.g., about 64MiB), it makes sense to consider using JFFS2. + + +Argh. Oh well,