9:50 p.m.
Here's an interesting problem...
I set my ImageCreator cachedir to /var/yum/cache to share my x86_64
laptop's cache. Maybe this was a bad idea, but an interesting thing
happened.
[root@newcaprica ltsp]# chroot-creator --target=/opt/ltsp/i386/
/etc/ltsp/ltsp-build-client-ks.cfg
Mounting /opt/ltsp/i386/ for chroot installation
Retrieving
http://homemirror.togami.com/pub/fedora/linux/releases/8/Everything/i386/...
...OK
Retrieving
http://homemirror.togami.com/pub/fedora/linux/updates/8/x86_64/repodata/r...
...OK
The resulting chroot successfully completed installation, but chroot to
run pretty much anything including /bin/bash failed. x86_64 and i386
packages mixed together in some broken way.
[root@newcaprica opt]# yum clean metadata
Loading "refresh-updatesd" plugin
Loading "basearchonly" plugin
27 metadata files removed
Cleaning out the metadata made it work as expected.
[root@newcaprica ltsp]# chroot-creator --target=/opt/ltsp/i386/
/etc/ltsp/ltsp-build-client-ks.cfg
Mounting /opt/ltsp/i386/ for chroot installation
Retrieving
http://homemirror.togami.com/pub/fedora/linux/releases/8/Everything/i386/...
...OK
Retrieving
http://homemirror.togami.com/pub/fedora/linux/updates/8/i386/repodata/rep...
...OK
Retrieving
http://homemirror.togami.com/pub/fedora/linux/updates/8/i386/repodata/pri...
...OK
So there was some kind of conflict between my x86_64 host laptop and the
i386 chroot both trying to use the same yum cache directory. I'm
guessing it was a bad idea to try to do so and this is unsupported.
However I am very surprised that it didn't error out.
Are there any genuine bugs in anything I described above?
Shouldn't yum warn or error out when it sees the repodata arch conflict?
I'm a little saddened that I can't share the same yum cache directories,
because the RPMS themselves could peacefully co-exist if it were not for
the metadata.
Warren Togami
wtogami(a)redhat.com
10:08 p.m.
OK, this is a bigger problem than simply conflicting with the host's yum
repodata cache. It can easily conflict with itself if you use a local
persistent cache.
Stepping back a bit to explain from the beginning:
Instead of create() I use each step. One of create()'s steps is
mount(). Instead of the defaults I use:
mount(None,"/path/to/anywhere")
This makes testing the image creator really fast because I don't have to
grab packages from my mirror each time. In the previous message I
described how this conflicted with my host's yum repodata when I used
/var/cache/yum. I of course can avoid this conflict by setting it to
anything else. But then I realized, it can easily conflict with itself
leading to failure.
If I use *any* hard-coded persistent cache directory with ImageCreator,
create a i386 image and immediately follow it with a x86_64 image, then
it is affected by the previous architecture's repodata.
Surely this is a bug?
Otherwise I have no choice but to include arch within cachedir's name,
which seems bad.
/var/cache/imagecreator-i386/
/var/cache/imagecreator-x86_64/
Warren Togami
wtogami(a)redhat.com
12:09 p.m.
On Sun, 2008-02-17 at 23:08 -0500, Warren Togami wrote:
If I use *any* hard-coded persistent cache directory with
ImageCreator,
create a i386 image and immediately follow it with a x86_64 image, then
it is affected by the previous architecture's repodata.
Yes, it's a cache. You're saying that you have a repository that's
named the same thing (which is the only thing to differentiate between
two repositories) and yet has different contents when you run it. Note
that things like this are part of the reason why we, by default,
instantiate a cache *per run* of livecd-creator. --cache is an option
for those who know what they're doing.
Otherwise I have no choice but to include arch within cachedir's
name,
which seems bad.
/var/cache/imagecreator-i386/
/var/cache/imagecreator-x86_64/
If you're doing runs of both i386 and x86_64 on the same machine and
want to keep a persistent cache between runs, this is what I would
recommend.
Jeremy
12:07 p.m.
On Sun, 2008-02-17 at 22:50 -0500, Warren Togami wrote:
I set my ImageCreator cachedir to /var/yum/cache to share my x86_64
laptop's cache. Maybe this was a bad idea, but an interesting thing
happened.
Don't do that. You're basically saying that you have a repository named
foo but foo is two different things depending on how you run.
[snip]
Are there any genuine bugs in anything I described above?
Shouldn't yum warn or error out when it sees the repodata arch conflict?
repodata doesn't have an inherent archness. You can have repodata
containing packages of all arches.
Jeremy
1:57 p.m.
On Tue, 19 Feb 2008 13:07:10 -0500
Jeremy Katz <katzj(a)redhat.com> wrote:
Don't do that. You're basically saying that you have a
repository
named foo but foo is two different things depending on how you run.
[snip]
> Are there any genuine bugs in anything I described above?
> Shouldn't yum warn or error out when it sees the repodata arch
> conflict?
repodata doesn't have an inherent archness. You can have repodata
containing packages of all arches.
FWIW in pungi I use a single cache name for all arches. However for
every single run I expire the metadata and require fresh metadata be
downloaded. This seems to work for me, not many people have complained
about getting new repodata every run.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
2:09 p.m.
Jesse Keating wrote:
On Tue, 19 Feb 2008 13:07:10 -0500
Jeremy Katz <katzj(a)redhat.com> wrote:
> Don't do that. You're basically saying that you have a repository
> named foo but foo is two different things depending on how you run.
>
> [snip]
>> Are there any genuine bugs in anything I described above?
>> Shouldn't yum warn or error out when it sees the repodata arch
>> conflict?
> repodata doesn't have an inherent archness. You can have repodata
> containing packages of all arches.
FWIW in pungi I use a single cache name for all arches. However for
every single run I expire the metadata and require fresh metadata be
downloaded. This seems to work for me, not many people have complained
about getting new repodata every run.
What do you use to expire the metadata? That sounds very useful. I
would like to keep a single cachedir mainly for the RPMS and not
necessarily the metadata.
Warren Togami
wtogami(a)redhat.com
3:51 p.m.
On Tue, 19 Feb 2008 15:09:54 -0500
Warren Togami <wtogami(a)redhat.com> wrote:
What do you use to expire the metadata? That sounds very useful. I
would like to keep a single cachedir mainly for the RPMS and not
necessarily the metadata.
I use a yum call to clean the metadata and sqlite data.
self.ayum.cleanMetadata() # clean metadata that might be in the cache from
previous runs
self.ayum.cleanSqlite() # clean metadata that might be in the cache from previous
runs
Some things to consider, don't allow multiple runs of livecd-creator to
use the same cache at the same time. This could be... interesting. So
a locking system is needed. I don't actually have a locking system in
pungi yet, I've been playing fast and loose with it.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
4:03 p.m.
Is there a way to clean the metadata from bash?
Tim
Jesse Keating wrote:
On Tue, 19 Feb 2008 15:09:54 -0500
Warren Togami <wtogami(a)redhat.com> wrote:
> What do you use to expire the metadata? That sounds very useful. I
> would like to keep a single cachedir mainly for the RPMS and not
> necessarily the metadata.
>
I use a yum call to clean the metadata and sqlite data.
self.ayum.cleanMetadata() # clean metadata that might be in the cache from
previous runs
self.ayum.cleanSqlite() # clean metadata that might be in the cache from previous
runs
Some things to consider, don't allow multiple runs of livecd-creator to
use the same cache at the same time. This could be... interesting. So
a locking system is needed. I don't actually have a locking system in
pungi yet, I've been playing fast and loose with it.
------------------------------------------------------------------------
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
--
_________________________________
Tim Wood, CLP, RHCT
719.338.7484 (tel)
The Data Wranglers
Web, Database & more since since 1994
www.datawranglers.com
4:07 p.m.
On Tue, 19 Feb 2008 15:03:53 -0700
Tim Wood <tim.wood(a)datawranglers.com> wrote:
Is there a way to clean the metadata from bash?
Erm.. I thought livecd-creator used a yum object instead of executing
yum.... but yes.
yum clean metadata dbcache
It'll clean it from all enabled repos.
Note: sharing system yum cache and compose tool yum cache is a pretty
bad idea. I would not recommend it.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
4:15 p.m.
Worked like a champ. Thanks. FWIW, I try to err on the side of caution
so I've never mixed up the system and livecd-tools caches. I have too
much "fun" without trying to intentionally shoot my foot off ;-)
Tim
Jesse Keating wrote:
On Tue, 19 Feb 2008 15:03:53 -0700
Tim Wood <tim.wood(a)datawranglers.com> wrote:
> Is there a way to clean the metadata from bash?
>
Erm.. I thought livecd-creator used a yum object instead of executing
yum.... but yes.
yum clean metadata dbcache
It'll clean it from all enabled repos.
Note: sharing system yum cache and compose tool yum cache is a pretty
bad idea. I would not recommend it.
------------------------------------------------------------------------
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
--
_________________________________
Tim Wood, CLP, RHCT
719.338.7484 (tel)
The Data Wranglers
Web, Database & more since since 1994
www.datawranglers.com
11:44 a.m.
On Tue, 2008-02-19 at 16:51 -0500, Jesse Keating wrote:
On Tue, 19 Feb 2008 15:09:54 -0500
Warren Togami <wtogami(a)redhat.com> wrote:
> What do you use to expire the metadata? That sounds very useful. I
> would like to keep a single cachedir mainly for the RPMS and not
> necessarily the metadata.
I use a yum call to clean the metadata and sqlite data.
Why do you do the big hammer rather than just setting metadata_expire to
be 0? Should have the same impact, but also allow the cached metadata
to persist as long as the repomd matches
Jeremy
12:39 p.m.
On Wed, 20 Feb 2008 12:44:21 -0500
Jeremy Katz <katzj(a)redhat.com> wrote:
Why do you do the big hammer rather than just setting
metadata_expire
to be 0? Should have the same impact, but also allow the cached
metadata to persist as long as the repomd matches
Because nobody had suggested it (:
--
Jesse Keating
Fedora -- All my bits are free, are yours?
3:24 p.m.
On Tue, 2008-02-19 at 14:57 -0500, Jesse Keating wrote:
On Tue, 19 Feb 2008 13:07:10 -0500
Jeremy Katz <katzj(a)redhat.com> wrote:
> Don't do that. You're basically saying that you have a repository
> named foo but foo is two different things depending on how you run.
>
> [snip]
> > Are there any genuine bugs in anything I described above?
> > Shouldn't yum warn or error out when it sees the repodata arch
> > conflict?
>
> repodata doesn't have an inherent archness. You can have repodata
> containing packages of all arches.
FWIW in pungi I use a single cache name for all arches. However for
every single run I expire the metadata and require fresh metadata be
downloaded. This seems to work for me, not many people have complained
about getting new repodata every run.
That doesn't sound crazy. If someone were to provide the patch, I'd
almost certainly apply it. Or I'll get to it "eventually"
Jeremy
5909
days inactive
5911
days old
livecd@lists.fedoraproject.org
12 comments
4 participants
participants (4)
-
Jeremy Katz -
Jesse Keating -
Tim Wood -
Warren Togami