Bug 1049656 - /.autorelabel fails: systemd[..]: Failed at step STDIN spawning /lib/systemd/fedora-autorelabel: Inappropriate ioctl for device
Summary: /.autorelabel fails: systemd[..]: Failed at step STDIN spawning /lib/systemd/...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 22
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1196974 1302678 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-08 00:14 UTC by David Strauss
Modified: 2019-09-12 07:48 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-19 18:51:03 UTC
Type: Bug


Attachments (Terms of Use)

Description David Strauss 2014-01-08 00:14:02 UTC
Description of problem:
I can't set a hostname after booting a Fedora Cloud image.

Version-Release number of selected component (if applicable):
Name        : systemd
Arch        : x86_64
Version     : 208
Release     : 9.fc20

Steps to Reproduce:
1. Download F20 Cloud qcow2.
2. Use virt-sysprep --root-password to set the image root password.
3. Create a VM from the image in virt-manager.
4. Update everything: yum upgrade -y
5. Reboot
6. Try setting the hostname

Actual results:

Shell:
[root@localhost ~]# hostnamectl set-hostname onebox-f20
Failed to issue method call: Activation of org.freedesktop.hostname1 timed out

Logs:
Jan 08 00:09:56 localhost dbus[249]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Jan 08 00:09:56 localhost systemd[1]: Starting Hostname Service...
Jan 08 00:09:56 localhost systemd-hostnamed[6910]: Failed to read hostname data: Permission denied
Jan 08 00:09:56 localhost systemd[1]: systemd-hostnamed.service: main process exited, code=exited, status=1/FAILURE
Jan 08 00:09:56 localhost systemd[1]: Failed to start Hostname Service.
Jan 08 00:09:56 localhost systemd[1]: Unit systemd-hostnamed.service entered failed state.

Expected results:
Hostname should get set.

Comment 1 David Strauss 2014-01-08 00:36:57 UTC
Running "setenforce 0" to disable selinux fixes the issue, but obviously there's some sort of policy problem.

Comment 2 David Strauss 2014-01-08 00:38:30 UTC
After setting it once with selinux disabled, setting it again works fine, even with selinux enabled.

Comment 3 Zbigniew Jędrzejewski-Szmek 2014-01-08 00:41:12 UTC
AVC messages?

Comment 4 David Strauss 2014-01-08 00:43:07 UTC
> AVC messages?

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

Comment 5 David Strauss 2014-01-08 00:45:25 UTC
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

Comment 6 David Strauss 2014-01-08 00:50:06 UTC
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.

Comment 7 Zbigniew Jędrzejewski-Szmek 2014-01-08 00:54:43 UTC
 % 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.

Comment 8 Zbigniew Jędrzejewski-Szmek 2014-01-08 00:55:06 UTC
:)

Comment 9 Zbigniew Jędrzejewski-Szmek 2014-01-08 03:32:44 UTC
It seems that virt-sysprep get the context on /etc/hostname wrong.

Comment 10 Richard W.M. Jones 2014-01-08 10:33:39 UTC
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)

Comment 11 Cole Robinson 2014-02-25 16:40:16 UTC
Closing as INSUFFICIENT_DATA. David, if you can still reproduce, please reopen and provide the info requested in Comment #10

Comment 12 Richard W.M. Jones 2014-04-16 21:45:38 UTC
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.

Comment 13 Richard W.M. Jones 2014-04-16 21:47:51 UTC
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.

Comment 14 Richard W.M. Jones 2014-04-16 21:57:27 UTC
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.

Comment 15 Richard W.M. Jones 2014-04-16 22:05:22 UTC
I'll note as a workaround that simply running
/lib/systemd/fedora-autorelabel (as root) works to relabel
the system.

Comment 16 Javier Ramirez 2014-10-05 19:27:37 UTC
Maybe this is obvious, but this also happens if the VM is a RHEL 7 system.

Comment 17 Jan Synacek 2015-03-04 09:09:11 UTC
*** Bug 1196974 has been marked as a duplicate of this bug. ***

Comment 18 Fedora End Of Life 2015-05-29 10:22:41 UTC
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.

Comment 19 Fedora End Of Life 2015-06-30 00:50:04 UTC
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.

Comment 20 Jaroslav Škarvada 2015-07-12 21:33:49 UTC
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.

Comment 21 Jaroslav Škarvada 2015-07-12 21:44:43 UTC
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.

Comment 22 Richard W.M. Jones 2015-07-12 22:10:27 UTC
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).

Comment 23 Jaroslav Škarvada 2015-07-12 23:50:32 UTC
(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'

Comment 24 Jaroslav Škarvada 2015-07-13 00:30:16 UTC
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.

Comment 25 Jaroslav Škarvada 2015-07-13 00:43:19 UTC
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.

Comment 26 Jaroslav Škarvada 2015-07-13 09:49:10 UTC
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.

Comment 27 Ryan Sawhill 2015-08-31 22:18:48 UTC
(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.

Comment 28 Javier Ramirez 2015-09-17 09:38:28 UTC
(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.

Comment 29 David Caro 2015-12-01 17:12:46 UTC
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'.

Comment 30 Petr Lautrbach 2015-12-02 14:25:21 UTC
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.

Comment 31 David Caro 2016-01-28 12:02:53 UTC
Yep that does the trick :)

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

Comment 32 Richard W.M. Jones 2016-01-28 12:04:17 UTC
*** Bug 1302678 has been marked as a duplicate of this bug. ***

Comment 33 lokesh.jain 2016-02-22 17:29:05 UTC
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?

Comment 35 Fedora End Of Life 2016-07-19 18:51:03 UTC
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.


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