Improve feedback of CLI upgrade

[troglobit]

Description

Currently the feedback on upgrade is rather terse, no feedback on which partition is being upgraded, only an internal reference to something called a "slot":

admin@infix-00-00-00:~$ rauc install ftp://192.168.2.1/infix-riscv64.pkg
installing
  0% Installing
  0% Determining slot states
 10% Determining slot states done.
 10% Checking bundle
 10% Verifying signature
 20% Verifying signature done.
 20% Checking bundle done.
 20% Checking manifest contents
 30% Checking manifest contents done.
 30% Determining target install group
 40% Determining target install group done.
 40% Updating slots
 40% Checking slot rootfs.0
 46% Checking slot rootfs.0 done.
 46% Copying image to rootfs.0
 47% Copying image to rootfs.0

You have to be quite well versed in the system to know that rootfs.0 == primary and rootfs.1 == secondary.

Seeing as we label the partitions primary and secondary maybe we could improve the output a bit, e.g.:

...
 40% Checking slot rootfs.0 (primary)
 46% Checking slot rootfs.0 (primary) done.
 46% Copying image to rootfs.0 (primary)
...

Where (primary) could either be based on basename $device or $bootname?

Additional Information

Also, on at least RISC-V targets upgrade gets stuck for a loooong time at 99%. So maybe add a leading comment, like:

NOTE: Please wait until the upgrade has reached 100%, traditionally that last percent takes as long as the first 99%

:smirk:

General Information

Anyone can help out by sponsoring development of new features or contributing pull requests. Please use this issue for discussions related to the feature.

[wkz]

Yeah this is an idiosyncrasy with RAUC in my opinion. I have no idea why you can't simply name the slots anything you want. Instead each slot has:

• A "slot name", which is not really a name at all, its just <slot-type>.<index>, and...
• A "boot name", which can be any string, but is only used when interfacing the bootloader; the rauc binary can't reference a slot by this name.

Yeah, the progress bar is very xkcd/612. I guess a note is better than nothing, but maybe we should have a look upstream to see if it has been fixed first? Or if we can improve it with a reasonable effort.