Re: [gentoo-user] old kernels are installed during the upgrade

[Wols Lists]

On 03/01/18 22:09, Alan McKinnon wrote:
> On 04/01/2018 00:02, Stroller wrote:
>>
>>> On 3 Jan 2018, at 21:55, Wols Lists  wrote:
>>>  
>>> What would be nice, would be if "emerge --depclean" had the smarts to
>>> recognise that /usr/src/linux pointed to the current active kernel, and
>>> didn't wipe that when it cleaned out everything else :-) That way, at
>>> most you could have the current and latest kernel sources available
>>> pretty easily.
>>
>> You've jogged a long-hibernating memory - the accidental removal of the 
>> current sources tree in an accident like this may be the exact reason why I 
>> refuse to allow kernel versions to be actively emerged.
> 
> I think that's a mountain and a molehill. You still have the image in
> /boot, config in /boot or in the running kernel, libs in /lib/modules
> and the bootloader is intact.
> 
> Delete the sources?
> - Re-emerge them. 90 seconds.
> - Re-compile using existing config. 20 minutes
> 
> So deleting the sources for the running kernel is a doh! moment. But no
> biggie, and certainly not cause for changing your routine (all in my own
> not at all humble opinion, of course)
> 
But it's a royal pain, especially if you don't realise that's what's
happened, because a general emerge is likely to have a lot of grief.

Dunno how many ebuilds actually refer to /usr/src/linux for some of
their header files, but I doubt it's negligible. It's certainly caused
me grief in the past.

(Yes I think they're not supposed to, but what's that saying about
theory and practice?)

I don't like it when well-known problems cause general breakage that is
likely to cause havoc for unsuspecting users...

Cheers,
Wol

[gentoo-user] Spectre CPU flaws

[thelma]

New bug resurface.
What is the command to test AMD CUP's if flag: X86_BUG_CPU_INSECURE is
enabled?

From:
https://lkml.org/lkml/2017/12/27/2

-- 
Joseph

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Adam Carter]

>
> Project Zero (Google) found it;
> https://googleprojectzero.blogspot.com.au/2018/01/
> reading-privileged-memory-with-side.html
>
> Phoronix has done some benchmarks on the impact of the kernel based
> workaround ([Kernel] Page Table Isolation (PSI) nee Kaiser)
> https://www.phoronix.com/scan.php?page=article=linux-
> more-x86pti=1
>
>
Re:AMD  - Looks like Linus agrees that PTI is not required for AMD CPUs.
Note that the project zero blog mentions that some AMD chips are subject to
some issues*. *There's three CVEs
*.*

From:
https://www.phoronix.com/scan.php?page=news_item=Linux-Tip-Git-Disable-x86-PTI
*"Update:* Linus Torvalds has now ended up pulling

the latest PTI fixes that also include the change to disable page table
isolation for now on all AMD CPUs. The commit is in mainline for Linux 4.15
along with a few basic fixes and ensuring PAGE_TABLE_ISOLATION is enabled
by default. "

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Adam Carter]

On Thu, Jan 4, 2018 at 2:15 PM, P Levine  wrote:

> I'm not sure if it's been mentioned here before but there apparently is a
> bug affecting all Intel CPUs manufactured in the last 10 years or so, in
> which protected kernel memory is leaked to userspace.  It can't be patched
> in microcode and will lead to some serious overhead to patch in the OS.
> See, Huge Intel CPU Bug Allegedly Causes Kernel Memory Vulnerability With
> Up To 30% Performance Hit In Windows And Linux
> 
>  and Meltdown and Spectre .
>
> Reported at Bug 643360 .
>

Its been mentioned in another thread, but I guess its a bit off topic there.

Project Zero (Google) found it;
https://googleprojectzero.blogspot.com.au/2018/01/reading-privileged-memory-with-side.html

Phoronix has done some benchmarks on the impact of the kernel based
workaround ([Kernel] Page Table Isolation (PSI) nee Kaiser)
https://www.phoronix.com/scan.php?page=article=linux-more-x86pti=1

[gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[P Levine]

I'm not sure if it's been mentioned here before but there apparently is a
bug affecting all Intel CPUs manufactured in the last 10 years or so, in
which protected kernel memory is leaked to userspace.  It can't be patched
in microcode and will lead to some serious overhead to patch in the OS.
See, Huge Intel CPU Bug Allegedly Causes Kernel Memory Vulnerability With
Up To 30% Performance Hit In Windows And Linux

 and Meltdown and Spectre .

Reported at Bug 643360 .

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 23:41, Neil Bothwick  wrote:
> 
> On Wed, 3 Jan 2018 22:07:22 +, Stroller wrote:
> 
>>> If you do want to use versions, I'd recommend using ~ rather than = to
>>> pick up patch-level updates.  
>> 
>> What do you mean by this exactly, please?
> 
> If you have =foo-1.0 matches only foo-1.0, if a patched version is
> released as foo-1.0-r1, you won't get it. With ~foo-1.0 you will.
> 
> Neither will match foo-1.1

I would have guessed "~" means "approximate", but this is what I don't want.

If I want to recompile my kernel I'll choose the latest version and download 
the full sources.

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 22:47, Alan McKinnon  wrote:
> 
 
 What do you mean by this exactly, please?
>>> 
>>> =4.9.34 selects that exact version and only that specific version
>>> ~4.9.34 select that version and also 4.9.34-r1. There might need to be a
>>> * on the end of ~4.9.34, I don;t quite recall. Answer in portage's man pages
>> 
>> I thought it was something like that, but searched `man portage` for "~" 
>> more than one way, and didn't find reference to this. Am I blind?
> 
> man 5 ebuild
> 
> Section "Extended Atom Prefixes", it is near the top, probably first
> page on most screen sizes.
> 
> The location is very non-obvious, I only know of it because I refr to it
> often once I found it

The ability to block atoms looks interesting, although I can't think when I'd 
use it.

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Neil Bothwick]

