Bug 1049656

Running "setenforce 0" to disable selinux fixes the issue, but obviously there's some sort of policy problem.

After setting it once with selinux disabled, setting it again works fine, even with selinux enabled.

AVC messages?

> AVC messages?

One would expect that, but I haven't been able to find any yet.

Here we go! I wasn't allowing for spaces in "avc:denied" while searching before.

./audit/audit.log:type=AVC msg=audit(1389138448.533:104): avc:  denied  { sys_admin } for  pid=600 comm="passwd" capability=21  scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tclass=capability
./audit/audit.log:type=AVC msg=audit(1389139719.659:787): avc:  denied  { read } for  pid=6842 comm="systemd-hostnam" name="hostname" dev="vda1" ino=2787 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file
./audit/audit.log:type=AVC msg=audit(1389139796.407:839): avc:  denied  { read } for  pid=6910 comm="systemd-hostnam" name="hostname" dev="vda1" ino=2787 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file
./audit/audit.log:type=AVC msg=audit(1389141256.494:1421): avc:  denied  { read } for  pid=7394 comm="systemd-hostnam" name="hostname" dev="vda1" ino=2787 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file
./audit/audit.log:type=AVC msg=audit(1389141285.273:1435): avc:  denied  { read } for  pid=7406 comm="systemd-hostnam" name="hostname" dev="vda1" ino=2787 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file
./audit/audit.log:type=AVC msg=audit(1389141342.483:1461): avc:  denied  { read } for  pid=7431 comm="systemd-hostnam" name="hostname" dev="vda1" ino=2787 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file
./audit/audit.log:type=AVC msg=audit(1389141373.187:1476): avc:  denied  { read } for  pid=7447 comm="systemd-hostnam" name="hostname" dev="vda1" ino=2787 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file
./audit/audit.log:type=AVC msg=audit(1389141373.187:1476): avc:  denied  { open } for  pid=7447 comm="systemd-hostnam" path="/etc/hostname" dev="vda1" ino=2787 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file
./audit/audit.log:type=AVC msg=audit(1389141373.187:1477): avc:  denied  { getattr } for  pid=7447 comm="systemd-hostnam" path="/etc/hostname" dev="vda1" ino=2787 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file
./audit/audit.log:type=AVC msg=audit(1389141373.193:1479): avc:  denied  { unlink } for  pid=7447 comm="systemd-hostnam" name="machine-info" dev="vda1" ino=2788 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file

The context after setting it once is:

[root@onebox-f20 log]# ls -Z /etc/hostname
-rw-r--r--. root root system_u:object_r:hostname_etc_t:s0 /etc/hostname

So, hostname should probably get set to that originally.

 % ls -lZ /etc/hostname
-rw-r--r--. root root system_u:object_r:hostname_etc_t:s0 /etc/hostname

It seems that /etc/hostname is mislabelled.

:)

It seems that virt-sysprep get the context on /etc/hostname wrong.

libguestfs indeed does not set the SELinux label on /etc/hostname.
It should touch /.autorelabel which will eventually autorelabel the
file.  However autorelabelling happens too late for systemd to
read the file on the first boot.

However ... There are a couple of mysterious things about this
bug report.

(1) By the time you get to a prompt where you can type the
hostnamectl command, the VM should have rebooted once and
autorelabelled, and the label on /etc/hostnamd should be
correct.  Why didn't that happen?

(2) What is the precise virt-sysprep command you are running?

(3) What is the label of the Fedora cloud image /etc/hostname
before you run virt-sysprep?  Do:

  guestfish --ro -a cloud.img -i llz /etc

What is the label after running virt-sysprep?

(4) Does the same problem happen if you disable the hostname
setting feature in virt-sysprep?

