1 |
On 05/01/2023 12:09, m1027 wrote: |
2 |
> frederik.pfautsch: > >>> So, ideally, there is c): In a hypothetic case we would prepare |
3 |
a >>> entire OS incl. our app (maybe via catalyst?) which would require |
4 |
>>> a bootloader-like mini-OS on the customer's side, to receive >>> |
5 |
updates over the internet, switch the OS at boot time, and >>> fallback. |
6 |
I was recently playing with systemd-boot and it's >>> interesting |
7 |
try-boot feature. >> >> So essentially it sounds like you want something |
8 |
similar to Yocto / >> Poky / Petalinux for the non-embedded world (and |
9 |
based on Gentoo of >> course; it sounds like catalyst is something like |
10 |
that)? > > I've had a look on that: Wow, another interesting approach to |
11 |
build > customized OSes. Thanks! > >> Just throwing crazy ideas around, |
12 |
what about using net-boot for >> your customer? This way they just need |
13 |
to store an image somewhere >> and can update it whenever necessary. Or |
14 |
(ab-)using an initramfs. >> Or u-boot bootloader, just like in the |
15 |
embedded world. Depending on >> the size of the actual OS/rootfs, taking |
16 |
ideas from e.g. Android >> with their A/B bootslots (i.e. two |
17 |
root-partitions or something, >> where one is active and the other can |
18 |
be updated with clever >> scripts, after a reboot they are swapped). > > |
19 |
... exactly what is on my wishlist currently! I am missing such an > |
20 |
alternative when in need for updating a remote (customer's) OS, where > |
21 |
ssh + emerge @world is just no option. If we had that, I'd see Gentoo > |
22 |
(e.g. with catalyst or via Yocto) shining bright here as it is > perfect |
23 |
in stipping down things to the required minimum. > > Thanks. |
24 |
Interesting projects in that space could be mender.io, or swupdate. |
25 |
|
26 |
Both are based on the idea of having at least two system partitions (+ |
27 |
maybe a couple of data partitions), and downloading the update on an |
28 |
inactive partion. On next boot, the bootloader tries to boot from the |
29 |
new partition; if that fails, it will fall back to the previous (known |
30 |
working) partition after a few tries. |
31 |
|
32 |
|
33 |
-- |
34 |
Xelnor |