Re: [gentoo-user] Is udev-mount still valid?

[Floyd Anderson]

On Fri, 13 Apr 2018 11:01:40 +0100
Mick  wrote:


[…]

Yes, the broken symlinks are from the sysinit runlevel.  I checked another
system of mine and it *also* has these broken symlinks ...  :-/

So, whatever mistake I made, I must have made it at least twice!  LOL!


I think this is nothing special and not your fault. I vaguely remember 
having broken symlinks in runlevels too – was it also tmpfiles.dev or 
udev-mount? I cannot recall it but I’m sure about those in folder 
/etc/ssl/certs or regarded to the packages media-libs/mesa and 
x11-libs/libXvMC for example.



Shouldn't the openrc or udev ebuild remove the symlinks, back when they became
depracated?


In a perfect world …
But I can well believe how hard it is to keep track of probably 
externally changed symlinks or similar. Most of the time it works and 
while at it, I like to say “thanks!”. Sporadically and being in 
housekeeping mode, I run something like:


   # find /{etc,lib,usr,var} -path /etc/config-archive -prune -o \
   -type l -xtype l -print

to obtain exceptional cases but ignoring prior sanitised stuff.


[…]

Thank you for these symlinks Floyd,


I posted those s/symlinks/links/ ;-) only for conveniently mouse 
clicking, maybe you can find more relevant things by a recursive grep 
search in:


 "$(portageq get_repo_path / gentoo)/metadata/news/"

I am using '/dev/sda1' notation for partitions in /etc/fstab, rather 
than any of the /dev/disk/by-* symlinks.


…and probably also in:

 /lib/udev/rules.d/

because rules using “*/by-*” syntax for their ‘SYMLINK+="..."’ foo for 
your re-plugged devices – as you can see with:


 $ udevadm monitor -u -p


udev-settle is not in my sysinit runlevel.


As it is supposed to be:

 “udev and udev-trigger will be added to your sysinit runlevel, but not
 udev-settle. udev-settle should not be added to a runlevel. Instead, if
 a service needs this, it should add "need udev-settle" to its
 dependencies.”

by the 2015-06-08-udev-init-scripts-changes.en.txt news.


--
Regards,
floyd

Re: [gentoo-user] Kernel module signature now shown on modinfo

[Mick]

On Thursday, 12 April 2018 22:47:31 BST Dave Trombley wrote:
> This has been broken for almost two years; the signature format switched to
> PKCS#7 and modinfo doesn't support it.   It's not as simple as just
> patching kmod because evidently the kernel change regressed or disrespected
> the relevent structure in the modules in a way that makes it impossible for
> kmod to even make sense of.   Details here:
> https://github.com/coreos/bugs/issues/1054
> 
> -David

Thanks David, I had come across an older bug somewhere, but there was no 
detailed explanation.

-- 
Regards,
Mick

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

Re: [gentoo-user] x11-drivers/nvidia-drivers-391+ does not support latest GPU?

[Arve Barsnes]

On 12 April 2018 at 15:31, Alexey Eschenko  wrote:
> I'm very surprised because I have GTX 1080 GPU:
>
>> # lspci | fgrep VGA
>> 42:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX
>> 1080] (rev a1)

This seems to be a bug in the nvida-drivers.eclass file. I have the
same card, and it is NOT going out of support now. If you look at the
link from the ebuild error message, our card is not one of the cards
on any of the "legacy cards" lists. If you search for drivers on
https://www.geforce.com/drivers you will see that this new beta driver
is available for our card.

