grub2 still hands off to blank tty7 on non-Server command-line-only systems and some Server systems

I reported this with apport, with the hope that the relevant configuration file or files would automatically be attached, but since that has not happened, I'll attach them manually. Please note that the one file that is known to be relevant is /etc/grub.d/10_linux.

I have just created a Natty i386 Beta 2 Server virtual machine that is very similar to the Natty i386 command-line only system I had installed from the alternate CD. Both before and after installing updates, it did NOT have this problem. Thus, it seems that bug 700686 / bug 695658 is fixed for Server systems but not for non-server command-line only systems.

The server system had the same line that I thought was problematic in /etc/grub.d/10_linux, which indicates to me that selectively changing that line is *not* the way bug 700686 / bug 695658 was fixed. Therefore, I am changing the title of this bug to reflect that, and also to reflect that this bug does not affect Ubuntu Server systems.

I see this problem with a fresh Ubuntu server install from about a week ago. Every time I boot, I end up at a blank screen with a blinking cursor, and I have to type ctrl-alt-F1 to get my login prompt. Took me a while the first time to figure out that my install wasn't broken and the boot had actually succeeded.

What install image did you use (e.g., Beta 2 CD, daily build)?

I'm encountering the same issue, same symptoms. I used mini.iso to create a minimal installation disk, then selected a command-line installation. I don't have the disk with me at the moment to give you the precise version of the disk image, but a visit to the download directory...

http://archive.ubuntu.com/ubuntu/dists/natty/main/installer-i386/current/images/netboot/

...shows that the mini.iso file was last modified 21-Apr-2011 08:03

@Akkana Peck
Except for the information you reported, all the instances I'm aware of of this bug, since bug 700686 was fixed, are with command-line only non-Server installations of Ubuntu. Can you tell us what install image you used (e.g., Beta 2 CD, daily build)?

I installed from an alternate installer ISO (ubuntu-11.04-beta2-alternate-i386.iso), and chose the server option, so it was installed as a commandline system. After installation, I installed X and various X clients, but not gdm -- for now I'm still booting into the console login prompt (except there wasn't a prompt, just a blank screen/blinking cursor).

After reading this bug I've commented out the "for word in $GRUB_CMDLINE_LINUX_DEFAULT; do" clause in /etc/grub.d/10_linux, and also changed GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub to "noplymouth" instead of "quiet splash", and now my boot is working great and I get the expected login prompt.

I'm experiencing this issue and am using the final release of natty amd64 netboot

2011-04-28 20:56 ubuntu-11.04-server-amd64-netboot.iso

I'm seeing this with both an i386 and amd64 cli-expert netboot install.

Can an admin please mark this as High importance? Not giving a login prompt on boot is especially serious when startup messages are hidden by default.

This is happening to me when installing from the 64bit Natty Minimal CD, at https://help.ubuntu.com/community/Installation/MinimalCD

It also occurs when upgrading from a Maverick minimal install to Natty with sudo do-release-upgrade.

I am also experiencing this problem. I have never had to deal with any kind of bug reporting (LUCKY!) - but I want to do what I can to help.

What can I do?

@Aaron, make sure the bug is marked as affecting you (at the top of the page).

There's probably not much more you can do, now that the bug is reported. We're pretty much just waiting for someone to get around to actually fixing it.

It does, except mine is not the beta version, it's final. Same kernel versions though.