On Wed, 3 Jan 2018 22:02:37 +, Stroller wrote:

> You've jogged a long-hibernating memory - the accidental removal of the
> current sources tree in an accident like this may be the exact reason
> why I refuse to allow kernel versions to be actively emerged.

It's not a big deal, as Alan explained, but I use a set to prevent any
kernel sources being depcleaned.


-- 
Neil Bothwick

Grow your own dope, plant a politician!


pgp4fxAKJiGEB.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] old kernels are installed during the upgrade

[Neil Bothwick]

On Wed, 3 Jan 2018 22:07:22 +, Stroller wrote:

> > If you do want to use versions, I'd recommend using ~ rather than = to
> > pick up patch-level updates.  
> 
> What do you mean by this exactly, please?

If you have =foo-1.0 matches only foo-1.0, if a patched version is
released as foo-1.0-r1, you won't get it. With ~foo-1.0 you will.

Neither will match foo-1.1

It's all in man portage.


-- 
Neil Bothwick

Only an idiot actually READS taglines.


pgpgOFx33buMo.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] old kernels are installed during the upgrade

[Alan McKinnon]

On 04/01/2018 00:41, Stroller wrote:
> 
>> On 3 Jan 2018, at 22:11, Alan McKinnon  wrote:
>>
>
> $ grep -e source /var/lib/portage/world
> sys-kernel/gentoo-sources:4.9.34
 ...
>>>
>>> I guess this risks that emerge will try to install 4.9.34-r1 during a 
>>> future update, but I don't believe I've ever experienced that.
>>
>> Only if the highest-versioned emerged sources are <4.9.34-r1
> 
> Yes, in the quoted example above I grepped my world file for sources and 
> 4.9.34 is currently installed. 
> 
>>>
 If you do want to use versions, I'd recommend using ~ rather than = to
 pick up patch-level updates.
>>>
>>> What do you mean by this exactly, please?
>>
>> =4.9.34 selects that exact version and only that specific version
>> ~4.9.34 select that version and also 4.9.34-r1. There might need to be a
>> * on the end of ~4.9.34, I don;t quite recall. Answer in portage's man pages
> 
> I thought it was something like that, but searched `man portage` for "~" more 
> than one way, and didn't find reference to this. Am I blind?

man 5 ebuild

Section "Extended Atom Prefixes", it is near the top, probably first
page on most screen sizes.

The location is very non-obvious, I only know of it because I refr to it
often once I found it


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] old kernels are installed during the upgrade

[Herminio Hernandez, Jr.]

I found this helpful in managing kernel versions

https://www.youtube.com/watch?v=UwvV2wf-Gk0

On Wed, Jan 3, 2018 at 3:41 PM, Stroller 
wrote:

>
> > On 3 Jan 2018, at 22:11, Alan McKinnon  wrote:
> >
> 
>  $ grep -e source /var/lib/portage/world
>  sys-kernel/gentoo-sources:4.9.34
> >>> ...
> >>
> >> I guess this risks that emerge will try to install 4.9.34-r1 during a
> future update, but I don't believe I've ever experienced that.
> >
> > Only if the highest-versioned emerged sources are <4.9.34-r1
>
> Yes, in the quoted example above I grepped my world file for sources and
> 4.9.34 is currently installed.
>
> >>
> >>> If you do want to use versions, I'd recommend using ~ rather than = to
> >>> pick up patch-level updates.
> >>
> >> What do you mean by this exactly, please?
> >
> > =4.9.34 selects that exact version and only that specific version
> > ~4.9.34 select that version and also 4.9.34-r1. There might need to be a
> > * on the end of ~4.9.34, I don;t quite recall. Answer in portage's man
> pages
>
> I thought it was something like that, but searched `man portage` for "~"
> more than one way, and didn't find reference to this. Am I blind?
>
> Stroller.
>
>
>

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 22:11, Alan McKinnon  wrote:
> 
 
 $ grep -e source /var/lib/portage/world
 sys-kernel/gentoo-sources:4.9.34
>>> ...
>> 
>> I guess this risks that emerge will try to install 4.9.34-r1 during a future 
>> update, but I don't believe I've ever experienced that.
> 
> Only if the highest-versioned emerged sources are <4.9.34-r1

Yes, in the quoted example above I grepped my world file for sources and 4.9.34 
is currently installed. 

>> 
>>> If you do want to use versions, I'd recommend using ~ rather than = to
>>> pick up patch-level updates.
>> 
>> What do you mean by this exactly, please?
> 
> =4.9.34 selects that exact version and only that specific version
> ~4.9.34 select that version and also 4.9.34-r1. There might need to be a
> * on the end of ~4.9.34, I don;t quite recall. Answer in portage's man pages

