Making it easier to test anaconda changes

Those of us that work on anaconda have long been in a bit of a difficult place when it comes to actually testing our changes. Things are dependent on a tree being available with a new anaconda that had buildinstall run… and these tend to take long enough (hours) that the run occurs once a day. If it works, great. If not, oh well. Which is pretty sucky when you have a typo that gets in the way of all of your testing. Sure, we had updates.img for some things, but it still ends up being dependent on the tree existing to begin with.

But now, that's changed. I've just sent off a set of patches which ultimately add a make testiso target to the anaconda makefile. Given an existing yum repo and this target, you can now get a testable, bootable ISO image to kick off a network install in a pretty short time period. To do this, I've cleaned up a lot of old cruft in our image building scripts and also now take advantage of the fact that we're using yum repos and thus have commands like repoquery and yumdownloader rather than depending on shell globbing and find commands to get packages. I've also made the necessary changes so that boot.iso goes away. While boot.iso had its day, these days, downloading 100 megs to start a network installation isn't that big of a deal. Especially when it means that you already have the second stage available and thus don't have to download it during the install. So for Fedora 9, we'll instead have a netinst.iso (note: better names still accepted) that you can download for starting your network installation.

13 thoughts on “Making it easier to test anaconda changes”

  1. This will make my life much better.
    Unfortunately, I’m still dealing with AS 2.1 anaconda, so in 2014 your new changes should start to make my life easier.

    No, really, I actually appreciate anyone who takes the time to make something easier to test.

  2. For network installations I generally use the rescue image, which has the second stage as well. Is there any extra value in a separate netinst iso?

  3. The main value is that we’re raising the visibility of the image and making it more clear that it can be used for installation rather than just being a “rescue” image.

  4. By the way, if I can make a suggestion, how about making anaconda pull a list of mirrors and let the user choose one? Rather than forcing him to write down the mirror host/directory to a paper, and then typing it in.

  5. That’s one of the things we’re working towards — but doing so is requiring blowing up a *lot* of in-grained assumptions from the past and so it’s taking a bit longer than we had hoped. Still _might_ make Fedora 9, but if not, it’ll definitely make it for Fedora 10.

  6. They can, however, add value to your GPS purchase by making it more useful on a daily basis. If you are drawn to a traffic service, look at all the costs associated before choosing a device.

  7. One of the things I brought up, but did not expand upon, was American Exceptionalism as the logical descendent of racial bigotry as a dark stain upon the soul of America.

  8. As for the developers who enable these services, there are definitely ways they can help raise the visibility of the practice – through e-mail alerts, trackbacks, or even giving the option to opt out.

  9. 9 times out of these people have not even attempted it, but believed the over-marketing non-sense of software RAID bigots who say hardware RAID is slower — typically based on their prior use of i hardware RAID solutions that were not viable 10 years ago, much less 5 years ago when StrongARM and ASICs started showing up.

  10. He heard life was better and much safer in California, so he soon found himself in the company of several other Mexican men also on their way north.

Comments are closed.