There are two places that remove from this list, and the current arm64
crash is running into a scenario where we try to remove from the
overlays list only to find that it's not actually there.
So don't remove if it's already gone.
`make dryrun` will now use the simple sample machine config instead of
probing local hardware. That local probe only seems to be viable
anyhow if we're running as root, and that's vulnerable to real problems
if dryrun is less than 100% insulated from making real machine changes.
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
https://bugs.launchpad.net/subiquity/+bug/1927103 reports a regression
where a subiquity-installed system has a swapfile even if a swap
partition has been explicitly configured.
The reason this broke is that previously subiquity tracked whether a
swap file should be allowed or not by keeping track of whether a swap
partition was mounted in add_mount / remove_mount. But since the
client/server split, those methods aren't called in the server process
any more.
Just get rid of all the cleverness and call _should_add_swapfile when
rendering the curtin config.
otherwise, especially on a serial console, there is not really any way
to debug what is going on.
also, when non-interactive defer setting the applicationstate to ERROR
until the information in the error report has been collected and the
error-commands have run.
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.
The pool is loaded off the same media as the installer and the
filesystem being installed so there's no real loss of security doing
this and it makes it easier for people to master custom ISOs with extra
packages in the pool and systems with inaccurate clocks (that cannot
reach ntp.ubuntu.com).
* 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.
Here is something you can try with a live server installer today: drop
into a subshell and type "kill -9 $$". The installer will crash with an
'Input/output error' from tcsetattr.
What's going on is some deep unix arcana: when the subshell exits via
signal somehow the shell's process group is still in the foreground
(even though there are no processes in it?) and calling tcsetattr() from
a background process is not allowed. So the fix for this is reasonably
simple (or at least: short): call tcsetpgrp() to put our process group
back into the foreground. A background process doing this gets sent
SIGTTOU, but if we ignore that, all is well.
Frankly this is all very strange and I would like a lie down now.