Ubuntu 20.04 and 18.04 hang on SSH.

[Sprbb]

Version:

[Version of the project installed] ubuntu 20.04 ubuntu 18.04

Environment:

[Details about the environment such as the Operating System, cookbook details, etc...] packer build -only=vmware-iso ubuntu-20.04-amd64.json packer build -only=vmware-iso ubuntu-18.04-amd64.json

Scenario:

[What you are trying to achieve and you can't?] A working VM

Steps to Reproduce:

[If you are filing an issue what are the things we need to do in order to repro your problem?] packer build -only=vmware-iso ubuntu-20.04-amd64.json packer build -only=vmware-iso ubuntu-18.04-amd64.json

Expected Result:

[What are you expecting to happen as the consequence of above reproduction steps?] A working VM

Actual Result:

[What actually happens after the reproduction steps?] A waiting VM

[Sprbb]

packer version 1.5.6

[survivant]

had the same issue with ubuntu-20.04 with packer 1.5.6

[svpernova09]

Confirmed having this issue w/ VMware Desktop 15.5.6 build-16341506, Packer 1.6.0 Template: packer_templates/ubuntu/ubuntu-20.04-amd64.json

Here's a debug log:

PS C:\Users\halo\Code\bento\packer_templates\ubuntu> packer build -debug -only=vmware-iso .\ubuntu-20.04-amd64.json
Debug mode enabled. Builds will not be parallelized.
vmware-iso: output will be in this color.

==> vmware-iso: Pausing after run of step 'StepPrepareTools'. Press enter to continue.
==> vmware-iso: Retrieving ISO
==> vmware-iso: Trying http://cdimage.ubuntu.com/ubuntu-legacy-server/releases/20.04/release/ubuntu-20.04-legacy-server-amd64.iso
==> vmware-iso: Trying http://cdimage.ubuntu.com/ubuntu-legacy-server/releases/20.04/release/ubuntu-20.04-legacy-server-amd64.iso?checksum=sha256%3A36f15879bd9dfd061cd588620a164a82972663fdd148cce1f70d57d314c21b73
==> vmware-iso: http://cdimage.ubuntu.com/ubuntu-legacy-server/releases/20.04/release/ubuntu-20.04-legacy-server-amd64.iso?checksum=sha256%3A36f15879bd9dfd061cd588620a164a82972663fdd148cce1f70d57d314c21b73 => C:\Users\halo\Code\bento\packer_templates\ubuntu\packer_cache\2034fb4886758b33b4b024f8986e2b66a1f2d9a0.iso
==> vmware-iso: Pausing after run of step 'StepDownload'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'StepOutputDir'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'StepCreateFloppy'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'StepRemoteUpload'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'StepRemoteUpload'. Press enter to continue.
==> vmware-iso: Creating required virtual machine disks
==> vmware-iso: Pausing after run of step 'stepCreateDisk'. Press enter to continue.
==> vmware-iso: Building and writing VMX file
==> vmware-iso: Pausing after run of step 'stepCreateVMX'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'StepConfigureVMX'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'StepSuppressMessages'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'StepHTTPIPDiscover'. Press enter to continue.
==> vmware-iso: Starting HTTP server on port 8090
==> vmware-iso: Pausing after run of step 'StepHTTPServer'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'StepConfigureVNC'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'StepRegister'. Press enter to continue.
==> vmware-iso: Starting virtual machine...
==> vmware-iso: Pausing after run of step 'StepRun'. Press enter to continue.
==> vmware-iso: Waiting 10s for boot...
==> vmware-iso: Connecting to VM via VNC (127.0.0.1:5997)
==> vmware-iso: Typing the boot command over VNC...
==> vmware-iso: Pausing after run of step 'boot_command: <esc><wait><esc><wait><enter><wait>/install/vmlinuz<wait> auto<wait> console-setup/ask_detect=false<wait> console-setup/layoutcode=us<wait> console-setup/modelcode=pc105<wait> debconf/frontend=noninteractive<wait> debian-installer=en_US.UTF-8<wait> fb=false<wait> initrd=/install/initrd.gz<wait> kbd-chooser/method=us<wait> keyboard-configuration/layout=USA<wait> keyboard-configuration/variant=USA<wait> locale=en_US.UTF-8<wait> netcfg/get_domain=vm<wait> netcfg/get_hostname=vagrant<wait> grub-installer/bootdev=/dev/sda<wait> noapic<wait> preseed/url=http://192.168.162.1:8090/preseed.cfg<wait> -- <wait><enter><wait>'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'StepTypeBootCommand'. Press enter to continue.
==> vmware-iso: Waiting for SSH to become available...

[svpernova09]

Here's a video of the VM running to the point it stalls out.

https://youtu.be/gqzjl6UxlJ8

[svpernova09]

I believe this is only affecting VMware. I currently have packer building the 20.04 template with Hyper-V past the point where VMware hangs.

[moreinhardt]

I can confirm this also happens with ubuntu 20.04 and proxmox when using packer v1.6.0.

[svpernova09]

Using VMware Workstation 15.5.2 build 15785246 the build proceeds as expected and completes. Using the latest 15.5.6 build-16341506 does not work, and will cause the build to hang.

[tas50]

Can you give this a try with the latest VMs I pushed last night? They're built on a newer VMware with a newer packer. You'll also want to make sure that you have everything on your local host upgraded to the latest as well.

[svpernova09]

Packer 1.6.1 VMware Workstation 15 Pro 15.5.6 build-16341506 chef/bento: b7b8a9bd30e143514b61a694c7d37155733adea1 Windows 10 Pro 2004 build 19041.450

Building via packer build -only=vmware-iso .\ubuntu-20.04-amd64.json still fails at the same place as it has previously.

Same result for 18.04:

[svpernova09]

Can you give this a try with the latest VMs I pushed last night? They're built on a newer VMware with a newer packer. You'll also want to make sure that you have everything on your local host upgraded to the latest as well.

I can confirm the box 'bento/ubuntu-20.04' (v202008.16.0) for provider: vmware_desktop and box 'bento/ubuntu-18.04' (v202008.16.0) for provider: vmware_desktop are both working as expected.

20.04

PS C:\Users\halo\Code\bento-20.04> vagrant up
Bringing machine 'default' up with 'vmware_desktop' provider...
==> default: Box 'bento/ubuntu-20.04' could not be found. Attempting to find and install...
    default: Box Provider: vmware_desktop, vmware_fusion, vmware_workstation
    default: Box Version: >= 0
==> default: Loading metadata for box 'bento/ubuntu-20.04'
    default: URL: https://vagrantcloud.com/bento/ubuntu-20.04
==> default: Adding box 'bento/ubuntu-20.04' (v202008.16.0) for provider: vmware_desktop
    default: Downloading: https://vagrantcloud.com/bento/boxes/ubuntu-20.04/versions/202008.16.0/providers/vmware_desktop.box
Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
    default:
==> default: Successfully added box 'bento/ubuntu-20.04' (v202008.16.0) for 'vmware_desktop'!
==> default: Cloning VMware VM: 'bento/ubuntu-20.04'. This can take some time...
==> default: Checking if box 'bento/ubuntu-20.04' version '202008.16.0' is up to date...
==> default: Verifying vmnet devices are healthy...
==> default: Preparing network adapters...
==> default: Starting the VMware VM...
==> default: Waiting for the VM to receive an address...
==> default: Forwarding ports...
    default: -- 22 => 2222
==> 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
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Configuring network adapters within the VM...
==> default: Waiting for HGFS to become available...
==> default: Enabling and configuring shared folders...
    default: -- C:/Users/halo/Code/bento-20.04: /vagrant```

18.04

PS C:\Users\halo\Code\bento-18.04> vagrant up
Bringing machine 'default' up with 'vmware_desktop' provider...
==> default: Box 'bento/ubuntu-18.04' could not be found. Attempting to find and install...
    default: Box Provider: vmware_desktop, vmware_fusion, vmware_workstation
    default: Box Version: >= 0
==> default: Loading metadata for box 'bento/ubuntu-18.04'
    default: URL: https://vagrantcloud.com/bento/ubuntu-18.04
==> default: Adding box 'bento/ubuntu-18.04' (v202008.16.0) for provider: vmware_desktop
    default: Downloading: https://vagrantcloud.com/bento/boxes/ubuntu-18.04/versions/202008.16.0/providers/vmware_desktop.box
Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
    default:
==> default: Successfully added box 'bento/ubuntu-18.04' (v202008.16.0) for 'vmware_desktop'!
==> default: Cloning VMware VM: 'bento/ubuntu-18.04'. This can take some time...
==> default: Checking if box 'bento/ubuntu-18.04' version '202008.16.0' is up to date...
==> default: Verifying vmnet devices are healthy...
==> default: Preparing network adapters...
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Starting the VMware VM...
==> default: Waiting for the VM to receive an address...
==> default: Forwarding ports...
    default: -- 22 => 2200
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2200
    default: SSH username: vagrant
    default: SSH auth method: private key
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Configuring network adapters within the VM...
==> default: Waiting for HGFS to become available...
==> default: Enabling and configuring shared folders...
    default: -- C:/Users/halo/Code/bento-18.04: /vagrant
PS C:\Users\halo\Code\bento-18.04>

[tas50]

You might want to try bumping the hardware version in the packer configs to a later version. I just recently had to bump the Fedora configs to 11 to get things to build completely. These configs build fine for me, but that's on Fusion, which is quite different. https://github.com/chef/bento/blob/master/packer_templates/fedora/fedora-33-x86_64.json#L73

[JeffreyFreeland]

I've been stuck for a few days with the same (or similar) hanging issue ever since assembling a new PC (both windows 10), but when using vagrant and virtualbox rather than packer. 18.04 hangs (with some output in the guest console), 20.04 hangs (no visible output), but 16.04 does not hang,. I'm using the most recent release for all of them. The previous Ubuntu 18.04 (v202010.24.0) seems to hang without output in the guest console as well. I'm using vagrant 2.2.14, virtualbox 6.1.16, and the following Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-18.04"
  config.vm.provider "virtualbox" do |vb|
    vb.memory = 1024
    vb.cpus = 1
  end
end

I get this result when running vagrant up:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'bento/ubuntu-18.04'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'bento/ubuntu-18.04' version '202012.21.0' is up to date...
==> default: Setting the name of the VM: vagrant-troubleshooting_default_1609787790968_65095
==> 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
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.

including this output in the guest for the most recent 18.04:

When looking for log output I was able to find these ssh related messages:

# Some relevant output info with VAGRANT_LOG=debug

DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2021-01-03T13:25:23.997222 #10776] DEBUG -- net.ssh.transport.session[53e4554]: establishing connection to 127.0.0.1:2222
D, [2021-01-03T13:25:24.008224 #10776] DEBUG -- net.ssh.transport.session[53e4554]: connection established
I, [2021-01-03T13:25:24.008332 #10776]  INFO -- net.ssh.transport.server_version[53e4ba8]: negotiating protocol version
D, [2021-01-03T13:25:24.008417 #10776] DEBUG -- net.ssh.transport.server_version[53e4ba8]: local is `SSH-2.0-Ruby/Net::SSH_6.2.0.rc1 x64-mingw32'

DEBUG ssh: == Net-SSH connection debug-level log END ==
ERROR warden: Error occurred: 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.

# Error message present when running vagrant up --debug

DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO ssh: SSH not ready: #<Vagrant::Errors::NetSSHException: An error occurred in the underlying SSH library that Vagrant uses.
The error message is shown below. In many cases, errors from this
library are caused by ssh-agent issues. Try disabling your SSH
agent or removing some keys and try again.

If the problem persists, please report a bug to the net-ssh project.

timeout during server version negotiating>

I attempted to see about disabling ssh-agent in windows, so I used Get-Service ssh-agent and Get-Service ssh-agent | Select StartType to see that it was already stopped and disabled respectively. I tried to enable it and start the service to see if that helped, but it did not.

I don't know where the source of the issue lies, but since 16.04 works this issue seemed like a reasonable place to comment.

[clong]

Seeing the same issue attempting to build this on ESXi via Packer using vmware-iso. Debug logs show:

2021/01/11 14:07:35 packer-builder-vmware-iso plugin: [DEBUG] starting remote command: esxcli --formatter csv network vm port list -w 566941
2021/01/11 14:07:36 packer-builder-vmware-iso plugin: [DEBUG] Error getting SSH address: No interface on the VM has an IP address ready
2021/01/11 14:07:41 packer-builder-vmware-iso plugin: [DEBUG] Opening new ssh session
2021/01/11 14:07:41 packer-builder-vmware-iso plugin: [DEBUG] starting remote command: esxcli --formatter csv network vm list
2021/01/11 14:07:41 packer-builder-vmware-iso plugin: [DEBUG] Opening new ssh session
2021/01/11 14:07:41 packer-builder-vmware-iso plugin: [DEBUG] starting remote command: esxcli --formatter csv network vm port list -w 566941
2021/01/11 14:07:42 packer-builder-vmware-iso plugin: [DEBUG] Error getting SSH address: No interface on the VM has an IP address ready

ESXi results of me manually running the command:

[root@esxi:~] esxcli --formatter csv network vm port list -w 566941
ActiveFilters,DVPortID,IPAddress,MACAddress,PortID,Portgroup,TeamUplink,UplinkPortID,vSwitch,
,,192.168.3.165,00:0c:29:64:e9:72,67108894,VM Network,vmnic0,2214592516,vSwitch0,

However, SSH never seems to start on the host:

$ ping 192.168.3.165
PING 192.168.3.165 (192.168.3.165): 56 data bytes
64 bytes from 192.168.3.165: icmp_seq=0 ttl=63 time=0.927 ms

$ ssh 192.168.3.165
ssh: connect to host 192.168.3.165 port 22: Network is unreachable

[clong]

Actually, it looks like this may have been a connectivity issue. If the VM can't reach the preseed file, it seems to hang at this point. Are the webserver logs for the HTTP server Packer starts stored somewhere? This would help verify connectivity.

[svpernova09]

You might want to try bumping the hardware version in the packer configs to a later version. I just recently had to bump the Fedora configs to 11 to get things to build completely. These configs build fine for me, but that's on Fusion, which is quite different. https://github.com/chef/bento/blob/master/packer_templates/fedora/fedora-33-x86_64.json#L73

I've tried hardware versions 16 to 9 from this list: https://kb.vmware.com/s/article/1003746 and still get a mysterious kernel panic I'm unable to see because of the low screen resolution.

packer build --only=vmware-iso .\ubuntu-20.04-amd64.json

VMware Workstation 16.1.0 build-17198959

[VivaldiKF]

I have also encountered this issue when attempting a packer build --only=vmware-iso ubuntu-20.04-amd64.json on both Linux and Windows.

Environment:

• Packer: v1.7.0
• Builder: vmware-iso
• ISO: ubuntu-20.04.1-legacy-server-amd64.iso
• Env: VMware Workstation 16.1.0 build-17198959

Linux:

Windows:

Note: My Packer 1.7 builds of CentOS 8.3 and Debian 10.8 were successful. This seems isolated solely to Ubuntu.

Given the several cited examples provided at this point, can this issue now be adequately triaged?

[svpernova09]

Just tested Ubuntu 20.04 on VMware Pro 16.1.1 build-17801498 and still getting Kernel Panic.

[mnightingale]

Also tested on VMware Pro 16.1.1 build-17801498

packer build -only=vmware-iso .\ubuntu-20.04-amd64.json

I've outputted the console to file, I've included a diff in case anyone else wants to maybe to check they get the same fault, I've no idea what's causing the problem though.

I notice the later Ubuntu configs only use the live distributions, I assume they've stopped publishing the legacy versions, maybe users blocked by this can just use the live config?

I've just tried ubuntu-20.04-live-amd64.json and that built (had to change mirror to old-releases and I downloaded it via torrent anyway because old-releases is slow), I also tried it with the 20.04.2 ISO and that worked after some changes to the boot command.

[    1.507221] kernel BUG at arch/x86/kernel/apic/vector.c:172!
[    1.508169] invalid opcode: 0000 [#1] SMP NOPTI
[    1.508933] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.0-42-generic #46-Ubuntu
[    1.509931] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/22/2020
[    1.509931] RIP: 0010:apic_update_vector+0xa5/0x160
[    1.509931] Code: c0 e0 5f 01 00 44 89 6b 10 4a 8b 0c ed 80 59 24 b8 48 89 c2 4a 8d 34 e1 48 8b 14 16 48 85 d2 74 0b 48 81 fa 00 f0 ff ff 77 02 <0f> 0b 4a 8d 14 e1 4c 89 14 02 48 83 c4 20 5b 41 5c 41 5d 41 5e 41
[    1.509931] RSP: 0018:ffffb44e0000f760 EFLAGS: 00010087
[    1.509931] RAX: 0000000000015fe0 RBX: ffff9ebe7ccbbf80 RCX: ffff9ebe7dd00000
[    1.509931] RDX: ffff9ebe7d46da00 RSI: ffff9ebe7dd00180 RDI: 0000000000000000
[    1.509931] RBP: ffffb44e0000f7a8 R08: 0000000000000000 R09: 0000000000000000
[    1.509931] R10: ffff9ebe7cb53200 R11: 0000000000000000 R12: 0000000000000030
[    1.509931] R13: 0000000000000001 R14: ffff9ebe7ccbb5c0 R15: 0000000000000000
[    1.509931] FS:  0000000000000000(0000) GS:ffff9ebe7dd00000(0000) knlGS:0000000000000000
[    1.509931] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.509931] CR2: 0000000000000000 CR3: 000000003180a000 CR4: 00000000001406e0
[    1.509931] Call Trace:
[    1.509931]  assign_vector_locked+0xb7/0x150
[    1.509931]  x86_vector_activate+0x1c7/0x2b0
[    1.509931]  __irq_domain_activate_irq+0x58/0x90
[    1.509931]  __irq_domain_activate_irq+0x38/0x90
[    1.509931]  irq_domain_activate_irq+0x29/0x40
[    1.509931]  irq_activate+0x25/0x30
[    1.509931]  __setup_irq+0x2f0/0x720
[    1.509931]  request_threaded_irq+0xfe/0x160
[    1.509931]  pcie_pme_probe+0xaa/0xe0
[    1.509931]  pcie_port_probe_service+0x36/0x60
[    1.509931]  really_probe+0x2b3/0x3e0
[    1.509931]  driver_probe_device+0xbc/0x100
[    1.509931]  __device_attach_driver+0x71/0xd0
[    1.509931]  ? driver_allows_async_probing+0x50/0x50
[    1.509931]  bus_for_each_drv+0x84/0xd0
[    1.509931]  __device_attach+0xe1/0x160
[    1.509931]  device_initial_probe+0x13/0x20
[    1.509931]  bus_probe_device+0x8f/0xa0
[    1.509931]  device_add+0x3c7/0x6b0
[    1.509931]  device_register+0x1b/0x20
[    1.509931]  pcie_port_device_register+0x2c6/0x540
[    1.509931]  pcie_portdrv_probe+0x36/0xc0
[    1.509931]  local_pci_probe+0x48/0x80
[    1.509931]  pci_device_probe+0x10f/0x1b0
[    1.509931]  really_probe+0x159/0x3e0
[    1.509931]  driver_probe_device+0xbc/0x100
[    1.509931]  device_driver_attach+0x5d/0x70
[    1.509931]  __driver_attach+0x8f/0x150
[    1.509931]  ? device_driver_attach+0x70/0x70
[    1.509931]  bus_for_each_dev+0x7e/0xc0
[    1.509931]  driver_attach+0x1e/0x20
[    1.509931]  bus_add_driver+0x152/0x1f0
[    1.509931]  driver_register+0x74/0xd0
[    1.509931]  ? dmi_pcie_pme_disable_msi+0x24/0x24
[    1.509931]  __pci_register_driver+0x57/0x60
[    1.509931]  pcie_portdrv_init+0x47/0x4f
[    1.509931]  do_one_initcall+0x4a/0x1fa
[    1.509931]  kernel_init_freeable+0x1b2/0x255
[    1.509931]  ? rest_init+0xb0/0xb0
[    1.509931]  kernel_init+0xe/0x100
[    1.509931]  ret_from_fork+0x22/0x40
[    1.509931] Modules linked in:
[    1.509931] ---[ end trace c4deb5948286575a ]---
[    1.509931] RIP: 0010:apic_update_vector+0xa5/0x160
[    1.509931] Code: c0 e0 5f 01 00 44 89 6b 10 4a 8b 0c ed 80 59 24 b8 48 89 c2 4a 8d 34 e1 48 8b 14 16 48 85 d2 74 0b 48 81 fa 00 f0 ff ff 77 02 <0f> 0b 4a 8d 14 e1 4c 89 14 02 48 83 c4 20 5b 41 5c 41 5d 41 5e 41
[    1.509931] RSP: 0018:ffffb44e0000f760 EFLAGS: 00010087
[    1.509931] RAX: 0000000000015fe0 RBX: ffff9ebe7ccbbf80 RCX: ffff9ebe7dd00000
[    1.509931] RDX: ffff9ebe7d46da00 RSI: ffff9ebe7dd00180 RDI: 0000000000000000
[    1.509931] RBP: ffffb44e0000f7a8 R08: 0000000000000000 R09: 0000000000000000
[    1.509931] R10: ffff9ebe7cb53200 R11: 0000000000000000 R12: 0000000000000030
[    1.509931] R13: 0000000000000001 R14: ffff9ebe7ccbb5c0 R15: 0000000000000000
[    1.509931] FS:  0000000000000000(0000) GS:ffff9ebe7dd00000(0000) knlGS:0000000000000000
[    1.509931] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.509931] CR2: 0000000000000000 CR3: 000000003180a000 CR4: 00000000001406e0
[    1.509931] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    1.509931] Kernel Offset: 0x35e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    1.509931] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

