[SOLVED] FC27 Failed to mount POSIX Message Queue, Kernel File System... after hard reset - permission denied
FedoraThis forum is for the discussion of the Fedora Project.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
FC27 Failed to mount POSIX Message Queue, Kernel File System... after hard reset - permission denied
My Fedora 27 x64 (4.14.14-300) runs on GB-BACE-3160 Brix PC. The PC uses 320GB HDD. The system is used as a simple server, so it works 24h.
From time to time - a few weeks or so - it freezes. HDD keeps writing something (repetitive, although irregular sound). No reaction to keyboard, mouse, remote SSH access. I have tried to leave it overnight, but it does not recover, so I am forced to hard reset it.
This time something has broken. Booting fails. It says: Failed to mount POSIX Message Queue File System,
Failed to start Remount and Kernel File Systems,
Failed to mount Kernel Debug File System,
Failed to mount Huge Pages File System
and lots of other failures comes after these.
See https://photos.app.goo.gl/qBUxT40zA2MTLTwO2
In emergency mode I have ran fsck. It says file systems are clean. SMART tests (Smartctl -h, short and long) found the disk to be perfectly healthy.
In all these cases Failed at step EXEC spawning /usr/bin/mount: Permission denied
is given as a reason.
What happen and how to fix this? What is causing system to freeze from time to time? How to diagnose it and prevent it?
If it fails regularly like that I'd suspect temperature - or maybe (less likely) memory. Should be something in the journal.
Boot an install iso and see if you can chroot into the on-disk F27 - that at least will enable you to see if the system/data looks ok. Maybe the initrd got corrupted by the automatic fsck at boot. Use dracut from the chroot to rebuild the initramfs and retry a boot.
Might be worth setting up a script to save the temps every hour or so - include the time.
I have used F27 in Live mode booted from USB stick to take a look at those not mounted partitions. They appeared as ready to mount disks on XFCE desktop. I was able to mount all of them and they looked just fine.
I am not familiar with chroot. I have never used it.
Quote:
Use dracut from the chroot to rebuild the initramfs and retry a boot.
I'm not sure how to do this. Could you be so kind and explain it or point to some references?
Just looking to see if the files are listed is not enough - you need to jump from the liveCD into the on-disk system. This is what a chroot does - you actually run from the disk so you can run file managers and pdf readers or whatever to ensure they run ok. Have a read of this for some background - you only need to do the bit under "Performing the chroot", but don't need the network, so maybe skip resolv.conf. Once in the chroot, run some programs, and when happy, simply run "sudo dracut" (no quotes) from a terminal. The Fedora wiki is a mess at the moment - try "man dracut" for info - use "q" to quit.
Note my sigline - you really need to ensure you have a valid backup prior to messing any more.
I have:
1. Backup boot, root, etc and other important files.
2. Followed steps described in "Performing chroot".
3. Checked mounted files. Didn't noticed anything wrong.
4. Ran dracut. It said "Cannot find module directory /lib/modules/4.13.9-300.fc27.x86_64/", so apparently it wanted to use Live kernel instead of the newest 4.15.14-300.fc27.x86_64 from mounted /mnt/boot
5. Checked kernel: uname -r -> 4.13.9-300.fc27.x86_64
6. cd into /mnt/boot
7. Ran dracut initramfs-4.15.14-300.fc27.x86_64.img 4.15.14-300.fc27.x86_64 --force
8. Verified initramfs was updated
9. exit chroot, umounted boot, proc, sys, dev, /mnt and rebooted.
Unfortunately it didn't change anything. The problem persists.
I have updated the system a few times, so I have 3 kernels. I have tried to boot each of them, but the system behaves just the same. I've added a movie showing system boot to the shared album linked in my initial post.
Have I done something wrong or simply it isn't the case? What else could I try?
Could it be all those file systems cannot be mounted as system doesn't recognize them as it's own? Maybe it sees them as foreign partitions and that is why permission is denied to mount them?
I've changed SELinux to Permissive mode in /etc/selinux/config and system booted, so I've checked local modifications to SELinux config files and file_contexts:
Code:
#semanage fcontext -C -l
fcontext SELinux type Context
/usr/bin/mount all files system_u:object_r:samba_share_t:s0
I have noticed context for the mount is suspicious.
The problem was, indeed, caused by improper file context of the /usr/bin/mount file: samba_share_t.
The file context change wasn't caused by some error due to hard reset, but... by my imprudent decision to follow the first suggestion of SELinux Alert Browser.
This first suggestion was to change /usr/bin/mount file context to samba_share_t to allow smbd to access getattr.
The solution was:
to delete invalid file context, restore default and relabel the file:
Code:
[root@atlas ~]# ls -Z /usr/bin/mount
system_u:object_r:samba_share_t:s0 /usr/bin/mount
[root@atlas ~]# semanage fcontext -d /usr/bin/mount
[root@atlas ~]# restorecon -v /usr/bin/mount
Relabeled /usr/bin/mount from system_u:object_r:samba_share_t:s0 to system_u:object_r:mount_exec_t:s0
[root@atlas ~]# ls -Z /usr/bin/mount
system_u:object_r:mount_exec_t:s0 /usr/bin/mount
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
