subiquity installer-shell sometimes behave differently (on s390x)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Fix Released
|
High
|
Canonical Foundations Team | ||
subiquity |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
While working on LP 1854965 I figured out that depending on the situation when a shell is opened in subiquity (on s390x) it can behave differently.
1) If a subiquity installation FAILED and one enters the shell, ssh (and other things like ftp...) work FINE. Hence log or crash files can copied over to another system via scp.
2) But if the installation is SUCCESSFUL and if one enters the shell on the final (reboot) screen, ssh does NOT seem to work as expected.
It looks like the shell is not reacting properly on ssh or scp questions like "Are you sure you want to continue connecting (yes/no/
Verbose mode or logs didn't show any useful information - hence it looked like Ctrl+c (SIGINT) is the only option.
Accidentally I found out that after having typed 'yes' on "Are you sure you want to continue connecting (yes/no/
Initially I thought it could be a problem with the "Integrated ASCII Console" itself - but it's not, since it works in both cases 1) and 2).
It looks like in cases 1) and 2) different environments are generated - interestingly the one at the end of a successful installation should be a proper one, but that's the one where things fail (or Ctrl+d is needed).
Looks like the used ttys are in both cases the same (/dev/ttysclp0 -- vt220), so there is no difference.
But env (or export) shows different environments.
Please see the attached doc for more details and output ...
subiquity 19.11.1 as part of 20.04 daily live ISO form Dec 2nd 2019 was used.
Btw. this is probably related to LP 1855311.
tags: | added: req4focal |
summary: |
- subiquity installer-shell can behave differently (on s390x) + subiquity installer-shell sometimes behave differently (on s390x) |
That's ... strange. I wonder if we have two processes trying to read from the console. The next time this happens can you run lsof and ps aux (lsof will probably produce quite a lot of output) before you control d anything?