I thought it was something like that, but searched `man portage` for "~" more 
than one way, and didn't find reference to this. Am I blind?

Stroller.

Re: [gentoo-user] iMON remote, evdev, X and Kodi stopped working

[Manuel McLure]

On Wed, Jan 3, 2018 at 11:42 AM, Mick  wrote:

>
>
> Sometime in autumn I had a similar symptom with a (non-gentoo) box running
> kodi here.  I had to reprogram the IR remote control handset, but wouldn't
> know how to go about it with yours ...
> --
> Regards,
> Mick


Interesting. After checking out /var/log/emerge.log I'm now confident that
the remote was working after I upgraded to xf86-input-evdev to 2.10.5,
since that happened in March (shortly after it went stable) and I upgraded
nvidia-drivers in October when I changed out the video card and I'm
positive I tested Kodi with the new card and everything worked. I did do a
"emerge -e @world" update to profile 17.0 in early December and that could
have corresponded with the start of the problem, although I think I
remember testing it and everything working.

-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft

Re: [gentoo-user] old kernels are installed during the upgrade

[Alan McKinnon]

On 04/01/2018 00:07, Stroller wrote:
> 
>> On 3 Jan 2018, at 21:53, Neil Bothwick  wrote:
>>>
>>> It installs exactly that version, and that exact version is recorded in
>>> the world file.
>>>
>>> $ grep -e source /var/lib/portage/world
>>> sys-kernel/gentoo-sources:4.9.34
>>
>> That's not a version, it's a slot. Whilst kernels are currently slotted
>> with the version number, nothing else is and there is no guarantee that
>> this will also hold for kernels.
> 
> Fair enough, but there's nothing else I need to treat this way.
> 
> I guess this risks that emerge will try to install 4.9.34-r1 during a future 
> update, but I don't believe I've ever experienced that.

Only if the highest-versioned emerged sources are <4.9.34-r1
> 
>> If you do want to use versions, I'd recommend using ~ rather than = to
>> pick up patch-level updates.
> 
> What do you mean by this exactly, please?

=4.9.34 selects that exact version and only that specific version
~4.9.34 select that version and also 4.9.34-r1. There might need to be a
* on the end of ~4.9.34, I don;t quite recall. Answer in portage's man pages


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] old kernels are installed during the upgrade

[Alan McKinnon]

On 04/01/2018 00:02, Stroller wrote:
> 
>> On 3 Jan 2018, at 21:55, Wols Lists  wrote:
>>  
>> What would be nice, would be if "emerge --depclean" had the smarts to
>> recognise that /usr/src/linux pointed to the current active kernel, and
>> didn't wipe that when it cleaned out everything else :-) That way, at
>> most you could have the current and latest kernel sources available
>> pretty easily.
> 
> You've jogged a long-hibernating memory - the accidental removal of the 
> current sources tree in an accident like this may be the exact reason why I 
> refuse to allow kernel versions to be actively emerged.

I think that's a mountain and a molehill. You still have the image in
/boot, config in /boot or in the running kernel, libs in /lib/modules
and the bootloader is intact.

Delete the sources?
- Re-emerge them. 90 seconds.
- Re-compile using existing config. 20 minutes

So deleting the sources for the running kernel is a doh! moment. But no
biggie, and certainly not cause for changing your routine (all in my own
not at all humble opinion, of course)

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 21:53, Neil Bothwick  wrote:
>> 
>> It installs exactly that version, and that exact version is recorded in
>> the world file.
>> 
>> $ grep -e source /var/lib/portage/world
>> sys-kernel/gentoo-sources:4.9.34
> 
> That's not a version, it's a slot. Whilst kernels are currently slotted
> with the version number, nothing else is and there is no guarantee that
> this will also hold for kernels.

Fair enough, but there's nothing else I need to treat this way.

I guess this risks that emerge will try to install 4.9.34-r1 during a future 
update, but I don't believe I've ever experienced that.

> If you do want to use versions, I'd recommend using ~ rather than = to
> pick up patch-level updates.

What do you mean by this exactly, please?

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 21:55, Wols Lists  wrote:
>  
> What would be nice, would be if "emerge --depclean" had the smarts to
> recognise that /usr/src/linux pointed to the current active kernel, and
> didn't wipe that when it cleaned out everything else :-) That way, at
> most you could have the current and latest kernel sources available
> pretty easily.

You've jogged a long-hibernating memory - the accidental removal of the current 
sources tree in an accident like this may be the exact reason why I refuse to 
allow kernel versions to be actively emerged.

Stroller.

Re: [gentoo-user] Plasma device notifier shows wrong free space on USB disks

[Stroller]

> On 3 Jan 2018, at 17:24, Flavio Cappelli  wrote:
> … 
> 
> I tried with three different USB drives and the behavior is the same:
> 
> ￜ- 4GB flash drive on USB2 interface, vfat formatted, 3.3GB free
> ￜ- 128GB flash drive on USB3 interface, exfat formatted, 107GB free
> ￜ- 500GB external HDD on USB2 interface, ext4 formatted, 468GB free
> 
> The device notifier always shows 1.2GB of free space and I cannot copy
> big files with dolphin to the USB disk.

