* [RAUC] Rauch usage hints needed @ 2019-12-01 10:55 Mauro Condarelli 2019-12-11 23:50 ` Enrico Jörns 0 siblings, 1 reply; 3+ messages in thread From: Mauro Condarelli @ 2019-12-01 10:55 UTC (permalink / raw) To: rauc Hi All, I'm trying to decide if rauch is the right tool for my project. 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 - 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 - system (rarely upgraded) allocated in SD, redundant probably /dev/mmcblk0p2 and /dev/mmcblk0p3 ext4 - 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. 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. Can someone advise? I am available to give more info, if needed. Thanks in Advance Mauro _______________________________________________ RAUC mailing list ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RAUC] Rauch usage hints needed 2019-12-01 10:55 [RAUC] Rauch usage hints needed Mauro Condarelli @ 2019-12-11 23:50 ` Enrico Jörns 2020-01-22 12:57 ` [RAUC] Rauc " Mauro Condarelli 0 siblings, 1 reply; 3+ messages in thread From: Enrico Jörns @ 2019-12-11 23:50 UTC (permalink / raw) To: Mauro Condarelli; +Cc: rauc 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RAUC] Rauc usage hints needed 2019-12-11 23:50 ` Enrico Jörns @ 2020-01-22 12:57 ` Mauro Condarelli 0 siblings, 0 replies; 3+ messages in thread From: Mauro Condarelli @ 2020-01-22 12:57 UTC (permalink / raw) To: Enrico Jörns; +Cc: rauc Thanks Joerns, I'm also very late answering, but I've been very busy (see below) On 12/12/19 12:50 AM, Enrico Jörns wrote: > 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 ;) I know ;) > 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 Fully understood (I should have known, clumsy fingers...) >> My target is an embedded Linux with: >> - SPI Flash for booting (paleolithic version of U-Boot) and possibly a >> initramfs/recovery (16M total) First good news is I managed to port current (actually "next"!) u-boot to my board and thus many of the limitations are lifted. >> - 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. Agreed. - two very small (4k) partitions holding fallback U-Boot ENV and serialization data (serial#, MAC addr, ...). >> - linux kernel (rarely upgraded, if ever) >> allocated in third Flash partition: /dev/mtd3 It will become /dev/mtd4. This Linux kernel is for exclusive use of the recovery system, in case SD card is completely unusable. >> - 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? As said: recovery system should not be actually used (hopefully ;) ) I don't think to provide updates for that is a priority: if we touch it we face chance to brick the system, quite the opposite of what a recovery system is meant to be. My system (mips MT7628) can see part (first 4MiB) of the SPI NOR as memory and thus I'm "booting from RAM". InitramFS has limited size while using SquashFS I can cram much more data in it. >> - 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! Of course! Idea would be to have multiple copies of Kernel (along with some backup copies of RootFS) in the first (FAT formatted) SD partition (/dev/mmcblk0p1) easily accessible from both U-Boot and Linux. I also moved U-Boot ENV to this partition so that "normal" (non recovery) boot could have a completely different environment. Recovery should mainly rely on "compiled-in" default ENV. Moving to SD also benefits from Wear-Leveling, so I can update ENV at each boot attempt to keep the boot-counter needed for automatic fallback (I'm still unsure on how to implement this in U-Boot; if there are "best practices" available...). >> - application (often upgraded) >> allocated in SD, redundant probably /dev/mmcblk0p5 and /dev/mmcblk0p6 >> ext4 mounted on /home It could be quite small. >> - 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 We could allocate a small partition just to store RAUC Update Artifacts without any interference with "live" system. Would this buy us some added robustness, in practice? >> 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. I just recently subscribed, I'll search the archives. >> 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 I've seen that. As I'm resuming work now on update system I will send my tentative architecture (and RAUC Configuration Files) to have an expert advise. > 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? Most of them. I'm still not very sure about how to proceed, but I hope a few tests will enable me to get a firmer grip unto the matter. > Best regards > > Enrico > Regards and Many Thanks Mauro _______________________________________________ RAUC mailing list ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-01-22 12:57 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-01 10:55 [RAUC] Rauch usage hints needed Mauro Condarelli 2019-12-11 23:50 ` Enrico Jörns 2020-01-22 12:57 ` [RAUC] Rauc " Mauro Condarelli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox