Elliot's Blog » anaconda http://blog.bentlogic.net The musings of a software engineer Sat, 18 Jul 2009 20:53:34 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 Foresight Installable Disk Image http://blog.bentlogic.net/2008/02/28/foresight-installable-disk-image/ http://blog.bentlogic.net/2008/02/28/foresight-installable-disk-image/#comments Thu, 28 Feb 2008 23:50:33 +0000 elliot http://blog.bentlogic.net/2008/02/28/foresight-installable-disk-image/ I spent a couple of days last week figuring out what it would take a make an installable USB key of Foresight Linux 2. I knew going in that Anaconda could handle installing from hard drive, but I wanted to make sure that the installer had the same sort of automated feel that it has when installing from CD (ie, no user interaction in the loader).

Through testing I found that hard drive install from USB mass storage needed a bit of work to get it like I wanted.

I noticed that when the loader asks for the device to install from it doesn’t always list the device that you want to install from. This is due to the fact that it takes a few seconds for usb devices to come up once the usb mass storage module is loaded. I have added a patch to the loader that waits for the USB bus to settle and automatically probes for a device to install from, which can be enabled by passing “method=hd:auto” on the kernel command line.

After fixing that I found that the source device was showing up during partitioning and bootloader configuration. Normally when installing from HD you might want to install from one partition on a device to another partition on the same device. However, this is not the case when installing from a USB key. So I added another option, “hidesrcdev”, that tells Anaconda to ignore the device that you are installing from.

Here is the first sample that I have put together if people would like to try it out:

http://people.rpath.com/~elliot/foresight-1.9.9.alpha4-x86.img.gz

To use this image you will need at least a 2GB USB mass storage device. Here are a few easy steps to get you started:

  1. download
  2. gunzip foresight-1.9.9.alpha4-x86.img.gz
  3. dd if=foresight-1.9.9.alpha4-x86.img of=/dev/sdb (substitute your usb device for sdb) Be warned that this will overwrite any data that is on the USB device.

If you have any questions or comments feel free to ask.

]]> http://blog.bentlogic.net/2008/02/28/foresight-installable-disk-image/feed/ 0 managing sources with hg convert http://blog.bentlogic.net/2007/12/01/managing-sources-with-hg-convert/ http://blog.bentlogic.net/2007/12/01/managing-sources-with-hg-convert/#comments Sat, 01 Dec 2007 22:17:21 +0000 elliot http://blog.bentlogic.net/2007/12/01/managing-sources-with-hg-convert/ One of the things I do at rPath is hack on Anaconda. We have decided to mostly standardize on Mercurial for our SCM. Since Anaconda, at the time, was managed in CVS, this meant that I needed to find a tool to convert a publically accessible CVS repository to a Mercurial repository. The only tool that I could find that was capable of doing this without having local access to the CVS repository was tailor. Tailor takes pretty much any SCM repository an converts it to darcs and then converts the darcs repository to another SCM repository format. Darcs is yet another SCM.

A couple of weeks ago the Fedora Project converted Anaconda from CVS to GIT. This meant that I needed to reconfigure tailor to handle the change. Through some help from the maintainer of tailor over IRC I was able to get tailor configured to deal with the switch. Over the next week or so I noticed that tailor had some issues handling branches in GIT and decided to find a new way to maintain my Anaconda Mercurial repository.

With a bit of searching I found the Mercurial convert extension. Which allowed me to switch away from tailor to something that would be at least somewhat supported by the Mercurial project. Getting the convert extension to pick up where tailor had left off took a bit of figuring out. The convert extension uses a map file that maps IDs for each GIT commit to a Mercurial commit ID. I had to manually create this file by extracting all of the commit IDs from the GIT repository and filling in null values for the the Mercurial ID side of the map. As the last entry I included the commit ID for the tip of the Mercurial repository that matched the point at which tailor had stopped being able to convert the GIT repository. With all of this in place hg convert could now handle converting the upstream Anaconda GIT repository to Mercurial. The Mercurial repository is now updated nightly (around 4am EST) from the upstream GIT repository.

You can find the converted upstream Anaconda Mercurial repository on rPath’s public Mercurial along side rPath’s custom Anaconda Mercurial repository, that includes support for both the Conary based installer and tar archive based installer.

]]> http://blog.bentlogic.net/2007/12/01/managing-sources-with-hg-convert/feed/ 0 Appliance Installer and IMAP on Gmail http://blog.bentlogic.net/2007/10/24/appliance-installer-and-imap-on-gmail/ http://blog.bentlogic.net/2007/10/24/appliance-installer-and-imap-on-gmail/#comments Wed, 24 Oct 2007 02:50:09 +0000 elliot http://blog.bentlogic.net/2007/10/24/appliance-installer-and-imap-on-gmail/ I did some testing with the Appliance Installer with Foresight Linux 2 today. Turns out that end to end time to install for a complete GNOME based Linux desktop is 7 minutes. That’s right 7 minutes. That includes user interaction and everything.

Looks like anaconda is shaping up for an alpha release of Foresight Linux 2. Ken is making good progress trying to get anaconda-templates built so that we should be able to get some sample ISOs out later this week or early next week.

Also, gmail has imap support….finally http://digg.com/software/Gmail_gets_IMAP

]]> http://blog.bentlogic.net/2007/10/24/appliance-installer-and-imap-on-gmail/feed/ 0