I bet it's to do with the FAT / VFAT formatting.

If you don't get any more helpful replies here, I would take this directly to 
the KDE lists.

Stroller

Re: [gentoo-user] old kernels are installed during the upgrade

[Wols Lists]

On 03/01/18 21:39, Stroller wrote:
>> What this completely misses, is that gentoo-sources merely DOWNLOADS THE
>> > LATEST KERNEL SOURCE. So updating gentoo-sources every time does nothing
>> > to change the kernel you are running.

> I don't know why you think I missed that.

Because you're banging on like downloading the source is the same thing
as installing a new kernel - which it's not.
> 
> If you `emerge gentoo-sources` then updates of them will appear every time 
> you --pretend update world until you allow them to be emerged, hence my use 
> of the word "nagged".
> 
Which is why I just let them appear and clutter up /usr/src :-)

> If you want to install them, that's your prerogative, but just allowing them 
> to be automatically emerged fills up your system with unwanted uncompressed 
> kernel sources, consuming huge amounts of space.
> 
I take your point - you're paying for storage by the meg, and a quick du
-sh tells me a kernel is approx 1G - ouch.

But is the OP like you, or like me - about to upgrade from a home system
that already has 6TB of storage ...

> 20GB should be ample space for an operating system IMO, but between /usr/src 
> and /usr/portage it's pretty easy to consume a quarter of that.

I remember when it fitted on an 8" floppy :-) It was bad enough
installing Slack from a 30-floppy set ...

What would be nice, would be if "emerge --depclean" had the smarts to
recognise that /usr/src/linux pointed to the current active kernel, and
didn't wipe that when it cleaned out everything else :-) That way, at
most you could have the current and latest kernel sources available
pretty easily.

Cheers,
Wol

Re: [gentoo-user] old kernels are installed during the upgrade

[Neil Bothwick]

On Wed, 3 Jan 2018 21:21:30 +, Stroller wrote:

> >> This pins your kernel version at 4.14.8-r1 and you can update when,
> >> in future, you decide it's time to update your kernel, without being
> >> nagged about it every time a new version is release or you emerge
> >> world.  
> > 
> > The equal sign doesn't pin versions, at least not that I remember. 
> > Package are pinned by slot in the world file. Coincidence may be that
> > the version you selected happens to be exclusively the only slot,
> > too.  
> 
> It installs exactly that version, and that exact version is recorded in
> the world file.
> 
> $ grep -e source /var/lib/portage/world
> sys-kernel/gentoo-sources:4.9.34

That's not a version, it's a slot. Whilst kernels are currently slotted
with the version number, nothing else is and there is no guarantee that
this will also hold for kernels.

If you do want to use versions, I'd recommend using ~ rather than = to
pick up patch-level updates.


-- 
Neil Bothwick

I backed up my hard drive and ran into a bus.


pgpCzHVwWyyLH.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Neil Bothwick]

On Wed, 3 Jan 2018 15:53:07 -0500, Rich Freeman wrote:

> I believe the kernel went with "Page Table Isolation (PTI)" rather
> that KAISER, probably to avoid ethnic issues.  Apparently this was
> deemed to have a more acceptable acronym than Forcefully Unmap
> Complete Kernel With Interrupt Trampolines.

ROFL!


-- 
Neil Bothwick

Q: How many accountants does it take to screw in a light bulb?
A: What kind of answer did you have in mind?


pgpSfj9bOZTlg.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] old kernels are installed during the upgrade

[Dale]

Wols Lists wrote:
> On 03/01/18 21:21, Stroller wrote:
>> Meanwhile, I've seen security vulnerabilities go unfixed for literally weeks 
>> in the bug tracker, so I don't see the significance of a vulnerability an 
>> attacker is unlikely to be able to reach. The sites I visit do not make me 
>> fear my kernel being attacked via the browser.
>>
>> This thread is not for arguing about security, which is an old discussion 
>> and which has been done to death. Everyone has their own opinions, and I'm 
>> not going to add any more.
>>
>> This thread is about how to fix OP's problem, and that's what I addressed. 
>> If you install kernels by specific version, as I suggest, then you're free 
>> to update them manually as often as you wish.
> And heaven help you if you think emerging a specific version of
> gentoo-sources will update the kernel you're running. Because Linux
> certainly won't.
>
> Hint: changing the current version of gentoo-sources does ABSOLUTELY
> NOTHING to your running system, so why not emerge them all?
>
> Cheers,
> Wol
>
>

My question would be the opposite.  Why emerge kernels you are not going
to build anyway?  The only kernels I have installed here are the ones I
have emerged, built and installed for either current or future use. 
There is no reason to have sources for kernels that I know I will never
use.  The same could apply to others as well. 

Dale

:-)  :-) 

Re: [gentoo-user] old kernels are installed during the upgrade

[Rich Freeman]

On Wed, Jan 3, 2018 at 4:21 PM, Stroller  wrote:
>
> If the kernel devs cared to announce when they were patching exploits then we 
> could take each
> one under consideration individually. But the kernel devs are secretive about 
> kernel exploits, because
> they know there are literally millions of systems out there on the internet 
> with kernels months and years old.
>