Diff to enable serial output (builds/packer-ubuntu-20.04-live-amd64-vmware/serial.log)

```diff diff --git a/packer_templates/ubuntu/ubuntu-20.04-amd64.json b/packer_templates/ubuntu/ubuntu-20.04-amd64.json index bb7caec..2531245 100644 --- a/packer_templates/ubuntu/ubuntu-20.04-amd64.json +++ b/packer_templates/ubuntu/ubuntu-20.04-amd64.json @@ -55,6 +55,7 @@ "", "/install/vmlinuz", " auto", + " console=tty0 console=ttyS0,115200n8", " console-setup/ask_detect=false", " console-setup/layoutcode=us", " console-setup/modelcode=pc105", @@ -72,6 +73,7 @@ " noapic", " preseed/url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/{{user `preseed_path`}}", " -- ", + " debug", "" ], "boot_wait": "5s", @@ -97,7 +99,8 @@ "cpuid.coresPerSocket": "1", "ethernet0.pciSlotNumber": "32" }, - "vmx_remove_ethernet_interfaces": true + "vmx_remove_ethernet_interfaces": true, + "serial": "file:serial.log" }, { "boot_command": [ ```

[svpernova09]

@mnightingale Can you share a fork with your changes for a working 20.04 build?

Here's my diff, but I'm still getting kernel panics but the serial.log is 0 bytes.