I'm not sure if this bug is because the eclass checks these cards
against any version higher than 391 and complains, in which case
*everyone* will get the error message, or if something else is going
on, but I feel confident that this driver should work fine for you
(consider that it's a beta driver though).

Arve

Re: [gentoo-user] Re: x11-drivers/nvidia-drivers-391+ does not support latest GPU?

[Alexey Eschenko]

Before updating the nvidia driver, you should always check here: 
Yes I've checked. That's why I was surprised by Portage build log. I 
didn't build nvidia-drivers manually for a long time and do not remember 
where this GPU checks are (ebuild or driver package).


I didn't think that this driver will not work with my GPU. I was 
confused by the message and wanted to report. If it's ebuild-side 
problem then must I create an issue in the Bugzilla?



On 04/12/2018 10:01 PM, Nikos Chantziaras wrote:

On 12/04/18 16:31, Alexey Eschenko wrote:
Is this some kind of maintainer's mistake or does NVIDIA really 
messed up with drivers again?


Before updating the nvidia driver, you should always check here:

  http://www.nvidia.com/Download/Find.aspx

and see if the version you're updating to is a beta driver or not.

As a long time nvidia-drivers user, I really recommend to:

  1. Use an LTS kernel series (latest LTS series is 4.14.x.)
  2. Do not install nvidia beta drivers.
  3. Do not use X.Org pre-releases.

Currently, that means these in package.mask:

  >=sys-kernel/gentoo-sources-4.15
  >=x11-drivers/nvidia-drivers-391
  >=x11-base/xorg-server-1.19.99

Unless you're using Chrome, where 390 has a bug that makes it unusable 
slow, so you need:


  >=x11-drivers/nvidia-drivers-385

You need to check on the available versions these packages manually 
from time to time to see if it's safe to update them.


Also, nvidia driver version can be confusing. 390 is the latest stable 
series, while 384 is the "LTS-like" stable series. To be frank, I find 
it impossible to tell what's happening with driver releases from 
nvidia if I don't read phoronix.com news.


In any event, the TL;DR is that sticking to non-beta drivers and 
non-beta xorg and the latest LTS kernel will result in avoiding the 
majority of breakages.





--
Kind regards,
Alexey Eschenko
https://skobk.in/

Re: [gentoo-user] Is udev-mount still valid?

[Mick]

On Tuesday, 10 April 2018 19:50:12 BST Floyd Anderson wrote:
> On Tue, 10 Apr 2018 17:11:17 +0100
> 
> Mick  wrote:
> >I've noticed udev has been playing up lately.  In particular, switching on
> >wireless/bluetooth would cause udev to be pegged to 100% CPU and bluetooth
> >won't work.  USB won't work thereafter; e.g. unplugging a USB mouse and
> >replugging it is not detected.
> >
> >I had a look at /etc/runlevels and noticed two broken symlinks:
> >
> >lrwxrwxrwx 1 root root   24 Nov 25  2013 tmpfiles.dev -> /etc/init.d/
> >tmpfiles.dev
> >lrwxrwxrwx 1 root root   22 Oct 26  2012 udev-mount ->
> >/etc/init.d/udev-mount
> >
> >The following two symlinks in the same runlevel are valid:
> >
> >lrwxrwxrwx 1 root root   16 May  2  2011 udev -> /etc/init.d/udev
> >lrwxrwxrwx 1 root root   24 Feb 25  2017 udev-trigger -> /etc/init.d/udev-
> >trigger
> 
> Not sure which runlevel(s) you’re listing here but if I read the
> sys-apps/openrc-0.35.5.ebuild correct, the expected runlevel for your
> broken ones is sysinit. I’m using OpenRC and haven’t these files, so
> same as Ian wrote.

Yes, the broken symlinks are from the sysinit runlevel.  I checked another 
system of mine and it *also* has these broken symlinks ...  :-/

So, whatever mistake I made, I must have made it at least twice!  LOL!

Shouldn't the openrc or udev ebuild remove the symlinks, back when they became 
depracated?


> >I'm not saying the above missing symlinks are causing the bluetooth
> >problem, but those symlinks should not be there.  Have I missed some
> >enotice to remove these two symlinks, or is something borked in my system?
> 
> Maybe [1][2][3] are relevant here.
> 
> 
> 
> References:
>   [1]
>  nges.html> [2]
>  t-and-netmount-changes.html> [3]
>  ocalmount_update.html>


Thank you for these symlinks Floyd, I am using '/dev/sda1' notation for 
partitions in /etc/fstab, rather than any of the /dev/disk/by-* symlinks.  
Also, udev-settle is not in my sysinit runlevel.
-- 
Regards,
Mick

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

Re: [gentoo-user] Kernel module signature now shown on modinfo

[Mick]

On Wednesday, 11 April 2018 21:39:30 BST Ben Mezger wrote:
> Greetings,
> 
> I have enabled module signature verification on my kernel, and it does
> seem to be enabled upon boot:
> 
> $  dmesg | grep -i 'x.*509'
> [1.259988] Asymmetric key parser 'x509' registered
> [1.811026] Loading compiled-in X.509 certificates
> [1.813833] Loaded X.509 cert 'Build time autogenerated kernel key:
> 77e716fc52a6293567d953cd24a5977e55b41a5e'
> 
> and doing a cat /proc/keys seems to show the key enabled:
> 
> $ cat /proc/keys
> ...
> 37c67374 I-- 1 perm 1f03 0 0 asymmetri Build time
> autogenerated kernel key: 77e716fc52a6293567d953cd24a5977e55b41a5e:
> X509.rsa 55b41a5e []
> ...
> 
> However, if I do a modinfo to see the key on a module, it seems empty:
> 
> $modinfo ntfs
> filename:   /lib/modules/4.9.76-gentoo-r1/kernel/fs/ntfs/ntfs.ko
> license:GPL
> version:2.1.32
> description:NTFS 1.2/3.x driver - Copyright (c) 2001-2014 Anton
> Altaparmakov and Tuxera Inc.
> author: Anton Altaparmakov 
> alias:  fs-ntfs
> srcversion: 0D7ACE93F603E9350827FB8
> depends:
> intree: Y
> vermagic:   4.9.76-gentoo-r1 SMP mod_unload
> signat: PKCS#7
> signer:
> sig_key:
> sig_hashalgo:   md4

I am getting a similar output with later source kernel than yours:

# modinfo ntfs
filename:   /lib/modules/4.15.17-gentoo/kernel/fs/ntfs/ntfs.ko.gz
license:GPL
version:2.1.32
description:NTFS 1.2/3.x driver - Copyright (c) 2001-2014 Anton 
Altaparmakov and Tuxera Inc.
author: Anton Altaparmakov 
alias:  fs-ntfs
srcversion: B6DF5EBF4EF8B063988F5CB
depends:
retpoline:  Y
intree: Y
name:   ntfs
vermagic:   4.15.17-gentoo SMP preempt mod_unload 
signat: PKCS#7
signer: 
sig_key:
sig_hashalgo:   md4

Which I find quite confusing.  Not only the keys are not shown, but the 
sig_hashalgo is md4 (cracked since 1995) instead of the SHA512 I had specified 
in my kernel .config.


> And hex dump does show me the digital signature appended at the end:
> 
> $ hexdump -C /lib64/modules/4.9.76-gentoo-r1/kernel/fs/ntfs/ntfs.ko| tail
> 0004e8c0  e3 dd 54 9d 5e f1 1a 12  56 47 4e 54 91 b9 fa ce 
> |..T.^...VGNT| 0004e8d0  e6 01 db 37 eb 83 f3 77  10 f0 b5 f8 11 fd 4e
> 86  |...7...w..N.| 0004e8e0  6c 81 8a 61 c2 15 6d 5a  35 93 8b 33 c0 32
> 2f e4  |l..a..mZ5..3.2/.| 0004e8f0  8c 15 71 de c8 c5 39 58  cc e8 65 e1 be
> 36 e6 02  |..q...9X..e..6..| 0004e900  b0 75 b5 a2 73 d8 4d 22  e7 2f 53 1f
> 42 fb ee 58  |.u..s.M"./S.B..X| 0004e910  f2 65 44 13 26 30 7b 31  1c 58 12
> 5a f2 5d b1 45  |.eD.&0{1.X.Z.].E| 0004e920  3a f0 a5 79 74 f4 00 00  02 00
> 00 00 00 00 00 00  |:..yt...| 0004e930  02 9e 7e 4d 6f 64 75 6c  65
> 20 73 69 67 6e 61 74  |..~Module signat| 0004e940  75 72 65 20 61 70 70 65 
> 6e 64 65 64 7e 0a|ure appended~.| 0004e94e
> 
> My question is: why doesn't modinfo show me the key fingerprint?

I don't know the answer, but would be interested to find out.  I have only 
used kernel autogenerated keys to do this, so I can't attest if the result is 
the same when creating own keys manually.

-- 
Regards,
Mick

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