By elliot on 28 February 2008 under anaconda, foresight
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:
- download
- gunzip foresight-1.9.9.alpha4-x86.img.gz
- 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.
By elliot on 01 December 2007 under anaconda, rPath
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.
By elliot on 24 October 2007 under Uncategorized, anaconda
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
By elliot on 18 October 2007 under Uncategorized
Today we released rPL 2 Alpha 4. This has been a long time coming. It involved a few rebuilds of the distro from scratch and switching away from our old internal build mechanism to rMake. Hopefully now that we have alpha 4 out the door beta 1 will be coming down the pipe soon.
One of the major changes in Alpha 4 is the addition of splashy for graphical boot. With splashy you get a splash screen and progress bar at boot and shutdown instead of the normal initscripts output. (Don’t worry for those of you who like to watch initscripts run, you can disable splashy by removing the “splash” and “vga=” kernel options from your grub.conf.) We are still working out some of the kinks, but don’t let this stop you from testing out splashy and remeber to file an issues that you happen to run across in rITS.
Another major addition in the alpha 4 release is the support in anaconda for the “Appliance Installer”. The Appliance Installer is significantly faster and has a smaller memory footprint than the “Installable ISO” that we normally use. How do we do that? We first let rBuilder generate a tarball of the group, split the tarball into chunks, and then add the chunks to the ISO. On the install side of things we feed the tarball chunks to tar over a pipe until the tarball is complete and then let anaconda write out some of the hardware specific configuration. This makes the Appliance Installer faster than *any* anaconda base that I have ever seen. Unfortunately there is no way for rBO projects to consume the Appliance Installer at this time, however there are some rBuilder features in the works to make it easier.
