[gentoo-user] udev update

[gentoo-user] udev update

[Francisco Ares]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

Hi,

Checking the news (eselect news read), I see that an upgrade to udev-217
might break firmware loading, so the news tagged "2014-11-07-udev-upgrade"
says that a kernel >= 3.7 should be configured to:

CONFIG_FW_LOADER_USER_HELPER=n

Is it that simple?  Trying a new kernel build using "menuconfig", it says
that CONFIG_FW_LOADER_USER_HELPER depends on CONFIG_FW_LOADER, and this one
depends on a huge list of other configuration elements.

Any thoughts?

Thanks,
Francisco

[-- Attachment #2: Type: text/html, Size: 659 bytes --]

Re: [gentoo-user] udev update

[Tanstaafl]

On 11/10/2014 8:21 AM, Francisco Ares <frares@gmail.com> wrote:
> Checking the news (eselect news read), I see that an upgrade to udev-217
> might break firmware loading, so the news tagged
> "2014-11-07-udev-upgrade" says that a kernel >= 3.7 should be configured to:
> 
> CONFIG_FW_LOADER_USER_HELPER=n
> 
> Is it that simple?  Trying a new kernel build using "menuconfig", it
> says that CONFIG_FW_LOADER_USER_HELPER depends on CONFIG_FW_LOADER, and
> this one depends on a huge list of other configuration elements.
> 
> Any thoughts?

Ueah... UGH... thanks Lennart/systemd devs for yet another thing to have
to worry about...

Re: [gentoo-user] udev update

[Rich Freeman]

On Mon, Nov 10, 2014 at 9:20 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 11/10/2014 8:21 AM, Francisco Ares <frares@gmail.com> wrote:
>> Checking the news (eselect news read), I see that an upgrade to udev-217
>> might break firmware loading, so the news tagged
>> "2014-11-07-udev-upgrade" says that a kernel >= 3.7 should be configured to:
>>
>> CONFIG_FW_LOADER_USER_HELPER=n
>>
>> Is it that simple?  Trying a new kernel build using "menuconfig", it
>> says that CONFIG_FW_LOADER_USER_HELPER depends on CONFIG_FW_LOADER, and
>> this one depends on a huge list of other configuration elements.
>>
>> Any thoughts?
>
> Ueah... UGH... thanks Lennart/systemd devs for yet another thing to have
> to worry about...
>

From the kernel config instructions (something not written by the systemd devs):
This option enables / disables the invocation of user-helper
(e.g. udev) for loading firmware files as a fallback after the
direct file loading in kernel fails. The user-mode helper is
no longer required unless you have a special firmware file that
resides in a non-standard path. Moreover, the udev support has
been deprecated upstream.

Announcing a feature as deprecated and later dropping it is hardly
controversial.  You chose a distro that gives you a choice of things
like your udev implementation and your kernel implementation (or using
udev at all), and as a result you get to deal with the fact that some
versions of the one have constraints on how you use the other.  If you
ran a distro like Ubuntu you wouldn't have to worry about any of this,
as you'd use the udev they gave you and the precompiled kernel they
gave you and the world's greatest desktop environment and you'd be
happy with it.  Anybody who has run Gentoo for a long time knows that
from time to time some change comes along and you'll just have to deal
with it - you can't just ignore things like firmware-loading on Gentoo
the way you can with some other distros.

Of course, nothing prevents anybody from creating a preconfigured
kernel for Gentoo.  There is genkernel of course, though I think we
probably could do better.  Most seem to be happy just managing their
own kernel configurations, and I think that is why nobody has bothered
to spend much time perfecting a canned kernel.

Going back to the original question, yes - it is that simple.
Dependencies are just dependencies - you only have to worry about them
when you turn things ON.

--
Rich

Re: [gentoo-user] udev update

[Francisco Ares]

[-- Attachment #1: Type: text/plain, Size: 2873 bytes --]

2014-11-10 12:37 GMT-02:00 Rich Freeman <rich0@gentoo.org>:

> On Mon, Nov 10, 2014 at 9:20 AM, Tanstaafl <tanstaafl@libertytrek.org>
> wrote:
> > On 11/10/2014 8:21 AM, Francisco Ares <frares@gmail.com> wrote:
> >> Checking the news (eselect news read), I see that an upgrade to udev-217
> >> might break firmware loading, so the news tagged
> >> "2014-11-07-udev-upgrade" says that a kernel >= 3.7 should be
> configured to:
> >>
> >> CONFIG_FW_LOADER_USER_HELPER=n
> >>
> >> Is it that simple?  Trying a new kernel build using "menuconfig", it
> >> says that CONFIG_FW_LOADER_USER_HELPER depends on CONFIG_FW_LOADER, and
> >> this one depends on a huge list of other configuration elements.
> >>
> >> Any thoughts?
> >
> > Ueah... UGH... thanks Lennart/systemd devs for yet another thing to have
> > to worry about...
> >
>
> From the kernel config instructions (something not written by the systemd
> devs):
> This option enables / disables the invocation of user-helper
> (e.g. udev) for loading firmware files as a fallback after the
> direct file loading in kernel fails. The user-mode helper is
> no longer required unless you have a special firmware file that
> resides in a non-standard path. Moreover, the udev support has
> been deprecated upstream.
>
> Announcing a feature as deprecated and later dropping it is hardly
> controversial.  You chose a distro that gives you a choice of things
> like your udev implementation and your kernel implementation (or using
> udev at all), and as a result you get to deal with the fact that some
> versions of the one have constraints on how you use the other.  If you
> ran a distro like Ubuntu you wouldn't have to worry about any of this,
> as you'd use the udev they gave you and the precompiled kernel they
> gave you and the world's greatest desktop environment and you'd be
> happy with it.  Anybody who has run Gentoo for a long time knows that
> from time to time some change comes along and you'll just have to deal
> with it - you can't just ignore things like firmware-loading on Gentoo
> the way you can with some other distros.
>
> Of course, nothing prevents anybody from creating a preconfigured
> kernel for Gentoo.  There is genkernel of course, though I think we
> probably could do better.  Most seem to be happy just managing their
> own kernel configurations, and I think that is why nobody has bothered
> to spend much time perfecting a canned kernel.
>
> Going back to the original question, yes - it is that simple.
> Dependencies are just dependencies - you only have to worry about them
> when you turn things ON.
>
> --
> Rich
>
>

Ok, I will try.

So, if I understood something, I will probably have to check this
configuration entry every time I build a new kernel from now on, because
"menuconfig" will probably set this on because of its dependencies, is this
correct?

Thanks!
Francisco

[-- Attachment #2: Type: text/html, Size: 3808 bytes --]

Re: [gentoo-user] udev update

[Rich Freeman]

On Mon, Nov 10, 2014 at 10:18 AM, Francisco Ares <frares@gmail.com> wrote:
>
> So, if I understood something, I will probably have to check this
> configuration entry every time I build a new kernel from now on, because
> "menuconfig" will probably set this on because of its dependencies, is this
> correct?
>

That depends on how you configure your kernels.  If you start from
your last kernel config then the setting won't change.  If you create
a new config every time, then it depends on how you're creating it.

Dependencies never cause something to be turned on or off.  You have
that a bit backwards conceptually.  KDE depends on glibc, which means
you can't install KDE if you don't have glibc present. That doesn't
mean that it is impossible to build a system which contains glibc and
not KDE.

Now, if you were talking about reverse-deps that would be another
matter.  The kernel config tools won't let you disable a setting which
is a dependency of another setting, though I believe they generally
don't automatically turn things on either.  Dependency-management in
the kernel is fairly primitive in general - it does a somewhat-decent
job of not letting you shoot yourself in the foot, as long as you
don't go manually editing .config files, but it can be a bit of a pain
turning on things that are missing dependencies.  It definitely isn't
targeted at the "end user."

--
Rich

Re: [gentoo-user] udev update

[Francisco Ares]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

2014-11-10 13:42 GMT-02:00 Rich Freeman <rich0@gentoo.org>:

> On Mon, Nov 10, 2014 at 10:18 AM, Francisco Ares <frares@gmail.com> wrote:
> >
> > So, if I understood something, I will probably have to check this
> > configuration entry every time I build a new kernel from now on, because
> > "menuconfig" will probably set this on because of its dependencies, is
> this
> > correct?
> >
>
> That depends on how you configure your kernels.  If you start from
> your last kernel config then the setting won't change.  If you create
> a new config every time, then it depends on how you're creating it.
>
> Dependencies never cause something to be turned on or off.  You have
> that a bit backwards conceptually.  KDE depends on glibc, which means
> you can't install KDE if you don't have glibc present. That doesn't
> mean that it is impossible to build a system which contains glibc and
> not KDE.
>
> Now, if you were talking about reverse-deps that would be another
> matter.  The kernel config tools won't let you disable a setting which
> is a dependency of another setting, though I believe they generally
> don't automatically turn things on either.  Dependency-management in
> the kernel is fairly primitive in general - it does a somewhat-decent
> job of not letting you shoot yourself in the foot, as long as you
> don't go manually editing .config files, but it can be a bit of a pain
> turning on things that are missing dependencies.  It definitely isn't
> targeted at the "end user."
>
> --
> Rich
>
>

I guess that last statement includes "genkernel" users.

Thanks,
Francisco

[-- Attachment #2: Type: text/html, Size: 2294 bytes --]

[gentoo-user] Re: udev update

[James]

Rich Freeman <rich0 <at> gentoo.org> writes:


> Of course, nothing prevents anybody from creating a preconfigured
> kernel for Gentoo.  There is genkernel of course, though I think we
> probably could do better.  Most seem to be happy just managing their
> own kernel configurations, and I think that is why nobody has bothered
> to spend much time perfecting a canned kernel.

> Rich

https://github.com/canek-pelaez/kerninst

Although Canek has created a nice system that addresses not
only new kernels, but also the other critical steps one has
to at least consider for a successful kernel upgrade, his solution
is targeted at a bit more complex situation than the average
user's needs, such as Francisco situation.

The old usage of :
make oldconfig 
make menuconfig

Is probably is in need of some extra "syntax_strokes" to create
a copy and paste style of kernel upgrade, should genkernel not 
be sufficient.

There's grub2 to consider, (u)efi bios,  mbr, initramfs and probably other
things to think about.  Maybe somebody smarter than me (not really
hard to find on this list) could modify Canek's script for the
general user case of simply upgrading gentoo-sources.
It could be put on the gentoo-wiki for folks to try out or packaged
as an overlay?. 

Feedback would (eventually) result in a version quite cool and moderized, 
without messing with genkernel. Once it becomes "robust" it would
be up to Sven & company to decide if it makes the handbook, as a replacement
or alternative to genkernel.....


Just a thought, but we get this sort of problem, quite often on this
list.... I think we should at least have a gentoo wiki page that folks
can read and learn about the general idea on different methods and the
caveats therein to kernel upgrades on Gentoo.  (pist) there could even
be a link to all the systemd and openrc   pages that come into play?


James