Find out why ubuntu wily and xenial base templates fail to get past the boot command key presses

[tylert]

At the moment, the wily and xenial base templates fail to automate the keypresses to get past the initial boot command part so it never actually starts off the install process.

1. extract the official server seed file from the wily and xenial ISOs to confirm they haven't changed
2. merge any changes with the existing wily and xenial preseed files in use here
3. if this doesn't fix it, keep applying various blunt instruments to ubuntu to make it work again

[mcclurmc]

I ran into this problem just now. I noticed that when vagrant is typing out the preseed url for xenial, the url gets a line split after the ub, so that the url is broken. The line split doesn't happen on precise. I can take a screencap if you want. Hope that helps your debugging.

[tylert]

I haven't had much opportunity to look at this yet--your help is very much appreciated. At first glance, this would appear to be an issue with Packer itself rather than the templates. It may be possible that this bug has already been fixed in the 5+ months between Packer 0.8.6 and Packer 0.9.0. I am somewhat doubtful that the problem lies in the ubiquity installer on wily and xenial.

I currently use VirtualBox 5.0.14 on Mac OS X (El Capitan), VirtualBox 4.3.36 on Linux (Debian 8.x) and qemu-kvm 2.1.2 on Linux (Debian 8.x) for testing.

[tylert]

Oh, I did confirm that the "ubuntu.seed" file (or whatever it was named; look in the preseed folder) packed inside the official Wily and Xenial server amd64 ISO files is identical to the ones that I am using (plus my added customizations).

[tylert]

I just tried this using qemu-kvm and the same newline after "ub" occurred there too for Wily.

[mcclurmc]

My versions are VirtualBox 5.0.8r103449 and Vagrant 1.8.1 on OSX, haven't tried this on Linux yet. I've got some errands to run, but I might be able to building packer from source to see if that fixes things.

[tylert]

Sounds good.

Typing in the boot command manually results in the same failure so maybe it is something else.

[mcclurmc]

Hey @tylert, do you have a WIP branch that resolves #4? I just built a new packer, and I figured I'd check with you before trying to update the xenial.json myself.

Of course, if you think that your manual test shows that the bug is upstream Ubuntu, maybe the bug isn't actually in Packer? Think I should hold off on further testing for now?

[tylert]

Issue #4 is mostly since I am waiting for precisely 1 new Packer feature to enter the mainline stable version--to stop it from renaming the ISOs that it downloads; For me, the hashed filenames are not optimal--I want the original filenames preserved. If you also want this functionality, you may pull my "foo" branch and use that. Otherwise, you may perform all your Xenial tests for issue #2 against the "master" branch. I didn't have much luck getting HEAD of Packer to work correctly when I tried last week but you may have more luck than me.

My quick-and-dirty initial manual tests above were simply to fire things up using packer, let it try and fail to send the key presses and then to jump in at the keyboard to type them in again (using the packer template boot command string as a guide). I think we can rule out the issue being in the virtualbox-iso or qemu packer builders themselves, however, it doesn't mean the problem isn't elsewhere in the packer code (i.e.: the code responsible for sending the keypresses or the code that sends the file over http perhaps). I only confirmed that the Wily ubiquity installer seems to behave the same when using packer + qemu and packer + vbox.

A better test might be to make the "base-64.seed" preseed file available via http (perhaps using the sow.py python script provided) and to attempt to bypass packer completely to try to rule that out. As in, get VirtualBox to boot the wily server ISO + manually type in the boot command string to fetch the preseed file over http. If you don't have a quick way to do this, you may do so if you have Python installed by typing:

cd packer-build
./sow.py

Anyway, thanks for taking the time to help out.

[tylert]

Well, ok, this would actually appear to be a regression in the Ubuntu installer...

• https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1505839
• https://bugs.launchpad.net/bugs/1537252
• ubuntu1510 does not build boxcutter/ubuntu#22

The workaround/fix is to change the boot_command string to stop it from dropping to text mode interface and use the F6 append string to send it a crap ton of "bs" keypresses instead before sending it the normal boot strings.

[tylert]

Fixed in master.

[mcclurmc]

Hey @tylert, thanks for the update! And thanks for maintaining a tool that does exactly the thing I need :)

[tylert]

Heh... Glad somebody is using it :)

[Ajedi32]

Specifically, this is fixed by 32d9faa