| 1 |
Am Tue, 02 Jan 2018 19:26:44 +0000 schrieb Stroller: |
| 2 |
|
| 3 |
>> On 2 Jan 2018, at 11:54, Kruglov Sergey <kr_serge@×××××××.com> wrote: |
| 4 |
>> |
| 5 |
>> Now I have gentoo-sources-4.14.8-r1 installed. |
| 6 |
>> After "emerge --ask --update --deep --with-bdeps=y --newuse @world" |
| 7 |
>> command emerge installs old kernel in NS (after first update 4.12.12, |
| 8 |
>> after second update 4.9.49-r1). |
| 9 |
>> How can I fix it? |
| 10 |
>> There is sys-kernel/gentoo-sources in my world set. |
| 11 |
> |
| 12 |
> Remove sys-kernel/gentoo-sources from your world file - I believe you |
| 13 |
> can do this using the emerge command, but am unsure of the right syntax; |
| 14 |
> you can just edit /var/lib/portage/world and delete the appropriate |
| 15 |
> line.D |
| 16 |
|
| 17 |
It is "emerge --deselect ...". |
| 18 |
|
| 19 |
|
| 20 |
> Now `emerge -n =sys-kernel/gentoo-sources-4.14.8-r1` - "This option can |
| 21 |
> be used to update the world file without rebuilding the packages." |
| 22 |
|
| 23 |
I don't think this is how it works. While technically correct, the |
| 24 |
outcome is different to what you're trying to achieve. |
| 25 |
|
| 26 |
|
| 27 |
> This pins your kernel version at 4.14.8-r1 and you can update when, in |
| 28 |
> future, you decide it's time to update your kernel, without being nagged |
| 29 |
> about it every time a new version is release or you emerge world. |
| 30 |
|
| 31 |
The equal sign doesn't pin versions, at least not that I remember. |
| 32 |
Package are pinned by slot in the world file. Coincidence may be that the |
| 33 |
version you selected happens to be exclusively the only slot, too. |
| 34 |
|
| 35 |
If you intend to pin a package, either emerge by slot, or use |
| 36 |
package.mask and package.unmask. |
| 37 |
|
| 38 |
|
| 39 |
> For this reason it's always best to emerge kernels with an equals sign, |
| 40 |
> pinning them at some specific version, IMO. |
| 41 |
|
| 42 |
Makes no sense if my above answer is correct. |
| 43 |
|
| 44 |
|
| 45 |
> This suggestion may provoke responses that the kernel is important and |
| 46 |
> you should update it to ensure you get security updates - look at the |
| 47 |
> attack vectors, you're probably sitting behind a NAT router, with very |
| 48 |
> few ports exposed to the internet. |
| 49 |
|
| 50 |
The attack vector is probably not the network facing surface of the |
| 51 |
kernel... Which makes your argument misleading at best... |
| 52 |
|
| 53 |
It is more likely that your kernel is attacked by something you did from |
| 54 |
the browser, or by running a server on one of the "few ports exposed" |
| 55 |
which is vulnerable, and that is the attack vector: A local privilege |
| 56 |
escalation or buffer overflow allowing the attacker to gain control of a |
| 57 |
process, and only then attacking the kernel. |
| 58 |
|
| 59 |
This is why you first should keep your software updated and secured, and |
| 60 |
for the rest just stick to gentoo-sources stable. |
| 61 |
|
| 62 |
Keep in mind that gentoo-sources back-ports some security fixes early. |
| 63 |
Also stable uses LTS kernels mostly which have long-term security |
| 64 |
maintenance. |
| 65 |
|
| 66 |
|
| 67 |
> It's adequate to update your kernel every 3 months. |
| 68 |
|
| 69 |
It's adequate to update your password every 3 months. |
| 70 |
|
| 71 |
It's adequate to update your software every 3 months. |
| 72 |
|
| 73 |
Really? No... |
| 74 |
|
| 75 |
It's adequate to update your software when a security hole was fixed - on |
| 76 |
the point. Not two or three months later... |
| 77 |
|
| 78 |
It gives a false impression of safety if you recommend such things. |
| 79 |
|
| 80 |
|
| 81 |
Just my two cents... ;-) |
| 82 |
|
| 83 |
|
| 84 |
-- |
| 85 |
Regards, |
| 86 |
Kai |
| 87 |
|
| 88 |
Replies to list-only preferred. |
Archives