cryptsetup password prompt not shown

[Esokrates]

Currently in utopic the following happens when booting an encrypted setup:

Press enter in grub, after a while screen freezes (or turns completely black) and stays like that. When I press the down key, I can see the password prompt. When I press the up key again, I get to the graphical password prompt.

This is demonstrated in the following screencast:
https://drive.google.com/file/d/0B7EMvd1LJKgZREJocHBueEhpa2s/edit?usp=sharing

Maybe this is related to the version of plymouth utopic currently uses, a similar debian bug report seems to be resolved with a newer version 0.9.0-6, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752752.
---
ApportVersion: 2.14.6-0ubuntu2
Architecture: amd64
DistroRelease: Ubuntu 14.10
InstallationDate: Installed on 2014-08-21 (0 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140821)
Package: plymouth 0.9.0-0ubuntu3
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 3.16.0-9.14-generic 3.16.1
Tags: utopic
Uname: Linux 3.16.0-9-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True
---
ApportVersion: 2.14.6-0ubuntu2
Architecture: amd64
DefaultPlymouth: /lib/plymouth/themes/ubuntu-logo/ubuntu-logo.plymouth
DistroRelease: Ubuntu 14.10
InstallationDate: Installed on 2014-08-21 (0 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140821)
MachineType: Dell Inc. Precision M4600
Package: plymouth 0.9.0-0ubuntu3
PackageArchitecture: amd64
ProcCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-9-generic root=/dev/mapper/VG--Ubuntu-LV--Ubuntu--ROOT ro rootflags=subvol=@ cryptopts=target=Ubuntu,source=/dev/disk/by-uuid/6fc200da-aa04-4e73-b6a7-a2326f0b6204,lvm=VG-Ubuntu quiet splash vt.handoff=7
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-9-generic root=/dev/mapper/VG--Ubuntu-LV--Ubuntu--ROOT ro rootflags=subvol=@ cryptopts=target=Ubuntu,source=/dev/disk/by-uuid/6fc200da-aa04-4e73-b6a7-a2326f0b6204,lvm=VG-Ubuntu quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.16.0-9.14-generic 3.16.1
Tags: utopic
TextPlymouth: /lib/plymouth/themes/ubuntu-text/ubuntu-text.plymouth
Uname: Linux 3.16.0-9-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True
dmi.bios.date: 03/10/2013
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A14
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA14:bd03/10/2013:svnDellInc.:pnPrecisionM4600:pvr01:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr:
dmi.product.name: Precision M4600
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

apport information

[Esokrates (esokrarkose)]

Okay it seems I was wrong, the bug seems not to be as generic, as I got it to work in kvm.

[Esokrates (esokrarkose)]

I played around and found the following:

When setting "GRUB_GFXPAYLOAD_LINUX=1920x1080" (which is my screenresolution) in /etc/default/grub and running "update-grub" the password prompt appears.

Trusty is not affected by this bug on my system, only utopic. I tried trusty and upgraded the kernel to the utopic version, but it still worked.

[Launchpad Janitor (janitor)]

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

[Martin Wimpress (flexiondotorg)]

I have encountered the same issue in Virtualbox guest and on real hardware with a Radeon GPU using the open source drivers.

[Esokrates (esokrarkose)]

It's actually a more generic problem: When I set up a normal install, without encryption, plymouth does not show up either, only when I press down and up again I see the bootsplash. In that case however it is not problematic, since there is no prompt for a password.

I am using the nouveau driver.

Martin, does the workaround of #17 work for you?

[Demetres Vassilakis (demetres-vassilakis)]

I have the same problem. Workaround #17 (setting GRUB_GFXPAYLOAD_LINUX=wxh in /etc/default/grub) works

[Hagen Kuehn (hag-k)]

The workaround highlighted with #21 worked for me.

$ sudo nano /etc/default/grub

Include the following parameter

GRUB_GFXPAYLOAD_LINUX=wxh

$ sudo update-grub

[Dekker500 (dekker-crater)]

Was experiencing the same bug (https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1375435) and this workaround worked for me.

HOWEVER, the GRUB_GFXPAYLOAD_LINUX setting I used was "text" (yes, literally "text"). The wxh was actually supposed to be the graphics resolution "640x480" (see post #17) but for me, that left it in graphical mode and failed to allow me to enter my password. Using "text" forced it into text mode, which works (but is not pretty). At least now I can login on the first boot.

[Mathieu Trudel-Lapierre (cyphermox)]

Is everyone having this bug using nouveau or the free radeon driver?

[Esokrates (esokrarkose)]

nouveau when I observed the bug the last time.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Mathieu Trudel-Lapierre (cyphermox)]

