Elogind boot errors with Current

upnort · 12-13-2020, 12:17 PM

After updating my Current VM yesterday I see the following error messages:

Code:

udevd[211]: failed to execute '/lib64/elogind/elogind-uaccess-command' '/lib64/elogind/elogind-uaccess-command /dev/sr0 ': No such file or directory
sshd[1792]: gkr-pam: unable to locate daemon control file

I don't see anything obvious in the change log.

In /etc/ssh/sshd_config, UsePAM=yes. A little searching indicates 'gkr-pam' has something to do with GNOME keyring?

The sshd seems to be a red herring. When I disable rc.sshd I see the error on login.

The errors appear booting to runlevel 3. X is not involved. When rc.S executes /dev/sr0 exists. Nominal digging indicates the elogind error is generated from the initrd.

teoberi · 12-13-2020, 12:44 PM

I confirm the same problem with udevd!
I found something here:
https://forums.gentoo.org/viewtopic-...0-start-0.html
I'm still trying to find a solution.

LuckyCyborg · 12-13-2020, 12:48 PM

Quote:

Originally Posted by teoberi

I confirm the same problem with udevd!
I found something here:
https://forums.gentoo.org/viewtopic-...0-start-0.html
I'm still trying to find a solution.

You just need to add /lib64/elogind/elogind-uaccess-command to initrd.

teoberi · 12-13-2020, 12:55 PM

Quote:

Originally Posted by LuckyCyborg

You just need to add /lib64/elogind/elogind-uaccess-command to initrd.

Have you tried this?
I don't have a virtual machine for test.

LuckyCyborg · 12-13-2020, 01:07 PM

Quote:

Originally Posted by teoberi

Have you tried this?
I don't have a virtual test machine.

Isn't obvious that this command is missing from initrd?

Honestly, I do not bothered about this error message, since I do not used a DVD or CD at least 5 years.

BTW, please note that /dev/sr0 is the first DVD or CD device and that error significance is that your DVD or CD device will not be available on initrd, but it still will be properly setup by the real system.

BUT, if this error really disturbs you, feel free to add this missing command and its associated libraries to initrd.

By hand, because apparently this is the Slackware way, according with the elder ones, when I tried to discuss about further improvements on initrd's abilities to be customized.

teoberi · 12-13-2020, 01:19 PM

Quote:

Originally Posted by LuckyCyborg

Isn't obvious that this command lacks from initrd?

It is obvious that this option is missing but I hope it will be solved soon.

Code:

mkinitrd --help

Quote:

mkinitrd creates an initial ramdisk (actually an initramfs cpio+gzip
archive) used to load kernel modules that are needed to mount the
root filesystem, or other modules that might be needed before the
root filesystem is available. Other binaries may be added to the
initrd, and the script is easy to modify. Be creative. :-)

ZhaoLin1457 · 12-13-2020, 02:13 PM

Why we need the DVD device to be functional while running the initrd?

upnort · 12-13-2020, 02:34 PM

I am able to stop the gkr-pam errors by commenting out the following in /etc/pam.d/system-auth:

Code:

#-session     optional      pam_gnome_keyring.so auto_start

Poking around the web and looking at PAM in some other distros, I think perhaps auto starting that PAM module should be reserved for modules related only to X rather than global.

upnort · 12-13-2020, 02:43 PM

I am able to stop the elogind error by copying /lib64/elogind to /boot/initd-tree and using the mkinitrd -u option.

While that solution eliminates the error spew, seems this should just not happen at all. I've never seen this error with other distros.

Alien Bob · 12-13-2020, 02:58 PM

Quote:

Originally Posted by upnort

I am able to stop the elogind error by copying /lib64/elogind to /boot/initd-tree and using the mkinitrd -u option.

While that solution eliminates the error spew, seems this should just not happen at all. I've never seen this error with other distros.

You still approach Slackware-current as if it were a stable release of an Enterprise Edition OS.
This is a Slackware's development environment you are using. If you run into a new issue caused by a disruptive mega update in the distro, you report it and ideally you accompany your report with the fix. If you don't have a fix, then you work with others here in the forum to find out what happened, what caused it and what fixes it. Win-win.

I spit on comments like "this should not happen at all, I've never seen this error with other distros".

upnort · 12-13-2020, 03:06 PM

Geez, Eric, I am treating Current as a development branch. I've been using Slackware for 15 years. I did report the bug. I did note a solution. My comparison to other distros was to note that perhaps the bug is unique to Slackware.

I see no reason to spit.

avian · 12-13-2020, 09:34 PM

Quote:

Originally Posted by upnort

I am able to stop the gkr-pam errors by commenting out the following in /etc/pam.d/system-auth:

Code:

#-session     optional      pam_gnome_keyring.so auto_start

Poking around the web and looking at PAM in some other distros, I think perhaps auto starting that PAM module should be reserved for modules related only to X rather than global.

Another option is to add "only_if=gdm,sddm,xdm" to the end of both "pam_gnome_keyring.so" lines.. i.e.

Code:

auth        optional      pam_group.so
auth        required      pam_unix.so likeauth nullok
-auth       optional      pam_gnome_keyring.so only_if=gdm,sddm,xdm

...
...
...

session     required      pam_limits.so
session     required      pam_unix.so
#session     required      pam_lastlog.so showfailed
#session     optional      pam_mail.so standard
-session     optional      pam_gnome_keyring.so auto_start only_if=gdm,sddm,xdm

This was suggested to me in a thread where I asked about similar errors when using dovecot. Its also stopped the same errors being spit out for afpd and a few other services. Seems to work a treat.

teoberi · 12-17-2020, 01:46 AM

After all, what do we do with the elogind boot error?
1. we leave it as is now;
2. one of those who modified the /sbin/mkinitrd file, ie Eric Hameleers, Robby Workman or Patrick Volkerding make the necessary additions;
3. each of us makes the changes we wants.

From my point of view the changes could be:
1. adding a new option for mkinitrd (eg -e);
2. adding a new block of code for elogind to the /sbin/mkinitrd file after the section

Quote:

# Include udev in initrd

just like here
section

Quote:

# Install libraries

Alien Bob · 12-17-2020, 02:06 AM

Please see https://alien.slackbook.org/blog/tod...#comment-38981 where gegechris99 informed me that I needed to fix my elogind-compat32 package which caused the above error.
In other words, this error should only happen if you have multilib installed.
Solution: reinstall elogind-compat32 (my fixed package!) and then reinstall elogind.

LuckyCyborg · 12-17-2020, 02:14 AM

Quote:

Originally Posted by Alien Bob

Please see https://alien.slackbook.org/blog/tod...#comment-38981 where gegechris99 informed me that I needed to fix my elogind-compat32 package which caused the above error.
In other words, this error should only happen if you have multilib installed.
Solution: reinstall elogind-compat32 (my fixed package!) and then reinstall elogind.

No, it happens also in pure 64bit Slackware, when is acttivated the option to add the eUDEV to initrd.

I suspect that it is generated by some elogind rules for eudev, which probably should be blacklisted.

BTW, I believe that would be extremely useful if /sbin/mkinitrd will read its LIBUDEV_BLACKLIST from a config file.