5:56 a.m.
What it says on the tin. Enabled the updates-repo during F10 install.
Boot.log at the very first boot:
Starting NetworkManager daemon: NetworkManager: error while loading
shared libraries: libudev.so.0: cannot open shared object file: No
such file or directory
Being without NetworkManager, it's rather difficult to ...use yum to
fix NetworkManager.
A google for "NetworkManager libudev.so.0" or "NetworkManager
libudev.so.0 fedora" reveals nothing interesting, so perhaps no one
has noticed this. This is my second install with updates-enabled. My
first used KDE, and had no NetworkManager at first boot. Thinking
selecting KDE broke something for the install, I tried a vanilla GNOME
Fedora setup for the second install, with updates. Then I noticed
this message on boot.
Alright, off to bed.
9:49 a.m.
On Fri, 13 Mar 2009 23:56:37 -0500
Jud Craft <craftjml(a)gmail.com> wrote:
What it says on the tin. Enabled the updates-repo during F10
install.
Boot.log at the very first boot:
Starting NetworkManager daemon: NetworkManager: error while loading
shared libraries: libudev.so.0: cannot open shared object file: No
such file or directory
Being without NetworkManager, it's rather difficult to ...use yum to
fix NetworkManager.
A google for "NetworkManager libudev.so.0" or "NetworkManager
libudev.so.0 fedora" reveals nothing interesting, so perhaps no one
has noticed this. This is my second install with updates-enabled. My
first used KDE, and had no NetworkManager at first boot. Thinking
selecting KDE broke something for the install, I tried a vanilla GNOME
Fedora setup for the second install, with updates. Then I noticed
this message on boot.
Alright, off to bed.
No idea why this happened, but it should be resolvable by installing
libudev0 from your install media.
Paul.
4:41 p.m.
Easy enough for me.
But imagine any Johnny Unlucky who downloads the network install
image, and does a fresh install with updates.
Unless he made extra copies of the Fedora install DVDs (and why would
he? that defeats the point of a minimal image) he has *no other
install media*. It's game over for him.
Kinda makes a network install with updates a little pointless, if the
result (a system without network access) can't be fixed without A)
network access, or B) another Fedora image (also possibly requiring
more network access).
6:22 p.m.
----- Original Message -----
From: "Jud Craft" <craftjml(a)gmail.com>
To: "Development discussions related to Fedora"
<fedora-devel-list(a)redhat.com>
Sent: Saturday, March 14, 2009 11:41 AM
Subject: Re: F10 Fresh Vanilla Install with Updates Has Broken
NetworkManager
Unless he made extra copies of the Fedora install DVDs (and why
would
he? that defeats the point of a minimal image) he has *no other
install media*. It's game over for him.
Well, it seems that since F9 most network problems can be solved by
sudo service NetworkManager stop
Of course, you have to know this, and it isn't QUITE that simple.
I'm still not convinced NetworkManager is ready for prime time. Even with
F11 alpha I have to do some fiddling around. I think F10 alpha actually
worked out of the box, but that was apparently an abberation. Hasn't worked
since without some help.
--McD
6:57 p.m.
"John J. McDonough" <wb8rcr(a)arrl.net> writes:
I'm still not convinced NetworkManager is ready for prime time.
NM might be great for laptops, but it's both useless and pernicious in
a static-IP environment. In both F9 and F10 I've had to turn it off,
and the single most annoying thing about it is *you can't really turn
it off*. There are pieces of it that keep coming to life anyway ...
eg bz #455825 and the fact that it keeps demanding my VPN password
when I'm not using it to control the VPN.
I would rpm -e it except that that would take out half the system.
regards, tom lane
6:59 p.m.
Keep in mind the issue is not "the usefulness of NetworkManager" or
"the NM service is having problems."
The NetworkManager service isn't even STARTING, since it's missing a
dependency library. Somehow yum updates messed up during install.
Simply put this should not happen.
7:26 p.m.
On Sat, Mar 14, 2009 at 9:59 AM, Jud Craft <craftjml(a)gmail.com> wrote:
Simply put this should not happen.
I haven't run into this myself and I can't seem to find an existing
report on this issue.
Can you give me more info please.
Just to be clear, this is a problem happening as part of the install
process? I want to make sure about that.
What was the media image you used for the install? We have several
and to try to confirm this we need to make sure we use the one you
used.
Did you run media check during the install?
Fresh install or upgrade?
Can you reproduce this on a new fresh install attempt using newly burned media?
-jef
10:28 p.m.
I'm using the stock F10 install DVD, but with updates enabled during
the install. That's all there is to it, NetworkManager doesn't work
at first boot.
This is not oversimplification, this is merely all I did. It's done
this twice now.
Now for something curious regarding libudev0:
It doesn't seem to actually be installed by the stock F10 image. If I
do a plain install (no updates), NetworkManager works fine. Running a
"yum update" then pulls down all the updates, as well as "Install
libudev0".
So at some point I suppose NetworkManager picked up a dependency on
libudev0, but for some reason updating during the installation process
doesn't pull this new package in.
10:57 p.m.
On Sat, Mar 14, 2009 at 1:28 PM, Jud Craft <craftjml(a)gmail.com> wrote:
I'm using the stock F10 install DVD, but with updates enabled
during
the install. That's all there is to it, NetworkManager doesn't work
at first boot.
libudev0 has not seen an update..it was in the F10 release tree. I
don't have this problem. My only thought is your media is corrupt.
Did you test the media, I don't think you answered that question.
-jef
11:23 p.m.
You're right, I intentionally didn't. But in my defense, I just
booted the install DVD and ran the disk-check on it, and it says no
errors found.
Serious though, I'm not making up that libudev0 stuff. "yum update"
pulled it down and installed it, rather than updating it. So I'm
assuming it wasn't installed to begin with. And yet the first-boot
NetworkManager service (from a plain install with no updates) worked
fine.
Judging by my first error message up above, the new updated
NetworkManager uses libudev0, and for some reason libudev0 isn't there
when I use updates in the middle of the installation process.
11:46 p.m.
On Sat, Mar 14, 2009 at 2:23 PM, Jud Craft <craftjml(a)gmail.com> wrote:
You're right, I intentionally didn't. But in my defense, I
just
booted the install DVD and ran the disk-check on it, and it says no
errors found.
Serious though, I'm not making up that libudev0 stuff. "yum update"
pulled it down and installed it, rather than updating it. So I'm
assuming it wasn't installed to begin with. And yet the first-boot
NetworkManager service (from a plain install with no updates) worked
fine.
I'm not saying your a making it up.
Here's the problem as I see it. libudev0 is in the release
repository, but it did not get placed on the dvd image as the
NetworkManager that came with the dvd did not depend on it. A later
NetworkManager update does depend on it. I'm not sure why your
scenario isn't picking up libudev0 and installing it. I'll have to do
more local testing to try to confirm this behavior. I've never run
into it myself, but my update habits may have prevented me from
noticing this previously.
-jef
12:29 a.m.
Jeff Spaleta wrote:
Here's the problem as I see it. libudev0 is in the release
repository, but it did not get placed on the dvd image as the
NetworkManager that came with the dvd did not depend on it. A later
NetworkManager update does depend on it. I'm not sure why your
scenario isn't picking up libudev0 and installing it. I'll have to do
more local testing to try to confirm this behavior. I've never run
into it myself, but my update habits may have prevented me from
noticing this previously.
You added only updates and not Everything, so there's nowhere it could pick
it up from as it never got updated.
Of course, if you do add Everything, that may end up used instead of the
packages on the DVD.
Enabling updates when installing from the DVD is not officially supported
for a reason.
Kevin Kofler
12:52 a.m.
That makes sense. Then the obvious answer is that enabling Updates
should also enable the default online repository, which has a slightly
wider collection of packages than the DVD and may be needed to fill in
dependencies pulled down by the Updates.
Packages should be grabbed by default from Updates, then from the DVD
(if no update required), then from the default repository (if not on
the DVD), in that order.
I'll make sure to enable the main repository as well next time.
Bummer that packages have to change their dependencies through the
lifetime of one Fedora release.
1:01 a.m.
Jud Craft wrote:
I'll make sure to enable the main repository as well next time.
Bummer that packages have to change their dependencies through the
lifetime of one Fedora release.
That's very common, and often unavoidable. Often updated versions need more
libraries to support some new features or to implement existing features in
a better or more reliable way. (This is what happened here, and also
commonly happens with KDE updates.) Sometimes a private copy of a library
gets replaced by the system library. And sometimes dependencies were simply
forgotten and need to be added in updates.
Kevin Kofler
1:22 p.m.
On Sun, 15 Mar 2009 00:29:54 +0100
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Jeff Spaleta wrote:
> Here's the problem as I see it. libudev0 is in the release
> repository, but it did not get placed on the dvd image as the
> NetworkManager that came with the dvd did not depend on it. A later
> NetworkManager update does depend on it. I'm not sure why your
> scenario isn't picking up libudev0 and installing it. I'll have to
> do more local testing to try to confirm this behavior. I've never
> run into it myself, but my update habits may have prevented me from
> noticing this previously.
You added only updates and not Everything, so there's nowhere it
could pick it up from as it never got updated.
Of course, if you do add Everything, that may end up used instead of
the packages on the DVD.
I would hope that the installer assigned a lower "cost" in yum to the
DVD than any network repo, which would avoid this issue.
Paul.
5:09 p.m.
I would hope that the installer assigned a lower "cost" in
yum to the
DVD than any network repo, which would avoid this issue.
Paul.
There's no reason to do that. The DVD has exactly the same packages
as the main Fedora repository, just a subset of them. If they are
present on the DVD, they should be used to reduce install time, I
think. Only grab them from the main repository if they are needed but
not found on the DVD. I think the simplest thing to do is just
automatically enable the main repository whenever the updates
repository is enabled.
Post-thought: I'm sorry, I admit I am unfamiliar with yum's costs.
Does a lower DVD cost mean that yum prefers packages from the network
instead? That was my assumption, and my conclusion: if a common
package between the two is the same, use the local one. (DVD)
The idea should be to A) trust the installation media whenever you
can, and B) perform as little extra network transaction as possible
for everything else.
I'll go ahead and tell you this completely means that the
Yum-Presto-On-Install idea is absolutely worthless if you think
otherwise; the whole "use small delta packages to do a quick update at
install-time" won't be any use at all if you're just downloading every
package (that was on the DVD) from the main repository anyway.
The DVD is like a local cache, it should be used as such.
7:21 p.m.
Jud Craft wrote:
Post-thought: I'm sorry, I admit I am unfamiliar with yum's
costs.
Does a lower DVD cost mean that yum prefers packages from the network
instead?
No. When given the choice between the same identical computer at 2 places,
would you pick the one with higher cost? ;-) Likewise, if yum can get the
same identical package at 2 places, it will prefer the one with lower cost.
Kevin Kofler
11:53 p.m.
On Sat, Mar 14, 2009 at 6:23 PM, Jud Craft wrote:
You're right, I intentionally didn't. But in my defense, I
just
booted the install DVD and ran the disk-check on it, and it says no
errors found.
Serious though, I'm not making up that libudev0 stuff. "yum update"
pulled it down and installed it, rather than updating it. So I'm
assuming it wasn't installed to begin with. And yet the first-boot
NetworkManager service (from a plain install with no updates) worked
fine.
Judging by my first error message up above, the new updated
NetworkManager uses libudev0, and for some reason libudev0 isn't there
when I use updates in the middle of the installation process.
--
This may or may not be related.
I had a similar situation. I had installed F-10 with updates enabled.
The installer picked and installed audacity from the updates repo, but
did not install its dependency wxGTK.
I got an error message like "cannot open shared object file" when I
ran audacity. Then I installed wxGTK manually and everything worked
fine.
It sounds similar to your problem, although it has nothing to do with
NetworkManager. Just for the record, wxGTK did not see any updates on
F-10 either.
Orcan
5:37 a.m.
On Sat, 2009-03-14 at 17:28 -0400, Jud Craft wrote:
So at some point I suppose NetworkManager picked up a dependency on
libudev0, but for some reason updating during the installation process
doesn't pull this new package in.
This is likely because the updates repo isn't the Everything repo. To
really do a proper install with updates you have to enable both the
Updates repo and the Everything repo.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:24 p.m.
On 15.03.2009 05:37, Jesse Keating wrote:
On Sat, 2009-03-14 at 17:28 -0400, Jud Craft wrote:
> So at some point I suppose NetworkManager picked up a dependency on
> libudev0, but for some reason updating during the installation process
> doesn't pull this new package in.
This is likely because the updates repo isn't the Everything repo. To
really do a proper install with updates you have to enable both the
Updates repo and the Everything repo.
Maybe it would be nice to have a way to tell anaconda and/or yum which
repos depend on each other. E.g. something like "enable Everything
automatically when updates repo is enabled" in anaconda or "if you users
requests to grab a package from rpmfusion-nonfree-updates-testing then
look for deps in rpmfusion-free-updates-testing and updates-testing as
well, as rpmfusion-nonfree-updates-testing depends on those" in yum.
Should I file a RFE for anaconda and yum or are that corner casees we
just ignore?
CU
knurd
5:12 p.m.
On Sun, 2009-03-15 at 16:24 +0100, Thorsten Leemhuis wrote:
Should I file a RFE for anaconda and yum or are that corner casees we
just ignore?
I don't think it would be ignored, however its just hard to express that
in a distro agnostic way. Avoiding hardcoded hacks specifically for
Fedora is one of the goals of anaconda upstream.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:17 p.m.
I don't think it would be ignored, however its just hard to
express that
in a distro agnostic way. Avoiding hardcoded hacks specifically for
Fedora is one of the goals of anaconda upstream.
Perhaps Anaconda (or Yum?) should have a slight refactoring of the way
it handles repositories.
It could be able to flag a repository as a "subset" of another
repository (DVD <= Main), and one repository as dependent on another.
(Updates -> Main).
Then, enabling Updates should automatically enable Main. But since
Main is just a superset of DVD, yum (or Anaconda) know to use DVD
packages whenever present to cut the install time.
This could be yum logic (lot of refactoring there, upstream changes,
maybe a bad idea) or perhaps just logic on the Anaconda side at the
select-repository-screen. Anaconda could just handle the subset logic
itself using yum costs in a way to prefer the subset repository first.
7:14 p.m.
On Sun, 2009-03-15 at 11:17 -0500, Jud Craft wrote:
> I don't think it would be ignored, however its just hard to
express that
> in a distro agnostic way. Avoiding hardcoded hacks specifically for
> Fedora is one of the goals of anaconda upstream.
Perhaps Anaconda (or Yum?) should have a slight refactoring of the way
it handles repositories.
It could be able to flag a repository as a "subset" of another
repository (DVD <= Main), and one repository as dependent on another.
(Updates -> Main).
Then, enabling Updates should automatically enable Main. But since
Main is just a superset of DVD, yum (or Anaconda) know to use DVD
packages whenever present to cut the install time.
This could be yum logic (lot of refactoring there, upstream changes,
maybe a bad idea) or perhaps just logic on the Anaconda side at the
select-repository-screen. Anaconda could just handle the subset logic
itself using yum costs in a way to prefer the subset repository first.
I think yum would be the logical place to handle this, because as the
problem is described, you could potentially hit it another way.
Do a clean install of Fedora 10. Then enable the Updates repository but
not the Everything repository. Try to update. I would expect it will
fail, because libudev0 won't be available for the NetworkManager update.
It seems that, the way we handle updates in Fedora, the updates
repository more or less 'depends' on the Everything repository. This
should therefore be enforced in yum somehow, in a way that anaconda will
respect. That should solve the problem in future in all cases.
(In MDV, FWIW, when this situation occurs - an update introduces a
dependency that didn't exist before - the package for the new dependency
is added to the updates repository, even if it has not been updated).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:29 p.m.
Sounds good. I'm at least happy I know what went wrong at install.
On Mon, Mar 16, 2009 at 1:14 PM, Adam Williamson wrote:
It seems that, the way we handle updates in Fedora, the updates
repository more or less 'depends' on the Everything repository. This
should therefore be enforced in yum somehow, in a way that anaconda will
respect. That should solve the problem in future in all cases.
(In MDV, FWIW, when this situation occurs - an update introduces a
dependency that didn't exist before - the package for the new dependency
is added to the updates repository, even if it has not been updated).
4:33 p.m.
I think yum would be the logical place to handle this, because as
the
problem is described, you could potentially hit it another way.
Do a clean install of Fedora 10. Then enable the Updates repository but
not the Everything repository. Try to update. I would expect it will
fail, because libudev0 won't be available for the NetworkManager update.
It seems that, the way we handle updates in Fedora, the updates
repository more or less 'depends' on the Everything repository. This
should therefore be enforced in yum somehow, in a way that anaconda will
respect. That should solve the problem in future in all cases.
In anaconda, we just use the /etc/yum.repos.d files that the system (in
this case, the fedora-release package) provides. If a repo is marked as
enabled=1 in its config file, anaconda will enable the repo by default.
If the Everything repo defaulted to enabled, anaconda would pick this up
and when the user checked the Updates repo, we wouldn't hit this
problem. Of course, enabling Everything by default might come with its
own set of problems.
Alternatively, we could probably come up with some crazy set of repo
dependencies to handle this. I'd just like to make sure it's not hard
coded into anaconda.
- Chris
4:53 p.m.
On Tue, 2009-03-17 at 11:33 -0400, Chris Lumens wrote:
In anaconda, we just use the /etc/yum.repos.d files that the system (in
this case, the fedora-release package) provides. If a repo is marked as
enabled=1 in its config file, anaconda will enable the repo by default.
If the Everything repo defaulted to enabled, anaconda would pick this up
and when the user checked the Updates repo, we wouldn't hit this
problem. Of course, enabling Everything by default might come with its
own set of problems.
Alternatively, we could probably come up with some crazy set of repo
dependencies to handle this. I'd just like to make sure it's not hard
coded into anaconda.
Both the Everything and the Updates repos are enabled by default in the
config file. I seem to remember that this just makes them /visible/ in
the UI for checking, doesn't actually enable them in Anaconda itself,
due to as you say, a host of other problems associated with doing mixed
media + network installs. What we don't have is any sort of breadcrumb
that would alert things like anaconda that if the user checks on the
updates repo, that the everything repo should also be checked on.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:58 p.m.
What we don't have is any sort of breadcrumb
that would alert things like anaconda that if the user checks on the
updates repo, that the everything repo should also be checked on.
More generally, wouldn't this kind of repository dependency be needed
for yum as well ? Like on an already installed Fedora, one could
enable the updates repository and disable the Everything repository
(thinking you only need updates and not base releases of software,
which is obviously wrong).
So, if this could be made in yum, wouldn't it also fix the issue in Anaconda ?
----------
Mathieu Bridon (bochecha)
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." ~Benjamin Franklin
5:29 p.m.
On Tue, 2009-03-17 at 16:58 +0100, Mathieu Bridon (bochecha) wrote:
More generally, wouldn't this kind of repository dependency be
needed
for yum as well ? Like on an already installed Fedora, one could
enable the updates repository and disable the Everything repository
(thinking you only need updates and not base releases of software,
which is obviously wrong).
So, if this could be made in yum, wouldn't it also fix the issue in
Anaconda ?
Yes, you'd want it at the yum level.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:56 p.m.
More generally, wouldn't this kind of repository dependency be
needed
for yum as well ? Like on an already installed Fedora, one could
enable the updates repository and disable the Everything repository
(thinking you only need updates and not base releases of software,
which is obviously wrong).
So, if this could be made in yum, wouldn't it also fix the issue in Anaconda ?
Yes, and it seems to me like this could be better handled in a yum
plugin than adding this kind of weirdness straight into yum itself.'
- Chris
6:19 p.m.
On Tue, 2009-03-17 at 16:58 +0100, Mathieu Bridon (bochecha) wrote:
> What we don't have is any sort of breadcrumb
> that would alert things like anaconda that if the user checks on the
> updates repo, that the everything repo should also be checked on.
More generally, wouldn't this kind of repository dependency be needed
for yum as well ? Like on an already installed Fedora, one could
enable the updates repository and disable the Everything repository
(thinking you only need updates and not base releases of software,
which is obviously wrong).
So, if this could be made in yum, wouldn't it also fix the issue in Anaconda ?
That's exactly what I said three posts ago :D
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:18 p.m.
On Tue, 2009-03-17 at 11:33 -0400, Chris Lumens wrote:
> I think yum would be the logical place to handle this, because
as the
> problem is described, you could potentially hit it another way.
Alternatively, we could probably come up with some crazy set of repo
dependencies to handle this. I'd just like to make sure it's not hard
coded into anaconda.
Yep, that was my main point too: this isn't anaconda specific, so fixing
it in anaconda makes no sense.
Ironically, someone on test-list ran into exactly the scenario I
outlined - they had trouble updating an F10 system because 'updates' was
enabled but 'everything' was not - later that same day :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:39 p.m.
Jesse Keating <jkeating(a)redhat.com> writes:
On Sat, 2009-03-14 at 17:28 -0400, Jud Craft wrote:
> So at some point I suppose NetworkManager picked up a dependency on
> libudev0, but for some reason updating during the installation process
> doesn't pull this new package in.
This is likely because the updates repo isn't the Everything
repo. To
really do a proper install with updates you have to enable both the
Updates repo and the Everything repo.
So the real question is: why in heck did yum install an update of NM
that it knew it didn't have the dependencies for? I surmise that the
install process is using --nodeps, and that seems just plain stupid.
regards, tom lane
12:34 a.m.
Tom Lane wrote:
So the real question is: why in heck did yum install an update of NM
that it knew it didn't have the dependencies for? I surmise that the
install process is using --nodeps, and that seems just plain stupid.
The install process ignores dependencies it cannot satisfy because otherwise
you couldn't do an upgrade without added repositories.
Kevin Kofler
8:36 a.m.
Am Montag, den 16.03.2009, 00:34 +0100 schrieb Kevin Kofler:
Tom Lane wrote:
> So the real question is: why in heck did yum install an update of NM
> that it knew it didn't have the dependencies for? I surmise that the
> install process is using --nodeps, and that seems just plain stupid.
The install process ignores dependencies it cannot satisfy because otherwise
you couldn't do an upgrade without added repositories.
Kevin Kofler
So for the case of no added repositories, will repoclosure not catch
this? Is there a test for this?
10:25 a.m.
nodata wrote:
Am Montag, den 16.03.2009, 00:34 +0100 schrieb Kevin Kofler:
> Tom Lane wrote:
>> So the real question is: why in heck did yum install an update of NM
>> that it knew it didn't have the dependencies for? I surmise that the
>> install process is using --nodeps, and that seems just plain stupid.
> The install process ignores dependencies it cannot satisfy because otherwise
> you couldn't do an upgrade without added repositories.
>
> Kevin Kofler
>
So for the case of no added repositories, will repoclosure not catch
this? Is there a test for this?
The process of building the install images for the DVDs pulls in all
dependencies itself so it's not an issue for a fresh install from media;
in the case of the problem in this thread, there *was* an added repo
(updates).
Paul.
1:33 p.m.
Kevin Kofler <kevin.kofler(a)chello.at> writes:
Tom Lane wrote:
> So the real question is: why in heck did yum install an update of NM
> that it knew it didn't have the dependencies for? I surmise that the
> install process is using --nodeps, and that seems just plain stupid.
The install process ignores dependencies it cannot satisfy because
otherwise
you couldn't do an upgrade without added repositories.
I'm not following. Where is the use in allowing you to do a broken
upgrade? ISTM that in a situation like this it *should* fail until
you add on the needed additional repositories.
regards, tom lane
1:35 p.m.
On Mon, 16 Mar 2009, Tom Lane wrote:
Kevin Kofler <kevin.kofler(a)chello.at> writes:
> Tom Lane wrote:
>> So the real question is: why in heck did yum install an update of NM
>> that it knew it didn't have the dependencies for? I surmise that the
>> install process is using --nodeps, and that seems just plain stupid.
> The install process ignores dependencies it cannot satisfy because otherwise
> you couldn't do an upgrade without added repositories.
I'm not following. Where is the use in allowing you to do a broken
upgrade? ISTM that in a situation like this it *should* fail until
you add on the needed additional repositories.
Anaconda may be doing things differently but yum has no facility built-in
for ignoring deps.
-sv
2:25 p.m.
On 16/03/09 12:35, Seth Vidal wrote:
Anaconda may be doing things differently but yum has no facility
built-in for ignoring deps.
Which is probably good!
I do however make use of "skip broken" (ie add skip_broken=1 to
/etc/yum.conf).
At least allows upgrades where dependencies are met to continue even if
the odd fileset is failing with a missing dependency.
2:38 p.m.
On Monday, March 16 2009, Tom Lane said:
Kevin Kofler <kevin.kofler(a)chello.at> writes:
> Tom Lane wrote:
>> So the real question is: why in heck did yum install an update of NM
>> that it knew it didn't have the dependencies for? I surmise that the
>> install process is using --nodeps, and that seems just plain stupid.
> The install process ignores dependencies it cannot satisfy because otherwise
> you couldn't do an upgrade without added repositories.
I'm not following. Where is the use in allowing you to do a broken
upgrade? ISTM that in a situation like this it *should* fail until
you add on the needed additional repositories.
The use case is that it's far better to get someone installed and then
let them clean up afterwards than have to figure out some way to do
something in the installer. Especially as the installer's ability for
multiple repositories is, in the scheme of things, pretty recent and
broken dependencies have existed forever :-)
Jeremy
11:57 p.m.
Jeff Spaleta wrote:
[re: F10 Fresh Vanilla Install with Updates Has Broken
NetworkManager]
Can you give me more info please.
I can reproduce this problem. Which product should get the bugzilla report?
I did a fresh install using Fedora-10-i386-DVD, with these check boxes only
[which give Gnome desktop]:
Office + Productivity
Installation Repo
Fedora 10-i386-updates
I did a media check of my DVD as part of the install; it passed.
I saved all the files in /tmp at the end of install, plus of course
the installed root itself.
There is no NetworkManager icon in the top bar at first user login.
There is no NetworkManager process running.
"ldd /usr/sbin/NetworkManager" shows a dependency on libudev.so.0,
but there is no file libudev* anywhere in the installed system.
--
5:32 p.m.
On Sat, 2009-03-14 at 13:57 -0400, Tom Lane wrote:
"John J. McDonough" <wb8rcr(a)arrl.net> writes:
> I'm still not convinced NetworkManager is ready for prime time.
NM might be great for laptops, but it's both useless and pernicious in
a static-IP environment. In both F9 and F10 I've had to turn it off,
and the single most annoying thing about it is *you can't really turn
it off*. There are pieces of it that keep coming to life anyway ...
eg bz #455825 and the fact that it keeps demanding my VPN password
If NM is off, it's not going to touch your resolv.conf. Remember,
resolv.conf can change at any time when you do stuff like turn on your
VPN. The issue you had is no different than if you started the VPN and
your machine crashed. On reboot, you'd be left with a non-working
resolv.conf.
when I'm not using it to control the VPN.
Are you sure it's asking for your VPN password? Or is it actually
asking for your gnome-keyring password because the driver has failed to
connect to your wifi AP, which means either your password is wrong or
the driver sucks?
dan
2:45 a.m.
Dan Williams <dcbw(a)redhat.com> writes:
On Sat, 2009-03-14 at 13:57 -0400, Tom Lane wrote:
> NM might be great for laptops, but it's both useless and pernicious in
> a static-IP environment. In both F9 and F10 I've had to turn it off,
> and the single most annoying thing about it is *you can't really turn
> it off*. There are pieces of it that keep coming to life anyway ...
> eg bz #455825 and the fact that it keeps demanding my VPN password
If NM is off, it's not going to touch your resolv.conf.
That was what you told me at the time, ignoring the fact that it
nonetheless *was* overwriting resolv.conf. I do appreciate the fact
that that behavior went away in F-10, though.
> when I'm not using it to control the VPN.
Are you sure it's asking for your VPN password?
Quite; it says my "network credentials have expired", or words to that
effect (not at the machine right now) in a password popup dialog.
Today I got as far as determining that this seems to be coming from
nm-system-settings, which apparently is getting dbus events about
vpn start/stop and is convinced that that's its turf even though
the NetworkManager service is off. Unless I'm missing something,
there is no configuration knob provided to disable the dbus sniffer.
So I'm down to rpm -e NetworkManager, which I have now done and will
soon see if I still have a working system ...
regards, tom lane
3:02 a.m.
On Mon, 2009-03-16 at 21:45 -0400, Tom Lane wrote:
Quite; it says my "network credentials have expired",
That almost sounds like the kerberos auth dialog
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:44 a.m.
Jesse Keating <jkeating(a)redhat.com> writes:
On Mon, 2009-03-16 at 21:45 -0400, Tom Lane wrote:
> Quite; it says my "network credentials have expired",
That almost sounds like the kerberos auth dialog
Well, yeah, I think what it wants is my Kerberos password. Not that
I've tried it; I'm not going to type *any* password into a popup window
that appears without any clear connection to what I'm doing. Even
if this thing had any use to me, I'd refuse to use it because it
encourages phishing-susceptible habits.
regards, tom lane
2:51 p.m.
On Mon, 2009-03-16 at 22:44 -0400, Tom Lane wrote:
Jesse Keating <jkeating(a)redhat.com> writes:
> On Mon, 2009-03-16 at 21:45 -0400, Tom Lane wrote:
>> Quite; it says my "network credentials have expired",
> That almost sounds like the kerberos auth dialog
Well, yeah, I think what it wants is my Kerberos password. Not that
I've tried it; I'm not going to type *any* password into a popup window
that appears without any clear connection to what I'm doing. Even
if this thing had any use to me, I'd refuse to use it because it
encourages phishing-susceptible habits.
If it's the kerberos ticket expiration dialog, that's not NM.
Dan
5:40 p.m.
On Mon, Mar 16, 2009 at 10:44 PM, Tom Lane <tgl(a)redhat.com> wrote:
Jesse Keating <jkeating(a)redhat.com> writes:
> On Mon, 2009-03-16 at 21:45 -0400, Tom Lane wrote:
>> Quite; it says my "network credentials have expired",
> That almost sounds like the kerberos auth dialog
Well, yeah, I think what it wants is my Kerberos password. Not that
I've tried it; I'm not going to type *any* password into a popup window
that appears without any clear connection to what I'm doing. Even
if this thing had any use to me, I'd refuse to use it because it
encourages phishing-susceptible habits.
Yes, that sounds like krb5-auth-dialog, which is an independent package from NM.
We would definitely like the UI for it to be better. If you're
interested in improving the Kerberos experience for the desktop, there
is an active upstream who would likely respond to a bug report. I
could imagine e.g. having a libnotify popup pointing to the new tray
icon, rather than an out-of-the-blue dialog. That wouldn't be
significant amounts of work.
10:50 a.m.
On 2009-03-18, 16:40 GMT, Colin Walters wrote:
Yes, that sounds like krb5-auth-dialog, which is an independent
package from NM.
We would definitely like the UI for it to be better. If you're
interested in improving the Kerberos experience for the desktop, there
is an active upstream who would likely respond to a bug report. I
could imagine e.g. having a libnotify popup pointing to the new tray
icon, rather than an out-of-the-blue dialog. That wouldn't be
significant amounts of work.
Rawhide krb5-auth-dialog is much much better and it has
persistent icon in the status area (which shows your current
Kerberos status and warns you if it is going to expire) and it
can actually (sometimes, bug
https://bugzilla.redhat.com/show_bug.cgi?id=491580 has been filed
this morning) refresh your ticket.
Local rebuild of Rawhide packages for F10 are at
http://mcepl.fedorapeople.org/rpms/
Matěj
2:57 p.m.
On Mon, 2009-03-16 at 21:45 -0400, Tom Lane wrote:
Dan Williams <dcbw(a)redhat.com> writes:
> On Sat, 2009-03-14 at 13:57 -0400, Tom Lane wrote:
>> NM might be great for laptops, but it's both useless and pernicious in
>> a static-IP environment. In both F9 and F10 I've had to turn it off,
>> and the single most annoying thing about it is *you can't really turn
>> it off*. There are pieces of it that keep coming to life anyway ...
>> eg bz #455825 and the fact that it keeps demanding my VPN password
> If NM is off, it's not going to touch your resolv.conf.
That was what you told me at the time, ignoring the fact that it
nonetheless *was* overwriting resolv.conf. I do appreciate the fact
that that behavior went away in F-10, though.
Again, like I've explained before, if NM is not running, it *will not*
touch your resolv.conf. That's simply an impossibility. If the
NetworkManager process isn't running, it cannot touch your resolv.conf
file. Just like there aren't real-life zombies that eat your brains, NM
can't eat your resolv.conf when it's not running.
What you were complaining about was the behavior of NM to rewrite
resolv.conf when it *is* running. If you stop NM, then NM takes the
network connections down, and *of course* it's going to clear out your
resolv.conf, because you don't have any active network connections! (and
thus you can't talk to nameservers anyway) Thus, on reboot, you don't
have anything in /etc/resolv.conf. Unless you've re-enabled the
'network' serivce that is (which you probably should have done if you
wanted networking), at which point DHCP should re-populate resolv.conf
for you. If you use static IP, well, then you should have DNS1= and
DNS2= etc in your ifcfg files to keep your DNS information around in a
file that isn't modified by tons of stuff (including stuff other than
NM).
I don't know how many times I have to explain this. /etc/resolv.conf
*cannot* be the canonical source for DNS information, because so many
services (including ones other than NM) update resolv.conf. Even if you
don't run NM, if you've started some VPN and then your box crashes, you
won't have correct resolv.conf information when you reboot. Same sort
of thing with NM.
Dan
>> when I'm not using it to control the VPN.
> Are you sure it's asking for your VPN password?
Quite; it says my "network credentials have expired", or words to that
effect (not at the machine right now) in a password popup dialog.
Today I got as far as determining that this seems to be coming from
nm-system-settings, which apparently is getting dbus events about
vpn start/stop and is convinced that that's its turf even though
the NetworkManager service is off. Unless I'm missing something,
there is no configuration knob provided to disable the dbus sniffer.
So I'm down to rpm -e NetworkManager, which I have now done and will
soon see if I still have a working system ...
regards, tom lane
5:34 p.m.
On Sat, 2009-03-14 at 13:22 -0400, John J. McDonough wrote:
----- Original Message -----
From: "Jud Craft" <craftjml(a)gmail.com>
To: "Development discussions related to Fedora"
<fedora-devel-list(a)redhat.com>
Sent: Saturday, March 14, 2009 11:41 AM
Subject: Re: F10 Fresh Vanilla Install with Updates Has Broken
NetworkManager
> Unless he made extra copies of the Fedora install DVDs (and why would
> he? that defeats the point of a minimal image) he has *no other
> install media*. It's game over for him.
Well, it seems that since F9 most network problems can be solved by
sudo service NetworkManager stop
Of course, you have to know this, and it isn't QUITE that simple.
If you have problems with NetworkManager, please file them in bugzilla
(or add your input to an existing bug) or otherwise bring them to my
attention. Citing vague "network problems" doesn't really help anyone,
and certainly doesn't help improve NM.
Dan
7:23 p.m.
If you have problems with NetworkManager, please file them in
bugzilla
(or add your input to an existing bug) or otherwise bring them to my
attention. Citing vague "network problems" doesn't really help anyone,
and certainly doesn't help improve NM.
Dan
I apologize, but the problem was not a network one at all. The
problem was that the NetworkManager did not have dependencies
installed correctly, and turned out to be related to a peculiar
yum/Anaconda install scenario.
8:54 p.m.
On Mon, 2009-03-16 at 13:23 -0500, Jud Craft wrote:
> If you have problems with NetworkManager, please file them in
bugzilla
> (or add your input to an existing bug) or otherwise bring them to my
> attention. Citing vague "network problems" doesn't really help
anyone,
> and certainly doesn't help improve NM.
>
> Dan
I apologize, but the problem was not a network one at all. The
problem was that the NetworkManager did not have dependencies
installed correctly, and turned out to be related to a peculiar
yum/Anaconda install scenario.
Yeah, the reply wasn't really directed to you, but to John J. McDonough
instead. I'm interested in trying to fix issues he's had with NM, but
until I know what those are...
Dan
5551
days inactive
5560
days old
51 comments
20 participants
participants (20)
-
Adam Williamson -
Chris Lumens -
Colin Walters -
Dan Williams -
Jef Spaleta -
Jeremy Katz -
Jesse Keating -
John J. McDonough -
John Reiser -
Jud Craft -
Kevin Kofler -
Matej Cepl -
Mathieu Bridon -
nodata -
Orcan Ogetbil -
Paul Howarth -
planetf1 -
Seth Vidal -
Thorsten Leemhuis -
Tom Lane