I'm skeptical of that claim.  I think it is more that they don't want
to try to track which commits are associated with CVEs.  I believe
they've said as much publicly.  They're not particularly secretive
about exploits except when they're under embargo (such as at the
present moment).

-- 
Rich

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 3 Jan 2018, at 21:31, Wols Lists  wrote:
> 
> And heaven help you if you think emerging a specific version of
> gentoo-sources will update the kernel you're running. Because Linux
> certainly won't.

Heaven help me?

Could you possibly clarify, please?

Stroller.

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 2 Jan 2018, at 19:47, Wols Lists  wrote:
> 
> You should also check the CVEs every time there's a new kernel!

Who the heck's got time for that? Really?

I have a life, mate. And that means I have better things to do with my time.

Translation of what you just said: you should buy a Mac, because Linux is so 
much work you have to check security bulletins all the time.

> What this completely misses, is that gentoo-sources merely DOWNLOADS THE
> LATEST KERNEL SOURCE. So updating gentoo-sources every time does nothing
> to change the kernel you are running.

I don't know why you think I missed that.

If you `emerge gentoo-sources` then updates of them will appear every time you 
--pretend update world until you allow them to be emerged, hence my use of the 
word "nagged".

If you want to install them, that's your prerogative, but just allowing them to 
be automatically emerged fills up your system with unwanted uncompressed kernel 
sources, consuming huge amounts of space.

20GB should be ample space for an operating system IMO, but between /usr/src 
and /usr/portage it's pretty easy to consume a quarter of that.

I'm happy to do things your way if you're contributing to my hosting bill, but 
from the sounds of it this is about the way YOU choose to administer YOUR 
systems, and that you think I should be deferential to that.

Do you not think, in my nearly 20 years of using *nix systems and reading *nix 
related mailing lists, I've never heard someone advocate these kind of security 
principles before?

These kind of arguments are theoretical. In the real world, there are millions 
of people still running Windows XP and now-obsolete versions of Android on 
their phones. A kernel that's a few months old is hardly likely to hurt me.

Stroller.
D

Re: [gentoo-user] old kernels are installed during the upgrade

[Wols Lists]

On 03/01/18 21:21, Stroller wrote:
> Meanwhile, I've seen security vulnerabilities go unfixed for literally weeks 
> in the bug tracker, so I don't see the significance of a vulnerability an 
> attacker is unlikely to be able to reach. The sites I visit do not make me 
> fear my kernel being attacked via the browser.
> 
> This thread is not for arguing about security, which is an old discussion and 
> which has been done to death. Everyone has their own opinions, and I'm not 
> going to add any more.
> 
> This thread is about how to fix OP's problem, and that's what I addressed. If 
> you install kernels by specific version, as I suggest, then you're free to 
> update them manually as often as you wish.

And heaven help you if you think emerging a specific version of
gentoo-sources will update the kernel you're running. Because Linux
certainly won't.

Hint: changing the current version of gentoo-sources does ABSOLUTELY
NOTHING to your running system, so why not emerge them all?

Cheers,
Wol

Re: [gentoo-user] old kernels are installed during the upgrade

[Stroller]

> On 2 Jan 2018, at 20:20, Kai Krakow  wrote:
> 
> 
>> Now `emerge -n =sys-kernel/gentoo-sources-4.14.8-r1` - "This option can
>> be used to update the world file without  rebuilding the packages."
> 
> I don't think this is how it works. While technically correct, the 
> outcome is different to what you're trying to achieve.
> 
> 
>> This pins your kernel version at 4.14.8-r1 and you can update when, in
>> future, you decide it's time to update your kernel, without being nagged
>> about it every time a new version is release or you emerge world.
> 
> The equal sign doesn't pin versions, at least not that I remember. 
> Package are pinned by slot in the world file. Coincidence may be that the 
> version you selected happens to be exclusively the only slot, too.

It installs exactly that version, and that exact version is recorded in the 
world file.

$ grep -e source /var/lib/portage/world
sys-kernel/gentoo-sources:4.9.34
$ 

> It's adequate to update your software when a security hole was fixed - on 
> the point. Not two or three months later...
> 
> It gives a false impression of safety if you recommend such things.

We could spend every day updating our systems - IDK about you, but I have 
better things to do.

If the kernel devs cared to announce when they were patching exploits then we 
could take each one under consideration individually. But the kernel devs are 
secretive about kernel exploits, because they know there are literally millions 
of systems out there on the internet with kernels months and years old.

You're right about the attack vectors, which is why I prioritise the apps and 
servers I run - an attacker has to get past those before it can exploit those. 
I updated OpenSSH and openssl the day I leaned of the HeartBleed attack for 
example.

Meanwhile, I've seen security vulnerabilities go unfixed for literally weeks in 
the bug tracker, so I don't see the significance of a vulnerability an attacker 
is unlikely to be able to reach. The sites I visit do not make me fear my 
kernel being attacked via the browser.

This thread is not for arguing about security, which is an old discussion and 
which has been done to death. Everyone has their own opinions, and I'm not 
going to add any more.

This thread is about how to fix OP's problem, and that's what I addressed. If 
you install kernels by specific version, as I suggest, then you're free to 
update them manually as often as you wish.

