Expat-IT Tech Bits

Home

Contact

Links

Search this site:

Categories:

/ (287)
  Admin/ (122)
    Apache/ (10)
      HTTPS-SSL/ (4)
      PHP/ (3)
      performance/ (2)
    Cherokee/ (1)
    LAN/ (4)
    LVM/ (6)
    Monitoring/ (2)
      munin/ (2)
    SSH/ (6)
    SSL/ (1)
    Samba/ (1)
    VPN-options/ (6)
      OpenVPN/ (1)
      SSH-Proxy/ (3)
      Tinc/ (1)
      sshuttle/ (1)
    backups/ (17)
      SpiderOak/ (1)
      backuppc/ (5)
      dirvish/ (1)
      misc/ (6)
      rdiff-backup/ (1)
      rsync/ (1)
      unison/ (2)
    commandLine/ (24)
      files/ (8)
      misc/ (10)
      network/ (6)
    crontab/ (1)
    databases/ (15)
      MSSQL/ (2)
      MySQL/ (8)
      Oracle/ (3)
      PostgreSQL/ (1)
    dynamicDNS/ (2)
    email/ (11)
      Dovecot/ (1)
      deliverability/ (1)
      misc/ (1)
      postfix/ (7)
      puppet/ (1)
    iptables/ (3)
    tripwire/ (1)
    virtualization/ (9)
      VMware/ (1)
      virtualBox/ (8)
  Coding/ (14)
    bash/ (1)
    gdb/ (1)
    git/ (3)
    php/ (5)
    python/ (4)
      Django/ (2)
  Education/ (1)
  Hosting/ (27)
    Amazon/ (18)
      EBS/ (3)
      EC2/ (10)
      S3/ (1)
      commandline/ (4)
    Godaddy/ (2)
    NearlyFreeSpeech/ (3)
    Rackspace/ (1)
    vpslink/ (3)
  Linux/ (30)
    Android/ (1)
    Awesome/ (3)
    CPUfreq/ (1)
    China/ (2)
    Debian/ (8)
      APT/ (3)
      WPA/ (1)
    audio/ (1)
    encryption/ (3)
    fonts/ (1)
    misc/ (6)
    remoteDesktop/ (1)
    router-bridge/ (3)
  SW/ (45)
    Micro$soft/ (1)
    browser/ (2)
      Chrome/ (1)
      Firefox/ (1)
    business/ (28)
      Drupal/ (9)
      KnowledgeTree/ (6)
      Redmine/ (2)
      SugarCRM/ (7)
      WebERP/ (2)
      WordPress/ (1)
      eGroupware/ (1)
    chat/ (1)
    email/ (1)
    fileSharing/ (2)
      btsync/ (1)
      mldonkey/ (1)
    graphics/ (2)
    research/ (2)
    website/ (6)
      blog/ (6)
        blosxom/ (3)
        rss2email/ (1)
        webgen/ (1)
  Security/ (15)
    IMchat/ (2)
    circumvention/ (2)
    cryptoCurrency/ (1)
    e-mail/ (4)
    greatFirewall/ (1)
    hacking/ (1)
    password/ (1)
    privacy/ (2)
    skype/ (1)
  Services/ (1)
    fileSharing/ (1)
  TechWriting/ (1)
  xHW/ (14)
    Lenovo/ (1)
    Motorola_A1200/ (2)
    Thinkpad_600e/ (1)
    Thinkpad_a21m/ (3)
    Thinkpad_i1300/ (1)
    Thinkpad_x24/ (1)
    USB_audio/ (1)
    scanner/ (1)
    wirelessCards/ (2)
  xLife/ (17)
    China/ (9)
      Beijing/ (5)
        OpenSource/ (3)
    Expatriation/ (1)
    Vietnam/ (7)

