Ubuntu 20.04 live not building on Virtualbox (cloud-init failure?)

[WolfangAukang]

Version:

Commit 9760060a295934562c03a010bb1f0234a9423c7b

Environment:

Using NixOS, running the cookbook from bento/packer_templates/ubuntu/ubuntu-20.04-live.amd64.json for Virtualbox (6.1.30 r148432)

Scenario:

Building an Ubuntu 20.04.4 image successfully

Steps to Reproduce:

Run packer build -only=virtualbox-iso ubuntu-20.04-live-amd64.json

Expected Result:

Successful build of the image

Actual Result:

[Mte90]

I have the same issues that let the machine to go in timeout

[elreydetoda]

alright, so this was going to be the message that I sent in response to this thread)...

So, it looks like for some reason the target system is failing an apt update. I had the same issue too, and then found this GH issue. I logged into the target system and noticed that it wasn't resolving the mirrors during the apt update. I checked the /etc/resolv.conf and there was nothing in that. So, I just did a quick echo 'nameserver 8.8.8.8 > /etc/resolv.conf and everything worked. I tried to configure DNS via the user-data file. But that just configured the initial host which is running the subiquity installer :disappointed: I still got the same error... Whatever it is, it seems like we need to fix DNS inside the target system to get things working somehow... The difficult thing is that it seems that the installer is not using /target anymore for installing the target OS, but it looks like they're probably using the mktemp -d command to generate a random folder in /tmp and running commands in that (if you look at where I chroot in my first command you'll understand why I think this). So, we can't run an early-commands addition to install a resolve.conf that'll work, so I'm stumped... :disappointed:

but for some reason when I went to add a sleep 30 to the early-commands section to try and modify the temporary directories (which I couldn't because they were only created after the early-commands), it all of a sudden started working... :confused:

I thought that it could be this bug: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1967458 and since it isn't closed that there was going to be no resolution (and honestly throwing a sleep 30 in there isn't really a resolution or else I'd submit a PR), but at least my install isn't failing anymore... :sweat_smile:

just to be clear I modified this file, and added a - sleep 30, right after this line.

[WolfangAukang]

@elreydetoda Generally, when I have to add a sleep before running a configuration script on an Ubuntu AMI, it is because apt is still running. As this is coming from the Ubuntu ISO, I am really not sure if it is the same problem, but I am not surprised that the solution of adding a sleep also works here. Maybe the issue is the same? Would be interesting to troubleshoot this.

My only variation is that I had to increase the sleep time to 60 (no specific reason besides 30 was not working for me). But now it works. Thank you!

[elreydetoda]

@elreydetoda Generally, when I have to add a sleep before running a configuration script on an Ubuntu AMI, it is because apt is still running. As this is coming from the Ubuntu ISO, I am really not sure if it is the same problem, but I am not surprised that the solution of adding a sleep also works here. Maybe the issue is the same? Would be interesting to troubleshoot this.

My only variation is that I had to increase the sleep time to 60 (no specific reason besides 30 was not working for me). But now it works. Thank you!

Well I'm glad it's working for you!

Ya, I can try and troubleshoot it after work today, and see if that's what's going on 🙂

I'll also edit this message in a bit (on my mobile right now) and add the crash logs that I netcat'ed out of the VM to see if that helps identify anything at all. (It's the subiquity crash logs (.crash & .meta) that it says it writes out at the end of the error message we got before)

[Stromweld]

latest code has been building correctly on virtualbox in the build pipelines. Closing this issue as complete.