Hi Paul,
What is this Arm64 board that needs a custom kernel? What peripherals are you speaking of? Are they proprietary or something you can share?
Building a separate project tree in the OBS might be a good way to get you there in terms of building a custom kernel tree which you could base off of tumbleweed latest kernels. It really depends on what your trying to accomplish here in terms of a product outcome. You of course could use your own Open Build Service on-premise as well if your worried about Intellectual property rights.
SUSE does have services agreements available to help with building such custom kernels and building proper maintenance where you would get the backing and support of an extended developer team at SUSE. We would need to explore this in detail if you are interested.
You can of course go this on your own and build this out in your own home directory in the OBS where the repos are built automatically through the automation available there. I'm pretty sure you could easily make this kernel available in a MicroOS tree, but would have to be built in using the kiwi process in the OBS if building an ISO or Image.
At first glance this is a lot and you would be maintaining quite a lot on your own, or duplicating a lot of work. I'm sure most of us would agree that there might be other ways that would be better.
Maybe Richard and Thorsten have some other ideas.
If it were me sure I would start with a separate project in my home OBS and start building.
Cameron Seader
Technology Strategist
SUSE
+1 208 420 2167
cs@suse.com
www.suse.com
________________________________________
From: Paul Graham
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