Ubuntu/focal64 box not starting

When i try start a VM with ubuntu/focal64, it fail with error

boby@sok-01:/mnt/data/sites/learn/vagrant/2020-09-13-ubuntu-20.04$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/focal64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/focal64' version '20200910.0.0' is up to date...
==> default: Setting the name of the VM: 2020-09-13-ubuntu-2004_default_1599985318716_1017
==> default: Fixed port collision for 22 => 2222. Now on port 2201.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2201 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2201
    default: SSH username: vagrant
    default: SSH auth method: private key

Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
boby@sok-01:/mnt/data/sites/learn/vagrant/2020-09-13-ubuntu-20.04$ 

I am using Ubuntu 18.04, Vagrant 2.2.10 and Virualbox 6.1.14 r140239.

Any idea why it failing ?

Thanks,

Yujin

Hi there!
There is a confirmed bug that causes some of the newer Ubuntu boxes to boot slowly, which is causing the SSH timeout in this case.
You can work around this by adding the following customizations to your Vagrantfile:

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

Cheers!

2 Likes

please help
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured (“config.vm.boot_timeout” value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you’re using a custom box, make sure that networking is properly
working and you’re able to connect to the machine. It is a common
problem that networking isn’t setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout (“config.vm.boot_timeout”) value.

still the problem

my Vagrantfile is

-- mode: ruby --

vi: set ft=ruby :

All Vagrant configuration is done below. The “2” in Vagrant.configure

configures the configuration version (we support older styles for

backwards compatibility). Please don’t change it unless you know what

you’re doing.

Vagrant.configure(“2”) do |config|
config.vm.provider :virtualbox do |v|
v.customize [“modifyvm”, :id, “–uart1”, “0x3F8”, “4”]
v.customize [“modifyvm”, :id, “–uartmode1”, “file”, File::NULL]
end

The most common configuration options are documented and commented below.

For a complete reference, please see the online documentation at

https://docs.vagrantup.com.

Every Vagrant development environment requires a box. You can search for

boxes at https://vagrantcloud.com/search.

config.vm.box = “centos/7”

Disable automatic box update checking. If you disable this, then

boxes will only be checked for updates when the user runs

vagrant box outdated. This is not recommended.

config.vm.box_check_update = false


end

is it right accordint to your advise???

Thanks for the workaround snippet! I added it to my Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/focal64"
  config.vm.provider "virtualbox" do |vb|
    vb.memory = "1024"
    vb.customize ["modifyvm", :id, "--uart1", "0x3F8", "4"]
    vb.customize ["modifyvm", :id, "--uartmode1", "file", "./ttyS0.log"]
  end
end

but still can’t get Ubuntu focal to boot up:

C:\Users\ChrisEich\Documents\repos\hub-system>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/focal64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/focal64' version '20210927.0.0' is up to date...
==> default: Setting the name of the VM: hub-system_default_1632871817992_15800
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
[hangs here]

By way of comparison, hashicorp/bionic64 works fine…

This is the last thing I see on the console, when I turn on the VB gui:

After that, the vagrant up command times out and vagrant ssh hangs, with no additional console output.

I spoke too soon; the boot continued after almost 45 minutes, and I was able to vagrant ssh after that. I changed the timeout to 3600 and tried vagrant reload. This time it took just over 3 minutes. The kernel messages indicate “detected stall” on one vCPU, and later on, “soft lockup” on both vCPUs:

[ 4.248957] sd 2:0:0:0: [sda] Attached SCSI disk
[ 4.250353] sd 2:0:1:0: [sdb] Attached SCSI disk
[ 138.108221] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 138.108404] raid6: sse2x4 gen() 41795998 MB/s
[ 138.118148] rcu: 1-…!: (2 ticks this GP) idle=e82/1/0x4000000000000000 softirq=903/906 fqs=1
[ 138.136074] (detected by 0, t=33120 jiffies, g=-567, q=238)
[ 138.146128] Sending NMI from CPU 0 to CPUs 1:
[ 148.119490] rcu: rcu_sched kthread starved for 33118 jiffies! g-567 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
[ 148.127342] rcu: RCU grace-period kthread stack dump:
[ 148.131620] rcu_sched I 0 10 2 0x80004000
[ 148.135496] Call Trace:
[ 148.137437] __schedule+0x2e3/0x740
[ 148.140070] schedule+0x42/0xb0
[ 148.142939] schedule_timeout+0x8a/0x160
[ 148.146478] ? __next_timer_interrupt+0xe0/0xe0
[ 148.149843] rcu_gp_kthread+0x48d/0x990
[ 148.153831] kthread+0x104/0x140
[ 148.157339] ? kfree_call_rcu+0x20/0x20
[ 148.161646] ? kthread_park+0x90/0x90
[ 148.165707] ret_from_fork+0x1f/0x40
[ 188.776650] watchdog: BUG: soft lockup - CPU#1 stuck for 44s! [modprobe:217]
[ 188.776631] watchdog: BUG: soft lockup - CPU#0 stuck for 38s! [swapper/0:0]
[ 188.776633] Modules linked in: raid6_pq(+) libcrc32c raid1 raid0 multipath linear mptspi scsi_transport_spi mptscsih psmouse mptbase e1000
[ 188.785353] Modules linked in: raid6_pq(+) libcrc32c raid1 raid0 multipath linear mptspi scsi_transport_spi mptscsih psmouse mptbase e1000
[ 188.794121] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-88-generic #99-Ubuntu
[ 188.817004] CPU: 1 PID: 217 Comm: modprobe Not tainted 5.4.0-88-generic #99-Ubuntu
[ 188.839315] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 188.839326] RIP: 0010:native_safe_halt+0xe/0x10
[ 188.839331] Code: 7b ff ff ff eb bd 90 90 90 90 90 90 e9 07 00 00 00 0f 00 2d 36 87 52 00 f4 c3 66 90 e9 07 00 00 00 0f 00 2d 26 87 52 00 fb f4 90 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 e8 0d 83 63 ff 65
[ 188.852916] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 188.865108] RSP: 0018:ffffffff9dc03e18 EFLAGS: 00010246 ORIG_RAX: ffffffffffffff13
[ 188.879272] RIP: 0010:raid6_sse24_xor_syndrome+0x255/0x280 [raid6_pq]
[ 188.888449] RAX: ffffffff9d0e2c00 RBX: 0000000000000000 RCX: 0000000000000001
[ 188.907828] Code: f8 66 41 0f ef 30 66 44 0f ef 27 4d 01 f9 66 45 0f ef 31 66 0f e7 22 66 41 0f e7 30 66 44 0f e7 27 66 45 0f e7 31 83 45 d4 40 <48> 63 55 d4 48 3b 55 c0 0f 82 09 fe ff ff 0f ae f8 e8 05 08 25 dc
[ 188.920221] RDX: 0000000000001bd6 RSI: ffffffff9dc03dd8 RDI: 0000002257860dd3
[ 188.934220] RSP: 0018:ffffc2218024bb28 EFLAGS: 00010206 ORIG_RAX: ffffffffffffff13