[mnightingale]

I had a hunch based on the kernel panic, could you try https://github.com/mnightingale/bento/tree/ubuntu_2004_apic I'm not sure if this change should only be for vmware-iso

I also checked the previous diff for serial and that worked, serial.log showed as 0 bytes but once opened it had the contents and filesize updated.

As far as I can see there is no legacy-server release for 20.04.2 but I've updated ubuntu-20.04-live-amd64.json at https://github.com/mnightingale/bento/tree/ubuntu_2004_upgrade I think there could be a timing issue with the boot command (I think it can wait too long at the beginning). I did replace the wait5s otherwise it takes too long typing.

[loister72]

I found a workaround for the kernel panic was to remove the apic line. I got past kernel panic then hangs after configuring the network.

[AcesTerra]

I am seeing the same issue with Ubuntu 20.04. Image was downloaded from https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img.

This is the JSON file used for Packer:

{ "builders": [ { "boot_command": [], "boot_wait": "10s", "disk_compression": "true", "disk_image": "true", "disk_interface": "virtio", "disk_size": "20000", "format": "qcow2", "headless": "true", "http_directory": ".", "iso_checksum": "none", "iso_url": "{{user iso_url}}", "name": "uefi", "qemuargs": [ [ "-m", "2048" ], [ "-cpu", "host" ], [ "-smp", "cpus=4" ], [ "-bios", "/usr/share/ovmf/OVMF.fd" ] ], "shutdown_command": "/sbin/halt -h -p", "ssh_password": "{{user root_password}}", "ssh_port": 22, "ssh_pty": true, "ssh_timeout": "10000s", "ssh_username": "root", "type": "qemu", "vm_name": "{{user image_name}}.qcow2", "vnc_bind_address": "0.0.0.0", "vnc_port_max": "5995", "vnc_port_min": "5995" } ], "post-processors": [ { "checksum_types": [ "md5" ], "output": "output-{{build_name}}/{{user image_name}}.qcow2.md5", "type": "checksum" } ], "provisioners": [ { "expect_disconnect": true, "pause_before": "5m", "scripts": [ "scripts/env_soft_pass.sh" ], "type": "shell" } ], "variables": { "disk_image": "{{env disk_image}}", "image_name": "{{env image_name}}", "image_repo": "{{env image_repo}}", "iso_checksum": "{{env iso_checksum}}", "iso_checksum_type": "{{env iso_checksum_type}}", "iso_url": "{{env iso_url}}", "root_password": "{{env ROOT_PASSWORD}}" } }

