how to select install slot on A/B boot when booting from usb (rauc.external)

[mifran23]

On initial setup of an A/B System we boot over usb (rauc.external set in cmdline) setup the partitions and then try to install both slot via

rauc install bundle.raucb

This installs the bundle in one of the slots. But I didn't find a way to select the other slot.
I tried to get the other slot selected by marking good the slot that got installed.
I even switched the partitions in /etc/rauc/system.conf.
But still the same partitions get flashed.
It seems like the changes in system.conf had no efect. Even after deleting the file install to the first slot works fine.

I know I can mount the boundle and install the partitions one by one.
But then I have to do the changes normaly done by hook by hand.
And if the hooks get changed I have to change the install script also.

So is it possible to change the slot for rauc install bundle.raucb ?

[ejoerns]

@mifran23 At the moment, there is no real option to select the slot group if multiple groups are available.

The 'logic' that selects the slot group to update just uses the first element if multiple are found.

One solution to this could be to have a look at the installation times and pick the slot group with the oldest installation date as the installation candidate.

Another would be to allow explicit installation of all slot groups at once.

To better understand your needs, may I ask what the motivation is to use RAUC during bootstrapping?

[mifran23]

@ejoerns Thank you for looking into this.

The RAUC bundle is qualified by our QA team.
So the idea was to boot a live image on our hw. Run some tests and if they pass a script is partitioning the nvme and installs the RAUC bundle in both slots.
My current solution is to mount the bundle and use rauc write-slot to install the slots and after that run the commands from my post install hook.

[pelrun]

+1 to this. Heck, I'd personally be happy if all I got was the capability for rauc write-slot to take bundles as input and use it like it would any other image, rather than jumping through hurdles as mifran23 has.

It's unpleasant to have to wrangle multiple types of image for different scenarios, when it seems trivial to just have the capability to pass bundles about and use them for both updates and for provisioning/emergency recovery.

[ejoerns]

@pelrun So you also have the need to provision both A and B in a factory or recovery case, correct?

+1 to this. Heck, I'd personally be happy if all I got was the capability for rauc write-slot to take bundles as input and use it like it would any other image, rather than jumping through hurdles as mifran23 has.

I'd say rauc write-slot is the wrong tool for this since it is explicitly designed to handle images instead of bundles. A potential solution outlined above would be to have something like rauc install --all-inactive.

[pelrun]

Yeah, I've since realised that as I continue to play about with things.

Your previous suggestion seems useful - rather than always return the first inactive slot encountered, to return one with the oldest installation timestamp (or with no timestamp.) I can easily run the install a couple of times in succession to ensure that all the slots are provisioned.

Actually already poking at select_inactive_slot_class_member to implement it myself... :D

[ejoerns]

For installing all slots, I realized we have an RFE Issue already:

#1129

Yeah, I've since realised that as I continue to play about with things.

Your previous suggestion seems useful - rather than always return the first inactive slot encountered, to return one with the oldest installation timestamp (or with no timestamp.) I can easily run the install a couple of times in succession to ensure that all the slots are provisioned.

Actually already poking at select_inactive_slot_class_member to implement it myself... :D

You might want to have a look at https://github.com/ejoerns/rauc/tree/topic/abc-update first. We also had similar ideas in other issues already.

[ejoerns]

I've now cleaned up and finalized my patches a bit and provided #1525 as a potential solution to this.

[pelrun]

I had tried out your branch and it neatly solved the problem on my end. Thanks!