Stroller.

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Rich Freeman]

On Wed, Jan 3, 2018 at 3:35 PM, Wols Lists  wrote:
>
> And as I understand it the code can be disabled with either a compile
> time option or command line switch to the kernel.

I suspect the compile-time option is PAGE_TABLE_ISOLATION (which was
newly added in 4.14.11).  The command line option nopti will disable
it at runtime.

Rumor has it that it will be disabled on AMD CPUs in 4.14.12, but I
can't point to anywhere authoritative for that news so I'd consider it
a rumor.  I've also heard that Arch has deployed it early to 4.14.11,
and I wouldn't be surprised if many distros do this if it is intended
to go into the next stable, as there would be no point subjecting AMD
users to performance issues.  I haven't spoken to the Gentoo kernel
team about what their plans are for it.  In any case, nopti on the
command line is probably the cleanest solution.  I personally avoided
disabling the feature in the compiled kernel because I don't want to
be using the same config file on an Intel CPU in a year or two and
forget I have it forced off.

> The relevant code is
> called KAISER, which forces kernel and user address space into different
> contexts, and causes a nasty context-switching overhead on both Intel
> and AMD cpus.
>

I believe the kernel went with "Page Table Isolation (PTI)" rather
that KAISER, probably to avoid ethnic issues.  Apparently this was
deemed to have a more acceptable acronym than Forcefully Unmap
Complete Kernel With Interrupt Trampolines.

-- 
Rich

Re: [gentoo-user] Re: old kernels are installed during the upgrade

[Wols Lists]

On 02/01/18 22:58, Adam Carter wrote:
> AMD coder's patch to disable the new code (to avoid the performance hit)
> where he states the issue doesnt exist on AMD processors;
> https://lkml.org/lkml/2017/12/27/2

Read LWN, specifically the links to the people who covered the bug.

It's a flaw in speculative forward processing, where the security does
not travel with the speculative processing. So user code can trigger a
page fault that references kernel code, causing that page to be
retrieved. OOPP. AMD keeps security context with the code, causing
an attempt to exploit the bug to fail with "invalid security context".

And as I understand it the code can be disabled with either a compile
time option or command line switch to the kernel. The relevant code is
called KAISER, which forces kernel and user address space into different
contexts, and causes a nasty context-switching overhead on both Intel
and AMD cpus.

Cheers,
Wol

Re: [gentoo-user] iMON remote, evdev, X and Kodi stopped working

[Mick]

On Wednesday, 3 January 2018 19:10:45 GMT Manuel McLure wrote:
> Hi all, I'm having a problem with my Kodi system. Unfortunately I don't use
> the Kodi system very often (the system also runs as a general server on my
> network so most of my work on it is done through ssh) so I don't know
> exactly when this happened, but it would have been in the last couple of
> months.
> 
> The problem is that the iMON IR remote stopped working at some point. I
> have an Antec Fusion Remote Black case that uses an iMON LCD and IR
> receiver. This was working fine with evdev/X/Kodi but at some point stopped
> working, and since I haven't used the Kodi interface for a few months I
> don't know exactly what broke it.
> 
> It looks like the most interesting information comes from Xorg.0.log:
> 
> ...
> [217569.500] (II) config/udev: Adding input device iMON Remote (15c2:ffdc)
> (/dev/input/event4)
> [217569.500] (**) iMON Remote (15c2:ffdc): Applying InputClass "evdev
> keyboard catchall"
> [217569.500] (II) Using input driver 'evdev' for 'iMON Remote (15c2:ffdc)'
> [217569.500] (**) iMON Remote (15c2:ffdc): always reports core events
> [217569.500] (**) evdev: iMON Remote (15c2:ffdc): Device:
> "/dev/input/event4"
> [217569.500] (--) evdev: iMON Remote (15c2:ffdc): Vendor 0x15c2 Product
> 0xffdc
> [217569.500] (WW) evdev: iMON Remote (15c2:ffdc): Don't know how to use
> device
> [217569.600] (EE) PreInit returned 8 for "iMON Remote (15c2:ffdc)"
> [217569.600] (II) UnloadModule: "evdev"
> ...
> 
> I've tried googling "evdev Don't know how to use device" but haven't found
> anything relevant. Does anyone have any clues about what I could be
> missing? It looks like xf86-input-evdev 2.10.5 went stable back in March
> 2017, and I'm pretty sure that the remote was working after that.

Sometime in autumn I had a similar symptom with a (non-gentoo) box running 
kodi here.  I had to reprogram the IR remote control handset, but wouldn't 
know how to go about it with yours ...
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] iMON remote, evdev, X and Kodi stopped working

[Manuel McLure]

Hi all, I'm having a problem with my Kodi system. Unfortunately I don't use
the Kodi system very often (the system also runs as a general server on my
network so most of my work on it is done through ssh) so I don't know
exactly when this happened, but it would have been in the last couple of
months.

The problem is that the iMON IR remote stopped working at some point. I
have an Antec Fusion Remote Black case that uses an iMON LCD and IR
receiver. This was working fine with evdev/X/Kodi but at some point stopped
working, and since I haven't used the Kodi interface for a few months I
don't know exactly what broke it.

It looks like the most interesting information comes from Xorg.0.log:

