Cameron, Thorsten, and Richard,
Thanks for the feedback and updates. They are much appreciated.
I have one additional question, at the moment, that is somewhat
related. I am targeting an Arm64 board that needs a custom kernel to
fully support all of the peripherals. What is the right strategy to
build and use a custom kernel in a MicroOS context?
I plan to patch the openSUSE kernel and try to build openSUSE-like
kernel RPMs from that source tree. I am hoping that approach would
provide a more seamless approach from an integration point of view,
leveraging the openSUSE installation process to automatically generate
the initrd, update the grub configuration, etc. I still need to
figure out where to place the updated device tree as well, but I think
I can figure that out. Currently the system is passing a device tree
to Grub through bootefi within U-Boot.
Assuming I can get all of that to work, I would probably host the
custom kernel in a separate local repository, install the new kernel
packages, and disable kernel package updates until, hopefully, the
mainline kernel supports the Arm64 SoC completely.
If you have any suggestions or insights, they would be greatly appreciated.
Thanks again!
Paul
On Thu, Jul 22, 2021 at 3:31 PM Richard Brown
On Thu, 2021-07-22 at 09:17 +0200, Thorsten Kukuk wrote:
I understand that this is probably not compatible with the "transactional-update" tool on the receiving end, but it might be a nice way to push updates to systems, taking advantage of the fact that only snapshots are being sent and, ideally, they would represent only the differences from previous snapshots (a natural way of handling the deltas between two file systems).
If "btrfs send" isn't the right mechanism for pushing updates, is there a better mechanism?
The idea with "btrfs send/receive" is not new. The biggest problem I see is, that /etc is part of the root filesystem (else it wouldn't be possible to do a rollback of the configuration files, too), and this directory contains host specific data, which you should never share with other uses. Like the unique machine-id.
Yeah I've been playing around with this and found the same conclusion. But then this is not exactly any different from regular transactional- update, which has to jump through some hoops to handle /etc properly.
I have a half-finished proof of concept script which, in theory at least, should follow the below workflow:
1. ssh from host to node 2. create new target snapshot for node 3. create new target /etc overlay for nodes new snapshot 4. btrfs send/recieve new rootfs from host to node 5. copy/move /etc from new node rootfs to new /etc overlay on node 6. mount users /etc overlay over new overlay
This would still be is an 'imperfect' system compared to a typical rpm based transactional-update, as it's impossible to make the users config available for the rpm to process and possibly update, but would still provide an arrangement where distro config can be updated and rolled back.
Things like machine-id would always be in the users /etc overlay so preserved between updates.
-- Richard Brown Linux Distribution Engineer - Future Technology Team
Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer