Alpine Linux - User contributions [en]

Setting up disks manually

2015-01-22T18:11:00Z

Tze:

{{Draft}}

You may have complex needs that aren't handled automatically by the [[Alpine Setup Scripts]]. In those cases, you'll need to prepare your disks manually.

It is possible to have one or more of RAID, encryption, and/or LVM on your {{Path|/}} (root) volume. However, the Alpine init script only knows how to handle them when they're layered in that order, and your initram and extlinux.conf file in the {{Path|/boot}} partition are configured properly.

Your {{Path|/boot}} cannot reside on a encrypted or LVM volume, at least not with Alpine's default bootloader (extlinux). (Grub2 can deal with {{Path|/boot}} being on an LVM volume.) The usual practice is to create a small partition for {{Path|/boot}}, and then devote the rest of your disk to a separate partition on which you layer one or more of RAID, encryption, and/or LVM.

Sometimes {{Path|/boot}} is also setup as a mirrored (RAID1) volume, however this is just for post-init access. That way, when you write a new kernel or bootloader config file to {{Path|/boot}}, it gets written to multiple physical partitions. During the pre-init, bootloader phase, only one of those partitions will be read from.

So, typical setups might look like this:

<pre>
One-disk system
---------------
+------------------------------------------------+
| small partition (32--100M), holding |
| only /boot, filesystem needn't be journaled |
+------------------------------------------------+
| rest of disk in second partition |
| +------------------------------------------+ |
| | cryptsetup volume | |
| | +-------------------------------------+ | |
| | | LVM PV, containing single VG, | | |
| | | containing multiple LVs, holding | | |
| | | /, /home, swap, etc | | |
| | +-------------------------------------+ | |
| +------------------------------------------+ |
+------------------------------------------------+

Two-disk system
---------------
+------------------------------------------------+ +------------------------------------------------+
| small partition (32--100M), holding | | small partition (32--100M), holding | These 2 partitions might
| only /boot, filesystem needn't be journaled | | only /boot, filesystem needn't be journaled | form a mirrored (RAID1)
+------------------------------------------------+ +------------------------------------------------+ volume
| rest of disk in second partition | | rest of disk in second partition |
| T================================================================================================T | These 2 partitions form
| T +--------------------------------------------------------------------------------------------+ T | a second mirrored
| T | cryptsetup volume | T | (RAID1) volume
| T | +---------------------------------------------------------------------------------------+ | T |
| T | | LVM PV, containing single VG, | | T |
| T | | containing multiple LVs, holding | | T |
| T | | /, /home, swap, etc | | T |
| T | +---------------------------------------------------------------------------------------+ | T |
| T +--------------------------------------------------------------------------------------------+ T |
| T================================================================================================T |
| | | |
+------------------------------------------------+ +------------------------------------------------+

</pre>

In a three-disk system, the {{Path|/boot}} would still be RAID1, but the larger partition might in that case be RAID5.

=== RAID ===
<code>setup-disk</code> will automatically build a RAID array if you supply the '''-r''' switch, or if you specify more than one device.

If you instead want to build your RAID array manually, see [[Setting up a software RAID array]]. Then you can add additional layers of encryption and/or LVM, or just assemble the RAID array, and supply the {{Path|/dev/mdi}} device directly to [[setup-disk]]. When you're finished, be sure to disassemble the RAID array before rebooting.

If <code>setup-disk</code> sees that you're using RAID---either because you gave it the <code>-r</code> switch, or multiple devices, or a {{Path|/dev/mdi}} device---then it will setup your initramfs and extlinux.conf file properly. However, in other cases, such as when you're also using encryption, or you invoke <code>setup-disk</code> with a mounted directory argument, these might not be properly setup for RAID. In that case, you may need to manually edit/rebuild them. The following assumes that <code>$MNT</code> holds the root directory you're installing into:

