2:04 p.m.
Ok, not looking before I lept I'm in deep again now having all the
open akmods bugs assigned to me! :)
I'll start reviewing them as I have time. Does anyone have suggestions
on which are the most serious? I'm thinking I should deal with the one
that causes systemctl to think akmods has failed (1813) first.
I'm sure I will run into issues I do not have enough experience to
solve on my own so I hope the usual people on this list will lend a
hand or advice.
Thanks,
Richard
4:32 p.m.
Le 22 sept. 2011 16:04, "Richard Shaw" <hobbes1069(a)gmail.com> a écrit :
Ok, not looking before I lept I'm in deep again now having all the
open akmods bugs assigned to me! :)
I'll start reviewing them as I have time. Does anyone have suggestions
on which are the most serious? I'm thinking I should deal with the one
that causes systemctl to think akmods has failed (1813) first.
I'm sure I will run into issues I do not have enough experience to
solve on my own so I hope the usual people on this list will lend a
hand or advice.
Thank you Richard to be volunteer to maintain akmods. I will try to provide
some lights as I've tought about some cases. But I've missed with
implementing the actual chznge as Im not a akmods users that much.
I know nucleo already suggested a unit systemd change. He might have
prepared something...
Nicolas (kwizart)
6:08 p.m.
On 09/22/2011 04:32 PM, Nicolas Chauvet wrote:
I know nucleo already suggested a unit systemd change. He might have
prepared something...
Well actually it was me that filed that file long way back
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1712
Nucleo for some reason added Before=prefdm.service and removed
RemainAfterExit line
I have had no problem with mine since I filed it.
JBG
6:58 p.m.
2011/9/22 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>:
On 09/22/2011 04:32 PM, Nicolas Chauvet wrote:
>
> I know nucleo already suggested a unit systemd change. He might have
> prepared something...
Well actually it was me that filed that file long way back
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1712
Nucleo for some reason added Before=prefdm.service and removed
RemainAfterExit line
I have had no problem with mine since I filed it.
I'm guessing here, but I assume the reason for "Before=prefdm.service"
is to make sure akmods runs prior to X coming up?
What does RemainAfterExit do?
Thanks,
Richard
4 a.m.
Richard Shaw wrote:
I'm guessing here, but I assume the reason for
"Before=prefdm.service"
is to make sure akmods runs prior to X coming up?
Even though I didn't write that line, I'm fairly sure that's what it is for.
Starting up X before your graphics driver finished compiling is not going to
work properly.
That said, the problem there is, this works for graphics drivers, but what
about akmods for wireless networking, for example? If you have systemwide
wireless connections set up in NetworkManager, you have to have the akmod
built before NetworkManager starts up. But if you only use akmods for a
graphics driver, or even for some obscure driver not needed at bootup at
all, your boot will block needlessly if NetworkManager waits for them.
The problem is, ordering constraints are highly dependent on what akmods
you're actually using.
Kevin Kofler
4:12 p.m.
On Thu, Sep 22, 2011 at 11:00 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Richard Shaw wrote:
> I'm guessing here, but I assume the reason for "Before=prefdm.service"
> is to make sure akmods runs prior to X coming up?
Even though I didn't write that line, I'm fairly sure that's what it is for.
Starting up X before your graphics driver finished compiling is not going to
work properly.
That said, the problem there is, this works for graphics drivers, but what
about akmods for wireless networking, for example? If you have systemwide
wireless connections set up in NetworkManager, you have to have the akmod
built before NetworkManager starts up. But if you only use akmods for a
graphics driver, or even for some obscure driver not needed at bootup at
all, your boot will block needlessly if NetworkManager waits for them.
The problem is, ordering constraints are highly dependent on what akmods
you're actually using.
Sounds like for the time being we need to go with the safest
(earliest) point for the time being. Does prefdm fit this requirement?
Thanks,
Richard
4:42 p.m.
On 09/23/2011 06:12 PM, Richard Shaw wrote:
On Thu, Sep 22, 2011 at 11:00 PM, Kevin
Kofler<kevin.kofler(a)chello.at> wrote:
> Richard Shaw wrote:
>> I'm guessing here, but I assume the reason for
"Before=prefdm.service"
>> is to make sure akmods runs prior to X coming up?
>
> Even though I didn't write that line, I'm fairly sure that's what it is
for.
> Starting up X before your graphics driver finished compiling is not going to
> work properly.
>
> That said, the problem there is, this works for graphics drivers, but what
> about akmods for wireless networking, for example? If you have systemwide
> wireless connections set up in NetworkManager, you have to have the akmod
> built before NetworkManager starts up. But if you only use akmods for a
> graphics driver, or even for some obscure driver not needed at bootup at
> all, your boot will block needlessly if NetworkManager waits for them.
>
> The problem is, ordering constraints are highly dependent on what akmods
> you're actually using.
Sounds like for the time being we need to go with the safest
(earliest) point for the time being.
Right.
Does prefdm fit this requirement?
I'd say no, Prefdm is one
of the latest services being started.
It may suffice the graphics driver case, it's very likely much too late
for other modules, because services before prefdm will require activated
kmods to be able to start up properly (printer drivers. network drivers
(consider ldap/nis-based authentication, nfs-based-autofs etc.)
Openly said, I doubt there is any suitable point :-)
Ralf
5:28 p.m.
On Fri, Sep 23, 2011 at 11:42 AM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
>
>
> Sounds like for the time being we need to go with the safest
> (earliest) point for the time being.
Right.
> Does prefdm fit this requirement?
I'd say no, Prefdm is one of the latest services being started.
It may suffice the graphics driver case, it's very likely much too late for
other modules, because services before prefdm will require activated kmods
to be able to start up properly (printer drivers. network drivers (consider
ldap/nis-based authentication, nfs-based-autofs etc.)
I might see if I can get Lennart to chime in on this problem. I can
think of a couple of ways to solve this dilemma but they're dependent
on what exactly systemd can handle.
What we need is some way for an akmod package to tell systemd when it
needs to run and have systemd understand that it should run on the
earliest requirement of all installed akmod packages and ignore the
rest.
Richard
4:55 p.m.
On Thu, 2011-09-22 at 09:04 -0500, Richard Shaw wrote:
Ok, not looking before I lept I'm in deep again now having all
the
open akmods bugs assigned to me! :)
I'll start reviewing them as I have time. Does anyone have suggestions
on which are the most serious? I'm thinking I should deal with the one
that causes systemctl to think akmods has failed (1813) first.
I'm sure I will run into issues I do not have enough experience
to
solve on my own so I hope the usual people on this list will lend a
hand or advice.
I think this email got some useful info:
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2011-September/...
seems only needs change the "128" to "0"
Thanks,
Richard
--
Sérgio M. B.
4809
days inactive
4810
days old
rpmfusion-developers@lists.rpmfusion.org
9 comments
6 participants
participants (6)
-
"Jóhann B. Guðmundsson" -
Kevin Kofler -
Nicolas Chauvet -
Ralf Corsepius -
Richard Shaw -
Sérgio Basto