Tag Archives: livecd

Fedora, HubSpot

Announcing ami-creator

8 Comments

I’ve been having to build some new CentOS images to be used with EC2 for work recently. I went into it thinking that it shouldn’t be too big of a deal. I know that some work had been going on in this area and Fedora 14 is now available on EC2, so I figured I could convince the same toolchain to work.

Unfortunately, I was pretty disappointed with my options.

  • Do some building by hand on an actual instance, then do the bundling and upload off of the running instance.
  • Some of the ThinCrust stuff initially looked promising, but it seems like it’s largely unmaintained these days and the ec2 conversion bits didn’t really work at this point. I was able to get my initial images this way, but mostly by having a wrapper shell script of doom that made me sad.
  • There’s always the rPath tools, but I wanted to stick to something more native and fully open source
  • The new kid on the block is apparently BoxGrinder but I found it to be a lot over-complicated and not that robust. I’m sorry, but generating your own format that you then transform into a kickstart config and even run through appliance-creator via exec from your ruby tool just felt wrong. No offense, but just felt like a lot more than I wanted to deal with

So, I sat down and spent an evening hacking and have the beginnings of a working ami-creator.
It’s pretty straight-forward and uses all of the python-imgcreate stuff that’s used to build Fedora live images. Your input is a kickstart config and out the other side pops an image that you can bundle and upload to EC2.

Thus far, I’ve tested it to build CentOS 5 and Fedora 14 images. I’m sure there are some bugs but at this point, it’s worth getting it out for more people to play with. Hopefully it’s something that’s a lot simpler and more accessible for people to build images and I think it will also fit in a lot better with having Fedora release engineering building the EC2 images in Fedora 15 if they want.

One of the big outstanding pieces that I still want to add is the necessary bits to be able to (optionally) go ahead and upload and register as an AMI with your EC2 account.  But release early, release often.

Comments, etc appreciated in all the normal ways.

Minor update: switched the repo to live on github instead

Fedora

PPC relevance in Fedora?

15 Comments

Warning: Something of a rant ahead… I considered not posting it, but am curious as to the responses I’ll get 🙂

Okay, I know I’ve said this before, but I’m wondering why we continue with the illusion that PPC is a “primary” arch for Fedora rather than a secondary. At one point, the argument was that we were waiting until there was another viable secondary arch and then ppc would become one as well. The better part of four releases later (as I’m pretty sure I was having this discussion before Fedora 7’s release), we’re still in the same place. Maybe having ppc as a secondary arch would help to make that process smoother as those that care could help to improve the process.

As it stands, we instead say out of one side of our mouth that ppc is a primary arch but we have regularly dropped it from being included in a major development milestone, livecds were broken for 18 months (!), ps3 support is regularly broken in one way or another (and ps3 is one of the touted “most valuable” ppc platforms) and the majority of the bugs against ppc I see filed are either from jlaska or the IBM bugzilla proxy.

In any case, Fedora 11 will see restored the ability to create live images on ppc after someone reported it and Josh Boyer was kind enough to sit down and send me a patch on top of the obvious things based on the original report. Which was the original thing that got me thinking on this topic again.

But to go a step further — are you using Fedora on a ppc? If so, what kind of hardware and in what sort of use case? Inquiring minds, or at least I, want to know. Drop me a line in the comments.

Fedora

Progress Towards Fedora 11 Beta

1 Comment

This week (and last) saw me spending a bit more time on “Fedora-y” things than I have been over the past while in an effort to try to help shore various pieces up in preparation for the Fedora 11 beta. Although the beta is actually going to go out a little later than the initial plan, it’s been a good run and there have been some good things accomplished.

First on the list was testing out the livecd. As is often the case, there were a variety of things which had either entirely or partially broken. Also, there was a (good) suggestion to go ahead and install xguest with the live image so that people can take advantage of the good work that Dan has done there. Luckily, this was all pretty straight-forward things and involved a few fixes here and there.

They did, though, highlight the fact that we lose out on some pretty valuable testing by not making live images available more regularly. The problems always come down, though, to how would we distribute such images — the mirrors probably wouldn’t like 700 megs x 2 arches x n spins (at least desktop + KDE would make sense) churning on a daily basis I don’t think. Especially since live images aren’t rsync-able. Would people be okay with torrent only distribution of more frequent snapshots? And be okay with live snapshots that were just produced in an automated fashion without any testing at all before they go out? Comments appreciated 🙂

The bigger thing that took some time was helping to get the new anaconda storage code working with the live install. This is something which isn’t big and glitzy because right now, it’s all unglamarous backend code. But Dave Lehman hammered out a nice start to overhaul the storage code in anaconda to take into account more of the things which are “modern” storage/partitioning needs. This has then been supplemented by an avalanche of patches from the rest of the anaconda team to get things into shape. My patches were some small ones to deal with some of the more interesting quirks with how we do an install from the livecd. Luckily, as of this afternoon, it looks like we have something there that will work pretty nicely. A shout out to the anaconda dudes for the hard work they’ve been putting into getting it into shape and pulling out what was one of the last pieces of anaconda that’s more than five years old. In Fedora 12, hopefully we can move on to the next step which is overhauling the user experience for partitioning in a major way.

Fedora

Multiple live images on a USB stick

It keeps coming up that people would like to support multiple live images running off the same USB stick/hard drive/$arbitrary medium and so it’s probably worth considering some of the ways that it could possibly be supported.  Also, for the personal reason, it would make it easier for me to effectively use my netbook with the super-slow SSD if I just put a new rawhide live image on it regularly and keep my homedir on the (faster) SD card 🙂

Breaking it down into components, I think there are a few things which we have to worry about

  1. Where to put things on the disk. 

    The more I think about it, the more I think that having “everything” for one image (including the bootloader bits) will be easiest.  The suggestion of using the iso label for namespacing seems to make reasonable sense.

  2. Boot loader config

    There are a couple of possibilities here… the simplest would just be that we edit the syslinux.cfg and append more entries.  A little bit more complicated would be to just have a simple “top-level” syslinux.cfg which uses CONFIG directives to load the additional config files.  Third would be a com32 module to iterate and set up the menu items automatically.  I lean towards the second, at least for at first unless someone is super-motivated to write a com32 module

  3. How to know the new directory

    There are multiple places scattered that have hard-coded looking for LiveOS.  There’s the initrd, there’s the livesys initscript and there’s livecd-iso-to-disk/liveusb-creator.  While we could add a kernel command line option and go and change each of these to set it/respect it, it feels like maybe the less general solution.  Maybe it’s just that we should always have livelabel= available so that we can use it other places? 

Of these, I’m especially not sold with the last question and would love to see some thoughts or ideas from others. From there, it should be pretty straight-forward to implement so that we can have everything in place for Fedora 11 Beta

On a related note — I wonder if there’s value in moving the livesys initscript from being based in the live image kickstart config to being provided by a package (most obviously, initscripts)