authorisation is not available check polkit running and reboots

Issue with one of my hosts running RHES7.7 as below

cat /etc/redhat-release

Red Hat Enterprise Linux Server release 7.7 (Maipo)
I have two hosts running RHES7.7. One of them encountered this issue after reboot. Sending message

authorisation is not available check polkit running

This basically means network service etc is not running as well. So I can only access this host through console. I can log in after giving root password for maintenance and data etc is there. I tried to start polkit with systemctl restart polkit but just fails with the above message and reboots. Appreciate any advice.

P.S. When I ran journalctl -u polkit, I got "no entries"!

Thanks

update

This is the error I am getting

enter image description here

thanks please find the outputs requested. sorry i can only access the host through the console

enter image description here

enter image description here

enter image description here

Asked By: Mich Talebzadeh

||

The authorisation is not available check polkit running is a red herring: the system appears to have dropped into emergency mode, where only very minimal system services are running. In this state, having polkit.service not running is normal and expected.


The first listed error message is from the kernel:

nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 122124

is about Nouveau, the open-source NVidia GPU driver. Have you been using it, or the proprietary (closed-source) driver from NVidia? What graphics hardware does your host have?

It is possible (even likely, see below) that this message is not related to your current problem. It might be just "noise" particular to your specific hardware and its current state of driver support.


The second message is from systemd-udevd:

Error running install command for rtl_pci

This is self-inflicted, as you have install rtl_pci /bin/false in your /etc/modprobe.d/local-blacklist.conf to prevent the rtl_pci module from loading: it causes the error message as a side effect.

If you want to get rid of the error message, you could replace the /bin/false in local-blacklist.conf with /bin/true. That would tell the system that leaving the module unloaded is not an error.


The third message might be the reason your system is dropping into emergency mode. It is from systemd, and after decoding the hexadecimal escapes, it looks like this:

Timed out waiting for device dev-disk-by-label-/apps.device.

That refers to /dev/disk/by-label//apps, or in other words, a filesystem with label /apps. According to your /etc/fstab, it should be an ext4-type filesystem that’s supposed to be mounted to /apps.

All the other filesystems listed in /etc/fstab have been successfully mounted, except /apps. And based on your lsblk output, it seems it could only be at /dev/sdd – there is no other device that is likely to contain an unmounted ext4 filesystem.

But according to lsblk, that disk has no partitions – have you initialized the whole disk as a single filesystem? If not, it’s possible the disk’s partition table may have been corrupted/overwritten, or the disk may have failed.

systemctl status apps.mount and/or journalctl -u apps.mount might provide more information on what went wrong with the mount attempt.

Unlike earlier RHEL releases with different init systems, the systemd-based RHEL 7.x will drop into emergency mode if any filesystem listed in /etc/fstab fails to mount, unless that filesystem has the noauto or nofail mount option. So the failure to mount /apps is the most likely reason the system is dropping into emergency mode.

You might temporarily comment out the last line of /etc/fstab and reboot to get the system into a more normal state: that should make further diagnosis and recovery easier.


You might want to start troubleshooting /dev/sdd by first verifying its health with smartctl -x /dev/sdd. If it indicates the disk is failing, it’s definitely time to order a new disk and ideally plan on restoring /apps from a good backup. But if smartctl does not indicate the disk as failing, it might not be the whole truth: disks can fail in ways smartctl cannot always detect.

(If you don’t have a good backup, and the data on /apps has significant value, it is time to decide whether you want to use professional data recovery services, or to try and recover the data yourself. )

If you know /dev/sdd should have a partition table, testdisk might be a good tool for trying to recover it:

yum install epel-release
yum update
yum install testdisk
testdisk /dev/sdd

If you know for certain that the whole disk /dev/sdd has been initialized as a single ext4 filesystem, you might try

e2fsck -C0 /dev/sdd

If the tool starts asking you questions (indicating there’s a problem it cannot reliably fix automatically), you should abort the check and create an image of the disk first.

Note: this command assumes that the device you point it at should contain an ext2/ext3/ext4 filesystem, and acts accordingly. If it does not find a valid superblock, it might be because the beginning of the disk has been corrupted or overwritten… or because the filesystem simply does not start at the beginning of the disk.

If you are uncertain, or if the disk shows any symptoms of hardware failure, your first priority should be to try and image the failing disk ASAP using ddrescue or a similar tool. You’ll also need another disk of suitable size to store the image of the potentially-failing disk.

Answered By: telcoM
Categories: Answers Tags: ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.