subiquity installer-shell sometimes behave differently (on s390x)

Bug #1855431 reported by Frank Heimes
44
This bug affects 9 people
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/[fingerprint])" and it looks like the command got stuck.
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/[fingerprint])" AND doing a Ctrl+d (aka ^D aka EOF) afterwards I was able to proceed!

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.

Revision history for this message
Frank Heimes (fheimes) wrote :
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

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?

Revision history for this message
Frank Heimes (fheimes) wrote :

I agree - I'm puzzled, too =)
Here is the output (please remember install failed - no Ctrl+d issue, install successful Ctrl+d issue).

Frank Heimes (fheimes)
tags: added: req4focal
Frank Heimes (fheimes)
summary: - subiquity installer-shell can behave differently (on s390x)
+ subiquity installer-shell sometimes behave differently (on s390x)
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Is this still happening?

Revision history for this message
Frank Heimes (fheimes) wrote :

Hi, yes, saw it just yesterday with 19.12.2.
Briefly discussed that with xnox, but we didn't had an immediate idea why that happens.
Tried it now with 19.12.2+git43.a18d6b67 and still face it.

Revision history for this message
Frank Heimes (fheimes) wrote :

I restarted testing subiquity and with the latest ISO (time stamp March 11th) and having subiquity updated to "edge" I don't see this issue anymore - neither on a successful or failed installation.
Hence I'm changing the status to (for now) Fix Committed, until the current installer in development (edge) has landed in a daily-live image.

Changed in subiquity:
status: New → Fix Committed
Changed in ubuntu-z-systems:
status: New → Fix Committed
Revision history for this message
Frank Heimes (fheimes) wrote :

With subiquity 20.03.2 I don't see this issue anymore - hence, changing status to Fix Released.

Changed in subiquity:
status: Fix Committed → Fix Released
Changed in ubuntu-z-systems:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.