Esokrates, could you try to boot your system after adding 'plymouth:debug' to the kernel command line in grub; and attaching /var/log/plymouth-debug.log; first making sure it doesn't include your passphrase for the disk encryption? If that doesn't trigger the bug, you may need to edit /etc/default/grub to add 'plymouth:debug' there and reconfigure grub.

So, after testing this for a while it looks to me like this is in fact a problem with drm, at least on radeon, and likely on nouveau as well. On my radeon system, it appears that plymouth tries to start the drm renderer and fails because it can't find the right encoder, or CRTC, to notice that the screen is lit -- that is, unless it was already lit and updated as such in drm by going through the grub menu. It asks libdrm for the available encoders, but the currently selected encoder for the connector remains 0; and if I bypass this and have it check the encoder for it's selected crtc, that value is also left at 0.

It seems like upstream linux commit https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/drm_crtc.c?id=abd69c55dd8f1f71b33b8c6165217f4329db8f25 should help, and in fact if I use the mainline kernel 3.19 rc1, things appear to be working properly; so I've opened a linux task for this issue.

[Joseph Salisbury (jsalisbury)]

In addition to upstream commit abd69c55d, at least two other commits are required: 144ecb97c and 623369e53. I'm working on backporting them and should have a test kernel shortly.

[Joseph Salisbury (jsalisbury)]

After some further research, we would need to backport quite a few commits to get the fixes from v3.19-rc1 into utopic. It would probably be too many changes for a stable release. At this point, the following commits would be needed, just to get abd69c5 to apply:

144ecb9 drm: Add atomic driver interface definitions for objects
cc4ceb4 drm: Global atomic state handling
2f324b4 drm/crtc-helper: Transitional functions using atomic plane helpers
623369e drm: Atomic crtc/connector updates using crtc/plane helper interfaces
abd69c5 drm: Handle atomic state properly in kms getfoo ioctl

Vivid will get all of these commits when it is rebased to upstream 3.19.

For Utopic it may be easier to perform a bisect to find the commit that started causing this issue, that is if it is indeed a regression. Can anyone affected by this bug report that they had a prior kernel that did not exhibit this bug?

[Launchpad Janitor (janitor)]

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

[NoOp (glgxg)]

Ubuntu 14.10: with no other changes, upgrading to the 3.19 kernel from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/
works for me.

Linux x 3.19.0-031900-generic #201502091451 SMP Mon Feb 9 15:10:05 UTC 2015 i686 i686 i686 GNU/Linux

Intel® 945GM x86/MMX/SSE2
*-display:0
       description: VGA compatible controller
       product: Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 03
       width: 32 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:16 memory:f0a00000-f0a7ffff ioport:1800(size=8) memory:d0000000-dfffffff memory:f0b00000-f0b3ffff

$ apt-cache policy plymouth
plymouth:
  Installed: 0.9.0-0ubuntu7
  Candidate: 0.9.0-0ubuntu7
  Version table:
 *** 0.9.0-0ubuntu7 0
        500 http://us.archive.ubuntu.com/ubuntu/ utopic/main i386 Packages
        100 /var/lib/dpkg/status

[Alberto Salvia Novella (es20490446e)]

It seems something went wrong in Launchpad about this bug. I'm trying to fix it manually now by reassigning packages, but probably nominations for series need to be approved again.

[NoOp (glgxg)]

Re my comment #31: changed back to 3.16 kernel and the problem reappears: boot, wait for black screen, reboot w/Ctrl-Alt-Del, grub appears, encrypt login appears, continue to boot normally. 100% reproducible. Definitely looks to be a kernel issue.

$ uname -a
Linux x 3.16.0-33-generic #44-Ubuntu SMP Thu Mar 12 12:25:57 UTC 2015 i686 i686 i686 GNU/Linux

[Joseph Salisbury (jsalisbury)]

The 3.19.0-8.8 is now 3.19.1 based. Can folks running Vivid test this kernel to confirm the bug is fixed in Vivid? You should be able to just apply the latest updates.

For Utopic, we may want to perform a kernel bisect to identify the specific commit that caused this regression. @NoOp, do you know that last good 3.16 kernel that did not have this bug and the first 3.16 kernel version that did? If not, I can provide some links to prior 3.16 kernel for testing.