...
[217569.500] (II) config/udev: Adding input device iMON Remote (15c2:ffdc)
(/dev/input/event4)
[217569.500] (**) iMON Remote (15c2:ffdc): Applying InputClass "evdev
keyboard catchall"
[217569.500] (II) Using input driver 'evdev' for 'iMON Remote (15c2:ffdc)'
[217569.500] (**) iMON Remote (15c2:ffdc): always reports core events
[217569.500] (**) evdev: iMON Remote (15c2:ffdc): Device:
"/dev/input/event4"
[217569.500] (--) evdev: iMON Remote (15c2:ffdc): Vendor 0x15c2 Product
0xffdc
[217569.500] (WW) evdev: iMON Remote (15c2:ffdc): Don't know how to use
device
[217569.600] (EE) PreInit returned 8 for "iMON Remote (15c2:ffdc)"
[217569.600] (II) UnloadModule: "evdev"
...

I've tried googling "evdev Don't know how to use device" but haven't found
anything relevant. Does anyone have any clues about what I could be
missing? It looks like xf86-input-evdev 2.10.5 went stable back in March
2017, and I'm pretty sure that the remote was working after that.

-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft

[gentoo-user] Plasma device notifier shows wrong free space on USB disks

[Flavio Cappelli]

Hi,

I have the KDE plasma device notifier that shows always 1.2GB of free
space on all USB disks (HDD or flash drives). Such issue does not happen
on internals SATA HDD / SDD. This issue also prevents me to copy files
bigger then 1.2GB to any mounted USB disk using dolphin (but I can copy
the same big files using "cp" in konsole, and I can copy files smaller
than 1.2GB with dolphin). I'm sure it did not happen some months ago.


I tried with three different USB drives and the behavior is the same:

ￜ- 4GB flash drive on USB2 interface, vfat formatted, 3.3GB free
ￜ- 128GB flash drive on USB3 interface, exfat formatted, 107GB free
ￜ- 500GB external HDD on USB2 interface, ext4 formatted, 468GB free

The device notifier always shows 1.2GB of free space and I cannot copy
big files with dolphin to the USB disk.


I have kde-plasma 5.11.4 andￜ kde-framework 5.41.0 installed, but the
issue happened also with kde-plasma 5.10.5 and kde-framework 5.40.0.


What can I check to solve it?

Many thanks.


Flavio

Re: [gentoo-user] x2goclient-4.1 will not compile

[thelma]

On 01/03/2018 01:39 AM, Neil Bothwick wrote:
> On Tue, 2 Jan 2018 22:15:27 -0700, the...@sys-concept.com wrote:
> 
>> /usr/lib64/qt5/bin/lrelease res/i18n/x2goclient_de.ts
>> make: /usr/lib64/qt5/bin/lrelease: Command not found
>> make: *** [Makefile:537: x2goclient_de.qm] Error 127
>>  * ERROR: net-misc/x2goclient-4.1.0.1-r1::gentoo failed (compile phase):
>>  *   emake failed
> 
> The build log and output from emerge --info would help, especially to see
> which USE flags you are using - there is no default USE setting n Gentoo.
> 
> However, the missing file mentioned is part of dev-qt/linguist-tools, do
> you have that installed? If not, and it really is required to build 
> x2goclient, you should file a bug report.

Thanks for asking.  I just installed dev-qt/linguist-tools but now
getting bunch of other errors, it is a long list:

...
src/settingswidget.cpp:373:5: error: request for member ‘i’ in
‘_container_’, which is of non-class type ‘int’
 foreach(mw,identWins)
 ^
src/settingswidget.cpp:373:5: error: request for member ‘control’ in
‘_container_’, which is of non-class type ‘int’
 foreach(mw,identWins)
 ^
src/settingswidget.cpp:373:5: error: request for member ‘control’ in
‘_container_’, which is of non-class type ‘int’
 foreach(mw,identWins)
 ^
make: *** [Makefile:1009: connectionwidget.o] Error 1
make: *** Waiting for unfinished jobs
make: *** [Makefile:934: sharewidget.o] Error 1
make: *** [Makefile:964: mediawidget.o] Error 1
make: *** [Makefile:977: configwidget.o] Error 1
make: *** [Makefile:949: settingswidget.o] Error 1
make: *** [Makefile:1032: configdialog.o] Error 1
 * ERROR: net-misc/x2goclient-4.1.0.1-r1::gentoo failed (compile phase):
 *   emake failed

===
emerge --info '=net-misc/x2goclient-4.1.0.1-r1::gentoo'
Portage 2.3.13 (python 3.5.4-final-0, default/linux/amd64/13.0/desktop,
gcc-5.4.0, glibc-2.25-r9, 4.9.72-gentoo x86_64)
=
 System Settings