{{Cmd|1=echo "/sbin/mdadm" > $MNT/etc/mkinitfs/files.d/raid
echo "/etc/mdadm.conf" >> $MNT/etc/mkinitfs/files.d/raid
# edit $MNT/etc/mkinitfs/mkinitfs.conf to make sure features="..."
# includes raid (this field is space-separated and quoted)
mkinitfs -c $MNT/etc/mkinitfs/mkinitfs.conf -b $MNT
# edit $MNT/etc/update-extlinux.conf to make sure modules=... contains
# raid1 or raid456 (whichever your / is on; this field is comma-separated)
# also check the root= setting
extlinux --raid --install $MNT/boot --update
}}

{{Todo|Does adding the <code>--update</code> option to <code>extlinux ...</code> suffice to make {{Path|/boot/extlinux.conf}} be regenerated? Or do we need to manually tweak that file, or run <code>update-extlinux</code>, as well?}}

You might also need to manually tweak {{Path|$MNT/etc/fstab}}. And you might need to copy {{Path|/usr/share/syslinux/mbr.bin}} to your disk's MBR.

=== Encryption ===

See [[Setting up encrypted volumes with LUKS]]. Then you can add an additional layer of LVM, or just unlock the volume you've created (using <code>cryptsetup luksOpen ...</code>), and supply the {{Path|/dev/mapper/something}} device directly to [[setup-disk]]. When you're finished, be sure to relock the volume (using <code>cryptsetup luksClose ...</code>) before rebooting.

If you install your {{Path|/}} (root) on an encrypted volume, you'll need to manually edit/rebuild your initram and your extlinux.conf file. The following assumes that <code>$MNT</code> holds the root directory you're installing into, that you've created the cryptvolume on the device {{Path|/dev/md2}}, and that you want to unlock the encrypted volume into a virtual volume named "crypt":

{{Cmd|1=# edit $MNT/etc/mkinitfs/mkinitfs.conf to make sure features="..."
# includes cryptsetup (this field is space-separated and quoted)
mkinitfs -c $MNT/etc/mkinitfs/mkinitfs.conf -b $MNT
# edit $MNT/etc/update-extlinux.conf to make sure default_kernel_opts="..."
# contains cryptroot=/dev/md1 and cryptdm=crypt (this field is also space-separated and quoted)
# also check the root= setting
extlinux --install $MNT/boot --update
}}

{{Todo|Does adding the <code>--update</code> option to <code>extlinux ...</code> suffice to make {{Path|/boot/extlinux.conf}} be regenerated? Or do we need to manually tweak that file, or run <code>update-extlinux</code>, as well?}}

You might also need to manually tweak {{Path|$MNT/etc/fstab}}.

=== LVM ===
<code>setup-disk</code> will automatically build and use volumes in a LVM group if you supply the '''-L''' switch.

If you instead want to build your LVM system manually, see [[Setting up Logical Volumes with LVM]]. Then <code>vgchange -ay</code>, format and mount your volumes, and supply the root mountpoint to [[setup-disk]]. When you're finished, be sure to
{{Cmd|umount ...
vgchange -an}}
before rebooting.

If <code>setup-disk</code> sees that you're using LVM---perhaps because you gave it the <code>-L</code> switch---then it will setup your initram and extlinux.conf file properly. However, in other cases, these might not be properly setup. In that case, you may need to manually edit/rebuild them. The following assumes that <code>$MNT</code> holds the root directory you're installing into:

{{Cmd|1=# edit $MNT/etc/mkinitfs/mkinitfs.conf to make sure features="..."
# includes lvm (this field is space-separated and quoted)
mkinitfs -c $MNT/etc/mkinitfs/mkinitfs.conf -b $MNT
# edit $MNT/etc/update-extlinux.conf to make sure root= is set correctly
extlinux --install $MNT/boot --update
}}

{{Todo|Does adding the <code>--update</code> option to <code>extlinux ...</code> suffice to make {{Path|/boot/extlinux.conf}} be regenerated? Or do we need to manually tweak that file, or run <code>update-extlinux</code>, as well?}}

You might also need to manually tweak {{Path|$MNT/etc/fstab}}.

