Cd menu not booting to ubiquity try/install menu but always to live session
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| ubiquity |
Fix Released
|
Undecided
|
Martin Pitt | |
| ubiquity (Ubuntu) |
Critical
|
Martin Pitt |
Bug Description
STEPS:
In normal bios/uefi in legacy mode you do not get the menu item to select install or try instead it boots to the live session instead.
If I interrupt the system at the keyboard and select install which would normally go straight to the ubiquity session installer it instead goes to the live session.
This is likely an issue in systemd setup.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ubiquity 2.21.57
ProcVersionSign
Uname: Linux 4.4.0-18-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CasperVersion: 1.372
CurrentDesktop: Unity
Date: Fri Apr 15 14:28:33 2016
InstallCmdLine: file=/cdrom/
LiveMediaBuild: Ubuntu 16.04 LTS "Xenial Xerus" - Beta amd64 (20160414)
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)
Related branches
Dave Morley (davmor2) wrote : | #1 |
Changed in systemd: | |
assignee: | nobody → Martin Pitt (pitti) |
Changed in ubiquity (Ubuntu): | |
assignee: | nobody → Mathieu Trudel-Lapierre (cyphermox) |
summary: |
- Cd menu not bootingto ubiquity try/install menu but always to live + Cd menu not booting to ubiquity try/install menu but always to live session |
Ubuntu QA Website (ubuntuqa) wrote : | #3 |
This bug has been reported on the Ubuntu ISO testing tracker.
A list of all reports related to this bug can be found here:
http://
tags: | added: iso-testing |
Kev Bowring (flocculant) wrote : | #5 |
Seen in hardware as well as virtual.
sudodus (nio-wiklund) wrote : | #9 |
I tested Lubuntu xenial-
With the boot options 'quiet splash' the bug pushes to 'Try Lubuntu' even when 'Install Lubuntu' was selected in the grub menu.
But without 'quiet splash', the system arrives at the 'Install Lubuntu' desktop with Ubiquity and without the panel and icons. So with this work-around the bug is grey, not red.
The reason for this comment is that many issues for DVD systems are also found for cloned USB systems, while grub booted systems may behave in a different way.
affects: | systemd → ubiquity |
Changed in ubiquity (Ubuntu): | |
importance: | Undecided → High |
Tim Lunn (darkxst) wrote : | #10 |
I am only getting the ubiquity greeter on about 1 in 3 boots, the rest of the time it boots straight through to the live session.
● ubiquity.service - Ubuntu live CD installer
Loaded: loaded (/lib/systemd/
Active: inactive (dead) since Mon 2016-04-18 00:51:14 UTC; 5min ago
Process: 1430 ExecStart=
Main PID: 1430 (code=exited, status=0/SUCCESS)
Apr 18 00:51:08 ubuntu-gnome systemd[1]: Starting Ubuntu live CD installer...
Apr 18 00:51:10 ubuntu-gnome python3[1438]: pam_unix(
Apr 18 00:51:14 ubuntu-gnome start-ubiquity-
Apr 18 00:51:14 ubuntu-gnome start-ubiquity-
Apr 18 00:51:14 ubuntu-gnome start-ubiquity-
Apr 18 00:51:14 ubuntu-gnome start-ubiquity-
Apr 18 00:51:14 ubuntu-gnome systemd[1]: Started Ubuntu live CD installer.
Xorg.0.log has this
[ 21.630] (WW) xf86OpenConsole: VT_ACTIVATE failed: Input/output error
[ 21.630] (EE)
Fatal server error:
[ 21.630] (EE) xf86OpenConsole: Switching VT failed
[ 21.630] (EE)
[ 21.630] (EE)
Please consult the The X.Org Foundation support
at http://
for help.
[ 21.630] (EE) Please also check the log file at "/var/log/
[ 21.630] (EE)
[ 21.630] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error
[ 21.630] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error
[ 21.630] (WW) xf86CloseConsole: VT_ACTIVATE failed: Input/output error
[ 21.630] (EE) Server terminated with error (1). Closing log file.
sudodus (nio-wiklund) wrote : | #11 |
Tim's observation "I am only getting the ubiquity greeter on about 1 in 3 boots, the rest of the time it boots straight through to the live session" and an observation that I made running without quiet splash, makes me think it is some kind of timeout or race condition.
I saw something counting down (in the text screen during booting. It might make a difference if that countdown will finish or not, and I think that things are faster without splash.
Martin Pitt (pitti) wrote : | #12 |
I confirm that booting the current desktop image in QEMU (qemu-system-x86_64 -m 2048 -cdrom xenial-
Going to VT1 and showing the journal shows that there is a dependency cycle between plymouth, ubiquity, and getty, which prevents ubiquity.service from starting:
plymouth-
Martin Pitt (pitti) wrote : | #13 |
>takes reeeally long to get to the live system [...] and the load is at 6.
Ignore this part, that was just because I forgot "-enable-kvm".
> Also, keyboard and mouse are broken in the live session
I'm still trying to figure out this. Annoyingly it works if I use the serial console (QEMU option "-serial stdio" and kernel option "console=ttyS0"). In one boot I had X.org use VT1, which would collide with getty on VT1 that we always start (as in Debian/Ubuntu we usually want the first X.org on VT7).
Interestingly, when I do that ubiquity.service actually does start, but fails to connect to X:
● ubiquity.service - Ubuntu live CD installer
Loaded: loaded (/lib/systemd/
Active: inactive (dead) since Mon 2016-04-18 10:33:09 UTC; 4min 23s ago
Process: 1238 ExecStart=
Main PID: 1238 (code=exited, status=0/SUCCESS)
Apr 18 10:32:57 ubuntu systemd[1]: Starting Ubuntu live CD installer...
Apr 18 10:32:59 ubuntu python3[1242]: pam_unix(
Apr 18 10:33:09 ubuntu start-ubiquity-
Apr 18 10:33:09 ubuntu start-ubiquity-
Apr 18 10:33:09 ubuntu start-ubiquity-
Apr 18 10:33:09 ubuntu start-ubiquity-
Apr 18 10:33:09 ubuntu systemd[1]: Started Ubuntu live CD installer.
Apr 18 10:33:03 ubuntu ubiquity[1556]: Ubiquity 2.21.57
Apr 18 10:33:04 ubuntu ubiquity[1556]: Exception in GTK frontend (invoking crash handler):
Apr 18 10:33:04 ubuntu ubiquity[1556]: Traceback (most recent call last):
Apr 18 10:33:04 ubuntu ubiquity[1556]: File "/usr/lib/
Apr 18 10:33:04 ubuntu ubiquity[1556]: main(oem_config)
Apr 18 10:33:04 ubuntu ubiquity[1556]: File "/usr/lib/
Apr 18 10:33:04 ubuntu ubiquity[1556]: install(
Apr 18 10:33:04 ubuntu ubiquity[1556]: File "/usr/lib/
Apr 18 10:33:04 ubuntu ubiquity[1556]: wizard = ui.Wizard(distro)
Apr 18 10:33:04 ubuntu ubiquity[1556]: File "/usr/lib/
Apr 18 10:33:04 ubuntu ubiquity[1556]: self.watch = Gdk.Cursor.
Apr 18 10:33:04 ubuntu ubiquity[1556]: TypeError: constructor returned NULL
But in this boot, the dependency cycle got broken at plymouth-
Indeed, if I boot with "maybe-ubiquity break=casper-bottom systemd.
- the menu always appears
- ubiquity-dm's X runs at VT1 ! (This explains keyboard/mouse failure, failure to start X and ubiquity-dm)
- Corresponding to the above, there is an "xo...
Martin Pitt (pitti) wrote : | #14 |
This regression was introduced by http://
This change both introduced the dependency cycle, it's pointless (as After= does not do *anything* about starting new units), and thus it does not actually fix bug 1567194. Thus for now I'm going to reopen the latter and revert that change.
Changed in ubiquity (Ubuntu): | |
importance: | High → Critical |
assignee: | Mathieu Trudel-Lapierre (cyphermox) → Martin Pitt (pitti) |
status: | Confirmed → In Progress |
status: | In Progress → Fix Committed |
Changed in ubiquity: | |
status: | New → Fix Released |
Launchpad Janitor (janitor) wrote : | #15 |
This bug was fixed in the package ubiquity - 2.21.58
---------------
ubiquity (2.21.58) xenial; urgency=medium
[ Martin Pitt
* ubiquity.service: Revert commit 6411.2.2 as this does not/can't fix
LP #1567194 but introduces a dependency cycle between getty, plymouth, and
ubiquity. (LP: #1570901)
* Automatic update of included source packages: hw-detect
1.117ubuntu2.
[ Christopher Lee ]
* autopilot-test: Double timeout for CI VM speed.
* autopilot-tests: Now storing results as subunit.
* autopilot-tests: longer timeout to handle CI VMs.
-- Martin Pitt <email address hidden> Mon, 18 Apr 2016 13:25:44 +0200
Changed in ubiquity (Ubuntu): | |
status: | Fix Committed → Fix Released |
I still experience this issue (daily-build 20160417).
Status changed to 'Confirmed' because the bug affects multiple users.