selinux, kickstart scripts and roles: I give up.
by Anthony Joseph Seward
As part of my kickstart %post script I run some commands as a normal
user by using su. The shell environment in the %post script does not
seem to have the permissions that I need to do this. I've tried
'setenforce 0', but that doesn't work. I tried to change the role too,
but that didn't work.
Does anyone have any ideas on how to get around this?
TIA,
ajs
20 years
how to install GPG keys for up2date?
by Rory Gleeson
I know this is going to seem like a dumb question to many, but how can I
install GPG Keys for up2date, so I won't get GPG key prompts for each package,
every time I update a batch?
I'm a newbie to this GPG key thing - I haven't encountered when updating with
other distros. Googling hasn't turned up any consistent info re: Fedora yet.
Thanks,
Rory
20 years
RE: header/RPM mismatch
by William Hooper
Fulko.Hew(a)sita.aero said:
>
>
>> up2date and yum have different feature sets.
>
> As an end-user, I don't know that, and I don't see that,
> unless I really dive into the documentation of both.
Again, this applies to a number of things. That doesn't mean that one
should go away.
[snip]
> I only have a single system image to update, therefore updating the
> system is purely functional and could/should be devoid
> of 'asthetic' flame wars.
Never seen an apt/yum/up2date or deb/rpm/tgz flamewar, huh?
[snip]
> Whats wrong, is that for some reason (that I do not understand)
> this morning I had the various apps reporting the following
> various needs:
>
> package rhn up2date yum
> -------------------------------------------------
> perl-XML-Twig need it need it need it
> perl-Net-DNS need it need it
> gaim need it
> rpmdb-fedora need it
>
> I'd have to think that if they were all using the same info,
> they'd be reporting the same thing. Wouldn't they?
Are they using the same info? By default up2date will use a random mirror
(possibly a different one each run). rhn-applet (which I assume is what
you mean by rhn) I'm not sure, I will have to look. Yum uses
download.fedora.redhat.com.
> The fact that three different apps are reporting three different
> 'apparent' states of my system is disconcerting.
Please give us more info. How about the output of:
yum check-update
up2date -l
rhn-applet-tui
[snip]
> My answers are... I don't know, I don't know, I don't....
> I installed whatever the 'system' told me to install.
> If I needed something else, 'the system' should have either come
> with it, or told me so, or the release notes....
It does come with the other GPG keys.
> Otherwise, how am I to know?
> I know this is a test release, but sorry...
Exactly, which means as a tester the decision of what keys to trust falls
on you. I definitely don't want up2date automatically importing beta or
test keys on a production system.
A better question to come out of this is why isn't yum doing gpg checks
out of the box?
> Because they are all intended to report the same information:
> "what RPMs I should be updating"
Just to take this reasoning to the extreme... apache and IIS should use
the same configuration info because they both "serve HTTP"?
The sooner you get past the idea that up2date and yum are different
programs, even though they have some functional overlap, the better off
you will be.
[snip]
>>It couldn't possibly be the fact that the mirrors (and main server) are
>>being hammered by people downloading the new test release...
>
> Hammered, just means slow or no data... It should never mean 'incorrect
> data'.
Well, missing headers or packages on the mirror: no data
Truncated package download: slow data followed by no data
>>That is what testing is about, finding out if anything broke. If you
>> want
>>new features and no bugs (yeah, right) wait for the release.
>
> Sorry M$... no bugs should always take precedence over new features
> especially since the bugs have been found and documented.
Got a bug number from bugzilla yet? You are still running on the
assumption that all your issues are the programs when it is more likely a
mirror or rawhide tree issue.
> Unless we test the software, report the problems, _and_ have the problems
> fixed, there will be no point in waiting for the next release, because
> the bugs will still be there in the new release.
> (Just like the 'update/size' bug that hasn't been fixed since Core 1).
Is a pretty cosmetic issue, but IIRC it only happens in 1 place now. The
metadata hasn't changed so it still doesn't have the size information to
put in before the packages are being downloaded.
[snip]
>>Whichever one you want. My point is that you don't run "both at the same
>>time" you are running up2date, then running yum. Just like KDE and
>> Gnome.
>
> OK, so noted. But on the other hand, if they are independent, and the
> result is in the RPM database, I should be able to run both interchangably
> but not simultaneously.
Exactly.
--
William Hooper
20 years
RE: header/RPM mismatch
by Fulko.Hew@sita.aero
> up2date and yum have different feature sets.
As an end-user, I don't know that, and I don't see that,
unless I really dive into the documentation of both.
The apparent, and implied use is that both tools can be used
to update your system to the 'current' level. Perhaps both
do more and different things above and beyond this basic function,
but most people look to them to perform nothing else but
'updating to current'.
> KDE and Gnome do the same thing (they are "Desktop Environments").
I guess you are correct. Where the functionality of KDE and GNOME
overlap there should not be differences in configuration.
But desktops _are_ different, they are visible, they are personal,
so I give that a little more slack.
I only have a single system image to update, therefore updating the
system is purely functional and could/should be devoid
of 'asthetic' flame wars.
... snip ...
>>>> The bigger issues is that headers are saved in two different
>>>> directories
>>>> on your system, so its guaranteed to get out of sync.
>>>
>>>Huh? Neither needs the others headers.
>>
>> Its more like neither _uses_ the other's headers...
>> hence the duplication and inconsistency problems that result.
>> (see the final comment).
>
>But vi not using emacs settings is OK? KDE not using Gnome settings is
>OK? PostgreSQL and MySQL not using the same files? What is the
>difference? Why is it so important that these two programs use the same
>everything when there are so few examples of two programs that do?
Whats wrong, is that for some reason (that I do not understand)
this morning I had the various apps reporting the following
various needs:
package rhn up2date yum
-------------------------------------------------
perl-XML-Twig need it need it need it
perl-Net-DNS need it need it
gaim need it
rpmdb-fedora need it
I'd have to think that if they were all using the same info,
they'd be reporting the same thing. Wouldn't they?
The fact that three different apps are reporting three different
'apparent' states of my system is disconcerting.
Thats why I don't know who to believe.
And yes, I know that rpm -q tells what I've got
But this discussion thread revolves around:
'which of these packages _really_ need updating'?
(Not a yum/up2date/apt-get/etc flame war.)
>>>> c) If you decide to carry on with up2date, you now have to ignore all
>>>> of the GPG errors, because of... (well I don't know).
>>>
>>>Of install the correct GPG keys...
>>
>> What are the correct keys?
>> I installed test 3 from the release CDs and went through the
>> upgrade process. Are there other manual, un-documented steps
>> that need to be performed to get rid of these GPG errors?
>> If so, please give me a link.
>
>Depends, what GPG keys did you install? You are running a test release,
>did you install the test key? You are trying to get updates from rawhide,
>did you install the rawhide key?
My answers are... I don't know, I don't know, I don't....
I installed whatever the 'system' told me to install.
If I needed something else, 'the system' should have either come
with it, or told me so, or the release notes....
Otherwise, how am I to know?
I know this is a test release, but sorry...
people should not have to be fighting these types of issues past the
first hour of a new release..
>http://fedora.redhat.com/about/security/
Ok, I will review that tonight, and see what it says.
>> Because I don't know which tool I _should_ be using. :-(
>
>Which ever one you like. That is what choice is about.
I would pick and only use one, but...
Sorry, with three different tools telling me three different
things make me believe that potentially none of them are right.
>Again, why should two completely different programs use the same
processes?
Because they are all intended to report the same information:
"what RPMs I should be updating"
>> And both used to work for me too. Its just that as the days
>> go by, and as we moved from test2 to test3, things are
>> degenerating (here).
>
>It couldn't possibly be the fact that the mirrors (and main server) are
>being hammered by people downloading the new test release...
Hammered, just means slow or no data... It should never mean 'incorrect
data'.
>That is what testing is about, finding out if anything broke. If you want
>new features and no bugs (yeah, right) wait for the release.
Sorry M$... no bugs should always take precedence over new features
especially since the bugs have been found and documented.
Unless we test the software, report the problems, _and_ have the problems
fixed, there will be no point in waiting for the next release, because
the bugs will still be there in the new release.
(Just like the 'update/size' bug that hasn't been fixed since Core 1).
> (w.r.t. header files and RPM files on mirrors....)
>You seem to be wanting to make a dependency there.
On the contrary, _I_ don't want to make a dependency between hdrs and RPMs
on repositories, but apparently there is one. And so, it should/must be
dealt
with in a professional manner.
>Whichever one you want. My point is that you don't run "both at the same
>time" you are running up2date, then running yum. Just like KDE and Gnome.
OK, so noted. But on the other hand, if they are independent, and the
result is in the RPM database, I should be able to run both interchangably
but not simultaneously.
>Again I ask why two separate programs should be expected to use the same
>set of files. What if you have up2date checking an apt repo? or RHN?
True, if two apps are using two different repositories, I would expect
two different answers, but since they are not, they are using the same
repositories, and the same mirrors, I expect them to report the same thing.
>You are trying to jam up2date and yum into the same mold, and they won't
>fit. They are two different programs with two different ways of doing
>things.
But the same basic end result:
"... You have the following list of RPMs to install:"
20 years
FC2T3 problems with partition with BootIt NG
by Ken Roser
Are there any testers out there using BootIt NG? I installed test 3 and
after some testing and some problems I decided to do another clean
install. Using BootIt NG, I deleted the 3 logical volumes that were
used by Fedora. These 3 logical volumes were in an extended partition
that also included an NTFS volume. After deleting these volumes, BootIt
NG didn't show that there was any free space in the extended partition.
It did show the NTFS volume and its size was considerably less than the
extended partition size so there should have been free space. Booting
Win XP and using disk management I can see the free space. Also,
another attempt to install Fedora does result in Fedora seeing the free
space. It's only BootIT NG that doesn't see the free space. I'm
currently working with the BootIT NG support person to try to resolve
this, but I'm wondering if others here might have encountered the same
problem.
This wasn't a problem with test1 and test2; just test3. Is there
anything going on with the disk partitioning that's different in test3?
The computer is a Dell Dimension 8300 with 80 GB disk and 1 GB RAM.
20 years
smc2802wV1 Fedora Core1 Kernel 2.6.5
by linuxrh
I have kernel 2.6.5 working with fedora C1 but I can't get my smc2802w
version1 working. I can't even get Fedora to see it.
Any one have a step by step setup for this card and this O/S....
Scott....
20 years
Re: up2date choking on Perl:Twig
by t l
try "yum --exclude=perl-XML-Twig update"
That should avoid the problem. This has already been bugzilla'ed:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122079
tom
-------------------------------------------
From: "rgleeson" <rgleeson(a)childwelfare.ca>
Subject: up2date choking on Perl:Twig
To: fedora-test-list(a)redhat.com
Message-ID: <20040430172221.M59667(a)childwelfare.ca>
Content-Type: text/plain; charset=iso-8859-1
I've been having problems using up2date (and Yum and Apt, for that
matter)
with the latest round of updates on Test 3.
Today I discovered it was was choking on Perl:Twig v.3.13-4. The
error
message is:
"unresolvable chain of dependencies - requres Perl:XML
XPath"
I have a couple of question related to this:
1) I have everything installed from the Test 3 CDs. Why am I running
in to a
dependency issue like this on an basic update? I already have 3.09-3
installed. How can I resolve it?
More long-term:
2) In the case of this conflict, would it not be a good idea to
install
everything possible and then note which packages couldn't be
installed at the
end, rather than choking the process at the beginning?
3) I keep getting GP Key (sp?) prompts for each package. Is there a
way to
bypass this?
#2 and #3 speak to the fluidity of an update with up2date, being able
to leave
it do its business and not having to babysit it.
4) very minor cosmetic point:
Why are there three periods on the bottom-left hand corner of the GUI
for
up2date? It makes it appear like it's still unfinished, which it may
be,
given it's a beta verion of Fedora.
5) I guess the refresh issue has been well-noted? The blanked out
screens
while retrieving info make it look as it up2date has stalled and
needs to be
re-started.
Rory
Toronto, Canada
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
20 years
up2date choking on Perl:Twig
by Rory Gleeson
I've been having problems using up2date (and Yum and Apt, for that matter)
with the latest round of updates on Test 3.
Today I discovered it was was choking on Perl:Twig v.3.13-4. The error
message is:
"unresolvable chain of dependencies - requres Perl:XML XPath"
I have a couple of question related to this:
1) I have everything installed from the Test 3 CDs. Why am I running in to a
dependency issue like this on an basic update? I already have 3.09-3
installed. How can I resolve it?
More long-term:
2) In the case of this conflict, would it not be a good idea to install
everything possible and then note which packages couldn't be installed at the
end, rather than choking the process at the beginning?
3) I keep getting GP Key (sp?) prompts for each package. Is there a way to
bypass this?
#2 and #3 speak to the fluidity of an update with up2date, being able to leave
it do its business and not having to babysit it.
4) very minor cosmetic point:
Why are there three periods on the bottom-left hand corner of the GUI for
up2date? It makes it appear like it's still unfinished, which it may be,
given it's a beta verion of Fedora.
5) I guess the refresh issue has been well-noted? The blanked out screens
while retrieving info make it look as it up2date has stalled and needs to be
re-started.
Rory
Toronto, Canada
20 years
RE: header/RPM mismatch
by William Hooper
Fulko.Hew(a)sita.aero said:
>
> ... some context snipped for brevity...
>
>>> If yum is supposed to replace up2date, then its config file, should be
>>> a
>>> superset
>>> of up2date.
>>
>>Who said yum is supposed to replace up2date?
>
> If yum is not to replace up2date for updating, then why does it exist?
> What itch is _it_ scratching that up2date
> wouldn't/shouldn't/couldn't scratch?
up2date and yum have different feature sets.
>>> After all, they are both supposed to do the same thing.
>>
>>Again, KDE vs. Gnome, vi vs. emacs, etc.
>
> but KDE and Gnome do _not_ do the same thing, and they do not
> use the same config files, and they are not infered to work together
> (except for the rhn applet that does work on both task bars.)
KDE and Gnome do the same thing (they are "Desktop Environments").
Because they are different programs they "and they do not use the same
config files, and they are not infered to work together", just like yum
and up2date.
> As for vi vrs emacs, they both operate on the same kind text files,
> and when your done editing your file with one, the file is still readable
> and usable by the other editor, so thats not a valid analogy.
up2date and yum operate on the same RPM files and when you are done the
RPM database is usable by the other. What is not valid?
>>> The bigger issues is that headers are saved in two different
>>> directories
>>> on your system, so its guaranteed to get out of sync.
>>
>>Huh? Neither needs the others headers.
>
> Its more like neither _uses_ the other's headers...
> hence the duplication and inconsistency problems that result.
> (see the final comment).
But vi not using emacs settings is OK? KDE not using Gnome settings is
OK? PostgreSQL and MySQL not using the same files? What is the
difference? Why is it so important that these two programs use the same
everything when there are so few examples of two programs that do?
>>> c) If you decide to carry on with up2date, you now have to ignore all
>>> of the GPG errors, because of... (well I don't know).
>>
>>Of install the correct GPG keys...
>
> What are the correct keys?
> I installed test 3 from the release CDs and went through the
> upgrade process. Are there other manual, un-documented steps
> that need to be performed to get rid of these GPG errors?
> If so, please give me a link.
Depends, what GPG keys did you install? You are running a test release,
did you install the test key? You are trying to get updates from rawhide,
did you install the rawhide key?
http://fedora.redhat.com/about/security/
>>> e) Ohh, sometimes up2date hangs... Well just re-install, maybe it'll
>>> work.
>>
>>Have a reproducible situation? A bug number? I've been using up2date on
>>FC1, FC2Test2, and FC2Test3 and I don't recall any hangs.
>
> Yes, 100% reproducible since yesterdays's daily RPM fetch.
> ... while typing this message, I tried it again, and it no longer
> hangs. :-( Maybe some of my earlier playing with the header
> directories has resolved something... I don't know....
> But the 'there are 2 packages to fetch, but you can only select
> one of them' issue still remains.
Must have missed that thread.
>>> d) If you get frustrated by the now broken up2date and the GPG issues
>>> you resort to using yum. But sometimes _it_ lies.
>>
>>So if "you resort to using yum" why do you think it should replace
> up2date?
>
> Because I don't know which tool I _should_ be using. :-(
Which ever one you like. That is what choice is about.
> I'd like to use the rhn_applet and up2date because:
> a) thats what I used with RH7.x, 8.x, 9.x
> b) it always _used_ to work
> c) its on the desktop and its pretty,
> d) and most of the time it works (or at least it did,
> ignoring the 'size reporting' issue
Already in bugzilla.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107048
> and the "GPG error' issues.
See above.
> But now that doesn't work so I have to use yum,
> which gets me a 'little' further.
>
>>> So in the end you don't know what you've got,
>>> who's wrong, whats wrong
>>> or where and how to fix it.
>>
>>They all use the same rpm database.
>
> Sorry, I was talking about the various update notice facilities
> and updating processes, not their end product.
Again, why should two completely different programs use the same processes?
>>> I don't mind having choices, but at least one of those choices should
>>> work, and if the others don't. Then they shouldn't be supplied.
>>
>>Both work for me. YMMV.
>
> And both used to work for me too. Its just that as the days
> go by, and as we moved from test2 to test3, things are
> degenerating (here).
It couldn't possibly be the fact that the mirrors (and main server) are
being hammered by people downloading the new test release...
> ... snip ...
>
>>I'm sorry, if you are not interested in new features why are you running
>> a
>>test release?
>
> Because I want some of those new feature, but call me selfish...
> I also don't want some of the old features broken. ;-)
> Like up2date, or USB hotplug.
That is what testing is about, finding out if anything broke. If you want
new features and no bugs (yeah, right) wait for the release.
>>>So set up multiple rsync jobs and have a human check that the first is
>>> done?
>>>
>>> No, set up one job that rsyncs the RPMs, and then rsyncs the headers.
>>
>>And the case of headers being release on the main site after the first
>> job
>>is started is resolved how?
>
> If there is a dependency and synchronization requirement on the
> updating facility, then rsync is 'inappropriate' to use to maintain
> mirrors in order to ensure 'system integrity'.
You seem to be wanting to make a dependency there.
>>>>Yes, I think you should pick one and throw the rest away.
>>>
>>> OK, which one? Which one works? ...Neither.
>>
>>In my experience both.
>
> That _used_ to be my experience, but since the virgin install of
> test3, this no longer seems to be the case (and its not just me,
> count at least 2 occurances here in Canada).
>
>> If you are trying to run up2date and yum at the same time you might have
>> just answered your own question.
>
> Then I'm back to asking which one _should_ I be using?
Whichever one you want. My point is that you don't run "both at the same
time" you are running up2date, then running yum. Just like KDE and Gnome.
> ... snip....
>
>>> But neither of them use the same front end database and neither
>>> seem to work right... anymore.
>>
>>Both use a yum repo and both put transactions into the RPM database.
>> What
>>database are you talking about?
>
> The directories where current and ancient headers and rpms are saved:
>
> /var/spool/up2date
> /var/cache/yum/development/headers
Again I ask why two separate programs should be expected to use the same
set of files. What if you have up2date checking an apt repo? or RHN?
You are trying to jam up2date and yum into the same mold, and they won't
fit. They are two different programs with two different ways of doing
things.
--
William Hooper
20 years
Re: alsa mute
by Law Horne
>
>
>/etc/asound.state is saved at shutdown, and running alsactl restore
>immediately after login does restore the correct values for PCM and
>other controls. So the problem seems to be that modprobe didn't run
>alsactl restore at startup.
>
Would running
"# rc-update add alsasound boot"
Not fix that? This is kinda shot in a dark as this from another
Linux distro alsa setup. But I have used this on slackware 9.1 and
it worked despite this not being it's own setup guide. I haven't had
a chance to try on fedora I got rid of my test3 installin favor of
Fedora core 1.
Law
20 years