=== Custom partitioning ===
<code>setup-disk</code> will by default set up a root parition, a separate /boot partition and a swap. If you want a different layout you can manually create the parititions, filesystems and mount them up on {{Path|/mnt}} (or any other mount point) and then run:

{{Cmd|setup-disk /mnt}}

<code>setup-disk</code> will install your running system on the mounted root, detect your file system layout and generate a fstab. You are responsible for making the proper partition bootable and make sure the MBR is ok for extlinux.

=== Dual-booting ===
See [[Installing Alpine on HDD dualbooting|Install to HDD with dual-boot]]

=== Other needs ===
* [[Installing Alpine Linux in a chroot]]
* [[Replacing non-Alpine Linux with Alpine remotely]]





== Setting up swap ==

# create partition with type "linux swap" (82) (If you're going to use an LVM logical volume for swap, skip this step and <code>lvcreate</code> that instead.)
# <code>mkswap /dev/sda2</code>
# <code>echo -e "/dev/sda2 none swap sw 0 0" >> /mnt/etc/fstab</code>
# <code>swapon /dev/sda2</code> (or <code>rc-service swap start</code>)

Then {{Cmd|free -m}} will show how much swap space is available (in MB).

If you prefer maximum speed, you don't need configure any raid devices for swap. Just add 2 swap partitions on different disks and linux will stripe them automatically. The downside is that at the moment one disk fails, the system will go down. For better reliability, put swap on RAID1.

{{Todo|Instructions for cryptswap?}}

[[Category:Installation]]
[[Category:Storage]]

Xen PCI Passthrough

2015-01-20T02:15:43Z

Tze:

This guide is to show how to configure PCI Passthrough on Alpine.

First use lspci to find out what PCI-Address the Device that you want to Passthrough has:
<pre>
node03:~# lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 Processor Family DRAM Controller (rev 09)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation C204 Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
03:03.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 (rev 0a)
</pre>

In my case i want to passthrough the SAS Controller so the Address is 01:00.0
Currently there is a bug [http://bugs.alpinelinux.org/issues/3609 #3609]in Alpine due to which we can't use the Default way to use Kernelparameters for it.

Edit /etc/modules and reboot the server:
<pre>
node03:~# grep pciback /etc/modules
xen_pciback hide=(01:00.0)
</pre>

After a reboot you should be able to see that the pci-device is using the pciback Kernelmodule and should be visible to passthrough via xl:
<pre>
node03:~# lspci -k | grep -A2 '01:00.0'
01:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)
Subsystem: LSI Logic / Symbios Logic Device 3020
Kernel driver in use: pciback
node03:~# xl pci-assignable-list
0000:01:00.0
</pre>

Now just add a line to your DomU's Config and everything should be fine.
<pre>
pci = [ '01:00.0' ]
</pre>

====Known Issue with LSI Controllers====
As the Kernelmodule for LSI Controllers is built into the Alpine Initramfs, the real Module is loaded before the pciback Module can be assigned.
Just blacklist the mpt2sas module in /etc/modprobe.d/blacklist.conf and rebuilt your initramfs.
<pre>
node03:~# grep sas /etc/modprobe.d/blacklist.conf
blacklist mpt2sas
node03:~# mkinitfs
==> initramfs: creating /boot/initramfs-grsec
11538 blocks
33641 blocks
</pre>

Talk:Tutorials and Howtos

2014-12-31T17:26:27Z

Tze: /* New Page for Xen pci passthrough */ new section

===Documentation requests:===
=====SSL + CA=====
Documentation on how to replace the ACF Web SSL keys with ones from the ACF CA interface.

=====Runlevel definitions=====
stuff which is not easy to find out:
boot vs. sysinit, why is fsck not enabled per default on a disk based install?

20:57, 1 January 2012 (UTC)

