Jch: Created page with " The goal is not only to have a working install but to have it at the after setup-alpine stage without human intervention... Tis is the first stages of a work in progress......"

2015-04-17T07:03:27Z

Created page with " The goal is not only to have a working install but to have it at the after setup-alpine stage without human intervention... Tis is the first stages of a work in progress......"

New page

The goal is not only to have a working install but to have it at the after setup-alpine stage without human intervention...
Tis is the first stages of a work in progress...

I want to pass a Block Device and a name as parameters. The block device could be an image file, a LV, a NBD, a hdd, a raid array, whatever. 
Everything else should be fully automatic according to some config file (stating the http-proxy, the time server, the log server, ...).

The I will just run the script, watch my dhcp logs to discover the new IP assigned (that's why the name is a parameter), then log in with ssh without password to customize it further but at high level only (will be a robot and not me in fact).

I guess it would be something like emulate boot from usb key with specific overlay already on key... 
then run setup-disk with proper parameters on the command line to avoid the interactive process (like setup-alpine does)... 
Methink this could be done from a couple of scripts put in /etc/local.d/. The last.stop one deleting all of them to be clean at next reboot. 
Let's start easy ;)

=== How to prepare a img file to emulate an USB key ===

first a working example done in console (accessed trough ssh). 
Will build a script from it...

First, lets's prepare somme block device (here an image file but could be something else) <pre>
apk add qemu-img
qemu-img create -f raw usbkey.img 512M
apk del qemu-img
T="usbkey.img"
</pre>

Next, let's install AL on this $T <pre>
apk add multipath-tools syslinux dosfstools
fdisk $T
kpartx -av $T
mkdosfs -F32 /dev/mapper/loop1p1
dd if=/usr/share/syslinux/mbr.bin of=/dev/mapper/loop1
syslinux /dev/mapper/loop1p1
mkdir key
mount -t vfat /dev/mapper/loop1p1 key
wget http://wiki.alpinelinux.org/cgi-bin/dl.cgi/v3.1/releases/x86_64/alpine-mini-3.1.1-x86_64.iso
mkdir cdrom
mount alpine-mini-3.1.1-x86_64.iso cdrom
cd cdrom
cp -a .alpine-release * ../key/
cd ..
umount key
umount cdrom
kpartx -d $T
apk del multipath-tools syslinux dosfstools
rm alpine-mini-3.1.1-x86_64.iso
</pre>

This block device may now be use to boot some KVM for instance like: <pre>
screen -d -m -S KVM-builder \
qemu-system-x86_64 -name KVM-usb -enable-kvm -cpu qemu64 -curses \
-device nec-usb-xhci -drive if=none,id=usbstick,file=$T -device usb-storage,drive=usbstick
</pre> This is working fine.

The problem is when adding a HDD to the lot, qemu try to boot from the hdd and does not even try to boot from the usb key. Enabling menu in boot let's one access the emulated bios which allows to select USB device to boot interactively but this break the goal of fully automated boot :( The stanza is for instance <pre>
screen -d -m -S KVM-builder \
qemu-system-x86_64 -name KVM-usb -enable-kvm -cpu qemu64 -curses \
-device nec-usb-xhci -drive if=none,id=usbstick,file=$T -device usb-storage,drive=usbstick \
-drive file=$T2 boot menu=on
</pre>

qemu-doc states that very clearly: 
> -boot [order=drives][,once=drives][,menu=on|off][,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_timeout][,strict=on|off] 
> Specify boot order drives as a string of drive letters. Valid drive letters depend on the target achitecture. The x86 PC uses: a, b (floppy 1 and 2), c (first hard disk), d (first CD-ROM), n-p (Etherboot from network adapter 1-4), hard disk boot is the default

User talk:Jch/How to automate KVM creation - Revision history

Jch: Created page with " The goal is not only to have a working install but to have it at the after setup-alpine stage without human intervention... Tis is the first stages of a work in progress......"