Ubuntu GNOME Xenial iso briefly boots to tty1, then demands password, and installer may quit & drop to login screen

[Erick Brunzell]

### Updated bug description

Testing the 16.04.1 release candidates I've encountered the above with both Intel ® GMA4500 and nVidia GeForce 7025 / nForce 630a graphics chips when booting from the standard boot menu. If the iso boots to the login screen I can simply click on Live Session User w/o entering any password and get to a functional live DE.

I've also encountered installer "crashes" where the installer seemingly just dies (maybe when the screensaver activates) and after rolling up the blinds I find that I've landed back at the login screen. In this case the simple workaround is to start the installation from the advanced boot menu.

Selecting either Try Ubuntu GNOME without changes or Install from the advanced boot menu works perfectly fine without the need to edit or add any boot parameter.

This does not affect Ubuntu, so it seems to be Ubuntu GNOME specific.

### Original bug description

Testing Ubuntu GNOME Xenial 20160222.1 amd64 and I find that selecting Try Ubuntu GNOME from the standard boot menu displays TTY 1 and requests a username but the keyboard appears to enter no text. It will however eventually boot to the login screen. After several tries I find the following steps reproduce the behavior:

(1) Boot Ubuntu GNOME Xenial live image, wait for the standard boot menu to appear, and select Try Ubuntu GNOME.
(2) You'll find that the screen displays TTY1 + requesting a user name.
(3) Do nothing and wait 2 to 3 minutes after which a GUI login screen appears.
(4) Click on Live session user and a new screen appears requesting a password.
(5) Enter nothing and press Enter and you'll finally get to the live desktop.

I was going to upload some pics of what happens but I'm unable to mount my camera in the live session.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: casper 1.367
ProcVersionSignature: Ubuntu 4.4.0-6.21-generic 4.4.1
Uname: Linux 4.4.0-6-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CasperVersion: 1.367
CurrentDesktop: GNOME
Date: Tue Feb 23 14:58:37 2016
LiveMediaBuild: Ubuntu-GNOME 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160222.1)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: casper
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.casper.conf: 2016-02-23T14:53:15.379536

[Ubuntu QA Website (ubuntuqa)]

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://iso.qa.ubuntu.com/qatracker/reports/bugs/1548864

[Erick Brunzell (lbsolost)]

Also affects Ubuntu GNOME Xenial 20160222.2 but I was wrong in part of my assumption so I'll edit my original comment.

[Tim Lunn (darkxst)]

I could not reproduce this under VMware, can you attach journal logs from the affected system?

[Erick Brunzell (lbsolost)]

