Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Solved] USE flags having no effect?/missing USE flag?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
Black Knight
n00b
n00b


Joined: 13 Dec 2015
Posts: 18

PostPosted: Sun Dec 13, 2015 9:32 pm    Post subject: [Solved] USE flags having no effect?/missing USE flag? Reply with quote

Longtime *nix user here, new to Gentoo.

I'm trying to install Gentoo, and I've followed the handbook up through the "Install the Gentoo base system" chapter. I'm chrooted into the new system, done emerge-webrsync and emerge --sync.
I've generated my locales, chosen a profile (default/linux/amd64/13.0), edited my make.conf, set my timezone, etc. Now it's time to install a kernel. I want to deblob my kernel, so I've set the deblob USE flag by creating /etc/portage/package.use/gentoo-sources with contents "sys-kernel/gentoo-sources deblob". When I
Code:
emerge --ask sys-kernel/gentoo-sources -v
the deblob USE flag is not preset (not just "-deblob", but not present at all). Adding deblob to my USE flag list in my make.conf has no effect. If I add the deblob flag to make.conf and emerge --info I see the flag listed, but
Code:
emerge --info sys-kernel/gentoo-sources
does *not* show the flag. I also noticed that the deblob flag is absent from my /etc/portage/profiles/use.desc file. Trying to emerge the kernel source with
Code:
USE="deblob" emerge --ask sys-kernel/gentoo-sources
has the same result.