@Aaron Anderson
Daniel Richard G. was saying that you should use the green "This bug affects..." link near the top of this bug page to indicate that the bug affects you. (Being subscribed to a bug can reasonably be taken as an indication of interest in it, but it doesn't indicate that you're actually affected by it; similarly, while it's generally a good idea to be subscribed to bugs affecting you, you can indicate that a bug affects you without being subscribed to it.)

You've raised a good point about how my original report was done with a beta install CD. Now that Natty has been out for a while, I should really try installing with the final (stable release) CD's and report on whether or not something has changed (on the VMware machine on which I'm testing this -- obviously, from the several corroborators, we know this bug still exists). I'll try to get around to that today.

Let me know if I can help. I might build a VM tonight and see which package is breaking things.

I have now tested with the stable, release version of Natty. I did this on i386 architecture (virtual machine file attached). As would be expected from my previous results and the experiences of others as documented in this bug, I found that the problem (handing off to tty7 when there's no GUI, and remaining there even after the system is fully started up and ready for use) occurs in all these situations:

(a) A fresh, command-line only install from the Natty Minimal CD (installing only core packages, with no extra selections).

(b) A fresh, command-line only install from the Natty Alternate CD (using the "Install a command-line system" option in the F4 menu), both before and after installing updates and rebooting.

(c) An upgrade to Natty from a freshly installed and fully updated command-line only installation from the Maverick Alternate CD (using the "Install a command-line system" option), both before and after installing updates and rebooting.

However, consistent with https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/761830/comments/11, I was not able to get this bug to occur with *any* Natty Server system, even after attempting a number of possible different installations. I tried with the following:

(d) A fresh install, using all default settings, from the Natty Server CD, both before and after installing updates and rebooting.

(e) A fresh install, using all default settings except using "vanilla" partitioning rather than LVM (in case that somehow made a difference in the way GRUB2 got configured), from the Natty Server CD, both before and after installing updates and rebooting.

(f) A fresh minimal install (using the "Install a minimal system" option in the F4 menu) from the Natty Server CD, using otherwise default settings, and not selecting any additional packages beyond the core system, both before and after installing updates and rebooting.

(g) A fresh minimal install (using the "Install a minimal system" option in the F4 menu) from the Natty Server CD, using otherwise default settings except using "vanilla" partitioning rather than LVM, and not selecting any additional packages beyond the core system, both before and after installing updates and rebooting.

(h) An upgrade to Natty Server from a freshly installed and fully updated command-line only default installation from the Maverick Server CD (in this installation, I did not select any additional packages beyond the core system when asked), both before and after installing updates and rebooting.

There are other possibilities for Natty Server systems, of course, but nonetheless, that represents a wide range of possible newly installed Server systems.

This VMware virtual machine file just provides specifications about the machine--it doesn't contain any of the hard disks or other supporting files. You can create a working virtual machine using this file as the base, but this file is not a functioning virtual machine (and certainly doesn't contain an installed OS!).

@Akkana Peck
In https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/761830/comments/16 you said you installed with the server option on the Natty Beta 2 alternate CD. Is that to say that you selected "Install an LTSP server"? Or did you select "Install a command-line system" (or something else)?

@Scott McLeod
In https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/761830/comments/17 you said you installed with ubuntu-11.04-server-amd64-netboot.iso, and experienced this bug on the resulting Natty Server system. I'm not familiar with that particular ISO image. Searching the web, and Launchpad, for it, seems only to reveal hits pertaining to that comment of yours in this bug. Where can I get that image, so that I can test with it (or with the corresponding image for the i386 architecture)?

I chose "Install a command-line system" from the alt installer.

@Akkana Peck
Ah, OK. In that case, it seems that Scott McLeod may be the only person so far who has experienced this bug on an Ubuntu Server system (since what you installed was a non-Server Ubuntu system with no GUI; see https://help.ubuntu.com/11.04/serverguide/C/preparing-to-install.html for an explanation of what's different between the Desktop and Server editions of Ubuntu, besides how servers typically don't have GUI's and desktop systems typically do).

@Eliah Kagan

The netboot image can be obtained through these URLs

http://cdimage.ubuntu.com/netboot/
http://archive.ubuntu.com/ubuntu/dists/natty/main/installer-amd64/current/images/netboot/mini.iso

Essentially it's a super stripped down installer (In this case around 22MB) that ensures an extremely fresh install.

http://psung.blogspot.com/2009/01/ubuntu-netboot-installers.html

@Scott McLeod
If you're talking about mini.iso (had you renamed it to ubuntu-11.04-server-amd64-netboot.iso yourself?), that's what I referred to as the Minimal CD in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/761830/comments/25. I was able to produce the bug after installing a minimal system with that. But that is not actually a server install CD. It can be used to install Ubuntu Server system, however (that's one of the options you can choose from). Had you used that to install an Ubuntu Server system, on which the problem occurred? It's not clear to me what steps you took which produced the results you reported in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/761830/comments/17.

I had(have) the same issue.

This is an easy fix by editing /etc/grub.d/10_linux

changing:

     GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT vt.handoff=7"

to

     GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT"

Be sure to run "sudo update-grub2" after making the the changes to 10_linux. Boots straight to the prompt there after.

Hope this helps.

Hi,

I came to know recently from Eliah that I might be effected by this bug.

I am running a fully updated 64-bit Natty Server System.

The architecture on which I am running this system is AMD64.

The iso image that I used to install this server system is "ubuntu-11.04-server-amd64.iso".

I have installed this server system on VMware Workstation 7.1.4 with Windows 7 Ultimate x64 being my host Operating System.

Since VMware recognized this installation media as Ubuntu x64, it proceeded with Easy Install, and I did NOT make any non-default configuration changes during installation of Natty Server, except that I changed the settings of my Virtual Machine itself such as the name of the virtual machine, the location of the virtual machine, the number of processors used, the amount of RAM allocated, the amount of space allocation, the type of I/O controllers used (ATAPI for IDE Controller & LSI Logic for SCSI Controller) and the Virtual Disk Type (selected as SCSI).

Eliah, I hope all of this information helps to determine whether or not this bug is applicable for x64 Natty Server Systems.

Thanks & Regards,
   Clifford Dhamanigi
   System Administrator, Oracle Solaris

Microsoft Certified Technology Specialist
   Oracle Certified Solaris 10 Associate
   Oracle Solaris 10 System Administrator Certified Professional

I am able to reproduce this bug on Natty i386 Server by using VMware Easy Install (in VMware Workstation 7.1.4 build-385536 on a Natty amd64 host). When I install Natty i386 Server manually (as I had always done in the past) on the same virtual machine, this bug does not occur. I am not sure what it is about VMware Easy Install that is triggering this bug. The most obvious explanation would have seemed to be that VMware Tools triggers it, since VMware Tools is automatically installed as the final, post-boot step of VMware Easy Install, and it is only *after* that first boot that the system boots handing off to tty7 instead of tty1. However, manually installing VMware Tools on a manually installed system (i.e., a system not installed with VMware Easy Install) does not trigger the problem.

This bug seems to occur the same way in Oneiric (which was to be expected)--testing I did today on VMware virtual machines with identical hardware indicates that it seems to always happen on command-line only non-Server systems (I used the Oneiric i386 20110708 daily alternate CD), to typically not happen on Server systems (tested with the Oneiric Server i386 20110708 daily), but to happen on Server systems installed with VMware Easy Install (same installation media).

@Clifford Dhamanigi
To clarify, the reason it was very helpful for you to post here was not that it was uncertain if this bug affected *all* amd64 Server systems (it certainly doesn't), but because it was uncertain if it affected any Natty server systems **at all**. Clearly, it does, though it remains to be seen if, on Ubuntu Server, this bug is limited to systems installed with VMware Easy Install.

I've dug into this issue a bit. I don't think there's much use in distinguishing between the various Ubuntu flavors here; it all comes down to this bit in /etc/grub.d/10_linux:

for word in $GRUB_CMDLINE_LINUX_DEFAULT; do
  if [ "$word" = splash ]; then
    GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT vt.handoff=7"
  fi
done

If you remove "splash" from GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and run update-grub(8), then you get a login prompt on tty1 when you boot a command-line system. If Ubuntu Server is doing anything different, it's probably in how the defaults in this file are configured.

I don't see the purpose of switching to tty7 if "splash" is specified but X is not installed, so maybe the 10_linux file needs an additional conditional (e.g. "[ -x /etc/X11/X ]").

Colin, you've said that the purpose of all this is "to transition smoothly to Plymouth, not to transition smoothly to X11" (bug 695658, comment 6). Could you clarify what should be happening in the splash-sans-X case?

Skunk,

Awesome... Works Great

Jeff

Firstly skunk's fix works for me.

Second, this is critical. Quite how many people realise you can do an Alt+F1 to gain access to their systems I don't know, but those that do not and have no remote access will be reinstalling and probably ending up in the same hole.

My platform: 64-but Win7Pro with VMWare Player installing i686 11.04 server edition. The first installation was with a custom install of 11.04-server-mini which I then dist-upgrade and ended up with this issue on reboot. The second was with 11.04-server (full ISO) which wen through VMware's "Easy install" before I dist-upgraded it. Both experienced this issue.

I'm still getting this with the 11.11 beta2. Why is this considered "low" importance? It makes the system unusable and can take a while to figure out, even for someone who knows what they're doing. It's especially pernicious in a VirtualBox VM, where ctl-alt-F1 doesn't do what you expect. Please raise the importance of this bug.

@Jim Rees
This does not speak to the question of this bug's importance, but please note that Alt+F1 is sufficient (and more appropriate) for switching from a virtual terminal that does not have X11 running on it, and Alt+F1 will typically behave as expected with VirtualBox and other virtualization software.

The real bug here is not so much that grub is asking the kernel to switch to vt7 when there is no splash. The real bug is that grub is requesting a vt switch at all. Grub has no business making this request because it has no way of knowing whether there is anything on vt7.

The way this should work, and the way it used to work, is that the post-grub application (splash, X, gdm, or /bin/login) would request a vt switch to itself (or not, in the case of /bin/login, which runs on all vts). Only the application running on a particular vt can know which vt should be switched to, and the switch shouldn't happen until that app is up and running.

Please don't lecture me about kms and how the current way of doing things is so much better than ums. I know about that. The kernel does vt switches at the request of user space programs. That part hasn't changed. The vt switch request should be a "pull" to the program requesting the vt, not a "push" from some program (like grub) that hopes and prays there is someone home on the target vt.

And by the way, VirtualBox on Mac does not pass Alt-F1 to the guest OS by default. That's not really relevant to this bug except that it tends to raise the frustration factor for those of us trying to deal with it. Except for this grub bug I would never have any need to switch vt on my ubuntu VM install.

Jim, I agree that having grub switch the VT rather than the program needing same is rather cart-before-horse-ish. It does have the advantage of happening very early in the boot process, however (even before the kernel/initrd are loaded), and I suspect the rationale for doing things this way is keen on that chronology, along with the desire for a graphically "seamless" boot process.

For my part, I wouldn't fault grub for doing the switch, if Ubuntu hadn't utterly failed to account for non-X installs when they wrote the logic in /etc/grub.d/10_linux.

Kind of unbelievable that this is still unfixed and still marked low priority. Can we at least have an explanation of what's broken in plymouth that makes it impossible to apply the suggested fix? I can look at fixing plymouth if that's the problem.

It looks like this gets added automatically if the splash option is specified in /etc/default/grub. It appears this option is there by default, but is removed at some point when installing from the server cd. However that happens on the server probably needs to behave the same on the alternate cd when you don't choose to install the desktop.

I'm sure this bug is low priority because it is very uncommon to install with the alternate desktop installer, and then not install the desktop, hence, there are more important problems to spend limited time fixing.

The vt.handoff kernel param shouldn't be there in the first place. See my comment above. And I don't see why this would be an uncommon installation. It's the only way I know of to install a command line system that's not a server.

This looks like it affects daily spins of Quantal too (as of today's date).
Using Quantal Server amd64 it boots into vt7.

There's a crazy if .. else block in /etc/grub.d/10_linux that sets linux_gfx_mode=text or linux_gfx_mode=grub which is possibly setting "keep" instead of "text" but I'm not sure what its doing to assist. This value seems to be used when determining whether to switch to vt7 though.

I am seeing this on Ubuntu-12.04-server-amd64 installs on both raw hardware (standard Intel server platforms) and also when installing in kvm/qemu. I am wondering if this is the cause of oem-config crashing on the ubuntu server installs (lp:1180880). More testing to see if they are related.

I found the perfect fix for this bug. I wiped my disk and installed a different (not Ubuntu) distro. I am much happier now.

Note on comment #47 and the oem-config bug: That was found to be unrelated, and a fix for it has already been released.

As for this bug, it appears to have gone away. I tested a minimal Raring install, and even through the GRUB boot options are the default "quiet splash", it does correctly switch to vt1 (and the login prompt) after showing the text-mode Ubuntu boot screen.

As far as I can tell, the GRUB handoff to vt7 still occurs, but then something else is switching the console back to vt1 after the splash screen (presumably in lieu of starting X).

I'm going to tentatively mark this bug as "Fix Released." If anyone is still seeing this problem in Raring or later, please set it back to "Confirmed."

This bug happens to me every time in Xenial (none in Trusty) when installing a server using minimal ISO.

Still happends on 17.04 (minimal)

I am seeing this bug in 17.10. If I carry out a minimal install with no packages selected at the final stage, I see a blank screen on boot.

The first time I saw this I did a hard reset and was presented with a boot menu. I presume this is some sort of failsafe behaviour in the event of a failed boot. If I then selected Ubuntu from that menu, the boot succeeded and the LVM decrypt prompt was shown.

On a subsequent reboot, the previous behaviour of displaying a blank screen resumed. I then discovered that I could switch to a text based tty by pressing Alt+F1, this also displayed the LVM decrypt prompt.

From what I have read in this and other, linked, bugs I expected this behaviour to disappear once I had installed a X and a display manager, however after installing GNOME (apt install gdm3) the system still boots to a blank screen except (and I swear this is reproducible) I now have to press Alt+F2, then Alt+F1 twice before I get to a usable LVM decrypt prompt.

I am a Linux novice so apologies if my terminology is off or if this post is totally useless.