=
System uname:
Linux-4.9.72-gentoo-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9550_@_2.83GHz-with-gentoo-2.4.1
KiB Mem: 4046816 total,   2947360 free
KiB Swap: 524284 total,524284 free
Timestamp of repository gentoo: Mon, 01 Jan 2018 01:00:01 +
Head commit of repository gentoo: 92ebd81c9350cef726ebeda90a1a8309b8f147eb
sh bash 4.3_p48-r1
ld GNU ld (Gentoo 2.29.1 p3) 2.29.1
app-shells/bash:  4.3_p48-r1::gentoo
dev-java/java-config: 2.2.0-r3::gentoo
dev-lang/perl:5.24.3::gentoo
dev-lang/python:  2.7.14-r1::gentoo, 3.5.4-r1::gentoo
dev-util/cmake:   3.9.6::gentoo
dev-util/pkgconfig:   0.29.2::gentoo
sys-apps/baselayout:  2.4.1-r2::gentoo
sys-apps/openrc:  0.34.11::gentoo
sys-apps/sandbox: 2.10-r4::gentoo
sys-devel/autoconf:   2.13::gentoo, 2.69::gentoo
sys-devel/automake:   1.11.6-r2::gentoo, 1.15.1-r1::gentoo
sys-devel/binutils:   2.29.1-r1::gentoo
sys-devel/gcc:5.4.0-r4::gentoo, 6.4.0::gentoo
sys-devel/gcc-config: 1.8-r1::gentoo
sys-devel/libtool:2.4.6-r3::gentoo
sys-devel/make:   4.2.1::gentoo
sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers)
sys-libs/glibc:   2.25-r9::gentoo
Repositories:

gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-extra-opts:

brother-overlay
location: /var/lib/layman/brother-overlay
masters: gentoo
priority: 50

Local
location: /usr/local/portage
masters: gentoo
priority: 

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA googleearth PUEL dlj-1.1 Oracle-BCLA-JavaSE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc
/usr/share/easy-rsa /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release
/etc/php/apache2-php5.6/ext-active/ /etc/php/cgi-php5.6/ext-active/
/etc/php/cli-php5.6/ext-active/ /etc/revdep-rebuild /etc/sandbox.d
/etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d
/etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=nocona -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--autounmask-write=y --keep-going --with-bdeps=y"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs collision-protect
config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync
multilib-strict news parallel-fetch preserve-libs protect-owned sandbox
sfperms strict unknown-features-warn unmerge-logs unmerge-orphans
userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="ftp://ftp.gtlib.gatech.edu/pub/gentoo
http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror;
LANG="en_US.utf8"
LC_ALL="en_US.UTF-8"

Re: [gentoo-user] x11-terms/terminator to be terminated

[Dan Johansson]

On 2018-01-03 12:46, Neil Bothwick wrote:

On Wed, 03 Jan 2018 12:13:45 +0100, Dan Johansson wrote:


The reason I use terminator is it's "multi-session" support. I use it
to open eight ssh connections to eight different hosts and then use 
the

"Send to all" feature to execute the same command on all hosts (and
watch the output from all hosts simultaneously).

Any suggestion a good tool that can do this?


I used to use net-misc/clusterssh to do this but these days I do it 
with

tmux.


THX for the tmux tip (I know I have seen this before, but at my age the 
memory sometimes fails) - I have now implemented a simple script to 
replace my terminator setup.


Regards,
--
Dan Johansson,
***
This message is printed on 100% recycled electrons!
***

Re: [gentoo-user] x11-terms/terminator to be terminated

[Neil Bothwick]

On Wed, 03 Jan 2018 12:13:45 +0100, Dan Johansson wrote:

> The reason I use terminator is it's "multi-session" support. I use it
> to open eight ssh connections to eight different hosts and then use the 
> "Send to all" feature to execute the same command on all hosts (and 
> watch the output from all hosts simultaneously).
> 
> Any suggestion a good tool that can do this?

I used to use net-misc/clusterssh to do this but these days I do it with
tmux.


-- 
Neil Bothwick

You are about to give someone a piece of your mind,
something you can ill afford...


pgpTQIrOIL750.pgp
Description: OpenPGP digital signature

[gentoo-user] x11-terms/terminator to be terminated

[Dan Johansson]

Today I noticed that x11-terms/terminator is to be deleted from the tree 
and I was wondering if someone can recommend a replacement (in the 
portage tree)?


The reason I use terminator is it's "multi-session" support. I use it to 
open eight ssh connections to eight different hosts and then use the 
"Send to all" feature to execute the same command on all hosts (and 
watch the output from all hosts simultaneously).


Any suggestion a good tool that can do this?

Regards,
--
Dan Johansson,
***
This message is printed on 100% recycled electrons!
***

Re: [gentoo-user] x2goclient-4.1 will not compile

[Neil Bothwick]

On Tue, 2 Jan 2018 22:15:27 -0700, the...@sys-concept.com wrote:

> /usr/lib64/qt5/bin/lrelease res/i18n/x2goclient_de.ts
> make: /usr/lib64/qt5/bin/lrelease: Command not found
> make: *** [Makefile:537: x2goclient_de.qm] Error 127
>  * ERROR: net-misc/x2goclient-4.1.0.1-r1::gentoo failed (compile phase):
>  *   emake failed

The build log and output from emerge --info would help, especially to see
which USE flags you are using - there is no default USE setting n Gentoo.

However, the missing file mentioned is part of dev-qt/linguist-tools, do
you have that installed? If not, and it really is required to build 
x2goclient, you should file a bug report.


-- 
Neil Bothwick

Two rights don't make a wrong, they make an airplane.


pgpdTeqf8ksvB.pgp
Description: OpenPGP digital signature