This is driving me nuts; I just want to install Gentoo :( . Any help would be appreciated!


Last edited by Black Knight on Wed Dec 16, 2015 7:42 am; edited 1 time in total
Back to top
View user's profile Send private message
tryn
Guru
Guru


Joined: 21 Dec 2002
Posts: 319
Location: 39.885° N. -88.913° W.

PostPosted: Sun Dec 13, 2015 10:00 pm    Post subject: Reply with quote

Black Knight

Try adding it this way in the file.

Code:
=sys-kernel/gentoo-sources-4.1.12  deblob


If this is the kernel that your wanting. If not change the numbers.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43200
Location: 56N 3W

PostPosted: Sun Dec 13, 2015 10:07 pm    Post subject: Reply with quote

Black Knight,

Welcome to Gentoo.

It looks like sys-kernel/gentoo-sources-4.1.3 was the last version to support the deblob USE flag.
You are doing everything correctly but the feature has either been removed or implemented differently.

-- edit --

It looks like the implementation has been changed.
Code:
  │ Symbol: FIRMWARE_IN_KERNEL [=n]                                                                          │ 
  │ Type  : boolean                                                                                          │ 
  │ Prompt: Include in-kernel firmware blobs in kernel binary                                                │ 
  │   Location:                                                                                              │ 
  │     -> Device Drivers                                                                                    │ 
  │       -> Generic Driver Options                                                                          │ 
  │ (8)     -> Userspace firmware loading support (FW_LOADER [=y])                                           │ 
  │   Defined at drivers/base/Kconfig:88                                                                     │ 
  │   Depends on: FW_LOADER [=y]


This means that the blobs are still in your kernel source code but not in the binary.
Unless you have FW_LOADER [=y], FIRMWARE_IN_KERNEL will be set to =n and hidden. Press 'z' to see hidden options in menuconfig.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.


Last edited by NeddySeagoon on Sun Dec 13, 2015 10:18 pm; edited 1 time in total
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sun Dec 13, 2015 10:15 pm    Post subject: Reply with quote

Black Knight ... welcome to gentoo.

4.1.12 doesn't support deblob ...

grep '^K_DEBLOB' ~portdir/sys-kernel/gentoo-sources/gentoo-sources-4.1.12.ebuild:
K_DEBLOB_AVAILABLE="0"

If you check the Changelog-2015 you'll see deblob was removed on 14 Jan 2015. In May we can see that some level of support was added back, but it looks like only certain package revisions are reciving this (for reasons not mentioned in the changelog).

So, you may have to use 3.18.23 ... though some of the early 4.x revisions do support deblob.

grep '^K_DEBLOB' ~portdir/sys-kernel/gentoo-sources/gentoo-sources-3.18.23.ebuild:
K_DEBLOB_AVAILABLE="1"

HTH & best ... khay
Back to top
View user's profile Send private message
Black Knight
n00b
n00b


Joined: 13 Dec 2015
Posts: 18

PostPosted: Sun Dec 13, 2015 10:31 pm    Post subject: Reply with quote

Since deblob has been dropped, some follow up questions:

Is there another way to cleanly deblob 4.1.12? Would using the kernel configuration param CONFIG_PREVENT_FIRMWARE_BUILD be sufficient? Something else? I'd really not rather use an outdated kernel, but I absolutely do not want blobs. I'm happy to do some manual kernel configuration, but I'd still prefer a system where I can do the kernel tweaks I need with genkernel --menuconfig and have it take care of my kernel/initramfs building otherwise, since I'm using an encrypted root.

Second, https://wiki.gentoo.org/wiki/Kernel/en still shows deblob as being a USE flag. Should I file a bug about this?

Thanks for the quick replies!

EDIT:
@NeddySeagoon
Just saw your edit. The "Include in-kernel firmware blobs in kernel binary" flag looks promising. Should I file a bug about the old USE flag on the wiki page?

Update:
So I ran decided to run another emerge --sync before continuing; suddenly if I try to
Code:
 emerge --ask sys-kernel/gentoo-sources
portage tries to pull gentoo-sources-4.0.9.
Running
Code:
grep -i deblob *
in /usr/portage/sys-kernel/gentoo-sources shows that this is the most recent ebuild to support the deblob USE flag, albiet with the "experimental" param. I take it portage's default behavior is to emerge the latest version that supports the given USE flags if no version is specified?

Last edited by Black Knight on Mon Dec 14, 2015 12:34 am; edited 1 time in total
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Mon Dec 14, 2015 12:15 am    Post subject: Reply with quote

Black Knight wrote:
Since deblob has been dropped, some follow up questions:

Black Knight ... you misunderstand, it was set to K_DEBLOB_AVAILABLE="0" (so, the useflag doesn't show, and no deblob is available) but it's being re-added ... what that means, and why only certain package versions have K_DEBLOB_AVAILABLE="1" I can't tell you.

Black Knight wrote:
Second, https://wiki.gentoo.org/wiki/Kernel/en still shows deblob as being a USE flag. Should I file a bug about this?

If it were removed then K_DEBLOB_AVAILABLE would probably have been removed entirely, so, its best understood as currently disabled (for certain package versions). So, no, it's not a bug ... though its being selectively enabled/disabled is highly irregular.

Black Knight wrote:
Running 'grep deblob *' in /usr/portage/sys-kernel/gentoo-sources shows that this is the most recent ebuild to support the deblob USE flag, albiet with the "experimental" param. I take it portage's default behavior is to emerge the latest version that supports the given USE flags if no version is specified?

No, the latest 'keyworded' version, the useflag has no effect in package selection (because unlike in this case useflags don't normally get removed, and replaced, between revisions ... they are fairly consistent). BTW ... 'grep -i' would be needed in the above, because the variable is uppercase, and this is what causes the useflag to be active, or not.

EDIT: on second thoughts, I'm not sure what K_DEBLOB_AVAILABLE might do if the useflag is enabled, it might actually effect package selection in this case.

best ... khay
Back to top
View user's profile Send private message
Black Knight
n00b
n00b


Joined: 13 Dec 2015
Posts: 18

PostPosted: Mon Dec 14, 2015 1:06 am    Post subject: Reply with quote

I can confirm that the USE flag does effect package selection. Running
Code:
emerge --ask sys-kernel/gentoo-sources

tries to pull 4.1.12 without the USE flag, and 4.0.9 with it. Not sure why I wasn't seeing this as per my original post, but portage is definitely behaving consistently now. Using the "=" prefix and appending the exact package version trumps this; portage will try to emerge the exact version despite the USE flag not being available.

Is there any advantage in "deblobedness/freedom" to the *compiled kernel* when using 4.0.9 with deblob vs 4.1.12 with the FIRMWARE_IN_KERNEL param? (and apart from the fact that 4.1.12 is a newer kernel, obviously). Both are marked stable on my arch, amd64: https://packages.gentoo.org/packages/sys-kernel/gentoo-sources

Good catch on the grep; neglected the -i when posting :mrgreen:.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Mon Dec 14, 2015 2:33 am    Post subject: Reply with quote

Black Knight wrote:
I can confirm that the USE flag does effect package selection.

Black Knight ... strange, because after my post above I did a quick test and got the following:

USE="deblob" emerge -pv gentoo-sources | grep '^[':
[ebuild  N  ] sys-kernel/gentoo-sources-4.1.12:4.1.12::gentoo  USE="-build -experimental -kdbus -symlink" 81,470 KiB

Black Knight wrote:
Is there any advantage in "deblobedness/freedom" to the *compiled kernel* when using 4.0.9 with deblob vs 4.1.12 with the FIRMWARE_IN_KERNEL param? (and apart from the fact that 4.1.12 is a newer kernel, obviously). Both are marked stable on my arch, amd64:

Keyworded 'stable', but that doesn't necessarily reflect the stability of the kernel in question, I'd generally avoid any 4.0.x (early releases for a major revision). If I had to have 4.x I would keyword 4.3.2 and either make the change to K_DEBLOB_AVAILABLE="1" (in a local overlay) or trust that FIRMWARE_IN_KERNEL will provide the same effect. That said, I know none of the drivers I require need firmware, so deblob isn't necessary here.

best ... khay
Back to top
View user's profile Send private message
Black Knight
n00b
n00b


Joined: 13 Dec 2015
Posts: 18

PostPosted: Mon Dec 14, 2015 7:21 am    Post subject: Reply with quote

khayyam,
I definitely get the version switch depending on the USE flag presence; reproduced this with your exact emerge command. Clearly our systems' configurations diverge in some other way.

Aside, you make a good point about the stability of the 4.0.x kernels and "stable" keywording. Are any of the gentoo-source kernel version considered stable or LTS? I noticed the 3.14.56 (the lastest stable flagged 3.x version) is near to the 3.14.58 LTS listed on kernel.org... Any correlation? This setup is for an older machine I'll actually be doing work on I and know I won't need anything as new as 4.1.x or even 4.0.x; I just want something reliable, secure (that is, receiving security patches) and "deblobable" in some way. Recommendations? Sorry if I'm missing something obvious but I'm not clear on which gentoo-source versions get security patches.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Mon Dec 14, 2015 10:58 am    Post subject: Reply with quote

Black Knight wrote:
I definitely get the version switch depending on the USE flag presence; reproduced this with your exact emerge command. Clearly our systems' configurations diverge in some other way.

Black Knight ... hmmmm, I can't think what, but never mind.

Black Knight wrote:
Aside, you make a good point about the stability of the 4.0.x kernels and "stable" keywording. Are any of the gentoo-source kernel version considered stable or LTS? I noticed the 3.14.56 (the lastest stable flagged 3.x version) is near to the 3.14.58 LTS listed on kernel.org... Any correlation? This setup is for an older machine I'll actually be doing work on I and know I won't need anything as new as 4.1.x or even 4.0.x; I just want something reliable, secure (that is, receiving security patches) and "deblobable" in some way. Recommendations? Sorry if I'm missing something obvious but I'm not clear on which gentoo-source versions get security patches.

Some will follow 'longterm', yes. You would need to set a mask in order to stick with a certain range. So, for example 3.14.x

/etc/portage/package.mask:
>=sys-kernel/gentoo-sources-3.18.21

Unfortunately 3.14.58 doesn't seem to provide deblob. As for patches, you're getting the upstream sources, plus 'genpatches'.

best ... khay
Back to top
View user's profile Send private message
Black Knight
n00b
n00b


Joined: 13 Dec 2015
Posts: 18

PostPosted: Tue Dec 15, 2015 1:24 am    Post subject: Reply with quote

So it looks like FIRMWARE_IN_KERNEL is even worse, building firmware directly into the kernel instead of building them as separate files, whereas I don't want them at all.
It seems CONFIG_PREVENT_FIRMWARE_BUILD might work, but it isn't clear to me that it's enough to keep 100% of the blobs out. Knowing this worked would be best, since then I could go with any kernel version that supports this option.

See
http://cateee.net/lkddb/web-lkddb/PREVENT_FIRMWARE_BUILD.html
and
http://cateee.net/lkddb/web-lkddb/FIRMWARE_IN_KERNEL.html

Failing in that, it doesn't look like there's a gentoo-source kernel with deblob and a stable mark that also follows a kernel.org longterm branch, and I'd rather not give up deblob unless I can be sure about the PREVENT flag. Based on your experience, what's the relative risk of going with a gentoo "testing" kernel (I'm eyeballing 3.18.23 here) vs a "stable"?

Also, your genpatches link mentions that "Each patchset is based on the initial stable release of the kernel's released at kernel.org"; I assume this is the same for the upstream patches? Is there a canonical way to know exactly which versions get what patches?
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Tue Dec 15, 2015 2:33 am    Post subject: Reply with quote

Black Knight wrote:
It seems CONFIG_PREVENT_FIRMWARE_BUILD might work, but it isn't clear to me that it's enough to keep 100% of the blobs out. Knowing this worked would be best, since then I could go with any kernel version that supports this option.

Black Night ... as I said above, none of the drivers I use require firmware, I'd compared the content of .config against the deblob output and everything deblob was targeting wasn't something I would consider, or need, enabled. What CONFIG_PREVENT_FIRMWARE_BUILD effects I'm not sure, but as you can run deblob outside of portage (or by copying the ebuild to a local overlay, editing, and setting K_DEBLOB_AVAILABLE="1") you should be able to get a blob free sources without there being some percentage of error ... it just takes more work.

Black Knight wrote:
Failing in that, it doesn't look like there's a gentoo-source kernel with deblob and a stable mark that also follows a kernel.org longterm branch, and I'd rather not give up deblob unless I can be sure about the PREVENT flag. Based on your experience, what's the relative risk of going with a gentoo "testing" kernel (I'm eyeballing 3.18.23 here) vs a "stable"?

I don't use gentoo-sources, but I wouldn't think there is too much risk in using 'unstable', the keywording is such that currently you'd get 4.1.x ... so you'd have to provide a mask to get 'unstable' 3.18.x. You can somewhat ignore the stable/unstable designation and focus on the version.

Black Knight wrote:
Also, your genpatches link mentions that "Each patchset is based on the initial stable release of the kernel's released at kernel.org"; I assume this is the same for the upstream patches? Is there a canonical way to know exactly which versions get what patches?

I don't think you can be sure of what version a patch is targeting, if it applies then that sort of provides the criteria. As for which patches are applied, other than by looking at the patch set, and/or Changelog (and bug # if supplied), no. You can find the patchset as tarballs in distfiles.

best ... khay
Back to top
View user's profile Send private message
Black Knight
n00b
n00b


Joined: 13 Dec 2015
Posts: 18

PostPosted: Tue Dec 15, 2015 3:02 am    Post subject: Reply with quote

khayyam,
Thanks for the clarification, all makes sense. I went ahead and masked 3.18.23 for now since it follows an LTS line and is a bit easier to deblob. All emerged and USE flags respected with no issues. Out of curiosity, what do you run if not gentoo-sources? Thanks again for the help!

Best,
Black Knight
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Tue Dec 15, 2015 3:50 am    Post subject: Reply with quote

Black Knight wrote:
Out of curiosity, what do you run if not gentoo-sources?

Black Knight ... sys-kernel/ck-sources ... actually, it's more of a hybrid, because I also use the tuxonice patches via epatch_user.

Black Knight wrote:
Thanks again for the help!

You're welcome.

best ... khay
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum