when trying to query the update path just now, I got an error with a traceback:
% sudo system-image-cli -c trusty -u 0 -n
Traceback (most recent call last):
File "/usr/bin/system-image-cli", line 9, in <module>
load_entry_point('system-image==1.9.1', 'console_scripts', 'system-image-cli')()
File "/usr/lib/python3/dist-packages/systemimage/main.py", line 185, in main
state.run_until('download_files')
File "/usr/lib/python3/dist-packages/systemimage/state.py", line 138, in run_until
step()
File "/usr/lib/python3/dist-packages/systemimage/state.py", line 314, in _get_master_key
raise SignatureError from None
systemimage.gpg.SignatureError
I didn't understand what this was about, so I just tried again and everything worked.
Considering that this is regarding signatures, that left me feeling uneasy.
Unfortunately I can't reproduce it, so maybe the best thing to do is catch this and give some useful advice?
This is odd. Note that the log file likely contains more information, although I don't know how helpful that would have been either. I'll bet you'll see
No valid image master key found
in the log file. The messages just before this would shed more light on the actual problem.
What this is saying is that the client tried to go out to the server to find an image-master.tar.xz keyring file, but there was some problem in downloading that file. Either it didn't exist on the server, or the json data didn't match (the model or type was wrong, or there was an expiry key containing a past timestamp), or the actual signature on the .tar.xz didn't match the associated .tar.xz.asc file.
In all likelihood this was a problem on the server which subsequently got repaired. The client will self-correct.
I can see where the exception is misleading. Probably it's better to re-raise the original exception, though it's always going to be the case that the log file will contain more useful details.