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] 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] Is udev-mount still valid?

[Floyd Anderson]

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.



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] 

 [2] 

 [3] 




--
Regards,
floyd

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

[Dale]

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
>
> 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?
>


If it helps any, I have this:

root@fireball / # /etc/init.d/udev  
udev  udev-settle   udev-trigger 
root@fireball / # /etc/init.d/udev

Dale

:-)  :-)