Installing Fedora 16 in XenServer

Getting Fedora 16 working in XenServer isn’t the easiest thing to do, but I’ve put together a repository on GitHub that should help. The repository contains a kickstart file along with some brief instructions to help with the installation. If you’re ready to get started right now, just clone the repository:

git clone git://github.com/rackerhacker/kickstarts.git kickstarts

There are some big issues with Fedora 16 which cause problems for installations within XenServer:

  • the installer sets up a console on something other than hvc0
  • anaconda won’t start without being in serial mode
  • anaconda tries to use GPT partitions by default
  • grub2 is now standard, but it causes problems for older XenServer versions

My kickstart works around the grub2 problem by throwing down an old-style grub configuration file and creating the proper symlinks. This config will still be updated when you upgrade kernels (at least in Fedora 16). It also sets up a very simple partitioning schema with one root and one swap partition. A DOS partition table is used in lieu of a GPT partition table.

When you start the installation, be sure to review the README.md in the git repository. It has some special instructions for boot options to meet the requirements of Fedora 16 and the kickstart file.

Tagged , , , ,

11 thoughts on “Installing Fedora 16 in XenServer

  1. Felix says:

    Hmm… the installation was quite automatic (which makes me a little nervous); but the bigger problem is – what is root password?!

  2. Major Hayden says:

    Felix –

    Kickstarts are supposed to be highly automated. That’s why they’re so commonly used in large server environments. The root password is ‘qwerty’ as you can see on line 20 here:

    https://github.com/rackerhacker/kickstarts/blob/master/Fedora%2016%20Minimal%20on%20XenServer%206/fedora16-minimal-xenserver6.ks#L20

  3. Felix says:

    Thanks, Major.
    The problem that I was trying to solve wasn’t automated install / kickstart per se. It was the fact that standard builds don’t get installed at all (as you mentioned). I am now thinking that I can use your build that matches what XenServer expects under RHEL, and not specify kickstart file.

    Or learn how kickstart works, and modify your response file to fit my needs. But I would still rather set up partitions interactively.

  4. Major Hayden says:

    Felix — In that case, just don’t use the “ks=…” in the boot options. You’ll be able to walk through stuff interactively. You may want to use the “vnc” boot option so you can connect to anaconda via VNC and do the partitioning as you see fit. Anaconda assumes a lot when you use the plain text mode.

  5. ritesh says:

    the root pasword is nt the problem .kickstart is only the function which installs the O.S root password is same as RHEL .username :root password: root123

  6. ritesh says:

    kickstart is a function as ghost installer ghost used to install windows and kickstart is used to install O.S. types like RHEL ,Fedora etc. it installs O.S. automatically

  7. Felix says:

    Hi ritesh,
    Thank you very much for sharing your knowledge about kickstart with the world. I am sure you also have good reasons to think that you know the root password (root123) better than the person who actually set it (qwerty). Unfortunately, you didn’t explain those reasons, and none comes to mind.

    Anyway, good luck in your further advice-giving pursuits!

  8. Muchtall says:

    Thanks for this information. It’s always nice when someone cuts a path for the rest of us, making the journey a bit easier.

    In case anyone else is like me, and prefers having as much control as possible over the installation using the Anaconda GUI, here’s the minimal kickstart config I used:

    #### START KS CONFIG ####
    # Install, not upgrade
    install

    # Setup the disk
    zerombr
    clearpart –all –drives=xvda
    part / –fstype=ext4 –grow –size=1024 –asprimary
    part swap –size=512
    bootloader –location=none –timeout=5 –driveorder=xvda

    # Add in an old-style grub.conf to make XenServer’s pygrub happy
    %post
    KERNELSTRING=`rpm -q kernel –queryformat=’%{VERSION}-%{RELEASE}.%{ARCH}’ | tail -n 1`

    cat > /boot/grub/grub.conf <<EOF
    default=0
    timeout=5
    title Fedora (${KERNELSTRING})
    root (hd0,0)
    kernel /boot/vmlinuz-${KERNELSTRING} ro root=/dev/xvda1 console=hvc0 quiet
    initrd /boot/initramfs-${KERNELSTRING}.img
    EOF

    ln -s /boot/grub/grub.conf /boot/grub/menu.lst
    ln -s /boot/grub/grub.conf /etc/grub.conf

    %end
    #### END KS CONFIG ####

    And use this in your advanced options: console=hvc0 serial ip=dhcp nogpt vnc ks=

  9. Philip Rhoades says:

    Major, Thanks for this info – it has helped me make a little progress with creating an iso that I can use to install an instance in this provider’s environment: http://ninefold.com – it seems that now, at least, I have an installed setup that is trying to boot but I get a Citrix XenServer screen telling me the nature of the VM and prompting to push F12 to get a boot menu. However, in both Chrome and Firefox, I can’t use F12 (Chrome brings up a developer screen and FF does nothing). Since there was a 5s timeout in the grub conf, I thought the VM should have completed booting?

    Any ideas/suggestions?

    Thanks,
    Phil.

  10. Philip Rhoades says:

    PS I should have said – I made some slight changes to your ks file to use Fedora 18.

  11. Philip Rhoades says:

    checking in the “new posts” option this time . .

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>