example:
$ curl --unix-socket .subiquity/socket a/dry_run/crash
Traceback (most recent call last):
File "/home/mwhudson/src/subiquity/subiquity/common/api/server.py", line 122, in handler
result = await implementation(**args)
File "/home/mwhudson/src/subiquity/subiquity/server/dryrun.py", line 24, in crash_GET
1/0
ZeroDivisionError: division by zero
The subiquity client does not ask about language in non-rich mode on a
serial port, and that's OK. But we still need the install to complete :)
There are other ways to fix this I guess -- we could not wait on the
locale model to get configured, for example, or explicitly select a
C.UTF-8 locale when "Continue in basic mode" is selected, or probably
some other things. But this works and seems OK.
* locale - let it check interactive-sections again
* Turn Serial into a whole new screen
When in serial, first offer the rich/basic choice (or SSH button),
and only show the current welcome screen if we choose rich mode.
Add a back button on Welcome if we are on serial.
LP: #1919251
* Drop the confirm_ssh_keys call if UI not as expected
There is a larger problem here of the UI body changing underneath of us,
but this is at least a baby step in the right direction.
Also this matches existing client/controllers/ssh.py behavior.
At least log the event when it happens.
LP: #1925048
* lint
https://bugs.launchpad.net/subiquity/+bug/1925068 reports a crash that
fails with the "self.global_overlays.remove(overlay)" in
remove_global_overlay failing because the overlay is not in the list. I
don't know how it happened but staring at the code I did guess one way
this could happen: if you have two non-interactive screens in a row
where the requests both take long enough to trip the 0.1s threshold to
show the progress screen, app.ui.set_body will get called twice with the
same view. Each call will layer all global overlays over the view, so
doing it twice will show the views twice.
This all makes me thing that the way global overlays are shown is a bit
wrong -- they should be "outside" the controller-supplied view! -- but,
well, it's easy enough to make sure that calling set_body twice with the
same view doesn't cause this particular problem.
Caller to guided_GET can now specify a minimum size disk that is
acceptable for guided partitioning. The unit is bytes.
The default value if this is unspecified is 6GiB.
Note that this default value is wholly inadequate for Desktop, which by
my measurements needs at least 8GiB to get the install completed if you
tell it to install everything, even though later it settles to a lower
installed size of 6.6GiB.
This fixes a problem where you drop to a shell and refresh subiquity
from that shell -- the client tries to restart but it is running in the
background and so crashes trying to modify the terminal settings. So
this kills the subprocess before restarting. This required the extremely
angry PR I sent before: forcefully killing the subprocess also crashes
the client before restart in a similar way.
* Add element updates (non-UI)
This can be controlled with autoinstall
updates: security or all
Also an API for controlling this:
curl --silent --unix-socket .subiquity/socket a/updates ->
"security"
curl -d '"all"' --unix-socket .subiquity/socket a/updates
* Automated tests - log grep for default/none/all states
* Enforce possible values on Updates controller
Route all the various get/set thru 2 common functions.
Validate incoming data.
Splitting subiquity into server and client means that in general
old versions of the client can still be running when the server is
updated (the client running on tty1 will be restarted by snapd/systemd
when the snap is updated but clients running via e.g. ssh will not). I
implemented a way for the client to detect this and restart itself: the
server sets a header in all responses that indicates if it has been
updated. So far so good. But the way it knows that it has been updated
is to check the presence of a file that is only created when subiquity
itself triggers the refresh, so it's not there in the case of manual
refresh, and as reported in https://bugs.launchpad.net/bugs/1921820 this
can lead to the client crashing because it cannot parse the new server's
response. This simply changes to creating the marker file in the snap
post-refresh hook, which will be executed for manual snap refreshes as
well.
While I'm at it, remove the rest of the post-install hook that restarted
subiquity clients running on the serial line as the generic machinery
will work for these too.
I checked the lszdev source and for all the other fields that we are
assume are boolean, it can only output "yes" or "no". Today, at least --
not sure how to make sure this is not broken by future changes. Still
this is a help.
for https://bugs.launchpad.net/subiquity/+bug/1919420
The NAME_REGEX currently used is "[a-z_][a-z0-9_-]*" which does correctly prevent hostnames starting with a hyphen.. but also prevents otherwise perfectly valid hostnames that start with a number. (Interestingly, an underscore is not defined as a valid hostname character, but is included as valid in the regex, I'm not sure why this is included but am leaving it in for backwards compatibility)
This patch adds 0-9 as valid characters at the start of a hostname, as per https://man7.org/linux/man-pages/man7/hostname.7.html#:~:text=Valid%20characters%20for%20hostnames%20are,to%20an%20address%20for%20use.
Each element of the hostname must be from 1 to 63 characters long
and the entire hostname, including the dots, can be at most 253
characters long. Valid characters for hostnames are ASCII(7)
letters from a to z, the digits from 0 to 9, and the hyphen (-).
A hostname may not start with a hyphen.
Michael Hudson-Doyle