Bug 862626 - /.autorelabel gets recreated and file system gets relabelled on every boot
/.autorelabel gets recreated and file system gets relabelled on every boot
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-10-03 07:55 EDT by Fikret Skrgic
Modified: 2013-08-01 07:25 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-01 07:25:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Fikret Skrgic 2012-10-03 07:55:19 EDT
Description of problem: /.autorelabel gets recreated and file system gets relabelled on every boot

Version-Release number of selected component (if applicable): 2.1.10-3.fc17.x86_64

How reproducible: Disable selinux and everytime you reboot the booting takes an eternity. If you delete /.autorelabel, it will be there after a reboot.

Steps to Reproduce:
1. Disable selinux and reboot at least once to allow relabelling
2. Reboot or even also delete /.autorelabel, which shouldn't be there ate this point anyway.
3. Reboot.
Actual results: Booting takes forever, relabelling takes place, and something, I couldn't figure out what, recreates /.autorelabel.

Expected results: Being selinux-free, completely untortured by it, and tranquillity. The system booting fast.

Additional info: I really do not care about selinux. It has no use for me whatsoever. The only relevant effect of it being omnipresent is that I have to deal with this annoyance. If I don't disable it, I am guaranteed to experience problems and something will not work. I have learned that a long time ago. So, the first thing I do after I install Fedora is disabling selinux. That has worked quite OK for quite a while. Not any more. If someone can, please, tell me what creates /.autorelabel, I would appreciate it a lot. Unfortunately it's impossible to remove selinux altogether. I removed everything besides libselinux and it still didn't help. How can I prevent this relabelling?

Please, spare me the explanations how selinux is good and I should enable it. I have no intention of learning how to deal with it. I just want to use my computer and it would work perfectly, everything does, if there was no selinux. There might be some people out there who actually benefit from it, but the vast majority of us are just suffering the consequences. If this cannot be made completely optional, removable, and non-intrusive, it's simply not an acceptably good implementation of what it is supposed to be. One should be able to uninstall it completely. Selinux prevents Linux from being used by people who do not have degrees in computer science. I don't think my wife would be able to report this problem. Selinux would simply render her computer unusable. I have a degree in computer science and I still cannot figure out how to deal with this. But that's not the point. I should be able to use the computer without studying selinux. Even if I studied it, and I had to to some extent just to be able to reach this point in the diagnosis, I shouldn't have to.
Comment 1 Daniel Walsh 2012-10-06 08:16:06 EDT
Thank you for your support.

Relabeling should never happen on a disabled SELinux box?  I have not heard of this bug before.

You could try to disable this service.


If this is happening to everyone it is a serious bug, in systemd.
Comment 2 Daniel Walsh 2012-10-08 10:53:10 EDT
I can not get this to happen on my F18 box.
Comment 3 Fikret Skrgic 2012-10-08 11:26:50 EDT
I managed to stop the recreation of /.autorelabel by deleting the files below and replacing them with symbolic links to /dev/null.

rm /usr/lib/systemd/system/fedora-autorelabel-mark.service
rm /usr/lib/systemd/system/fedora-autorelabel.service

ln -s /dev/null /usr/lib/systemd/system/fedora-autorelabel-mark.service
ln -s /dev/null /usr/lib/systemd/system/fedora-autorelabel.service

Trying to disable them, didn't help:

systemctl disable fedora-autorelabel.service
systemctl disable fedora-autorelabel-mark.service

/.autorelabel was still always recreated. With the files removed I verified that it doesn't get created any more.

It is better now, but not perfect.

[root@turing fskrgic]# systemd-analyze blame 
  9913ms network.service
  6055ms udev-settle.service
  5199ms home.mount
  1915ms lvm2-monitor.service
  1853ms fedora-storage-init-late.service
  1843ms fedora-readonly.service
  1592ms fedora-loadmodules.service
  1574ms systemd-logind.service
  1549ms avahi-daemon.service
  1495ms jetty.service
  1316ms colord-sane.service
  1254ms colord.service
  1209ms systemd-vconsole-setup.service
  1123ms media.mount
  1114ms abrt-vmcore.service
  1077ms dev-hugepages.mount
  1074ms fedora-storage-init.service
  1065ms dev-mqueue.mount
  1051ms sendmail.service
  1049ms udev-trigger.service
  1049ms sys-kernel-debug.mount
  1021ms udev.service
   825ms systemd-remount-fs.service
   821ms sshd.service
   786ms rtkit-daemon.service
   508ms sys-kernel-config.mount
   442ms upower.service
   423ms bluetooth.service
   336ms systemd-readahead-collect.service
   312ms systemd-readahead-replay.service
   298ms console-kit-log-system-start.service
   250ms boot.mount
   179ms systemd-user-sessions.service
   172ms gpm.service
   165ms irqbalance.service
   138ms acpid.service
   115ms mcelog.service
    98ms console-kit-daemon.service
    96ms mdmonitor.service
    93ms mdmonitor-takeover.service
    79ms sm-client.service
    64ms dbus.service
    47ms rc-local.service
    32ms systemd-sysctl.service
    28ms fedora-wait-storage.service
     5ms rpcbind.service
     1ms sys-fs-fuse-connections.mount

Something is fishy anyway. As hardware gets faster and faster, booting should also become faster and faster. I remember reading about how systemd would improve the boot time. I see the opposite. I think that there's a trend of everything getting steadily slower in the decade (on roughly as fast hardware as available at the time) including desktop environments. Selinux, IMHO, is the biggest mistake in the history of Linux. It's just such a bad idea I am really surprised the usually conservative crowd dealing with the guts of the system accepted it. It's just like not being able to remove Internet Explorer from Windows. Actually, it's worse, since this has very limited usage. It's barely useful to anyone.
Comment 4 Daniel Walsh 2012-10-09 11:50:22 EDT
The creation of .autorelabel is not the problem.  Since this should be created on a disabled machine.  The init script paying attention to /.autorelabel on a disabled SELinux machine is the problem.

I find systemd with a Solid State Drive to be very fast in booting, on a regular disk, it is not going to speed up the machine.

Reassigning to initscripts, since this is not an selinux-policy issue.
Comment 5 Bill Nottingham 2012-10-09 12:00:48 EDT
.autorelabel creation is predicated on booting without selinux; that's entirely expected.

However, fedora-autorelabel.service has:


so it shouldn't even be running if SELinux is disabled. Moving to systemd... when you see a boot taking forever, what do you get for 'systemctl status fedora-autorelabel.service'?
Comment 6 Michal Schmidt 2012-10-09 12:10:16 EDT
How *exactly* did you disable SELinux?

On a side note:

> ln -s /dev/null /usr/lib/systemd/system/fedora-autorelabel.service

Modifying files under /usr/lib is a bad idea. A package update will revert your changes. You can put the symlink under /etc/systemd/system, or you can use:
systemctl mask fedora-autorelabel.service
Comment 7 Fedora End Of Life 2013-07-03 23:35:10 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 8 Fedora End Of Life 2013-08-01 07:25:32 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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