Bug 1121051

Does this happen if you put selinux in permissive mode?

selinux=0 is part of my kernel params, SElinux so is not involved

at the bottom the syslog surrounding that message
directly after "systemd[1]: Set hostname to" in the second block

i see that for a long time because every time i boot any machine i grep for "fail", "error" and "warning" in dmesg as well as /var/log/messages which i would suggest maintainers of core packages also should do, that would have found a dozen of bugreports i wrote for Fedora earlier
________________________________________________________


Jul 18 12:17:56 buildserver64 rsyslogd: [origin software="rsyslogd" swVersion="7.4.8" x-pid="664" x-info="http://www.rsyslog.com"] start
Jul 18 12:17:56 buildserver64 systemd-cgroups-agent[253]: Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: No such file or directory


Jul 18 12:17:56 buildserver64 systemd[1]: systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
Jul 18 12:17:56 buildserver64 systemd[1]: Detected virtualization 'vmware'.
Jul 18 12:17:56 buildserver64 systemd[1]: Set hostname to <buildserver64.vmware.local>.
Jul 18 12:17:56 buildserver64 systemd[1]: Failed to configure loopback device: Permission denied
Jul 18 12:17:56 buildserver64 systemd[1]: Mounted POSIX Message Queue File System.


Jul 18 12:17:56 buildserver64 kernel: Initializing cgroup subsys cpuset
Jul 18 12:17:56 buildserver64 systemd[1]: Mounted Huge Pages File System.
Jul 18 12:17:56 buildserver64 kernel: Initializing cgroup subsys cpu
Jul 18 12:17:56 buildserver64 kernel: Initializing cgroup subsys cpuacct
Jul 18 12:17:56 buildserver64 systemd[1]: Mounted Debug File System.
Jul 18 12:17:56 buildserver64 kernel: Linux version 3.15.6-200.fc20.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC) ) #1 SMP Fri Jul 18 02:36:27 UTC 2014
Jul 18 12:17:56 buildserver64 systemd[1]: Started udev Coldplug all Devices.
Jul 18 12:17:56 buildserver64 kernel: Command line: BOOT_IMAGE=/vmlinuz-3.15.6-200.fc20.x86_64 root=UUID=9b4bf81a-5b1e-4922-b0d1-e6b65e9b61f9 ro pnpacpi=off pci=noacpi acpi=noirq audit=0 audit=0 rd.plymouth=0 pl
ymouth.enable=0 zswap.enabled=0 nodmraid raid=noautodetect nomodeset selinux=0 net.ifnames=0 biosdevname=0 elevator=deadline divider=20 clocksource=hpet nmi_watchdog=0 pcie_aspm=off nousb noisapnp noresume nodom
ains nobar norom printk.time=0 thermal.off=1 consoleblank=0 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 vconsole.font=latarcyrheb-sun16 vconsole.keymap=de-latin1-nodeadkeys locale.LANG=de_DE.UTF-8 LANG=de_DE.UTF-8
Jul 18 12:17:56 buildserver64 kernel: Disabled fast string operations
Jul 18 12:17:56 buildserver64 kernel: e820: BIOS-provided physical RAM map:
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
Jul 18 12:17:56 buildserver64 systemd[1]: Started Create static device nodes in /dev.
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x0000000000100000-0x000000007feeffff] usable
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x000000007fef0000-0x000000007fefefff] ACPI data
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x000000007feff000-0x000000007fefffff] ACPI NVS
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x000000007ff00000-0x000000007fffffff] usable
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x00000000f0000000-0x00000000f7ffffff] reserved
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Jul 18 12:17:56 buildserver64 kernel: BIOS-e820: [mem 0x00000000fffe0000-0x00000000ffffffff] reserved

in that early state there is also permanent a message about /run/systemd/private which later exists - so that things should not be done in that early state if the always fail anyways

Jul 24 16:30:44 testserver systemd-cgroups-agent[243]: Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: No such file or directory
Jul 24 16:30:44 testserver systemd[1]: Failed to configure loopback device: Permission denied

Is there any way this could be related to VMWare? I.e., can you reproduce this on regular hardware, and are you able to manually configure the loopback device once the machine has been booted?

Either way what is the output of "ip addr show dev lo"?

> Is there any way this could be related to VMWare

no, i recently WOL'ed my physical workstation at the office with no VMware part of the game

Jul 27 21:47:07 rh systemd[1]: Failed to configure loopback device: Permission denied
_________________________________________________________

> Either way what is the output of "ip addr show dev lo"?

[root@rh:~]$ ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
_________________________________________________________

as far as i understand the logs that is *early boot* long before the final network configuration

3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014

[root@rh:~]$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
stepping        : 7
microcode       : 0x29
cpu MHz         : 1611.812
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6784.32
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

hmm, did you turn off ipv6 in the kernel or something?

yes because there is no ipv6 ISP left and right from me but that should not affect early boot i guess since it happens in sysctl.conf and no ipv6 related boot param

[root@srv-rhsoft:~]$ cat /boot/grub2/grub.cfg | grep -i ipv6
[root@srv-rhsoft:~]$ cat /etc/sysctl.conf | grep -i ipv6
##### secure IPv6 #####
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.default.accept_source_route=0

systemd git will now skip over EPERM when configuring loopback. This change was made for compatibility with unprivileged containers, but should fix this bug too.

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.