[NoOp (glgxg)]

@Joseph: I don't recall which 3.6 kernel - it's a fairly recent install on a test laptop. I have the following installed:

$ dpkg -l | grep linux-image
ii linux-image-3.16.0-32-generic 3.16.0-32.42 i386 Linux kernel image for version 3.16.0 on 32 bit x86 SMP
ii linux-image-3.16.0-33-generic 3.16.0-33.44 i386 Linux kernel image for version 3.16.0 on 32 bit x86 SMP
ii linux-image-3.19.0-031900-generic 3.19.0-031900.201502091451 i386 Linux kernel image for version 3.19.0 on 32 bit x86 SMP
ii linux-image-3.19.1-031901-generic 3.19.1-031901.201503080052 i386 Linux kernel image for version 3.19.1 on 32 bit x86 SMP
ii linux-image-4.0.0-040000rc3-generic 4.0.0-040000rc3.201503082035 i386 Linux kernel image for version 4.0.0 on 32 bit x86 SMP
ii linux-image-extra-3.16.0-32-generic 3.16.0-32.42 i386 Linux kernel extra modules for version 3.16.0 on 32 bit x86 SMP
ii linux-image-extra-3.16.0-33-generic 3.16.0-33.44 i386 Linux kernel extra modules for version 3.16.0 on 32 bit x86 SMP
ii linux-image-generic 3.16.0.33.34 i386 Generic Linux kernel image

It's a fully encrypted 14.10 and for some reason the /boot is only about 236MB so I have to keep removing older image & headers, otherwise I'd have more. If you give me the links I can try the 3.16's older than 3.16.0-32 & see if I can narrow it down.

