Clone AWS ami-816835e4

General questions
1

I’m trying to transfer the community VyOS 1.1.6 AWS image (ami-816835e4) from us-east-1 to sa-east-1. For do this, I’ve created an instance from that ami on us-east-1 and created a private ami from it -> ami-1614f97b.

After that, I’ve created a new instance from my private ami-1614f97b to check if it will start correctly before copy it to sa-east-1. But the instance created from it doesn’t starts successfull.

This is the console output. Note that there is a curl error when it tried to download the ssh public key. The ssh public key is the same used by the instance created from the community ami.

[    0.525847] Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
Loading, please wait...
mdadm: No arrays found in config file or automatically


INIT: version 2.88 booting

Using makefile-style concurrent boot in runlevel S.
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...[   19.718396] piix4_smbus 0000:00:01.3: SMBus base address uninitialized - upgrade BIOS or use force_addr=0xaddr
done.
Setting preliminary keymap...done.
Activating swap...done.
Cleaning up ifupdown....
Setting up networking....
Assembling MD arrays...done (no arrays found in config file or automatically).
Fast boot enabled, so skipping file system check. ... e[33m(warning).e[39;49m
Mounting local filesystems...done.
Activating swapfile swap...done.
Cleaning up temporary files....
Configuring network interfaces...done.
Cleaning up temporary files....
Setting console screen modes.
e]Rcannot (un)set powersave mode
e[9;30]e[14;30]Skipping font and keymap setup (handled by console-setup).
Setting up console font and keymap...done.
Loading kernel modules...done.
Setting kernel variables ...done.

INIT: Entering runlevel: 2

Using makefile-style concurrent boot in runlevel 2.
Starting enhanced syslogd: rsyslogd.
Starting ACPI services....
Not starting as we're not running in a vm.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler: cron.
Loading cpufreq kernel modules...done (none).
Starting network plug daemon: netplugd.
Starting routing daemons: ripd ripngd ospfd ospf6d bgpd.
Mounting VyOS Config...done.
Starting VyOS router: migrate rl-system firewall configure e[31mfailed!e[39;49m
EC2: -----BEGIN FETCH SSH PUBLIC KEY-----.
EC2: Requesting ssh public key from EC2 instance metadata.

curl: (7) Failed to connect to 169.254.169.254: Network is unreachable

    == WARNING ==
    No ssh public key found!
    If you launch an instance without specifying a keypair,
    you can't connect to the instance.
    Please terminate this instance and launch a new EC2 instance.

    == IMPORTANT ==
    Don't forget to create a keypair or select an existing one
    before you launch the new instance.
EC2: -----END FETCH SSH PUBLIC KEY-----.
Starting vyos-intfwatchd: vyos-intfwatchd.

Welcome to VyOS - VyOS-AMI ttyS0

VyOS-AMI login: ```

Why this error only ocurrs with the instance created from the private ami?
2

how does a describe-images differ from the public AMI to your AMI?

aws ec2 describe-images --image-ids ami-816835e4

aws ec2 describe-images --image-ids ami-1614f97b

I think the curl error is the clue that we need. I went through the same steps and hit the same problem. It is because there is a statically configured MAC address in the config.boot file. I think the instance boots up and sees that eth0 has a MAC that’s not defined on the system, so it probably renames the existing eth0 to eth1 which doesn’t have any network configuration on the system, so network never comes up and it can’t get an IP address (or curl for it’s public key).

A workaround is to launch your instance from ami-816835e4 then edit /config/config.boot and remove the hw-id from eth0 save the file and poweroff, then create image from this. When you launch your new instance the hw-id (MAC Address) is undefined for eth0, so it should be able to accept whatever MAC is given for the instance (after which it will probably populate it in the config). Give that a try and let us know if it works.

3

Ok. As I said before, my goal is to get 1.1.6 on sa-east-1 region. So, I’ve used another aproach: I’ve launched an instance based on VyOS (HVM) 1.1.0 (ami-adc175b0) on sa-east-1 and upgraded it to 1.1.6 using this procedure: http://vyos.net/wiki/Upgrade.

After upgrade to 1.1.6, I’ve upgraded to 1.1.7. Now I have 1.1.7 running on sa-east-1:

vyos@VyOS-AMI:~$ show system image 
The system currently has the following image(s) installed:

   1: VyOS-1.1.7 (default boot) (running image)
   2: VyOS-1.1.6
   3: 1.1.0

I did the same on an instance in us-east-1 based on VyOS (HVM) 1.1.0 (ami-ee299086).

So, I recommend to the community to do the same procedure that I did. The advantage is that you don’t need to have a private ami, avoiding costs.

Thank you very much jl3128