Today’s live-server installer (the one with serial 20180320) does not work because subiquity never starts. subiquity’s logs show that it is getting permission denied when reading from stdin, which is a bit surprising to say the least!
There are apparmor denials in syslog like this:
Mar 21 01:41:11 ubuntu-server kernel: [ 1919.759983] audit: type=1400 audit(1521596471.871:78): apparmor="DENIED" operation="file_inherit" profile="/usr/lib/snapd/snap-confine" name="/dev/tty1" pid=2566 comm="snap-confine" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
which definitely seem related. Switching snap-confine’s apparmor over to complain mode lets subiquity start.
I’ve done some digging into what’s going on and it’s a bit strange. (Hi @jdstrand!)
The way subiquity starts (or is supposed to start) is that the subiquity snap defines a systemd service which runs a shell script that does some setup and then invokes “/sbin/agetty -n --noclear -l /snap/bin/subiquity tty1 $TERM”, “/snap/bin/subiquity” being another command defined by the snap.
It seems to be this invocation of a snapped command from within another shell script that is under classic confinement. If I put just “/sbin/agetty -n --noclear -l /snap/bin/subiquity tty1 $TERM” in a shell script and invoke it, subiquity starts as expected. If I copy a profile snapd wrote for a classically confined command and hack it to apply to the shell script, subiquity does not start. This seems wrong as I thought classic confinement was basically meant to let you do anything!
Having written all this out, I think I can work around it (by having my shell script invoke $SNAP/usr/bin/subiquity, not /snap/bin/subiquity) but this all smells wrong.