===Sorting / Categories: ===
I wonder if we shoudl tag articles (categories) and have an category index here
----
:I guess this will be needed sooner or later so my short answer is '''YES'''. - Any suggestions for categories? BTW please add <nowiki>~~~~</nowiki> or <nowiki>--~~~~</nowiki> at the end of your talk text to add your signature and time mark. Thanks --[[User:K0gen|K0gen]] 14:32, 18 May 2010 (UTC)

----
Suggested Categories:
* ACF
* HOWTO
* development
* network
* install
* vserver
* voip
* email
* virtualizaion
* xfce
* xorg
there are probably more
--[[User:Ncopa|Ncopa]] 04:33, 21 May 2010 (UTC)
----
How about adding a network monitoring category to the list? [[User:Jbilyk|Jbilyk]] 22:23, 8 October 2010 (UTC)
----
:Sure. Maybe just ''monitoring''? Then we can include disk monitoring etc. --[[User:Ncopa|Ncopa]] 01:31, 12 October 2010 (UTC)

== a template for obsolete? ==

Would it be an idea to have a template for obsolete docs?
<nowiki>{{Obsolete}}</nowiki>

We could also include a category ''obsolete''there so we can quickly find all outdated docs.
--[[User:Ncopa|Ncopa]] 09:18, 24 May 2010 (UTC)
----
:Check out my candidates for [[User:K0gen/Templates#Long_Info_Box|Under construction and Obsolete templates]]. If You like it, tweak them, fix them, use them :) --[[User:K0gen|K0gen]] 04:34, 27 May 2010 (UTC)

== a template for Alpine-version tested doc ==
Many docs/howtos are related to some specific version(s) of Alpine and might or might not apply for some specific version of Alpine.
I think it would be a good idea to have some template (and maybe a tag) that shows which (latest) Alpine release this doc has proven to work. With such information in a doc/howto it's quite easy to either test/update it for a newer release of of Alpine or mark the doc obsolete.
-- [[User:Mhavela|Mhavela]] 16:26, 29 May 2010 (UTC)
:This is interesting idea. We should also think about dealing with changes in futures Alpine Linux versions and how to address documentation and changes that appear for them. I've started working on something but I need Ideas, hints or examples. Should it be on the top or bottom? Right or left, big or small? You know what I mean... --[[User:K0gen|K0gen]] 03:14, 2 June 2010 (UTC)

== category HOWTO? ==

Do we really want a category HOWTO? I think its too general to be useful.
--[[User:Ncopa|Ncopa]] 07:47, 1 June 2010 (UTC)
:I say we skip the howto category for now. If we grow in 1000 howto's than maybe we can bring it back, but for now this category is pointless.--[[User:K0gen|K0gen]] 03:14, 2 June 2010 (UTC)

== New Page for Xen pci passthrough ==

Hey Guys,

I wanted to add a Page for Xen pci passthrough, as it is not working on Alpine as documented on the XEN Wiki, due to bug #3609.
Can somebody create a new empty page? I was either blind, too stupid or i'm not allowed to.

Thanks!

Bridge

2014-11-12T06:34:13Z

Tze:

[[Category:Networking]]
This document describes how to configure a [http://en.wikipedia.org/wiki/Bridging_%28networking%29 network bridge] interface in Alpine Linux.

== Using brctl ==
Bridges are manually managed with the '''brctl''' command.
<pre>
Usage: brctl COMMAND [BRIDGE [INTERFACE]]

Manage ethernet bridges

Commands:
show Show a list of bridges
addbr BRIDGE Create BRIDGE
delbr BRIDGE Delete BRIDGE
addif BRIDGE IFACE Add IFACE to BRIDGE
delif BRIDGE IFACE Delete IFACE from BRIDGE
setageing BRIDGE TIME Set ageing time
setfd BRIDGE TIME Set bridge forward delay
sethello BRIDGE TIME Set hello time
setmaxage BRIDGE TIME Set max message age
setpathcost BRIDGE COST Set path cost
setportprio BRIDGE PRIO Set port priority
setbridgeprio BRIDGE PRIO Set bridge priority
stp BRIDGE [1|0] STP on/off
</pre>

To manually create a bridge interface br0:
{{Cmd|brctl addbr br0}}

To add interface eth0 and eth1 to the bridge br0:
{{Cmd|brctl addif br0 eth0
brctl addif br0 eth1}}

Note that you need to set the link status to ''up'' on the added interfaces.
{{Cmd|ip link set dev eth0 up
ip link set dev eth1 up}}

[[Category:Networking]]

== Configuration file ==
{{Note|Alpine Linux v2.4 or newer is required for this}}
Install the scripts that configures the bridge.
{{Cmd|apk add bridge}}

Bridging is then configured in ''/etc/network/interfaces'' with the ''bridge-ports'' keyword.
Note that you normally don't assign ip addresses to the bridged interfaces (eth0 and eth1 in our example) but to the bridge itself (br0).

In this example the address 192.168.0.1/24 is used.

<pre>
auto br0
iface br0 inet static
bridge-ports eth0 eth1
bridge-stp 0
address 192.168.0.1
netmask 255.255.255.0
</pre>

You can set the various options with those keywords:
; bridge-aging
: Set ageing time
; bridge-fd
: Set bridge forward delay
; bridge-hello
: Set hello time
; bridge-maxage
: Set bridge max message age
; bridge-pathcost
: Set path cost
; bridge-portprio
: Set port priority
; bridge-bridgeprio
: Set bridge priority
; bridge-stp
: STP on/off

== Using pre-up/post-down ==
For older versions of Alpine Linux, or if you want be able to control the bridge interfaces individually, you need to use pre-up/post-down hooks.

Example ''/etc/network/interfaces'':

<pre>
auto br0
iface br0 inet static
pre-up brctl addbr br0
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
post-down brctl delbr br0

auto eth0
iface eth0 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down

auto eth1
iface eth1 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down
</pre>

That way you create br0 with: ifup br0, and you can add/remove
individual interfaces to the bridge with ifup eth0, ifdown eth0.

== Bridging for a Xen dom0 ==
Bridging in a dom0 is a bit specific as it consists in bridging a real interface (i.e. ethX) with a virtual interface (i.e. vifX.Y).
At bridge creation time, the virtual interface does not exist and will be added by the Xen toolstack when a domU is booting (see Xen documentation on how to link the virtual interface to the correct bridge).

;Particularities :
- the bridge consists of a single physical interface 
- the physical interface does not have an IP and is configured as manual 
- the bridge will have the IP and will be auto, resulting in bringing up the physical interface 

This translates to this sample config :

Example ''/etc/network/interfaces'':

<pre>
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
bridge_ports eth0
bridge_stp 0
</pre>

After the domU OS is started, the virtual interface wil be added and the working bridge can be checked with
<pre>
brctl show

ifconfig -a
</pre>

Create Alpine Linux PV DomU

2014-08-27T13:49:38Z

Tze: Changed the Kernel and initrd Names, furthermore changed the path to the grub config to /boot/grub/menu.lst, as it is the default location for pv-grub, so the domU Config doesn't need the "extra =" line

== Obtain a copy of Alpine Linux ==

To create an Alpine Linux PV DomU you will need an Alpine Linux iso.

Download the latest and greatest iso

{{download|alpine}}

== Extract the xen-aware linux kernel ==

Next, mount the iso and extract the kernel and initramfs:

<pre>
# mkdir -p /mnt/alpine_iso
# mount -t iso9660 -o loop /path/to/the/iso /mnt/alpine_iso
# cp /mnt/alpine_iso/boot/grsec /path/to/save/kernel/
# cp /mnt/alpine_iso/boot/grsec.gz /path/to/save/kernel/
# umount /mnt/alpine_iso
# rmdir /mnt/alpine_iso
</pre>

Now we have the kernel in /path/to/save/kernel/grsec and initramfs in /path/to/save/kernel/grsec.gz.

== Create the disk image ==
Now we should create an empty file, that will be the hard drive of the DomU (in this example we are using a 3GB disk):

<pre>
# dd if=/dev/zero of=/path/to/disk.img bs=1M count=3000
</pre>

== Create a DomU config file that boots the ISO image ==
The next step is to create a basic DomU configuration file, so we can launch the pv guest iso (save it where you like, although the most common place is /etc/xen/).

<pre>
# Alpine Linux PV DomU

# Kernel paths for install
kernel = "/path/to/save/kernel/grsec"
ramdisk = "/path/to/save/kernel/grsec.gz"
extra="alpine_dev=xvdc:iso9660 modules=loop,squashfs,sd-mod,usb-storage modloop=/boot/grsec.modloop.squashfs console=hvc0"

# Path to HDD and iso file
disk = [
'format=raw, vdev=xvda, access=w, target=/path/to/disk.img',
'format=raw, vdev=xvdc, access=r, devtype=cdrom, target=/path/to/the/iso'
]

# Network configuration
vif = ['bridge=br0']

# DomU settings
memory = 512
name = "alpine"
vcpus = 1
maxvcpus = 1
</pre>

== Install the guest ==
Now that we have all the necessary files, we can start the DomU to proceed with the install:

<pre>
# xl create -f /path/to/conf -c
</pre>

Login into the system with user "root" and no password, and proceed with the normal install:

<pre>
# setup-alpine
</pre>

After configuring the basic system, you will be asked where would you like to install Alpine, choose xvda and sys.

This will create three partitions on your disk, xvda1 for /boot, xvda2 for swap and xvda3 for /

<pre>
Available disks are:
xvda (3.1 GB )
Which disk(s) would you like to use? (or '?' for help or 'none') [none] xvda
The following disk is selected:
xvda (3.1 GB )
How would you like to use it? ('sys', 'data' or '?' for help) [?] sys
WARNING: The following disk(s) will be erased:
xvda (3.1 GB )
WARNING: Erase the above disk(s) and continue? [y/N]: y
Initializing partitions on /dev/xvda...
Creating file systems...
Installing system on /dev/xvda3:

Installation is complete. Please reboot.

# halt

</pre>

== Adjust the domU config file to boot from fresh install ==

In your Dom0, edit your DomU config file to boot from the fresh install

<pre>
# Alpine Linux PV DomU

# Kernel paths for install
kernel = "/path/to/save/kernel/grsec"
ramdisk = "/path/to/save/kernel/grsec.gz"
extra="modules=sd-mod,usb-storage,ext4,squashfs console=hvc0 root=/dev/xvda3"

# Path to HDD and iso file
disk = [
'format=raw, vdev=xvda, access=w, target=/path/to/disk.img'
]

# Network configuration
vif = ['bridge=br0']

# DomU settings
memory = 512
name = "alpine"
vcpus = 1
maxvcpus = 1
</pre>

==Adding a grub config file to boot with pvgrub==

Now boot the VM once more to add a grub config file so that we may load the xen-aware kernel from within the VM.

This means that upgrading the kernel will not mean copying it to the dom0.

<pre>
# xl create -f /path/to/conf -c
</pre>

Log in as root and create the file /boot/grub/menu.lst with the following content

<pre>

#/boot/grub/menu.lst

default 0
timeout 5

title alpine-xen-pv
root (hd0,0)
kernel /boot/vmlinuz-grsec modules=sd-mod,usb-storage,ext4,squashfs console=hvc0 root=/dev/xvda3
initrd /boot/initramfs-grsec

</pre>

Halt your VM one last time

<pre>
# halt
</pre>

==Adjust the DomU config file one last time to use pvgrub==

Your final xen DomU config file should look something like this.

<pre>
# Alpine Linux PV DomU
disk = [
'format=raw, vdev=xvda, access=w, target=/path/to/alpine.img'
]

kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"

vif = [ 'bridge=br0' ]
memory = 1024
name = "alpine"
vcpus = 1
maxvcpus = 1

</pre>

When you next boot, you will be presented with the grub boot menu, and your VM will boot.

[[Category:Virtualization]]