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.
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. /usr/lib/systemd/system/fedora-autorelabel.service If this is happening to everyone it is a serious bug, in systemd.
I can not get this to happen on my F18 box.
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.
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.
.autorelabel creation is predicated on booting without selinux; that's entirely expected. However, fedora-autorelabel.service has: ConditionSecurity=selinux ConditionKernelCommandLine=|autorelabel ConditionPathExists=|/.autorelabel 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'?
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
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.
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.