* Open the permissions on the socket
Installer clients can be non-root.
Installer clients run in an environment where root is just a
password-less sudo away.
* Same permissions on the other socket also
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.