Bug 508659 - livecd-creator doesn't create on rawhide
Summary: livecd-creator doesn't create on rawhide
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: James Antill
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 500798
TreeView+ depends on / blocked
 
Reported: 2009-06-29 11:22 UTC by Petr Sklenar
Modified: 2014-01-21 23:10 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
While populating the package sack, yum did not account for the possibility repos had been added where none existed before. Therefore, if the repos were not specified in the original configuration, and repos were subsequently added, yum would not add to the package sack the first time that it tried to use the new repos. This situation could lead to problems during installation or the creation of live CDs. Yum now re-initializes the package sack when a repo is added if no repo was previously specified.
Clone Of: 508139
Environment:
Last Closed: 2009-09-02 07:34:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1419 0 normal SHIPPED_LIVE yum bug fix update 2009-09-02 07:32:56 UTC

Description Petr Sklenar 2009-06-29 11:22:24 UTC
+++ This bug was initially created as a clone of Bug #508139 +++

This is a problem because we need live cds to run the f12 test days.


[mclasen@planemask spin-kickstarts]$ sudo livecd-creator --config fedora-livecd-desktop.ks 
mke2fs 1.41.6 (30-May-2009)
Filesystem label=fedora-livec-x86
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
196608 inodes, 786432 blocks
7864 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=805306368
24 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912

Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
tune2fs 1.41.6 (30-May-2009)
Setting maximal mount count to -1
Setting interval between checks to 0 seconds
filespec_eval:  hash table stats: 12 elements, 12/65536 buckets used, longest chain length 1
/usr/lib/python2.6/site-packages/imgcreate/errors.py:45: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
  return unicode(self.message)
Error creating Live CD : Failed to find package 'kernel' : No package(s) available to install

--- Additional comment from mclasen on 2009-06-25 15:40:50 EDT ---

The same result with the f11 repos instead of rawhide.

--- Additional comment from katzj on 2009-06-25 16:26:23 EDT ---

Builds are working for me here although bug 505121 is still present.

Is this an i386 or x86_64 host?  Does 'yum install kernel' do the right thing?

--- Additional comment from mclasen on 2009-06-25 16:35:09 EDT ---

x86_64 host.

> Does 'yum install kernel' do the right thing?  

Seems to:

[mclasen@planemask gnome-panel-2.26.2]$ sudo yum install kernel
Loaded plugins: dellsysidplugin2, presto, refresh-packagekit
Setting up Install Process
Package kernel-2.6.31-0.28.rc1.fc12.x86_64 already installed and latest version
Nothing to do

--- Additional comment from katzj on 2009-06-26 12:12:16 EDT ---

This is broken by commit 5216a27d35d60e46f028b1fbba58acae5b9e79d2 in yum -- if you initially set up without any repos (==> len(ayum.pkgSack)=0) and then add repos, yum no longer adds to the pkgSack on the first access with the new repos.

It's a side effect, but it's a side effect that both livecd-creator and anaconda depend on working (and thus, probably that other tools do as well)

--- Additional comment from james.antill on 2009-06-26 12:53:42 EDT ---

Crap ... this just went into the RHEL-5.4 candidate too.

Ok, so here's what I think we can do (to fix both bugs):

commit 0e9c56de28596bad95c13fee15187df3249f4be1
Author: James Antill <james>
Date:   Fri Jun 26 12:51:12 2009 -0400

    Re-setup the pkgSack whenever the sacks change

diff --git a/yum/__init__.py b/yum/__init__.py
index be98aae..ef793f6 100644
--- a/yum/__init__.py
+++ b/yum/__init__.py
@@ -480,8 +480,11 @@ class YumBase(depsolve.Depsolve):
         """populates the package sacks for information from our repositories,
            takes optional archlist for archs to include"""
 
-        if self._pkgSack is not None and thisrepo is None:
+        pkgSack_count = len(self.repos.pkgSack.sacks)
+        if (self._pkgSack is not None and
+            pkgSack_count == self._old_pkgSack_count and thisrepo is None):
             return self._pkgSack
+        self._old_pkgSack_count = pkgSack_count
         
         if thisrepo is None:
             repos = 'enabled'

...can you confirm, if so I'll puch it everywhere.

--- Additional comment from james.antill on 2009-06-26 12:58:51 EDT ---

Ok, that's insane ... because the sacks come from populateSacks, which is inside that function ... I think the only way we can do this is test to see if listEnabled() has changed.
Probably the fastest way to do that is put some timestamp in the repos object, and then check if timestamp == old_timestamp.

--- Additional comment from svidal on 2009-06-26 13:24:53 EDT ---

How about we fix the problem separately in package-cleanup and not modify yum?

--- Additional comment from james.antill on 2009-06-26 14:42:00 EDT ---

It's not just package-cleanup that hits it, it also hit at least versionlock ... and generally anything 485578 that uses .pkgSack when they are empty due to excludes (I think). I'm also not sure how we can fix it at a higher level.
 I've pushed a patch which is almost all comment and I think fixes it with no bad side effects ... Jeremy can you have a look?

http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=06e7d4492846f30d03e400d795bd353bdac6ab77

--- Additional comment from james.antill on 2009-06-26 14:43:10 EDT ---

Yep, I'm on top form ... I pasted the above BZ number into the wrong place and pushed the commit without adding it to the summary. I shall now go drink some cherry coke and wait for my holiday to start.

--- Additional comment from mclasen on 2009-06-28 19:45:34 EDT ---

The patch in comment 8 at least allows livecd-creator to get to the point where it falls over broken dependencies in rawhide. I guess thats progress...

Comment 10 Ruediger Landmann 2009-09-01 21:58:26 UTC
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
While populating the package sack, yum did not account for the possibility repos had been added where none existed before. Therefore, if the repos were not specified in the original configuration, and repos were subsequently added, yum would not add to the package sack the first time that it tried to use the new repos. This situation could lead to problems during installation or the creation of live CDs. Yum now re-initializes the package sack when a repo is added if no repo was previously specified.

Comment 11 errata-xmlrpc 2009-09-02 07:34:36 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1419.html


Note You need to log in before you can comment on or make changes to this bug.