In part one of this series, I described how to get the basic distribution copied down from AWS to a local partition within a virtualized environment.
For part two of this series, I am going to describe putting a working kernel and kernel tool building environment on the virtual disk created during part 1, and boot it up for the first time.
We need a bootable kernel to continue working with our new image and the Amazon provided Linux kernel does not include the drivers for normal SCSI disks (or virtual disks in this case), and my attempts at rebuilding the kernel, or the modules, failed repeatedly.
At the end of part one, we copied everything over from the Amazon Linux EC2 instance into our second 40 GiB virtual disk mounted as /mnt.
We need a working kernel from Ubuntu 10.10; this works perfect for us because it is using the same version of glibc as Amazon Linux is – version 2.12.
First, let’s update our Ubuntu system to the last kernel release for 10.10, and I am assuming you are still in a root shell.
Insert the following three lines:
deb http://old-releases.ubuntu.com/ubuntu/ maverick main restricted universe multiverse deb http://old-releases.ubuntu.com/ubuntu/ maverick-updates main restricted universe multiverse deb http://old-releases.ubuntu.com/ubuntu/ maverick-security main restricted universe multiverse
Then issue the following 3 commands:
apt-get update apt-get -y dist-upgrade reboot
Once the system reboots, log back in and then get a root shell, and mount up our 40 GiB virtual disk:
sudo su - root mount -o async,noatime /dev/sdb1 /mnt
This next command will copy over all the kernel items we need to get the kernel (and tools) copied over to the new image:
tar cfp - <code>locate 2.6.35-32</code> | (cd /mnt ; tar xfp -)
The above command takes the output of the locate command as file parameters to the tar command. The tar command is creating a new archive but outputting to standard out. The second part of the command line (after the | symbol) changes the directory to /mnt and executes a tar command extracting the data coming in on standard input.
This may take from 20 seconds to 5 minutes to run depending on the speed of your storage.
Once your command line returns issue a halt so that we can continue forward:
As I stated before, I used VMware Fusion for my work and these instructions reflect such.
For your VM, you need to click on the settings wrench and then select the primary hard disk.
Remove this disk from the image BUT do not move it to the trash or delete permanently. If any mistakes have happened then we can at least attach this disk to the virtual machine and start over without reinstalling.
Go to the startup disk control and set the CDROM as the bootable device. We will change this later but for the moment we need to boot from the CDROM one more time.
Close the settings window and power on the VM.
When prompted, choose your language, and then select ‘Rescue a broken system‘. Answer defaults for everything until prompted to mount a root disk.
When prompted: Device to use as root file system, select /dev/sda1 as the root disk
When prompted: Execute a shell in /dev/sda1 – press return
You are now in a root shell on the virtual disk where Amazon Linux currently resides. We are going to edit 3 files, turn off 2 AWS specific startup scripts, and rename one directory used for DHCP within EC2.
We will install the boot blocks.
Let’s edit the boot menu so we can start-up using our new kernel:
cd /boot/grub vi menu.lst
Add to the top, after hidden menu, including a blank line, the following:
title Amazon Linux 2013.09 (2.6.35-32-ubuntu vagrant-box) root (hd0) kernel /boot/vmlinuz-2.6.35-32-server root=/dev/sda ro initrd /boot/initrd.img-2.6.35-32-server
Resulting file should look similar to this:
# created by imagebuilder default=0 timeout=1 hiddenmenu title Amazon Linux 2013.09 (2.6.35-32-ubuntu vagrant-box) root (hd0) kernel /boot/vmlinuz-2.6.35-32-server root=/dev/sda ro initrd /boot/initrd.img-2.6.35-32-server title Amazon Linux 2013.09 (3.4.83-70.111.amzn1.x86_64) root (hd0) kernel /boot/vmlinuz-3.4.83-70.111.amzn1.x86_64 root=LABEL=/ console=hvc0 LANG=en_US.UTF-8 KEYTABLE=us initrd /boot/initramfs-3.4.83-70.111.amzn1.x86_64.img
Now to install the grub boot loader:
Disable the scripts that give us problems as we are not running in EC2:
chkconfig cloud-init off chkconfig cloud-init-user-scripts off
And rename the directory that does EC2 DHCP magic that causes failures without EC2:
mv /etc/dhcp/dhclient.d /etc/dhcp/dhclient.d.ORIG
Exit the shell and you will be prompted to reboot.
Once you are at the CDROM boot screen, shut down the virtual machine, click on the settings wrench, and set the startup disk to the first hard disk.
Power on the virtual machine. If everything was correctly done then it should take you to a login prompt.
Unfortunately you cannot log in just yet – that comes in part three.
As before, you can donate to this work by sending BTC to this Bitcoin address.