bz#624028 livecd-creator creates iso that doesn't boot

[Brian C. Lane]

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.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

[Bruno Wolff III]

On Thu, Oct 28, 2010 at 17:39:35 -0700,
  "Brian C. Lane" <bcl(a)redhat.com&gt; wrote:
>  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. 
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.

[Jasper Hartline]

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.

[Bruno Wolff III]

On Mon, Nov 08, 2010 at 10:39:58 -0700,
  Jasper Hartline <jasper.hartline(a)gmail.com&gt; 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.

[Brian C. Lane]

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(a)redhat.com&gt; wrote:
>  > 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.
>  
>  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.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

[Bruno Wolff III]

On Mon, Nov 08, 2010 at 11:26:55 -0800,
  "Brian C. Lane" <bcl(a)redhat.com&gt; 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.

[Brian C. Lane]

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(a)redhat.com&gt; 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.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

[Bruno Wolff III]

On Mon, Nov 08, 2010 at 11:41:20 -0800,
  "Brian C. Lane" <bcl(a)redhat.com&gt; 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.

[James Heather]

>  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

[Marc Herbert]

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?

[Bruno Wolff III]

On Sat, Nov 06, 2010 at 12:07:25 -0500,
  Bruno Wolff III <bruno(a)wolff.to&gt; 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.