Bug 1406254 - rhel-import-state sets incorrect mode for /dev/shm when dracut places it in /run/initramfs/state
Summary: rhel-import-state sets incorrect mode for /dev/shm when dracut places it in /...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: initscripts
Version: 7.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: 7.4
Assignee: David Kaspar // Dee'Kej
QA Contact: Leos Pol
Filip Hanzelka
: 1405188 (view as bug list)
Depends On: 1347436 1392766
TreeView+ depends on / blocked
Reported: 2016-12-20 06:32 UTC by Supreet
Modified: 2021-06-10 11:46 UTC (History)
40 users (show)

Fixed In Version: initscripts-9.49.38-1.el7
Doc Type: Release Note
Doc Text:
rhel-import-state no longer changes access permissions for `/dev/shm/`, allowing the system to boot correctly Previously, problems during the boot-up process occurred due to the introduction of a new script in a *dracut* update. The new script changed the access permission to the `/dev/shm/` directory when the *dracut* utility placed the directory to the `/run/initramfs/state/`. With this update, rhel-import-state no longer changes the access permissions for `/dev/shm/`, and the system starts correctly.
Clone Of: 1347436
Last Closed: 2017-08-01 07:29:01 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2759321 0 None None None 2018-03-29 01:38:57 UTC
Red Hat Product Errata RHBA-2017:2286 0 normal SHIPPED_LIVE initscripts bug fix and enhancement update 2017-08-01 11:26:43 UTC

Description Supreet 2016-12-20 06:32:21 UTC
+++ This bug was initially created as a clone of Bug #1347436 +++

One of my customer faced this issue because of this extra file called "usr/lib/dracut/hooks/pre-trigger/03-lldpad.sh" which got included with latest dracut "dracut-033-463.el7" and changed the permission 1755 to /dev/shm

Though the workaround :

Solved the issue in 2 ways :

1) Either by masking the rhel-import-state.service


2) By removing usr/lib/dracut/hooks/pre-trigger/03-lldpad.sh from initramfs and repacking the initramfs.

But still customer wants the fix for RHEL 7 builds as this file is included in all UEFI machines

Comment 2 Colin.Simpson 2016-12-21 18:15:11 UTC
We see this. On Desktops it causes chrome to fail, was how we first noticed it:

shm_open() failed: Permission denied [20860:20860:1109/094549:ERROR:shared_memory_posix.cc(290)] Creating shared memory in /dev/shm/.com.google.Chrome.0RxfmG failed: Permission denied [20860:20860:1109/094549:ERROR:shared_memory_posix.cc(293)] Unable to access(W_OK|X_OK) /dev/shm: Permission denied [20860:20860:1109/094549:FATAL:shared_memory_posix.cc(295)] This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 1777 /dev/shm' to fix. Abort (core dumped) 

But more surprised more people haven't seen or reported this issue, you'd think a lot of software would rely on this. It would seem to be quite a significant issue.

Comment 3 Adam Williamson 2016-12-21 18:24:19 UTC
Colin: the bug likely doesn't affect all systems; it comes down to whether /dev/shm is in /run/initramfs/state or not. dracut might put it there, or it might not; there are both legitimate reasons and at least one bug which caused it to be placed there when it wasn't really needed, which was the case we ran into with Fedora UEFI live installs.

The immediate fix is to change initscripts as it was changed in F25, so that when /dev/shm is synced from /run/initramfs/state to the 'real' root, its permissions are correct. But you may also want to look into why /dev/shm is showing up in /run/initramfs/state for you in the first place and figure if it's a legitimate reason or a bug in dracut. If you're using FCoE, for instance, it's there for a legitimate reason.

Comment 4 Colin.Simpson 2016-12-21 18:44:13 UTC
Interesting, we don't use FCoE, but some packages may have crept onto some machines. But I can't see which one would trigger this. 

I thought maybe fcoe-utils but I see anaconda-core needs this, so I can't remove that one.

Comment 5 Adam Williamson 2016-12-21 18:51:13 UTC
if you're interested to figure it out you kinda have to dig into the dracut source, which is...a bunch of shell scripts with a whole bunch of their own conventions. it's so much fun!

From the original comment on this bug it sounds a bit like perhaps an EL7 update did something inadvisable, but I don't work on RHEL so I haven't looked at it in detail. You might want to look at that /usr/lib/dracut/hooks/pre-trigger/03-lldpad.sh file, though, and see if it looks like it might be the culprit for you too. If it causes the dracut 'lldpad' module to be included, then it's likely the culprit - any path which causes that module to be included will result in /dev/shm being in /run/initramfs/state .

I don't know how 'conditional' the impact is (i.e. whether any EL 7 install with that file will have the problem, or if there's some kind of test in the file which means only certain systems will be affected). Supreet probably would have more info. It sounds like this may be similar to the case in Fedora, where it would affect any UEFI install if all the packages needed by the dracut 'fcoe' module are installed.

Comment 6 Colin.Simpson 2016-12-21 19:15:38 UTC

I think the  /usr/lib/dracut/hooks/pre-trigger/03-lldpad.sh is the cuprit as /dev/shm/ contains lldpad.state. 

But, I wonder if simply having an UEFI system is enough to trigger this chain of events?

Comment 7 Adam Williamson 2016-12-21 20:00:30 UTC
If RHEL 7's current dracut does not have this issue fixed:


then yes, just having that hook on a UEFI install with all the packages required for the dracut fcoe module would likely trigger it.

It sounds like RHEL 7 just needs the same fixes we applied to Fedora: firstly fix initscripts to set the mode correctly when transferring the directory, and secondly fix dracut not to enable the fcoe module on any UEFI system.

Comment 8 Colin.Simpson 2016-12-22 10:46:49 UTC
This is a regression as this doesn't happen in 7.2. Given this and that there is a Fedora fix already, is a patch on the way, or do we need to open a support case?

Comment 9 Michal Sekletar 2016-12-22 11:17:17 UTC
(In reply to Colin Simpson from comment #8)
> This is a regression as this doesn't happen in 7.2. Given this and that
> there is a Fedora fix already, is a patch on the way, or do we need to open
> a support case?

Please open a support case.

Comment 10 Colin.Simpson 2016-12-22 11:37:59 UTC
Opening the support case leads to a KB article that suggests a workaround:


(this also suggests another bug report on this issue that is private). 

But this KB Article is WRONG in scope. It effects *ALL* UEFI systems and not just ones that have FCoE, due the the FCoE modules being included on any UEFI system.  But I guess the workaround should work.

Comment 12 Michal Sekletar 2016-12-22 12:39:49 UTC
Patch from Fedora could be easily backported.

Comment 13 Lukáš Nykrýn 2017-01-02 14:33:10 UTC
*** Bug 1405188 has been marked as a duplicate of this bug. ***

Comment 25 errata-xmlrpc 2017-08-01 07:29:01 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.