I was going to post this on the bug, but I think the list is a better place for this discussion. And I think it probably relates to a couple of other bugs.
https://bugzilla.redhat.com/show_bug.cgi?id=624028
I am not sure that these problems are actually livecd-creator problems. I think they are related to:
1) The mix of packages being selected for your install, and the repositories providing them
2) The fact that install media is 'frozen', as is anaconda, after an extensive testing cycle and that packages involved have moved forward, but are now only tested against running systems, not recreating boot media.
Because of #2 using the updates and testing-updates repositories can result in building systems that won't boot.
I think that as a a baseline, things ought to work correctly if only the base repo is used in the creation. If other packages need to be added (and that is kinda the point, isn't it?) then making a local repo with just those hand-selected packages makes sense to me.
On Thu, Oct 28, 2010 at 17:39:35 -0700, "Brian C. Lane" bcl@redhat.com wrote:
- The fact that install media is 'frozen', as is anaconda, after an
extensive testing cycle and that packages involved have moved forward, but are now only tested against running systems, not recreating boot media.
Because of #2 using the updates and testing-updates repositories can result in building systems that won't boot.
I think that as a a baseline, things ought to work correctly if only the base repo is used in the creation. If other packages need to be added (and that is kinda the point, isn't it?) then making a local repo with just those hand-selected packages makes sense to me.
Given the manpower we have that may be the practical approach. I would suggest that the target is that being able to do a live image respin with the updates repository enabled should work. If the project decides that this must work, we could add retesting one or more live images to the critical path update tests. I don't think this is a good idea now, but maybe someday.
As far as I am aware livecd-creator will make a Live image out of any repository you give it, this includes updates repository.
Given the manpower we have that may be the practical approach. I would suggest that the target is that being able to do a live image respin with the updates repository enabled should work. If the project decides that this must work, we could add retesting one or more live images to the critical path update tests. I don't think this is a good idea now, but maybe someday.
On Mon, Nov 08, 2010 at 10:39:58 -0700, Jasper Hartline jasper.hartline@gmail.com wrote:
As far as I am aware livecd-creator will make a Live image out of any repository you give it, this includes updates repository.
But they don't always work, because sometimes updates break anaconda. This isn't well tested and the anaconda team historically has been forward looking and not spending a lot of resources on maintenance for released versions.
On Sat, Nov 06, 2010 at 12:07:25PM -0500, Bruno Wolff III wrote:
On Thu, Oct 28, 2010 at 17:39:35 -0700, "Brian C. Lane" bcl@redhat.com wrote:
- The fact that install media is 'frozen', as is anaconda, after an
extensive testing cycle and that packages involved have moved forward, but are now only tested against running systems, not recreating boot media.
Because of #2 using the updates and testing-updates repositories can result in building systems that won't boot.
I think that as a a baseline, things ought to work correctly if only the base repo is used in the creation. If other packages need to be added (and that is kinda the point, isn't it?) then making a local repo with just those hand-selected packages makes sense to me.
Given the manpower we have that may be the practical approach. I would suggest that the target is that being able to do a live image respin with the updates repository enabled should work. If the project decides that this must work, we could add retesting one or more live images to the critical path update tests. I don't think this is a good idea now, but maybe someday.
Well, the updates repo is the problem. In the recent cases the problem was that udev and NetworkManager had changed things post-release which broke anaconda. If things are going to work with updates then anaconda is going to need to be updated instead of frozen at release time.
On Mon, Nov 08, 2010 at 11:26:55 -0800, "Brian C. Lane" bcl@redhat.com wrote:
Well, the updates repo is the problem. In the recent cases the problem was that udev and NetworkManager had changed things post-release which broke anaconda. If things are going to work with updates then anaconda is going to need to be updated instead of frozen at release time.
Other options are having updates not break anaconda by being backwards compatible or not allowing updates that break anaconda.
On Mon, Nov 08, 2010 at 01:26:56PM -0600, Bruno Wolff III wrote:
On Mon, Nov 08, 2010 at 11:26:55 -0800, "Brian C. Lane" bcl@redhat.com wrote:
Well, the updates repo is the problem. In the recent cases the problem was that udev and NetworkManager had changed things post-release which broke anaconda. If things are going to work with updates then anaconda is going to need to be updated instead of frozen at release time.
Other options are having updates not break anaconda by being backwards compatible or not allowing updates that break anaconda.
That's not going to happen, everyone is focused on running systems after the release so they aren't going to pay any attention to things that break anaconda.. More likely is to convince the anaconda team to take selected updates after release and do a new build.
On Mon, Nov 08, 2010 at 11:41:20 -0800, "Brian C. Lane" bcl@redhat.com wrote:
That's not going to happen, everyone is focused on running systems after
Most likely.
the release so they aren't going to pay any attention to things that break anaconda.. More likely is to convince the anaconda team to take selected updates after release and do a new build.
If as a project we thought it was important enough we could make this happen as part of critpath QA. If a critpath update breaks, say the desktop spin from being built with updates and working, we could reject the update. I don't see that being the case (that respins are high priority) today, but it is an option that could be made to work with some effort.
If as a project we thought it was important enough we could make this happen as part of critpath QA. If a critpath update breaks, say the desktop spin from being built with updates and working, we could reject the update.
That seems to me to be an entirely appropriate requirement. Without this, there is no simple way of building a live CD that has the latest security fixes.
Currently, Fedora makes a live CD available for download, as well as install media. It's not a disaster for the install media users if a critical security bug is found in (say) Firefox, because one is expected to install and then update. But once an update has broken anaconda, you can't build a new live CD that's safe to use. OK, you can create your own repo and import the security updates that don't break anaconda, but that's quite high maintenance, and even then, the new package that breaks anaconda might have knock-on dependencies that stop you using many of the fixed packages.
James
Le 08/11/2010 20:35, James Heather a écrit :
If as a project we thought it was important enough we could make this happen as part of critpath QA. If a critpath update breaks, say the desktop spin from being built with updates and working, we could reject the update.
That seems to me to be an entirely appropriate requirement. Without this, there is no simple way of building a live CD that has the latest security fixes.
What about anaconda doing something like: "yum --security update" ?
This would considerably reduce risks, wouldn't it?
On Sat, Nov 06, 2010 at 12:07:25 -0500, Bruno Wolff III bruno@wolff.to wrote:
Given the manpower we have that may be the practical approach. I would suggest that the target is that being able to do a live image respin with the updates repository enabled should work. If the project decides that this must work, we could add retesting one or more live images to the critical path update tests. I don't think this is a good idea now, but maybe someday.
Another option I forgot, is having livecd-creator fix anaconda on the fly, such as by providing an updates-image or other method. That approach has issues as well, but might be reasonabke in some cases.
livecd@lists.fedoraproject.org
-
Brian C. Lane -
Bruno Wolff III -
James Heather -
Jasper Hartline -
Marc Herbert