BTW: 3.19.1 does not have the issue, but it does have other issues instead:
[ 101.622829] WARNING: CPU: 0 PID: 2401 at /home/kernel/COD/linux/drivers/gpu/drm/drm_irq.c:1121 drm_wait_one_vblank+0x177/0x180 [drm]()
[ 101.622832] vblank not available on crtc 1, ret=-22
[ 101.622833] Modules linked in: pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) nfnetlink_queue nfnetlink_log nfnetlink vmw_vsock_vmci_transport vsock vmw_vmci snd_atiixp_modem snd_via82xx_modem snd_intel8x0m snd_ac97_codec ac97_bus ctr ccm snd_hda_codec_hdmi snd_hda_codec_conexant ip6t_REJECT nf_reject_ipv6 snd_hda_codec_generic snd_hda_intel xt_hl dm_crypt ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 xt_limit xt_tcpudp arc4 xt_addrtype nf_conntrack_ipv4 snd_hda_controller nf_defrag_ipv4 iwldvm xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp uvcvideo snd_hda_codec mac80211 nf_conntrack iptable_filter ip_tables hp_wmi gpio_ich x_tables sparse_keymap videobuf2_vmalloc snd_hwdep snd_pcm videobuf2_memops snd_seq_midi snd_seq_midi_event snd_rawmidi iwlwifi snd_seq videobuf2_core snd_seq_device snd_timer hid_logitech_hidpp v4l2_common cfg80211 snd videodev media coretemp soundcore joydev serio_raw parport_pc lpc_ich ppdev shpchp lp parport mac_hid binfmt_misc uas usb_storage hid_logitech_dj usbhid hid psmouse ahci libahci i915 r8169 mii i2c_algo_bit video drm_kms_helper wmi drm
[ 101...

[NoOp (glgxg)]

Correction:
"@Joseph: I don't recall which 3.6 kernel"
should be: @Joseph: I don't recall which 3.16 kernel

[Joseph Salisbury (jsalisbury)]

It would be good to test some or the prior Upstream 3.16 kernels, to find out if this is indeed a regression. The original bug reporter reported it with the 3.16.0-9.14-generic Ubuntu kernel, which is based on Upstream 3.16.1, so we should test earlier than that.

Can you test the following kernels and report back? We are looking for the first kernel version that exhibits this bug:
v3.16-rc3: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc3-utopic/

If v3.16-rc3 does not exhibit the bug then test v3.16-rc6:
v3.16-rc6: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc6-utopic/

If v3.16-rc3 does exhibit the bug then test v3.16-rc2:
v3.16-rc2: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc2-utopic

Thanks in advance!

[NoOp (glgxg)]

@Joeseph: sure - give me some time to clean out /boot & I'll test them shortly. Note: I can only test the 32bit kernels as I do not have 14.10 installed on a 64bit yet.

[NoOp (glgxg)]

Tried all three: rc2, rc3, rc6 and all of them prompt for the passphrase properly. I powered down between each boot to ensure that they weren't prompting following a reboot (as previously reported). I'll try rc1 and 3.15 to see if I can reproduce with any of those.

[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/1359689

[Steve Langasek (vorlon)]

On Sat, Dec 26, 2015 at 05:20:48AM -0000, Mike Butash wrote:
> Wow, I installed a 3.19 kernel today on 14.04,

Ok, so why did you do this? The 3.19 kernel is supported on 14.04 as an LTS
hardware enablement stack; it is not guaranteed that switching kernels, from
the 3.13 kernel that was included in 14.04 to the 3.19 enablement stack,
will be regression-free on all hardware for all use cases.

> Why is this *still* an issue? Does no one at canonical use disk
> encryption? Can we please finally add testing luks to some sort of
> regression tests?

This bug does not affect all hardware in all configurations of cryptsetup.
I believe there was another bug report besides this one where the kernel
team was bisecting to track this issue down. I don't have the bug number to
hand.

[Eric Hammond (esh)]

I upgraded to Ubuntu 15.10 (wily) with the default kernel 4.2.0-22 and this problem disappeared. Let me know if any other information would be helpful.

[shr00mie (alexlevin-z)]

i'm trying to install 15.10 and this problem is present from install.

i7 3770
GTX 680

probably need to tool around with /etc/default/grub and see if one of those configs will work, but would be nice if one didn't have to go through a grub customization to get this to work out of the box.

initially with default driver it looks like this
http://i.imgur.com/ENT4Buv.jpg

after installing prep nvidia driver and setting the i think it was gfx_payload option to my resolution, i was able to get the normal looking screen, but input appeared as plain text in the top left corner of the screen and did absolutely nothing.
http://i.imgur.com/akiQuU9.jpg

[Patrick Banholzer (patrick-banholzer)]

This Problem persists when using 14.04 Trusty with linux-image-generic-lts-wily for Hardware Support.

It helped to edit /etc/default/grub as follows:

removing the >quiet splash< ... what resulted to:
GRUB_CMDLINE_LINUX_DEFAULT="nomdmonddf nomdmonisw net.ifnames=0"

and adding the following line:
GRUB_GFXPAYLOAD_LINUX=text

after that I didn't have a splash but users where able to input their password.

[Erick Brunzell (lbsolost)]

I'm seeing this with the latest Ubuntu GNOME Xenial images. After completing a full disk encryption install the newly installed OS just boots to a blank, black screen. Then if you fiddle around with various key combinations (sometimes just repeatedly pressing esc) text will finally appear on the screen asking to "please unlock disk sda5_crypt". And if you hold your mouth just right you may be able to blindly enter the encryption password and boot with just the right keyboard combination. (pic attached)

[Erick Brunzell (lbsolost)]

This is fixed in Ubuntu GNOME Xenial 20160225.1 amd64.

[Pratomo Asta Nugraha (pratomoasta)]

Linux pratomo-X450JB 4.5.0-040500rc7-generic #201603061830 SMP Sun Mar 6 23:33:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[Martin Wimpress (flexiondotorg)]

I just tested this on 3 different computers using Ubuntu MATE 16.04 Beta 2, all were installed with full disk encryption.

  * Thinkpad T43p (i386, Radeon)
  * Thinkpad x201 (amd64, Intel IGP)
  * Thinkpad T61s (amd64, nVidia)

In all cases I could not reproduce this issue. It works are intended.

[Xtien (xtien)]

The issue seems to be with desktop computers, not laptops? Full disk encryption works well on my laptop, has always worked well, just not on my desktop computer.

[Erick Brunzell (lbsolost)]

I was not able to reproduce this behavior using the Ubuntu GNOME Xenial 20160323.1 images.

[sudodus (nio-wiklund)]

This problem is still there in Lubuntu desktop, which means the desktop iso file with the graphical user interface.

The problem appears on desktop computers as well as on laptop computers, and I think it is caused by problems with plymouth (which displays nothing, no logo, no dots, (and no passphrase if disk encryption is selected).

The problem is that the passphrase is not displayed, but it is still possible to type it and finish with the Enter key. That brings you to the login screen of the installed Lubuntu system.

[sudodus (nio-wiklund)]

This bug is still alive in Lubuntu Xenial final.

[RyperX (ryperx)]

I can also confirm this problem.

The system is starting when i use the 4.4.0-21-generic (recovery mode)
It doesnt start when i choose 4.4.0-21-generic

I only see a blue screen when i would start with 4.4.0-21-generic

4.2.0-34-generic is working fine

[Frédéric (frederick-sauvage)]

I confirm the problem since I upgraded to Lubuntu 16.04.

Does anyone have a solution to remove cryptsetup without reinstall all the system ?

[Peter Matulis (petermatulis)]

Upgraded Lubuntu 15.10 and there is no way to enter the passphrase. I was somehow able to get to a console where I found a prompt to enter one. On a next reboot I could not find this again.

[Moppers (moppers)]

Admittedly this was on Parallels (a VM host for Mac) but I noticed this problem only occurs for me when the grub menu is allowed to time out. If I manually select an OS, I can enter the encyption passphrase.

[Peter Matulis (petermatulis)]

I just tried selecting a boot entry in the GRUB menu. It doesn't help.

[Nathan Rennie-Waldock (nathan-renniewaldock)]

Definitely still affects 16.04.
Just did a test install in a VM for a fully encrypted dual-boot setup, blue screen, no password prompt. Had to disable splash to get it.

[Dummy Goat (dummygoat)]

I would also like to confirm that this bug affects Ubuntu 16.04.
I was able to semi-fix this by following #73's instructions.

[Ilias (ilias63)]

I faced the same issue using xubuntu 16.04 (clean installation) after I installed NVIDIA binary driver - version 340.96 from nvidia-340 (proprietary-tested) instead of X.Org X server - Nouveau (under which no issue appeared). NVidia driver is more stable so I have to hold it. I edited /etc/default/grub to have a fully text boot instead of plymouth boot but I still want to be advised if there is any solution for this issue.
Under Xubuntu 14.04 no issue appeared.

[Amael (amael)]

Hello, I confirm on a Ubuntu 16.04 (upgraded through years) with Nvidia graphics 340.96 and crypsetup install.

Screen freezes when asking for disk password.

Changing boot options to noslpash and switching to text mode allows me to enter the password and boot the system.

[Frédéric (frederick-sauvage)]

Since few months, after updates, no problem

[Jonas (teazulo195)]

Ubuntu 16.04 newest nVidia drivers version 367.35. Same problem as everyone in here. Unable to enter password after installing the nVidia driver. Screen stays frozen with no input.

Well, what's worked for me as a workaround is to change: GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash” in the /etc/default/grub to GRUB_CMDLINE_LINUX_DEFAULT=”” and then run sudo grub-update. It gives me the old style scrolling text login where I have an option to enter my filesystem decryption password. – ksclarke

I did that and it works but it is now the old plain login text you get from a distro without an user interface. Really ugly and not user friendly.

[lightweight (dave-egressive)]

I believe I'm experiencing the same bug after an in situ upgrade from Linux Mint 17.3 (based on Ubuntu 14.04) to 18.0 (running 4.4.0 kernel by default). I find that the boot process changes the graphics mode once (after selecting the default kernel) but with a black (but lit) screen (as opposed to the black unlit screen when modes switch), no visible text or graphics.

Prior to the upgrade I was also running a 4.4.0 kernel (with 17.3), and had no issues with getting the orange-ish decryption screen prior to the full boot.

I find that I can enter my passphrase even without seeing a prompt, and (if typed successfully!) it then proceeds to a graphical login.

Going back to an earlier kernel (4.2.0, still installed) gives me a text-mode decryption form (not the graphical mode version).

I'm running this on a Thinkpad X1 Carbon (v2) with 1600x900 LCD, Intel graphics. I've implemented the suggested GRUB tweaks above and will report if they make any difference at my next reboot.

[lightweight (dave-egressive)]

Ok, after a reboot (I set GRUB_GFXPAYLOAD_LINUX=1600x900 in /etc/default/grub), no change in behaviour. I'm *not* seeing the characters that some people (in older comments above) report by hitting up and down arrows (I see no visible change to my display from any characters). If I type the passphrase on the dark screen (yes, risky I know!) incorrectly, there's no visible change to the system. I tried a reboot with the "upstart" version of the boot profile (as opposed to the default systemd) and I get a text-mode encryption passphrase prompt. It otherwise starts as expected (pops straight into graphics mode MDM (the default Mint graphical login manager).

[Jonas Sundman (jonas-sundman)]

Workarounds using a text boot works, but is quite ugly. If having multiple encrypted disks each needs to be separately unlocked (plymouth feeds the first password to the following ones). Also the password prompts either not visible or aligned to a very far right which makes it hard to notice when to strart typing your passwords.

[linuxuser9090 (linuxuser9090)]

I have this issue with Xubuntu 16.04 using nvidia-370 drivers, on a GTX 980 ti. I have made the following changes to /etc/default/grub for nosplash and text mode but still have a blank/black screen:
GRUB_CMDLINE_LINUX_DEFAULT="nosplash"
GRUB_GFXPAYLOAD_LINUX=text

Unfortunately I have four encrypted volumes, so I have to type each password, wait a few seconds, then type the next. There is no indication whether I typed any of the four correctly or incorrectly. I know something went wrong when the system does not correctly boot up after going through each of the four passwords.

I have tried using plymouth which also does not work, I see the default blue password prompt but typing a password does nothing (CTRL+ALT+F7 will show whatever was typed).

I have also tried using the same password on all four volumes and using the patch here: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1022815 but that also doesn't work

[oh-no (oh-no)]

I'm currently facing this issue on Ubuntu 16.04 too, on a GTX 980 with nvidia-364 driver (tough its the same on all versions I tried).

I can boot with fail safe graphics mode, but not normally.

Trying to fix this with

GRUB_GFXPAYLOAD_LINUX=wxh
or
GRUB_GFXPAYLOAD_LINUX=text

has no effect, I'm left with a passphrase entry screen that displays all entered text on the top left, entering my passphrase here does not work.

[SamuelColvin (samcolvin)]

Any update on this? Seems mad that there's a "Critical" error on ubuntu that's been around for over two years and no one from Canonical appears to be trying to fix it. A sad reflection on the current state of ubuntu.

I'm on 16.04 and with LVM and LUKS and having the same problem. I can boot successfully with "4.4.0-36-generic" but all subsequent linux images: -38, -42 and -43 either give me:
* a blank screen
* out of focus password screen which doesn't respond to input
* or "Loading initial ramdisk ..." then nothing more

I've tried numerous combinations of GRUB_GFXPAYLOAD_LINUX and GRUB_CMDLINE_LINUX_DEFAULT and boot-repair with no success.

[sudodus (nio-wiklund)]

In order to check this I grabbed the iso file

ubuntu-16.04.1-desktop-amd64.iso

and installed a system with 'encrypted disk with LVM' according to the choice in the partitioning window of the installer. It had a working plymouth screen when I booted in the installed system. I updated & upgraded the system to be up to date with the kernel 4.4.0-43-generic. After reboot there is still a working plymouth screen. See the attached photo (sorry for the low quality ).

I tested this in a Toshiba laptop bought 2013,

http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/

Is this what you are missing? Please try to install from the first point release (16.04.1 LTS).

[sudodus (nio-wiklund)]

Is this problem depending on the nvidia proprietary graphics driver for new nvidia graphics chips/cards, that some versions of the nvidia drivers will make the system run without the plymouth screen?

In that case there is not much we can do except suggesting that you try the free 'nouveau' driver, or try the newest version of Ubuntu, 16.10 (Yakkety Yak) with the newest kernel series and its corresponding graphics drivers.

[SamuelColvin (samcolvin)]

I think it's very likely this is (at least in some cases) related to nvidia drivers.

I first got this problem while trying to fix a problem with ubuntu freezing after initial login described [here](http://askubuntu.com/a/760935/207604). I did "update" > "upgrade" > "upgrade nvidia drivers" as per the answer I've highlighted.

Unfortunately this upgraded the kernel from .36 to .38 as well as upgrading nvidia drivers from 364 (I think) to 370, so I don't know which caused the problem.

For anyone else with this problem: the only solution/work-around I found was to set

    GRUB_CMDLINE_LINUX=""
    GRUB_CMDLINE_LINUX_DEFAULT=""

in "/etc/default/grub", then "update-grub". Not sure if both are required but that worked and I'm not touching it any more.

[Mathieu Trudel-Lapierre (cyphermox)]

Don't know why this was moved to kubuntu-debug-installer, but I have no idea how that would be related (or really, what that package does at all).

Re-setting to plymouth, I'll have another look to see if there's still something to be done about this given that Debian claims to have fixed the issue.

[Marzanna (marzanna)]

In Xubuntu 17.04 (Zesty Zapus) I get black screen on password prompt.
With GRUB_GFXPAYLOAD_LINUX=1920x1080 I see password prompt but I can't enter anything and I see some logs appearing over graphical prompt. If I set GRUB_CMDLINE_LINUX_DEFAULT="quiet" I see text prompt and I can enter password.
linux-4.10.0-13-generic
plymouth-0.9.2-3ubuntu15
nvidia-drivers-378.13

[jwhendy (jw-hendy)]

I mostly use arch, but need ubuntu for work and find bugs ridiculously frustrating. I see a bunch of 'status -> won't fix' changes above, without any real explanation ("We'll have another look" and "maybe Debian fixed it."). This is so typical. I hunt down something relevant and find out "it's been fixed in version xx.xx", which is, of course, not the version I'm using or the version the bug is actually about.

I just turned off switchable graphics because more than one monitor was ungodly confusing since they're on different cards. Using nvidia-375 only requires nomodeset, and after an update to 4.4.0-83 yesterday I just got a screen freeze at boot. Like others, I figured out to turn off quiet and splash, and whaddya know, everything is fine under the hood. Still, it's annoying and alarming when you dist-upgrade and a previous splash screen/cryptsetup screen stops appearing whatsoever!

What does LTS support until 2021 for 16.04 mean if bugs will just be ignored/deferred?

Lastly, it would be awesome to have a short summary of the conclusion. There's a massive number of comments here and I don't have the time right now to figure out which of them contains truly relevant nuggets of information.

[Steve Langasek (vorlon)]

On Fri, Jun 30, 2017 at 03:38:26PM -0000, jwhendy wrote:
> I see a bunch of 'status -> won't fix' changes above, without any real
> explanation ("We'll have another look" and "maybe Debian fixed it.").

For the record, the tasks that were 'wontfix' were for releases that are EOL
and no longer receive updates.

[Jondice (brandon-barker)]

The magic combo that worked for me on a fresh install of Ubuntu Xenial 16.04.3 LTS (on a new Dell Precision workstation - not a laptop) was:

GRUB_CMDLINE_LINUX_DEFAULT="nomodeset"
GRUB_CMDLINE_LINUX=""
GRUB_GFXPAYLOAD_LINUX=1920x1200

Of course the GRUB_GFXPAYLOAD_LINUX should match your monitor's native resolution.

[Maciej Jesionowski (yavn)]

Adding my experience in case someone has the same issue.

Installed a fresh Ubuntu 16.04.3 with the clear entire drive and set up LUKS+LVM option. After the first reboot I got the graphical password prompt but couldn't type anything. After the next reboot, after passing GRUB, the screen just stayed blank purple. Only ctrl+alt+del worked.

To get the system boot correctly I edited the default GRUB Ubuntu entry (the 'e' key in GRUB):

1. change the line "gfxmode $linux_gfx_mode" to "gfxmode auto", or just remove it whole
2. remove the "splash" from the linux kernel cmdline
3. boot with F10

After that I got a text prompt to unlock my disk volume and after giving it the password the system started normally.

If this works for you and you want to make it persistent, edit the /etc/default/grub file (with sudo):

1. remove the "splash" from GRUB_CMDLINE_LINUX_DEFAULT
2. uncomment the line GRUB_GFXMODE and set it to "auto", GRUB_GFXMODE=auto
3. save the file and run the command "update-grub"

Hope this helps.

[Moppers (moppers)]

This bug doesn't say Artful but I have it in Artful.

I installed a new Artful 64-bit, and encrypted both home and user.

Everything was fine until I installed the nvidia drivers and now I cannot login unless I choose recovery mode. Either I get a black screen, or I get the key prompt with a disabled keyboard.

[windowsguy (something-f)]

Same as Moppers, on Artful and can't see LUKS prompt. Only recovery mode lets me access data and my 2nd display cannot work.

Earlier today I booted with LUKS just fine, but after suspend I got a black screen on both displays and couldn't recover. After I power cycled it, now I can see LUKS prompt only with recovery mode.

I've tried to boot with 4.13.0-16-generic, 4.13.0-17-generic, 4.13.0-19-generic, all have the same problem (blank screen). Now I enabled "proposed" updates to see whether that helps.