Unable to switch to console/ttys from ubiquity

[Franz Hsieh]

In previous Ubuntu release, I am able to switch to console/ttys while installing the system. However it is impossible to switch console/ttys on 16.04 daily images.

Steps to reproduce the issue:

1) Choose 'Install Ubuntu' option in DVD boot menu.
2) After Ubiquity brings up, press Ctrl-Alt-F1
3) Black screen, no prompt is shown

Ubuntu Xenial (daily image)
Release: 16.04
ubiquity:
  Installed: 2.21.53
  Candidate: 2.21.53
  Version table:
 *** 2.21.53 0
        500 http://archive.ubuntu.com/ubuntu/ xenial/main amd64 Packages
        100 /var/lib/dpkg/status

[Mathieu Trudel-Lapierre (cyphermox)]

This is only broken in the only-ubiquity case (ie. when you pick "Install" rather than "Try") and was already broken in wily release.

That said, it's on my list of things to fix for this cycle, it's just kind of cosmetic so not the top priority. I'll see what I can do, I wasn't that far from making it work.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 2.21.56

---------------
ubiquity (2.21.56) xenial; urgency=medium

  * Update translations from Launchpad. (LP: #1569232)
  * debian/ubiquity.ubiquity.service: Start console ttys for debugging during
    an installation. (LP: #1567194)
  * data/oem-config.target: also enable console TTYs for the OEM configuration
    target/service.

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 12 Apr 2016 21:42:50 -0400

[Martin Pitt (pitti)]

This change (http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6411.2.2) does not actually help to fix this bug, as "After=" does not do anything about adding new dependencies, it controls ordering only. Thus there are still no VTs during maybe-ubiquity, thus reopening this bug.

That change also caused bug 1570901.

[Martin Pitt (pitti)]

This isn't actually easy to fix with our current dependency layout -- ubiquity has "Before=plymouth-quit-wait.service" and getty@.service has "After=plymouth-quit-wait.service", i. e. right now we sort ubiquity ← plymouth ← getty. Thus we can't possibly start getty before/with ubiquity, we need to re-think how we insert/use plymouth here.

[Martin Pitt (pitti)]

For the record: The "Before=plymouth-quit-wait.service" was introduced in http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6363 to fix bug 1527353.

[Martin Pitt (pitti)]

> "After=" does not do anything about adding new dependencies

sorry, that was unclear. I meant to say "anything about starting new services". Also, we don't actually need to do that, getty and the others are already waiting to start, we just currently force ubiquity to run before those.

[Martin Pitt (pitti)]

Pasting the important bits from some private email conversation here, for posterity.

My reply:
------------ 8< ------------
At the moment we told the boot sequence these two:

 * ubiquity runs before stopping plymouth since
   http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6363

 * We must start gettys after stopping plymouth as otherwise they
   would disrupt the plymouth VT.

Thus transitively we said "run ubiquity before gettys". If we want to
stop doing that, we must either drop one of these two, or pin plymouth
to VT7 (not sure where it's running ATM, but this would mean even more
VT switches, increasing the flicker) or stop using plymouth for
ubiquity-only mode. The latter might be an option?

We haven't really discussed this bug after the 16.04 release week, as
it seems fairly low-priority: if you want to do other things while the
installing, just start the live desktop session and run ubiquity from
there.
------------ 8< ------------

Mathieu's reply:

TBH, I think the second solution is probably best (along with making sure
plymouth runs on the right VT, which is likely 7). This would allow us to
bring up the gettys in background and have them ready when plymouth finally
quits, as you can sometimes run into a blank VT for server installs with no
getty appearing -- I'm thinking this might actually be fixed by such a
change as well.

[Dimitri John Ledkov (xnox)]

Unlike installed desktops, we do not appear to be booting with vt.handoff=7 this is what should be putting plymouth on vt7, not switching and starting ubiquity there.

Similar to lightdm.service, I find that: Requires=getty.target; <email address hidden>; <email address hidden> => results in working tty2-6, only-ubiquity on tty1, and live session on tty7 (if e.g. one "quits" only-ubiquity). After=systemd-user-sessions.service would not hurt either, however, in practice, it is not needed, as that one starts whilst ubiquity is starting up/running.

[Dimitri John Ledkov (xnox)]

Actually, ubiquity used to be on vt7, why is it ending up on vt1? start-ubiquity-dm should be starting on tty7...

With: kernel cmdline vt.handoff=7, <email address hidden>, <email address hidden>, Requires=getty.target, eding ubiquity-dm active_vt() function to just return int(7) => boot takes forever, ubiquity comes up on vt7. There are systemd messages on vt1 and can login on vt2-6. Horum, something is odd, plymouth should be on vt7 too.

[Dimitri John Ledkov (xnox)]

1) change initramfs plymouth init-premount hoook to parse /proc/cmdline and pass --tty=/dev/tty$N where $N is vt.handoff=$N

2) change ubiquity to require getty.target, and be after getty.target, and after <email address hidden>, and conflict with <email address hidden>

3) test images with above

4) change image build process to specify vt.handoff=7 on the cmdline & profit.

I thought plymouthd used to parse vt.handoff in the past, no?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mark Brown (mstevenbrown)]

Is there any estimate of a fix for this? We have a couple of OEMs affected.

[Steve Langasek (vorlon)]

Fixed in ubiquity 18.04.5.

[Yuan-Chen Cheng (ycheng-twn)]

$4, can you update the status if oem-priority per your test result when convenient ?

[Shih-Yuan Lee (fourdollars)]

I can switch to console/ttys from ubiquity on the latest daily xenial and bionic images.
However we still need to add systemd.debug-shell manually to the kernel parameter to enable the debug shell in tty9.