I got this error when Packer tries to SSH VM:

packer build template.json

uefi: output will be in this color.

==> uefi: Retrieving ISO ==> uefi: Trying ./focal-server-cloudimg-amd64.qcow2 ==> uefi: Trying ./focal-server-cloudimg-amd64.qcow2 ==> uefi: ./focal-server-cloudimg-amd64.qcow2 => /builds/focal-server-cloudimg-amd64.qcow2 ==> uefi: Copying hard drive... ==> uefi: Resizing hard drive... ==> uefi: Starting HTTP server on port 8039 ==> uefi: Found port for communicator (SSH, WinRM, etc): 4067. ==> uefi: Looking for available port between 5995 and 5995 on 0.0.0.0 ==> uefi: Starting VM, booting disk image uefi: The VM will be run headless, without a GUI. If you want to uefi: view the screen of the VM, connect via VNC without a password to uefi: vnc://0.0.0.0:5995 ==> uefi: Overriding defaults Qemu arguments with QemuArgs... ==> uefi: Waiting 10s for boot... ==> uefi: Connecting to VM via VNC (0.0.0.0:5995) ==> uefi: Typing the boot command over VNC... ==> uefi: Using ssh communicator to connect: 127.0.0.1 ==> uefi: Waiting for SSH to become available...