(I agree it would be better if virt-sysprep did set the label
on /etc/hostname and we should fix that, but the bug as described
in this report doesn't seem like it could happen)

Closing as INSUFFICIENT_DATA. David, if you can still reproduce, please reopen and provide the info requested in Comment #10

I have seen this.  I created a VM and imported it into
libvirt (using virt-install --import).  The VM probably
didn't relabel/reboot, because /.autorelabel still exists.

Looking at the journal, it has strange errors like:

fedora-autorelabel.service - Relabel all filesystems, if necessary
   Loaded: loaded (/usr/lib/systemd/system/fedora-autorelabel.service; static)
   Active: failed (Result: exit-code) since Thu 2014-04-17 01:42:29 EDT; 2min 21s ago
  Process: 300 ExecStart=/lib/systemd/fedora-autorelabel (code=exited, status=208/STDIN)
 Main PID: 300 (code=exited, status=208/STDIN)

Apr 17 01:42:29 localhost.localdomain systemd[1]: fedora-autorelabel.service: main process exited, code=exited, status=208/STDIN
Apr 17 01:42:29 localhost.localdomain systemd[1]: Failed to start Relabel all filesystems, if necessary.
Apr 17 01:42:29 localhost.localdomain systemd[1]: Unit fedora-autorelabel.service entered failed state.

I would say this is a systemd bug of some sort, but it's
fairly impenetrable.

Actually there's a bit more information in the main journal:

Apr 17 01:42:29 localhost.localdomain systemd[1]: Started Mark the need to relabel after reboot.
Apr 17 01:42:29 localhost.localdomain systemd[1]: Started Reconfigure the system on administrator request.
Apr 17 01:42:29 localhost.localdomain systemd[1]: Starting Relabel all filesystems, if necessary...
Apr 17 01:42:29 localhost.localdomain systemd[1]: Starting Trigger Flushing of Journal to Persistent Storage...
Apr 17 01:42:29 localhost.localdomain systemd[1]: Starting Tell Plymouth To Write Out Runtime Data...
Apr 17 01:42:29 localhost.localdomain systemd[300]: Failed at step STDIN spawning /lib/systemd/fedora-autorelabel: Inappropriate ioctl for device
Apr 17 01:42:29 localhost.localdomain systemd[1]: Starting Create Volatile Files and Directories...
Apr 17 01:42:29 localhost.localdomain systemd[1]: Starting Security Auditing Service...
Apr 17 01:42:29 localhost.localdomain systemd[1]: fedora-autorelabel.service: main process exited, code=exited, status=208/STDIN
Apr 17 01:42:29 localhost.localdomain systemd[1]: Failed to start Relabel all filesystems, if necessary.
Apr 17 01:42:29 localhost.localdomain systemd[1]: Unit fedora-autorelabel.service entered failed state.

Looking at the source, the error means that systemd forked and
tried to execve /lib/systemd/fedora-autorelabel, but the execve
failed, and errno was set to ENOTTY (Inappropriate ioctl for device).

So likely NOT a systemd bug specifically, but I've no idea at
the moment what component is the right one.

I'll note as a workaround that simply running
/lib/systemd/fedora-autorelabel (as root) works to relabel
the system.

Maybe this is obvious, but this also happens if the VM is a RHEL 7 system.

*** Bug 1196974 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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 this bug is closed as described in the policy above.

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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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

Same problem, still doesn't work on f22:

# systemctl -l status fedora-autorelabel.service
* fedora-autorelabel.service - Relabel all filesystems, if necessary
   Loaded: loaded (/usr/lib/systemd/system/fedora-autorelabel.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2015-07-12 23:17:24 CEST; 15min ago
  Process: 920 ExecStart=/lib/systemd/fedora-autorelabel (code=exited, status=208/STDIN)
 Main PID: 920 (code=exited, status=208/STDIN)

Jul 12 23:17:24 yarda systemd[1]: Starting Relabel all filesystems, if necessary...
Jul 12 23:17:24 yarda systemd[1]: fedora-autorelabel.service: main process exited, code=exited, status=208/STDIN
Jul 12 23:17:24 yarda systemd[1]: Failed to start Relabel all filesystems, if necessary.
Jul 12 23:17:24 yarda systemd[1]: Unit fedora-autorelabel.service entered failed state.
Jul 12 23:17:24 yarda systemd[1]: fedora-autorelabel.service failed.

It seems the following kernel boot command line parameters blocked it from running:

console=tty0 console=ttyS0,115200

I used it to to mirror console output to serial port. After removal fedora-autorelabel.service started on boot.

It is probably regression, because autorelabel worked in the past with this configuration and systemd, IIRC F18/F19 or so and without systemd this configuration worked since F12 without problem.

When it fails, is there any SELinux information?  You can probably
get that by typing this command shortly after boot:

ausearch -m avc -ts recent

It may also be in logs from your previous failed boot (maybe
in /var/log/audit or work out the journalctl equivalent).

(In reply to Richard W.M. Jones from comment #22)
> When it fails, is there any SELinux information?  You can probably
> get that by typing this command shortly after boot:
> 
> ausearch -m avc -ts recent
> 
> It may also be in logs from your previous failed boot (maybe
> in /var/log/audit or work out the journalctl equivalent).

Cannot find anything related:

Jul 12 23:17:23 yarda systemd[1]: Started Mark the need to relabel after reboot.
Jul 12 23:17:23 yarda systemd[1]: Starting Tell Plymouth To Write Out Runtime Data...
Jul 12 23:17:23 yarda systemd[1]: Starting Import network configuration from initramfs...
Jul 12 23:17:23 yarda systemd[1]: Starting Rebuild Journal Catalog...
Jul 12 23:17:23 yarda systemd[1]: Starting Preprocess NFS configuration...
Jul 12 23:17:23 yarda systemd[1]: Starting Relabel all filesystems, if necessary...
Jul 12 23:17:23 yarda systemd[1]: Starting Restore /run/initramfs on shutdown...
Jul 12 23:17:23 yarda systemd[1]: Reached target Encrypted Volumes.
Jul 12 23:17:23 yarda systemd[1]: Starting Encrypted Volumes.
Jul 12 23:17:23 yarda systemd[882]: Failed at step STDIN spawning /lib/systemd/fedora-autorelabel: Inappropriate ioctl for device
Jul 12 23:17:23 yarda systemd[1]: fedora-autorelabel.service: main process exited, code=exited, status=208/STDIN
Jul 12 23:17:23 yarda systemd[1]: Failed to start Relabel all filesystems, if necessary.
Jul 12 23:17:23 yarda systemd[1]: Unit fedora-autorelabel.service entered failed state.
Jul 12 23:17:23 yarda systemd[1]: fedora-autorelabel.service failed.
Jul 12 23:17:23 yarda systemd[1]: Started Restore /run/initramfs on shutdown.
Jul 12 23:17:23 yarda systemd[1]: Started Tell Plymouth To Write Out Runtime Data.
Jul 12 23:17:23 yarda systemd[1]: Started Rebuild Journal Catalog.
Jul 12 23:17:23 yarda systemd[1]: Started Preprocess NFS configuration.
Jul 12 23:17:23 yarda audit[1]: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fedora-autorelabel comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

It's probably failing on setup_input in execute.c @ 1382 
        r = setup_input(context, socket_fd, params->apply_tty_stdin);
        if (r < 0) {
                *exit_status = EXIT_STDIN;
                return r;
        }

I guess (I haven't time to proof it by debugging) it can fail in acquire_terminal in util.c @ 2043 when calling inotify setup. It failed on my x240 when it was outside of the dock, so there probably was no ttyS0. But IIRC it also failed when it was previosly in the dock and there was ttyS0 - I will retest later when get to the dock.

AFAIR there is no serial port on the dock.

The only thing that I can't understand is that everything (all other services) work, but autorelabel not.

Whether it is worth fixing I leave on your discretion.

To clarify it, there is serial port ttyS0 on the machine - the Intel AMT serial port - but if there is no remote session, it's disconnected and that's probably why the ioctl is failing on it.

(In reply to Javier Ramirez from comment #16)
> Maybe this is obvious, but this also happens if the VM is a RHEL 7 system.

Can you share exactly how you're able to reproduce this on RHEL7? I haven't been able to.

(In reply to Ryan Sawhill from comment #27)
> (In reply to Javier Ramirez from comment #16)
> > Maybe this is obvious, but this also happens if the VM is a RHEL 7 system.
> 
> Can you share exactly how you're able to reproduce this on RHEL7? I haven't
> been able to.

Sorry I can't recall if I did something different from the description, I have just tested with a 7.1 qcow2 and could not reproduce it either, so I guess that it was fixed already.

I can reproduce right now with the fedora23 image that virt-builder gets:

 virt-builder --selinux-relabel fedora-23

After that, if you start a vm with that image, the .autorelabel  file is still there but no relabeling has been done, for example, not relabeling any .ssh dir you created and not allowing key auth to the vm.

I can see in the journal logs:

Dec 01 12:01:13 vdsm_functional_tests_host-fc23 systemd[1]: Starting Relabel all filesystems, if necessary...
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 kernel: intel_rapl: no valid rapl domains found in package 0
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 kernel: Console: switching to colour frame buffer device 128x48
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 kernel: cirrus 0000:00:02.0: fb0: cirrusdrmfb frame buffer device
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 kernel: cirrus 0000:00:02.0: registered panic notifier
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 systemd[443]: fedora-autorelabel.service: Failed at step STDIN spawning /lib/systemd/fedora-autorelabel: Inappropriate ioctl for device
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 kernel: [drm] Initialized cirrus 1.0.0 20110418 for 0000:00:02.0 on minor 0
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 systemd[1]: Starting Restore /run/initramfs on shutdown...
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 systemd[1]: Started Create Volatile Files and Directories.
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 systemd[1]: fedora-autorelabel.service: Main process exited, code=exited, status=208/STDIN
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? a
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 kernel: tsc: Refined TSC clocksource calibration: 2793.538 MHz
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 kernel: clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x28446877189, max_idle_ns: 440795280878 ns
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 systemd[1]: Failed to start Relabel all filesystems, if necessary.
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 systemd[1]: fedora-autorelabel.service: Unit entered failed state.
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fedora-autorelabel comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=
Dec 01 12:01:13 vdsm_functional_tests_host-fc23 systemd[1]: fedora-autorelabel.service: Failed with result 'exit-code'.

As a workaround, you can try to remove line 17: StandardInput=tty from /usr/lib/systemd/system/fedora-autorelabel.service.

tty is required probably due to the possibility to relabel system manually via sulogin when AUTORELABEL is set to 0 in /etc/selinux/config.

But it doesn't really solve the cause of the problem when systemd is not able connect /dev/console as stdin to the service.

Yep that does the trick :)

   --edit '/usr/lib/systemd/system/fedora-autorelabel.service: $_ = "" if /StandardInput=tty/'

*** Bug 1302678 has been marked as a duplicate of this bug. ***

Adding:
--edit '/usr/lib/systemd/system/rhel-autorelabel.service: $_ = "" if
/StandardInput=tty/'
to the virt-customize command did the trick for us on RHEL-7.2 qcow2.

Although this workaround stands good as of now, is there any permanent solution for this problem?

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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