Latest Vagrant box for Ubuntu Xenial is failing to boot

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

I've noticed the same thing since 20160205 if that helps.

I have discovered that "recovery" boot mode is working. The reason is, that "recovery mode" doesn't contain "console" kernel parameters.

After enabling GUI console, pressing "ESC" early on boot, entering grub and removing "console" parameters works.

Also, I have discovered, that "recovery" mode doesn't contain "net.ifnames=0" parameter, so network devices will be enabled with completely different names than in "normal" mode. Maybe it should be submitted as different issue.

The 20160218.4 build still has the problem (http://cloud-images.ubuntu.com/xenial/20160218.4/xenial-server-cloudimg-amd64-vagrant.box)

I don't see or can't get to the grub menu with any key combo as imiciik posted.

Can confirm it's still a problem with 20160218.4, but I have a couple workarounds.. Technically, the issue isn't that xenial fails to boot -- it's just that you can't see it (and neither can vagrant).

The issue is with 'console=ttyS0' on the grub command line. It's strange because my earlier vivid vagrant boxes also have this, but those never had a problem. Maybe some difference in other graphics stuff loaded in those vivid boxes... Anyway, on to the workarounds:

1 - edit xenial's grub.cfg to remove console=ttyS0.

If your host is Linux, you should be able to mount the vmdk with 'kpartx -av /path/to/ubuntu-xenial-*.vmdk', then mount whatever loops kpartx spits back at you. If you're not comfortable with kpartx, you can launch virtualbox, edit a known working guest to add the xenial vmdk as another disk, boot that guest, and then 'sudo mount /dev/sdb1 /mnt'.

At this point, you've got the xenial root disk mounted (i'm assuming at /mnt). Now edit /mnt/boot/grub/grub.cfg to remove the console=ttyS0 bits (i used sudo vi and a :w! for this since grub.cfg is mod 444). Now 'sudo umount /mnt'.

If you did this with a known working guest through virtualbox, be sure to shutdown the guest, and remove the xenial vmdk from the guest's config so you don't unintentionally mount that again.

Now 'vagrant up' your xenial machine, and it should proceed to a point you can 'vagrant ssh' to it (although you'll probably then hit bug 1538547).

2: add a serial port to your vagrant box

I'm assuming here that you've run something like "vagrant box add xenialbox <url>" and adjusted your Vagrantfile to use xenialbox, and are sitting at a failed "vagrant up <your-xenial-guest>". That's perfect. Now open virtualbox and forcefully halt your xenial guest. Edit the guest by clicking Settings -> Ports -> Serial Ports -> Port 1. Click the "enable serial port" check box, leave the defaults alone for COM1, ensure Port Mode is "Disconnected" and click OK to save the settings.

Now you can re-run 'vagrant up <your-xenial-guest>" and it ought to work.. (again, until you hit bug 1538547).

Either of these worked for me to get 'vagrant ssh <my-xenial-guest>' working with virtualbox 5.0.14.

Thank you kindly Kevin for the solution and Ivan for reporting the bug. I've been tied up in meetings all week and hope to get something out the door next week. With the excitement of CVE's, 14.04.4 and other fun things this week, I've been a little behind on getting this fixed.

Dear Ben,
I completely don't understand Bazaar. I have found your patch above, but it was not working. I had to add following lines to Vagrantfile to make it working:

"""
  config.vm.provider "virtualbox" do |v|
    v.customize [ "modifyvm", :id, "--uart1", "0x3F8", "4" ]
    v.customize [ "modifyvm", :id, "--uartmode1", "file", "console.log" ]
  end
"""

This bug was fixed in the package livecd-rootfs - 2.380

---------------
livecd-rootfs (2.380) xenial; urgency=medium

  [ Ben Howard ]
  * live-build/ubuntu-cpc/hooks/042-vagrant.binary: add serial device for
    Vagrant images (LP: #1546108).

  [ Daniel Watkins ]
  * Refactor ubuntu-cpc hooks to hard-code producing an 'ext4' rootfs, which
    is used outside of the livecd-rootfs build process (specifically for EC2
    publication).

 -- Dimitri John Ledkov <email address hidden> Mon, 22 Feb 2016 19:17:15 +0000

The previous fix won't work. @kwmonoroe pointed out the configuration was wrong. I've re-submitted a fix at:
lp:~utlemming/livecd-rootfs/v381

I think it'll be another day before we have a build that works. If you need a working box (and Launchpad doesn't purge it out), you can find a build here:
https://launchpad.net/~utlemming/+livefs/ubuntu/xenial/cpc/+build/53150/+files/livecd.ubuntu-cpc.vagrant.box

Still no usable build.

I'm also having to add an optical drive now.

The Feb 27 vagrant box works for me:

http://cloud-images.ubuntu.com/xenial/20160227/xenial-server-cloudimg-amd64-vagrant.box

A serial port and console.log are created, and initial 'vagrant up' works. I'm still hitting bug 1538547, but it doesn't seem to affect my ability to 'vagrant ssh' into the machine.

Looks like with released fix VM boot speed has decreased drastically: https://bugs.launchpad.net/cloud-images/+bug/1567265

On my system with VirtualBox 5.0.24 recent image (from https://cloud-images.ubuntu.com/xenial/current/, dated 20160725) with enabled UART boots till "Btrfs loaded" string in 105 seconds, and with disabled in under 7 seconds.

While enabled UART change fixes booting, it significantly reduces likelihood of image usage due to very slow boot speed.

Same, getting hard lockups on boot. Images from everywhere else work beautifully.

Enable Serial Port for VM fix issue for me.

Ports -> Serial Ports -> Port 1 -> Enable Serial Port