1:22 a.m.
I've recently set up a virtual machine running rawhide and I've noticed
that NetworkManager never seems to start on boot; I must always start it
manually. As far as I can tell, it is configured to start on boot. Is
there something about the virtual machine context that would trigger
this?
--
Braden McDaniel <braden(a)endoframe.com>
3:04 p.m.
There seems to be an SElinux denial for me which stops it from starting (I
upgraded from Fedora 14 and its NOT a live machine).
I would assume its the same error?
On 31 January 2011 07:22, Braden McDaniel <braden(a)endoframe.com> wrote:
I've recently set up a virtual machine running rawhide and
I've noticed
that NetworkManager never seems to start on boot; I must always start it
manually. As far as I can tell, it is configured to start on boot. Is
there something about the virtual machine context that would trigger
this?
--
Braden McDaniel <braden(a)endoframe.com>
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
10:16 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/31/2011 04:04 PM, Naheem Zaffar wrote:
There seems to be an SElinux denial for me which stops it from
starting
(I upgraded from Fedora 14 and its NOT a live machine).
I would assume its the same error?
On 31 January 2011 07:22, Braden McDaniel <braden(a)endoframe.com
<mailto:braden@endoframe.com>> wrote:
I've recently set up a virtual machine running rawhide and I've noticed
that NetworkManager never seems to start on boot; I must always start it
manually. As far as I can tell, it is configured to start on boot. Is
there something about the virtual machine context that would trigger
this?
--
Braden McDaniel <braden(a)endoframe.com <mailto:braden@endoframe.com>>
--
devel mailing list
devel(a)lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/devel
Could you attach the AVC?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1IMdQACgkQrlYvE4MpobMJKACfcN3xMOrlUTablIoGgdGIyjGa
fC8AnjmSLBzqT8SwEX3XJMDM/EFFxVPM
=Twyw
-----END PGP SIGNATURE-----
4:05 p.m.
On 1/31/11 4:04 PM, Naheem Zaffar wrote:
There seems to be an SElinux denial for me which stops it from
starting
(I upgraded from Fedora 14 and its NOT a live machine).
I would assume its the same error?
So far, I have not identified an SELinux denial that appears to be
associated with this. But I'll keep looking.
Braden
5:02 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/01/2011 05:05 PM, Braden McDaniel wrote:
On 1/31/11 4:04 PM, Naheem Zaffar wrote:
> There seems to be an SElinux denial for me which stops it from starting
> (I upgraded from Fedora 14 and its NOT a live machine).
>
> I would assume its the same error?
So far, I have not identified an SELinux denial that appears to be
associated with this. But I'll keep looking.
Braden
ausearch -m avc -ts today
Does it work in permissive mode? If not then why do you think this is
an SELinux issue?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1IkSIACgkQrlYvE4MpobM4dgCfUm1qPIf0eO/7TicnZDkNizeO
e+MAoL+m56WYtGcAJAT1b25kbSD5zgMr
=qZ+4
-----END PGP SIGNATURE-----
12:33 p.m.
On Mon, 2011-01-31 at 02:22 -0500, Braden McDaniel wrote:
I've recently set up a virtual machine running rawhide and
I've noticed
that NetworkManager never seems to start on boot; I must always start it
manually. As far as I can tell, it is configured to start on boot. Is
there something about the virtual machine context that would trigger
this?
Rawhide? F14? There is a known issue in Rawhide with systemd that
hasn't been tracked down yet, but it should be working in F13/F14 as
long as NM is enabled in "chkconfig".
Dan
1:03 p.m.
On 2/3/11 1:33 PM, Dan Williams wrote:
On Mon, 2011-01-31 at 02:22 -0500, Braden McDaniel wrote:
> I've recently set up a virtual machine running rawhide and I've noticed
> that NetworkManager never seems to start on boot; I must always start it
> manually. As far as I can tell, it is configured to start on boot. Is
> there something about the virtual machine context that would trigger
> this?
Rawhide? F14?
"I've recently set up a virtual machine running rawhide...."
There is a known issue in Rawhide with systemd that
hasn't been tracked down yet, but it should be working in F13/F14 as
long as NM is enabled in "chkconfig".
Indeed, I have not observed the issue on F14.
Braden
1:07 p.m.
On 2/1/11 6:02 PM, Daniel J Walsh wrote:
On 02/01/2011 05:05 PM, Braden McDaniel wrote:
> On 1/31/11 4:04 PM, Naheem Zaffar wrote:
>> There seems to be an SElinux denial for me which stops it from starting
>> (I upgraded from Fedora 14 and its NOT a live machine).
>>
>> I would assume its the same error?
>
> So far, I have not identified an SELinux denial that appears to be
> associated with this. But I'll keep looking.
>
> Braden
ausearch -m avc -ts today
Does it work in permissive mode? If not then why do you think this is
an SELinux issue?
I never said I did; it was just an avenue of investigation that was
suggested here.
Based on others' comments (and the fact that I haven't found anything
corroborating), it looks like a dead end.
Braden
2:12 p.m.
On Mon, 31.01.11 02:22, Braden McDaniel (braden(a)endoframe.com) wrote:
I've recently set up a virtual machine running rawhide and
I've noticed
that NetworkManager never seems to start on boot; I must always start it
manually. As far as I can tell, it is configured to start on boot. Is
there something about the virtual machine context that would trigger
this?
what does "systemctl status NetworkManager.service" say?
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:54 a.m.
On 01/31/2011 08:22 AM, Braden McDaniel wrote:
I've recently set up a virtual machine running rawhide and
I've noticed
that NetworkManager never seems to start on boot; I must always start it
manually. As far as I can tell, it is configured to start on boot. Is
there something about the virtual machine context that would trigger
this?
I had similar problem when NetworkManager worked only when I reinstalled
it and after a while it stopped working again saying something like:
"can't get capabilities" which turned out to be a problem with prelink
which is solved in prelink-0.4.4-1.fc15.x86_64.
Hope this helps,
Jirka
12:31 p.m.
On Thu, 2011-02-03 at 21:12 +0100, Lennart Poettering wrote:
On Mon, 31.01.11 02:22, Braden McDaniel (braden(a)endoframe.com)
wrote:
> I've recently set up a virtual machine running rawhide and I've noticed
> that NetworkManager never seems to start on boot; I must always start it
> manually. As far as I can tell, it is configured to start on boot. Is
> there something about the virtual machine context that would trigger
> this?
what does "systemctl status NetworkManager.service" say?
After booting and logging in as root:
# systemctl status NetworkManager.service
NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service)
Active: inactive (dead)
CGroup: name=systemd:/system/NetworkManager.service
--
Braden McDaniel <braden(a)endoframe.com>
2:16 a.m.
On Fri, 04.02.11 13:31, Braden McDaniel (braden(a)endoframe.com) wrote:
On Thu, 2011-02-03 at 21:12 +0100, Lennart Poettering wrote:
> On Mon, 31.01.11 02:22, Braden McDaniel (braden(a)endoframe.com) wrote:
>
> > I've recently set up a virtual machine running rawhide and I've
noticed
> > that NetworkManager never seems to start on boot; I must always start it
> > manually. As far as I can tell, it is configured to start on boot. Is
> > there something about the virtual machine context that would trigger
> > this?
>
> what does "systemctl status NetworkManager.service" say?
After booting and logging in as root:
# systemctl status NetworkManager.service
NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service)
Active: inactive (dead)
CGroup: name=systemd:/system/NetworkManager.service
Hmm, is it even enabled? Try "systemctl is-enabled NetworkManager.service ; echo
$?" ?
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:44 a.m.
On Tue, 2011-02-08 at 09:16 +0100, Lennart Poettering wrote:
On Fri, 04.02.11 13:31, Braden McDaniel (braden(a)endoframe.com)
wrote:
>
> On Thu, 2011-02-03 at 21:12 +0100, Lennart Poettering wrote:
> > On Mon, 31.01.11 02:22, Braden McDaniel (braden(a)endoframe.com) wrote:
> >
> > > I've recently set up a virtual machine running rawhide and I've
noticed
> > > that NetworkManager never seems to start on boot; I must always start it
> > > manually. As far as I can tell, it is configured to start on boot. Is
> > > there something about the virtual machine context that would trigger
> > > this?
> >
> > what does "systemctl status NetworkManager.service" say?
>
> After booting and logging in as root:
>
> # systemctl status NetworkManager.service
> NetworkManager.service - Network Manager
> Loaded: loaded (/lib/systemd/system/NetworkManager.service)
> Active: inactive (dead)
> CGroup: name=systemd:/system/NetworkManager.service
>
Hmm, is it even enabled? Try "systemctl is-enabled NetworkManager.service ; echo
$?" ?
# systemctl is-enabled NetworkManager.service ; echo $?
1
I'm not sure whether "1" means it is or it isn't; but
system-config-services claims it's enabled.
--
Braden McDaniel <braden(a)endoframe.com>
4:04 a.m.
On Tue, 08.02.11 04:44, Braden McDaniel (braden(a)endoframe.com) wrote:
> > > what does "systemctl status
NetworkManager.service" say?
> >
> > After booting and logging in as root:
> >
> > # systemctl status NetworkManager.service
> > NetworkManager.service - Network Manager
> > Loaded: loaded (/lib/systemd/system/NetworkManager.service)
> > Active: inactive (dead)
> > CGroup: name=systemd:/system/NetworkManager.service
> >
>
> Hmm, is it even enabled? Try "systemctl is-enabled NetworkManager.service ;
echo $?" ?
# systemctl is-enabled NetworkManager.service ; echo $?
1
So, it isn't enabled. A zero exit code means it is enabled, a non-zero
exit code means it isn't. (that's normal unix logic, even if it appears
reversed)
Try enabling it via "systemctl enable NetworkManager.service"
Not sure what went wrong here, but normally this fragment in
Networkmanager.spec should ensure that the systemd service gets enabled
on upgrades from sysv versions:
%triggerin -- NetworkManager < 1:0.8.1-5
if /sbin/chkconfig NetworkManager ; then
/bin/systemctl enable NetworkManager.service >/dev/null 2>&1 || :
fi
or is this a fresh install? if so, I am not entirely sure whose job it
is to enable NM initially after install. Dan?
I'm not sure whether "1" means it is or it isn't;
but
system-config-services claims it's enabled.
s-c-s only covers sysv services. We probably should deprecate it or at
least add a bit of code to point out that whether a service is on or off
in sysv is ignored for native systemd services.
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:18 a.m.
On Tue, 2011-02-08 at 11:04 +0100, Lennart Poettering wrote:
On Tue, 08.02.11 04:44, Braden McDaniel (braden(a)endoframe.com) wrote:
> I'm not sure whether "1" means it is or it
isn't; but
> system-config-services claims it's enabled.
s-c-s only covers sysv services. We probably should deprecate it or at
least add a bit of code to point out that whether a service is on or off
in sysv is ignored for native systemd services.
What utility are you recommending to replace it?
Jon.
4:27 a.m.
On Tue, 08.02.11 05:18, Jon Masters (jonathan(a)jonmasters.org) wrote:
On Tue, 2011-02-08 at 11:04 +0100, Lennart Poettering wrote:
> On Tue, 08.02.11 04:44, Braden McDaniel (braden(a)endoframe.com) wrote:
> > I'm not sure whether "1" means it is or it isn't; but
> > system-config-services claims it's enabled.
>
> s-c-s only covers sysv services. We probably should deprecate it or at
> least add a bit of code to point out that whether a service is on or off
> in sysv is ignored for native systemd services.
What utility are you recommending to replace it?
Well, systemadm does some of this stuff, but doesn't really do
enabling/disabling of services, and also needs some love.
I guess my answer is to use "systemctl enable foo.service" and
"systemctl disable foo.service" until somebody comes up with an UI for
this (if one is actually needed).
Lennart
--
Lennart Poettering - Red Hat, Inc.
9:39 a.m.
On Tue, 2011-02-08 at 11:04 +0100, Lennart Poettering wrote:
On Tue, 08.02.11 04:44, Braden McDaniel (braden(a)endoframe.com)
wrote:
> > > > what does "systemctl status NetworkManager.service" say?
> > >
> > > After booting and logging in as root:
> > >
> > > # systemctl status NetworkManager.service
> > > NetworkManager.service - Network Manager
> > > Loaded: loaded
(/lib/systemd/system/NetworkManager.service)
> > > Active: inactive (dead)
> > > CGroup: name=systemd:/system/NetworkManager.service
> > >
> >
> > Hmm, is it even enabled? Try "systemctl is-enabled NetworkManager.service
; echo $?" ?
>
> # systemctl is-enabled NetworkManager.service ; echo $?
> 1
So, it isn't enabled. A zero exit code means it is enabled, a non-zero
exit code means it isn't. (that's normal unix logic, even if it appears
reversed)
Try enabling it via "systemctl enable NetworkManager.service"
Not sure what went wrong here, but normally this fragment in
Networkmanager.spec should ensure that the systemd service gets enabled
on upgrades from sysv versions:
%triggerin -- NetworkManager < 1:0.8.1-5
if /sbin/chkconfig NetworkManager ; then
/bin/systemctl enable NetworkManager.service >/dev/null 2>&1 || :
fi
or is this a fresh install? if so, I am not entirely sure whose job it
is to enable NM initially after install. Dan?
I installed F14 from DVD and immediately did a yum upgrade to rawhide.
> I'm not sure whether "1" means it is or it
isn't; but
> system-config-services claims it's enabled.
s-c-s only covers sysv services. We probably should deprecate it or at
least add a bit of code to point out that whether a service is on or off
in sysv is ignored for native systemd services.
Why not fix it? That is, why should a user of this app care whether a
service is SysV or systemd? Or, is this app being replaced by some
other UI?
--
Braden McDaniel <braden(a)endoframe.com>
9:56 a.m.
On 02/08/2011 09:09 PM, Braden McDaniel wrote:
Why not fix it? That is, why should a user of this app care whether a
service is SysV or systemd? Or, is this app being replaced by some
other UI?
Also is there a plan to modify chkconfig in a similar way to service so
that it calls systemctl if it is a systemd service? That would make the
transition less abrupt
Rahul
11:06 a.m.
On Tue, 2011-02-08 at 11:27 +0100, Lennart Poettering wrote:
On Tue, 08.02.11 05:18, Jon Masters (jonathan(a)jonmasters.org) wrote:
>
> On Tue, 2011-02-08 at 11:04 +0100, Lennart Poettering wrote:
> > On Tue, 08.02.11 04:44, Braden McDaniel (braden(a)endoframe.com) wrote:
>
> > > I'm not sure whether "1" means it is or it isn't; but
> > > system-config-services claims it's enabled.
> >
> > s-c-s only covers sysv services. We probably should deprecate it or at
> > least add a bit of code to point out that whether a service is on or off
> > in sysv is ignored for native systemd services.
>
> What utility are you recommending to replace it?
Well, systemadm does some of this stuff, but doesn't really do
enabling/disabling of services, and also needs some love.
I guess my answer is to use "systemctl enable foo.service" and
"systemctl disable foo.service" until somebody comes up with an UI for
this (if one is actually needed).
My point is that if there's a GUI config tool today, there should be one
tomorrow. Even when in curses, it's nice for some users after install to
be able to configure this stuff with a menu. And none of those users who
want a config tool are going to care that upstart was replaced, etc.
Jon.
11:21 a.m.
On Tue, 2011-02-08 at 21:26 +0530, Rahul Sundaram wrote:
On 02/08/2011 09:09 PM, Braden McDaniel wrote:
>
> Why not fix it? That is, why should a user of this app care whether a
> service is SysV or systemd? Or, is this app being replaced by some
> other UI?
Also is there a plan to modify chkconfig in a similar way to service so
that it calls systemctl if it is a systemd service? That would make the
transition less abrupt
Funnily enough, I think that avahi was not fixed to use the new tool.
11:50 a.m.
On Tue, 08.02.11 10:39, Braden McDaniel (braden(a)endoframe.com) wrote:
> Try enabling it via "systemctl enable
NetworkManager.service"
>
> Not sure what went wrong here, but normally this fragment in
> Networkmanager.spec should ensure that the systemd service gets enabled
> on upgrades from sysv versions:
>
> %triggerin -- NetworkManager < 1:0.8.1-5
> if /sbin/chkconfig NetworkManager ; then
> /bin/systemctl enable NetworkManager.service >/dev/null 2>&1 || :
> fi
>
> or is this a fresh install? if so, I am not entirely sure whose job it
> is to enable NM initially after install. Dan?
I installed F14 from DVD and immediately did a yum upgrade to rawhide.
That's weird then. I am not sure how this could fail...
> > I'm not sure whether "1" means it is or it
isn't; but
> > system-config-services claims it's enabled.
>
> s-c-s only covers sysv services. We probably should deprecate it or at
> least add a bit of code to point out that whether a service is on or off
> in sysv is ignored for native systemd services.
Why not fix it? That is, why should a user of this app care whether a
service is SysV or systemd? Or, is this app being replaced by some
other UI?
Well, the UI makes a couple of assumptions (i.e. runlevel stuff) that
doesn't really apply to systemd, but sure it could be updated.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:52 a.m.
On Tue, 08.02.11 21:26, Rahul Sundaram (metherid(a)gmail.com) wrote:
On 02/08/2011 09:09 PM, Braden McDaniel wrote:
>
> Why not fix it? That is, why should a user of this app care whether a
> service is SysV or systemd? Or, is this app being replaced by some
> other UI?
Also is there a plan to modify chkconfig in a similar way to service so
that it calls systemctl if it is a systemd service? That would make the
transition less abrupt
here's already the glue code to forward "systemctl enable" to
"chkconfig
on" if a native service is not found but a sysv one is. The other way
round is still on my todo list. If somebody else wants to do this work
I'd be very happy though.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:52 a.m.
On Tue, 08.02.11 17:21, Bastien Nocera (bnocera(a)redhat.com) wrote:
On Tue, 2011-02-08 at 21:26 +0530, Rahul Sundaram wrote:
> On 02/08/2011 09:09 PM, Braden McDaniel wrote:
> >
> > Why not fix it? That is, why should a user of this app care whether a
> > service is SysV or systemd? Or, is this app being replaced by some
> > other UI?
>
> Also is there a plan to modify chkconfig in a similar way to service so
> that it calls systemctl if it is a systemd service? That would make the
> transition less abrupt
Funnily enough, I think that avahi was not fixed to use the new tool.
it does:
%triggerun -- avahi < 0.6.26-1
if /sbin/chkconfig avahi-daemon ; then
/bin/systemctl enable avahi-daemon.service >/dev/null 2>&1 || :
fi
it's all there.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:31 p.m.
On Tue, Feb 08, 2011 at 11:04:41AM +0100, Lennart Poettering wrote:
> > Hmm, is it even enabled? Try "systemctl is-enabled
NetworkManager.service ; echo $?" ?
> # systemctl is-enabled NetworkManager.service ; echo $?
> 1
So, it isn't enabled. A zero exit code means it is enabled, a non-zero
exit code means it isn't. (that's normal unix logic, even if it appears
reversed)
For that reason, a better command to give people might be:;
systemctl is-enabled NetworkManager.service && echo yes
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
12:14 a.m.
On Tue, 2011-02-08 at 18:50 +0100, Lennart Poettering wrote:
On Tue, 08.02.11 10:39, Braden McDaniel (braden(a)endoframe.com)
wrote:
> > Try enabling it via "systemctl enable NetworkManager.service"
> >
> > Not sure what went wrong here, but normally this fragment in
> > Networkmanager.spec should ensure that the systemd service gets enabled
> > on upgrades from sysv versions:
> >
> > %triggerin -- NetworkManager < 1:0.8.1-5
> > if /sbin/chkconfig NetworkManager ; then
> > /bin/systemctl enable NetworkManager.service >/dev/null 2>&1
|| :
> > fi
> >
> > or is this a fresh install? if so, I am not entirely sure whose job it
> > is to enable NM initially after install. Dan?
>
> I installed F14 from DVD and immediately did a yum upgrade to rawhide.
That's weird then. I am not sure how this could fail...
Are the deps set up so that we can be sure systemctl is actually enabled
when NetworkManager gets updated? i.e. does NM have a Requires(post):
systemctl (or whatever the package is called)? If not, the script might
well fail because systemctl isn't there.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4811
days inactive
4827
days old
24 comments
11 participants
participants (11)
-
Adam Williamson -
Bastien Nocera -
Braden McDaniel -
Dan Williams -
Daniel J Walsh -
Jiri Moskovcak -
Jon Masters -
Lennart Poettering -
Matthew Miller -
Naheem Zaffar -
Rahul Sundaram