Hi Mauro, sorry for being a bit late in answering. It turns out that the less of the year remains, the more is still to be done until it ends ;)
Am 01.12.19 um 11:55 schrieb Mauro Condarelli: > Hi All, > I'm trying to decide if rauch is the right tool for my project. Please, says 'rauc' (or even better 'RAUC'). 'rauch' in german means 'smoke' and this should not be the connotation :D > My target is an embedded Linux with: > - SPI Flash for booting (paleolithic version of U-Boot) and possibly a > initramfs/recovery (16M total) > - A sizable SD card (8G). > > Bad problem is SD is very sensitive to "unexpected" shutdowns which I > cannot prevent. > > Slots should include: > > - uboot (possibly never updated) > allocated in first Flash partition: /dev/mtd1 Never say never, as bootloaders may fail updating more recent kernels depending on how much they interact with device tree loading etc. > - linux kernel (rarely upgraded, if ever) > allocated in third Flash partition: /dev/mtd3 > > - recovery (possibly never updated) > allocated in fourth Flash partition: /dev/mtd4 > probably a SquashFS, but could also be a initramfs (cpio) > copies of rauc modules could be stored in first SD partition (vfat) > /dev/mmcblk1 Note that because of security concerns, it might require being updated, too. But from the general concept of a recovery system, yes it should be rarely updated. What about saving one partition and using a kernel with built-in initramfs? > - system (rarely upgraded) > allocated in SD, redundant probably /dev/mmcblk0p2 and /dev/mmcblk0p3 > ext4 Does that bring its own kernel or the one from /dev/mtd3? Updating the kernel is a definitive use case! > - application (often upgraded) > allocated in SD, redundant probably /dev/mmcblk0p5 and /dev/mmcblk0p6 > ext4 mounted on /home > > - accumulated data (initially empty; should be preserved at all cost) > allocated in SD, not redundant, but possibly backed-up before upgrade. > ext4 mounted on /srv > > At first documentation perusal I saw no direct support for MTD. There were patches from ladis on this list recently that you might have seen if you're subscribed. Otherwise you could use a hook script first of all. > My current "solution" relies on a bunch of scripts that are rapidly growing > and a rather complex usage of OverlayFS. > I am thus looking for a "more structured" solution, possibly rauch. Yes, that is the exact reason why one wants to use an (open source) framework for these kind of things. And RAUC should be able to cover your use case of asymmetric A+recovery update. See minimal example: https://rauc.readthedocs.io/en/latest/scenarios.html#asymmetric-slots The good on this is, that even if there is some small aspect still missing, it could be implemented and then be maintained in a shared and more well-tested environment than a custom script can be. > Can someone advise? > I am available to give more info, if needed. Your general concept looks reasonable. Do my hints already give you the answers you require? Best regards Enrico -- Pengutronix e.K. | Enrico Jörns | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ RAUC mailing list