| 17 Apr 2024 |
 shoragan | ? | 12:18:47 |
 Jacmet | shoragan: so parse the output of rauc info and check against what is in system.conf? I guess I could do that, but it would IMHO make more sense if rauc would do it for me | 12:19:07 |
| Jacmet | shoragan: currently not, just rauc install foo.raucb | 12:19:33 |
 ejoerns | 'rauc info' also serves as a 'host' command. Thus it would not make sense to check the compatible there. | 12:21:43 |
| ejoerns | Jacmet: So you have cases where the signature may be valid but the compatible not? | 12:21:57 |
| Jacmet | ejoerns: ahh yes | 12:22:14 |
| Jacmet | ejoerns: most likely not, but what is the point of compatible then in the end? | 12:22:41 |
| Jacmet | I just tweaked my compatible in system.conf and wanted to verify that rauc info would complain about it | 12:23:17 |
| ejoerns | Jacmet: If you have different products but all signed with the same company key for example. In the end its more for additional safety and clarity of purpose anyway. | 12:24:55 |
| Jacmet | ejoerns: as install does verify the compatible, you could imagine someone expecting to use it, E.G. if you have different board variants with the same signatures but some versions can not be installed on older units. I'm not doing something like that today, but it doesn't seem that far fetched to expect to be able to block such installations using the compatible | 12:25:29 |
| ejoerns | Jacmet: Yes, I am aware that it might be used ;) It was more about finding out how your concrete use case looks like The better we know the purpose of a feature request, the easier it is to find a proper solution (or where the existing solutions might be sufficient in the end) :) | 12:27:27 |
| Jacmet | ejoerns: the exact use case here is really trying to fit rauc into a system with certain legacy expectations, E.G. that install is explicitly split up in transfer, check, install. Transfer is easy to do outside rauc, but rauc info doesn't really do a full check given the compatible (and hooks) | 12:29:53 |
| shoragan | note that with streaming, you can't separate those stages any more | 12:31:26 |
| ejoerns | Jacmet: Note that for the case you described there is 'variant' support in RAUC which would at least allow to have bundles that install on different boar variants/revision with the same compatible. However, there is again no easy way to find out if an installation will succeed beforehand | 12:31:29 |
| shoragan | and check isn't really needed, as a failed installation doesn't cause any harm | 12:31:58 |
| Jacmet | so a "rauc check <bundle>" or "rauc verify <bundle>" would be handy. I don't really have an opinion of it it makes more sense to extend rauc info to check the compatible or add a --check-only flag to rauc install | 12:32:03 |
| Jacmet | shoragan: true, but these devices also typically don't have a network connection so no big loss ;) | 12:32:29 |
| shoragan | a check could only find a small subset of issues | 12:32:35 |
| * shoragan has to go | 12:32:50 |
| Jacmet | shoragan: agreed, you cannot guarantee that the install will always succeed if the check did, but you can at least check that the bundle is well formed (E.G. is a rauc file, signed by a trusted key, compatible matches, ..) | 12:33:45 |
| shoragan | if those are incorrect, the install will fail quickly | 12:34:05 |
| ejoerns | Indeed, we would have more things to check, like if the variant matches, if the required images are on board, etc. I am not sure where this should be done best or if it gives sufficient benefit over just trying and failing | 12:34:12 |
| ejoerns | What we try to improve is to improve checks during early installation so we can be quite sure we do the right thing once we switch the bootloader and override partition contents | 12:35:06 |
| ejoerns | (a bit over-improved :) ) | 12:36:03 |
| Jacmet | ;) | 12:36:43 |
| Jacmet | ejoerns: so then perhaps the most sensible solution is to add a mode to install that stops after those checks rather than extend rauc info? | 12:37:32 |
| ejoerns | Jacmet: That's pretty close to a --dry-run mode that we discussed once. It depends on how you intend to use it. If it is possible to provide the right bundles for the right hardware, I'd always prefer this instead of checking too much on the target :) | 12:42:25 |
| Jacmet | shoragan: that is true, but triggering an installation "too early" is a bit annoying as we often need to reboot at the end of a succesful installation, which breaks the communication with the host (E.G. there may be various microcontrollers that control power or similar low level stuff) | 12:42:40 |
| Jacmet | ejoerns: indeed ;) | 12:42:58 |
| ejoerns | Jacmet: Just as a side-note: you could also split installation and activation of an update if reboot is the major issue | 12:45:09 |
