In older versions of arch linux, the hashicorp packer package (and
binary) was named packer-io to avoid clashing with a pre-existing AUR
helper called packer. Recently, the AUR helper package was renamed to
packer-aur and the old packer-io (and corresponding binary) was
renamed to packer.
https://www.archlinux.org/packages/community/x86_64/packer/
Previously, the wrapacker script would unconditionally set PACKER_BIN
to "packer-io" if the file /etc/arch-release existed. We now instead
the check for the existence of a packer-io command, and fall back to
the default "packer" in case that doesn't exist.
mirrors.kernel.org is redirecting to mirrors.edge.kernel.org, causing
ISO_NAME to be set to an empty string. This resulted in ISO_URL being
set to the wrong value and packer failing to download the iso.
Packer template variables allow for dynamic integration of isodate
variables.
This commit leverages the isotime template engine to auto generate
the year and month values for the ISO url as well as the SHA checksum
fields.
This will allow for the ISO image to continuously remain up-to-date
without the need for continued monthly commits.
Additionally, it leverages this same template variable to ensure that
the resulting box filename matches the date it was created, for archival
purposes.
It seems the archlinux dropped support for dual iso.
According the official mirror (and many other which I have checked)
there is only -x86_64.iso file.
You can see it here: https://mirrors.kernel.org/archlinux/iso/latest/
This fix will ensure that the correct signature is read when the image
is parsed in sha1sum.txt file.
This splits the difference between 60 seconds (from [1]) and the
previous 20 seconds, which is no longer enough time to boot cleanly...
@tomswartz07, @mod, and I have all been experiencing mid-20 second boot
times, so 40 seconds seems like enough headroom without being excessive.
[1]: 443997f28c
Update to Jan 2017 ISO (Happy New Year!)
It appears that the ISO startup boot time is slightly longer, recently.
Increase timeout before typing boot commands, to prevent initial parts
of the enable-ssh script from being cut off.
The nomenclature used with wrapacker is a bit of a mixture between the
Packer "builder" used and the Vagrant "provider" that will eventually
launch the resulting image that it creates. This tries to be a bit more
liberal with the input that will be accepted for that option.
The Vagrant documentation for option "group" in syncing folders states
(in https://www.vagrantup.com/docs/synced-folders/basic_usage.html#group):
"By default this will be the SSH user". Vagrant indeed tries to change
the owner and group of synchronized files to vagrant:vagrant (not
vagrant:users). It outputs:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
find /vagrant '!' -type l -a '(' ! -user vagrant -or ! -group vagrant
')' -exec chown vagrant:vagrant '{}' +
Stdout from the command:
Stderr from the command:
find: 'vagrant' is not the name of an existing group
Fix this by using --user-group instead of --gid users in the useradd
command which creates user vagrant.
Previously, there was an issue with mkfs failing due to a missing
options flag; this error was difficult to catch, as it was only output
in the provisioned OS's virtual machine file.
This change moves the base installation steps to be more in line with
the other provisioning steps, and allows for any errors, issues, or
output to be cached in the logs of the interface running the Packer
build.
Version 1.43 of e2fsprogs changes mkfs to default 64bit.
This doesn't play nicely with Syslinux, so disable it.
We wouldn't need 64bit filesystems unless we're working with 16TiB
filesystems.