It gets stuck in SSH. I checked sshd service is enabled in VM and I can SSH from VM to localhost but Packer cannot SSH to VM. I have built images for CentOS, Clear Linux and Windows without any problem.

Does anyone has a workaround for this?

Best regards.

[svpernova09]

On a whim, I tried to build again today and it works I'm not sure what's changed.

Windows 10 Pro 21H2 19044.1165 VMware® Workstation 16 Pro 16.1.2 build-17966106

Running packer build --only=vmware-iso .\ubuntu-20.04-amd64.json in Powershell.

[ggarg1980]

I believe this is only affecting VMware. I currently have packer building the 20.04 template with Hyper-V past the point where VMware hangs.

I am having issues with packer, Ubuntu 20.04 with Hyper-V, is it possible to share the configuration

[svpernova09]

I was able to start a build but it crashed again with the same kernel error. Not sure how to debug.

[mnightingale]

It's a while since I've tried this but it seems to have ran all the way through for me, it was stuck at "Waiting for SSH to become available" for a little while.

Windows 10 Pro 21H119043 VMware® Workstation 16 Pro 16.2.0 build-18760230 Packer 1.7.2

packer build --only=vmware-iso .\ubuntu-20.04-amd64.json

==> Wait completed after 11 minutes 10 seconds

==> Builds finished. The artifacts of successful builds are:
--> vmware-iso: 'vmware' provider box: ../../builds/ubuntu-20.04.vmware.box

It might be worth trying resetting the VMware network (Edit > Virtual Network Editor > Change Settings > Restore Defaults)

---

It looks like the kernel panic for this was fixed in https://github.com/chef/bento/commit/a4b90eee98a1c45617753ebbd5d3769d88e826f8 which removed the noapic line which I had success with previously.

I've just completed a laravel/homestead build (I had to change boot_wait back to 5s else it didn't interrupt the boot sequence early enough and did a normal boot and got stuck at a language screen)

[Gorkyman]

Is this resolved now? Can we have vmware build back?

[Stromweld]

@Gorkyman there is a known issue with the vmware packer plugin and the latest version of vmware fusion 13 due to the update of the location for vmware tools. https://github.com/hashicorp/packer-plugin-vmware/issues/109

[Stromweld]

Closing this issue due to age. Please feel free to re-open or submit a new issue if the problem still exists with the latest version of the bento code.

[Gorkyman]

@Stromweld I think the issue was resolved now?