Archives:

  • 2016/07
  • 2016/05
  • 2016/02
  • 2016/01
  • 2015/12
  • 2015/11
  • 2015/06
  • 2015/01
  • 2014/12
  • 2014/11
  • 2014/10
  • 2014/09
  • 2014/07
  • 2014/04
  • 2014/02
  • 2014/01
  • 2013/12
  • 2013/10
  • 2013/08
  • 2013/07
  • 2013/06
  • 2013/05
  • 2013/04
  • 2013/02
  • 2013/01
  • 2012/12
  • 2012/10
  • 2012/09
  • 2012/08
  • 2012/07
  • 2012/06
  • 2012/05
  • 2012/04
  • 2012/03
  • 2012/01
  • 2011/12
  • 2011/11
  • 2011/10
  • 2011/09
  • 2011/08
  • 2011/07
  • 2011/06
  • 2011/05
  • 2011/04
  • 2011/02
  • 2010/12
  • 2010/11
  • 2010/10
  • 2010/09
  • 2010/08
  • 2010/07
  • 2010/06
  • 2010/05
  • 2010/04
  • 2010/03
  • 2010/02
  • 2010/01
  • 2009/12
  • 2009/11
  • 2009/10
  • 2009/09
  • 2009/08
  • 2009/07
  • 2009/06
  • 2009/05
  • 2009/04
  • 2009/03
  • 2009/02
  • 2009/01
  • 2008/12
  • 2008/11
  • 2008/10
  • 2008/09
  • Subscribe XML RSS Feed

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
    PyBlosxom

    This site has no ads. To help with hosting, crypto donations are accepted:
    Bitcoin: 1JErV8ga9UY7wE8Bbf1KYsA5bkdh8n1Bxc
    Zcash: zcLYqtXYFEWHFtEfM6wg5eCV8frxWtZYkT8WyxvevzNC6SBgmqPS3tkg6nBarmzRzWYAurgs4ThkpkD5QgiSwxqoB7xrCxs

    Sun, 02 Oct 2011


    /Hosting/Rackspace: Use Your Own Kernel on Rackspace

    Rackspace recently announced[1] that they have made it possible for Rackspace cloud server users to manage their own kernel, rather than being stuck with the Rackspace-provided kernel. Ie. it is now possible to upgrade your Rackspace cloud server, just like on Amazon AWS!!

    The plan is apparently to phase in this new capability for new servers, but existing servers can be retrofitted as well. However this process did not turn out to be quite as straight-forward as I had hoped, or these documents[2][3] lead me to believe. I will try to recall the necessary steps to get from Lucid to Maverick.

    I had an Ubuntu Lucid machine. Before turning it into a Maverick machine, the first step is to MAKE A BACKUP OF YOUR SERVER. This process is highly error-prone, and the result of any small error is a server that will not boot. In fact, it is advisable to make a new server backup after each of the major steps below.

    Next step is to switch over to pv-grub and get that working:

    mkdir /boot/grub
    cp /etc/init/tty1.conf /etc/init/hvc0.conf
    sed -i 's/tty1/hvc0/' /etc/init/hvc0.conf
    sed -i 's/sda/xvda/' /etc/fstab
    apt-get install linux-virtual
    

    And create a /boot/grub/menu.lst that, for Lucid, looks something like this:

    default=0
    timeout=5
     
    title=DISTRO-NAME "Ubuntu 2.6.32-33-server"
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-33-server ro console=hvc0 root=/dev/xvda1
        initrd /boot/initrd.img-2.6.32-33-server
    

    Now open a ticket with Rackspace and ask them to switch your server over to pv-grub. Actually, it would probably be better to do this via chat, because they will reboot the server when they make the switch, and if something is wrong with your configuration the server will not come back. If and when it does, your still-Lucid server will be running with the Ubuntu repository-provided kernel, rather than the kernel provided by the Rackspace virtualization environment.

    The next step is the more-or-less standard Ubuntu upgrade from Lucid to Maverick. At the end, DO NOT REMOVE THE LUCID KERNEL, because after you reboot at the end of the upgrade you will find that your newly upgraded Maverick server is still running the Lucid kernel. Here is where it hit the fan for me. Up to this point, despite the less then perfect documentation, Rackspace support was very helpful. I got stuck here and they basically cut me loose, telling me they do not debug OS issues.

    ********* UPDATED SECTION **********************

    Do not linger at Maverick. Upgrade directly from Lucid, to Maverick, and then to Natty, WITHOUT REBOOTING. The Lucid kernel will work with the Natty userspace. If you do as I describe in the section marked "DON'T DO THE BELOW", yes you will get a functioning Maverick server, but your Rackspace snapshot backups will not work (will not boot) as the partition label disappears from the partition in the backup. Going directly to Natty is much cleaner, easier, and safer, as only the Maverick kernel is problematic and needs special handling. Once you have upgraded the userland to Natty, BACKUP YOUR SERVER. Then, again, modify /boot/grub/menu.lst:

    default=0
    timeout=5
     
    title=DISTRO-NAME "Ubuntu 2.6.38-11"
        root (hd0)
        kernel /boot/vmlinuz-2.6.38-11-virtual ro console=hvc0 root=/dev/xvda1
        initrd /boot/initrd.img-2.6.38-11-virtual
    

    to point to the Natty kernel, and reboot.

    (Note that I tried the Ubuntu grub-legacy-ec2 package to try to achieve automatic updates of /boot/grub/menu.lst, but the result was a non-booting server.)

    ********* DON'T DO THE BELOW *******************

    Next stop for me was to call on Canonical[4] for some help, and they were helpful as well. The obvious thing to do here is just edit /boot/grub/menu.lst to point to the Maverick kernel and initrd instead of Lucid's. This did not work, due to a quirk in the Maverick kernel. To get around it, label your root partition:

    e2label /dev/xvda1 MYROOT

    Now make the following change to /boot/grub/menu.lst:

    default=0
    timeout=5
     
    title=DISTRO-NAME "Ubuntu 2.6.35-30-virtual"
        root (hd0)
        kernel /boot/vmlinuz-2.6.35-30-virtual ro console=hvc0 root=LABEL=MYROOT
        initrd /boot/initrd.img-2.6.35-30-virtual
    

    Note the "root=LABEL=MYROOT" part. And to /etc/fstab:

    proc            /proc       proc    defaults    0 0
    LABEL=MYROOT  /     ext3  defaults,errors=remount-ro,noatime    0 1
    UUID=b9f62618-9dff-4bb4-9f58-3c2c5a95625d  none  swap  sw          0 0
    

    (you can get the UUID value for swap from /dev/disk/by-uuid/)

    And now when you reboot, it should all work: a Maverick server running the Maverick kernel.

    [1] http://www.rackspace.com/cloud/blog/2011/07/13/new-feature-manage-your-own-kernel-in-linux-cloud-servers/
    [2] http://www.rackspace.com/knowledge_center/linux_kernel_management
    [3] http://www.rackspace.com/knowledge_center/index.php/Using_a_Custom_Kernel_with_pv-grub
    [4] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/821466

    posted at: 09:38 | path: /Hosting/Rackspace | permanent link to this entry