I have my dunce cap on tonight :^( What journal logs? Path to log would be nice, thanks.

[Tim Lunn (darkxst)]

just grab the output from journalctl

journalctl &> journal.log

[Tim Lunn (darkxst)]

this may also be related to upower bug that is causing problems on laptop, apparently removing battery helps in that case.

[Erick Brunzell (lbsolost)]

The 20160224.2 amd64 image is much, much better! The tty1 login screen appears only very briefly - under 30 seconds - and then the image boots to the live DE as it should. So we could probably consider this fixed but I'll leave it open and see what happens with future images between now and final.

[Brian Murray (brian-murray)]

Setting to incomplete pending further testing.

[Erick Brunzell (lbsolost)]

This is back in all its glory in Ubuntu GNOME 20160225.1 amd64. It boots to a screen showing tty1, then if you wait about 3 minutes the login screen appears and you can login with no password. I'll follow up with journalctl info later, right now I'm checking on more serious bugs.

I do notice some difference in behavior with different hardware. On these two sets of hardware the behavior is as described above:

(1) Intel Pentium Dual-Core E5300 @ 2.60GHz w/Intel GMA4500 Graphics
(2) Intel Atom 230 @ 1.60GHz w/Intel 82945G/GZ Graphics

On this third set of hardware I get the tty1 screen but all I have to do is wait a minute or so and booting to the live DE proceeds w/o ever displaying the login screen:

(3) AMD Sempron LE-1250 @ 2.2 GHz w/nVidia C61 [GeForce 7025 / nForce 630a]

As stated above this seemed to be fixed for a few builds but is sadly now back.

[Erick Brunzell (lbsolost)]

Info as requested. The tty1 screen appears around 17:45 and the login screen(s) pop up around 17:47.

[Tim Lunn (darkxst)]

IS this the same hardware that you see the garbled images on?

I see this in the logs, that would be a kernel bug
Feb 25 17:45:14 ubuntu-gnome /usr/lib/gdm3/gdm-x-session[3595]: [intel_init_bufmgr:1092] Error initializing buffer manager.
Feb 25 17:45:14 ubuntu-gnome acpid[1021]: client connected from 3597[0:0]
Feb 25 17:45:14 ubuntu-gnome /usr/lib/gdm3/gdm-x-session[3595]: (EE) AIGLX error: Calling driver entry point failed
Feb 25 17:45:14 ubuntu-gnome /usr/lib/gdm3/gdm-x-session[3595]: (EE) AIGLX: reverting to software rendering
Feb 25 17:45:14 ubuntu-gnome /usr/lib/gdm3/gdm-x-session[3595]: (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
Feb 25 17:45:14 ubuntu-gnome acpid[1021]: 1 client rule loaded
Feb 25 17:45:14 ubuntu-gnome /usr/lib/gdm3/gdm-x-session[3595]: (II) AIGLX: Loaded and initialized swrast
Feb 25 17:45:14 ubuntu-gnome /usr/lib/gdm3/gdm-x-session[3595]: (II) GLX: Initialized DRISWRAST GL provider for screen 0

[Tim Lunn (darkxst)]

Feb 25 17:45:15 ubuntu-gnome gnome-session[3606]: [intel_init_bufmgr:1092] Error initializing buffer manager.
Feb 25 17:45:15 ubuntu-gnome gnome-session[3606]: libGL error: failed to create dri screen
Feb 25 17:45:15 ubuntu-gnome gnome-session[3606]: libGL error: failed to load driver: i965

[Erick Brunzell (lbsolost)]

"IS this the same hardware that you see the garbled images on?"

Yes, one set is, but bug #1507255 has been fixed since about the 4.4.0-6-generic kernel.

I don't have access to that hardware at this moment but I will have again later tonight of tomorrow.

[Tim Lunn (darkxst)]

24.2 had a new kernel, but all later images have the same, I can't see anything that changed since that would affect this.

I'm susprised you are seeing this on three different systems, but there havent been any other reports of this. It may be different bugs that all cause Xorg to fail loading.

Is it only happening on the Live images? or also on installed system? You certainly shouldnt see the user menu when booting a live session and if you do that means presumable that gdm has been respawned at some point after the failure.

Might be worth testing with a newer kernel, either latest mainline or the 4.4 in -proposed atm.

[Erick Brunzell (lbsolost)]

I tested both Ubuntu and Ubuntu GNOME 20160226 amd64 images and they're good. Well, to be really picky the Ubuntu GNOME image does show the tty1 text very briefly like in bug #557000. That's been a very minor issue as long as I can remember. I've never seen it on a live image before but I still see it on every cold boot of my production machines running Trusty.

It's really a fake tty1 prompt because you can't enter anything or log in to a shell, and in most cases it's gone within just a few seconds. The exception has been with some recent Ubuntu GNOME images where that tty1 text appears on a black screen just before the live DE displays. It's odd that some images have been OK and some have not since about the 21st.

Hopefully it won't rear its ugly head again, in which case we can just mark this fix released.

[Tim Lunn (darkxst)]

Lance, At which part of the boot process does the tty1 flash up, before or after plymouth animation?

[Erick Brunzell (lbsolost)]

I would say just at the end of the plymouth animation. On installed systems I've never seen it appear longer than 5 to 10 seconds. Unless you're sitting and watching the boot process you'd never know it happens. Even during this extended 2 to 3 minute period of display we've seen with some of the live images it's not possible to enter anything using the keyboard, so it's just like something is running in the background and sits there pondering its next move for a moment..

I have tried with the recent "bad" images booting from the advanced boot menu with quiet splash removed and I didn't see anything of interest. If this crops up again with the live images I'll try and grab some pics. With any luck this will become a non-issue.

[Tim Lunn (darkxst)]

so what should happen on an installed system, is that gdm will stop plymouth but leave the splash up on the screen (animation stops), Then there should be a seamless transition to Xorg or wayland, though perhaps wayland doesnt yet support that, however its also not installed by default.

The live session is slightly different in that is uses ubiquity-dm to launch the greeter, but I think it has all the same logic as gdm.

There is a plymouth-quit service that shouldnt run atleast when using gdm, but if it did would cause the spash to disappear, you could try

systemctl disable plymouth-quit.service
sytemctl mask plymouth-quit.service

and see if that helps (undo changes using enable/unmask commands)

Alternatively it could be a driver specific Xorg bug, not handling the background transition properly

[Erick Brunzell (lbsolost)]

With Ubuntu GNOME 20160323.1 amd64 step #5 of this behavior changed:

(1) Boot Ubuntu GNOME Xenial live image, wait for the standard boot menu to appear, and select Try Ubuntu GNOME.
(2) You'll find that the screen displays TTY1 + requesting a user name.
(3) Do nothing and wait 2 to 3 minutes after which a GUI login screen appears.
(4) Click on Live session user and a new screen appears requesting a password.
(5) Enter nothing and press Enter and you'll finally get to the live desktop.

A password is now demanded, just leaving it blank and pressing enter does nothing.

[Erick Brunzell (lbsolost)]

Booting Ubuntu GNOME 20160323.1 amd64 from the advanced boot menu works OK so this is not a huge deal. We'd just want to mention it in the release notes.

[Erick Brunzell (lbsolost)]

This affects two totally different sets of hardware using the Ubuntu GNOME 20160323.1 amd64 image:

(1) AMD Sempron LE-1250 @ 2.2 GHz w/nVidia C61 [GeForce 7025 / nForce 630a]

(2) Intel Pentium Dual-Core E5300 @ 2.60GHz w/Intel GMA4500 Graphics

And it's worse because after waiting 2 to 3 minutes for that tty1 prompt to disappear you're asked for a password and just leaving it blank doesn't work.

The only way I've found to get these images to work is to boot from the advanced boot menu. Booting the image in EFI mode it works fine. I wish we'd just stop hiding the advanced boot menu ;^)

[Tim Lunn (darkxst)]

This is really 2 seperate issues

First, ubiquity-dm is failing to load, due to some presumably racy GPU issue. I then guess casper has not run yet, so the autologin settings are not yet applied. Finally after some delay systemd decides to spawn gdm.

The second issue I have file as Bug 1561302. gdm currently won't allow for passwordless login

[Tim Lunn (darkxst)]

Can you boot with "debug-ubiquity" on the kernel command line, and then grab the ubiquity logs (/var/log/installer). Also fresh journal logs could be helpful.

[Tim Lunn (darkxst)]

I think i mis-read re comment #23, so you do see the Try Ubuntu screen (ubiquity-dm), so casper should have run (can you check if autologin options are enabled in /etc/gdm3/custom.conf.

From your previous journal logs it looks like gdm is spawned 3 times with the first 2 failing. Though I can't really see what is different between the first 2 and the last. Still would like to see the new logs (there has been a new Xorg and kernel since last time)

DRI is broken in all three (Comment #13), which means hardware GL will always be broken. You should probably file a kernel bug for that as its likely hardware specific. Does OpenGL rendering work on an installed desktop system or when you boot from advanced menu? This isnt likely to be causing the issue, it should fallback to software rendering, although sometimes maybe it doesnt. Also gnome-shell can be quite laggy with software rendering on weaker hardware

[Erick Brunzell (lbsolost)]

I don't know how I'd ever collect any logs from this current borkage because the only way you can get to the live DE is by rebooting and selecting the desired boot option from the advanced boot menu. Possibly if I were using a live USB with persistence the failed boot would be logged somewhere?

I'm fried right now and just headed off to bed but I'll try Ubuntu itself tomorrow and see what happens with it. If it can't be reproduced on another flavor would it still be a kernel issue? Seems odd that it would affect two vastly different sets of hardware in exactly the same way.

[Erick Brunzell (lbsolost)]

Oh, how would booting with "debug-ubiquity" show anything since the image boots normally from the advanced boot menu? These errors only occur when booting from the standard boot menu.

[Tim Lunn (darkxst)]

switch to VT and then copy them onto a USB or mount some other hdd partition.

I expect the kernel bug will still be there, but lightdm seems to handle software fallback better, so you probably won't notice without checking the logs.

ubiquity displays the "Try Ubuntu greeter", I asked for those before I realised it was working. I think it also runs casper to set autologin and other session customisations, so maybe useful in that sense.

[Tim Lunn (darkxst)]

btw I can't reproduce this on my laptop which has Intel GM45 graphics (I think that is the same generation gpu as your GMA4500)

[Erick Brunzell (lbsolost)]

The 20160327 amd64 image is working just fine on both of the aforementioned sets of hardware.

[Tim Lunn (darkxst)]

Lance, are you still getting the DRI errors (Comment #13) on that image?

[Erick Brunzell (lbsolost)]

Just checked 20190329 amd64 and all still seems well other than some unrelated and known installer bugs :^)

I did produce a journal.log so I'm attaching that. I see a number of "Error retrieving chunk extents: Operation not supported" but I'm unsure what any of those really mean. Is it possible to use grep to locate any DRI errors?

[Tim Lunn (darkxst)]

journalctl | grep intel_init_bufmgr

they are still there, which presumably means you are still on llvmpipe software rendering.

[John Przybytek (jprzybytek)]

I'm getting this only from a machine boot from a DVD but not from an iso in VirtualBox

[Launchpad Janitor (janitor)]

[Expired for casper (Ubuntu) because there has been no activity for 60 days.]

[Erick Brunzell (lbsolost)]

Still affects the 16.04.1 candidates with this hardware:

AMD Sempron Processor LE-1250 @ 2.2 GHz
nVidia C61 [GeForce 7025 / nForce 630a] (rev a2)
nVidia MCP61 High Definition Audio (rev a2)
nVidia MCP61 Ethernet (rev a2)
2GB DDR2 RAM

Not sure what other info is needed.

BTW I'll be AFK for several hours but I'll follow up on this ASAP.

[Launchpad Janitor (janitor)]

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