3

Last night I did an upgrade on my fedora 24 alpha install and when booting first time today I just ended up with a black screen.

Then I tried booting into rescue mode, which left me with a shell after showing the fedora loading screen. I tried reverting the last update listed with dnf historylist undo id#, but that failed because it doesn't connect to the network.

In the shell, it shows this line before prompting for root pwd:

dracut-pre-udev[302]: Symbol 'svc_auth_none' has different size in shared object, consider relinking

Any ideas how I could revert the last update?

EDIT:

I have looked through the log provided by journalctl -xb and there seem to be a lot of systemd errors related to mounting all kinds of drives, so that is probably the reason why it won't boot. Funny thing is that my hardware setup has not changed one bit, drives are all working as supposed to.

I forgot to add that I tried booting into the two previous alpha kernel versions to no avail (though both used to work previous to yesterdays update).

EDIT2:

Ouput of journalctl -xb -p3:

    -- Logs begin at Mit 2016-01-20 15:01:49 CET, end at Fre 2016-04-29 17:06:53 CEST. --
Apr 29 19:06:48 localhost systemd[1]: Device dev-disk-by\x2dpartlabel-Microsoft\x5cx20reserved\x5cx20partition.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 and /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb/sdb1
Apr 29 19:06:48 localhost systemd[1]: Device dev-disk-by\x2dpartlabel-EFI\x5cx20System\x5cx20Partition.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2 and /sys/devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sdd/sdd1
Apr 29 19:06:48 localhost systemd[1]: Device dev-disk-by\x2dpartlabel-Basic\x5cx20data\x5cx20partition.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb/sdb2 and /sys/devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sdd/sdd4
Apr 29 19:06:50 localhost rpcbind[314]: cannot open file = /tmp/rpcbind.xdr for writing
Apr 29 19:06:50 localhost rpcbind[314]: cannot save any registration
Apr 29 19:06:50 localhost rpcbind[314]: cannot open file = /tmp/portmap.xdr for writing
Apr 29 19:06:50 localhost rpcbind[314]: cannot save any registration
Apr 29 17:06:50 linux.fritz.box systemd[1]: Failed to mount NFSD configuration filesystem.
-- Subject: Unit proc-fs-nfsd.mount has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit proc-fs-nfsd.mount has failed.
-- 
-- The result is failed.
Apr 29 17:06:50 linux.fritz.box systemd[1]: dev-disk-by\x2dpartlabel-Microsoft\x5cx20reserved\x5cx20partition.device: Dev dev-disk-by\x2dpartlabel-Microsoft\x5cx20reserved\x5cx20partition.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb/sdb1 and /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
Apr 29 17:06:51 linux.fritz.box systemd[1]: dev-disk-by\x2dpartlabel-EFI\x5cx20System\x5cx20Partition.device: Dev dev-disk-by\x2dpartlabel-EFI\x5cx20System\x5cx20Partition.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2 and /sys/devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sdd/sdd1
Apr 29 17:06:51 linux.fritz.box systemd[1]: dev-disk-by\x2dpartlabel-Basic\x5cx20data\x5cx20partition.device: Dev dev-disk-by\x2dpartlabel-Basic\x5cx20data\x5cx20partition.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb/sdb2 and /sys/devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sdd/sdd4
Apr 29 17:06:51 linux.fritz.box systemd[1]: Failed to mount /boot/efi.
-- Subject: Unit boot-efi.mount has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit boot-efi.mount has failed.
-- 
-- The result is failed.
Apr 29 17:06:53 linux.fritz.box systemd[1]: Failed to mount /mnt/20DF1A322D28FF74.
-- Subject: Unit mnt-20DF1A322D28FF74.mount has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit mnt-20DF1A322D28FF74.mount has failed.
-- 
-- The result is failed.

EDIT3:

Contents of /etc/systemd/system/default.target

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
  • I think that error may be a red herring. What do you see with journalctl -xb -p3? – mattdm Apr 29 '16 at 14:30
  • @mattdm Apart from the aforementioned systemd errors about failed local and network device mounts, there's errors about being unable to open rpcbind.xdr and portmap.xdr for writing. – sobek Apr 29 '16 at 16:29
  • What are the errors about failed device mounts, exactly? What's the first one? What hardware is this? (What storage type?) – mattdm Apr 29 '16 at 16:30
  • Hmmm. It's pretty weird that the older kernels don't boot. I was going to suggest rebuilding the initramfs with dracut but I don't think that'd help if the older versions don't work either. (I guess it can't hurt...) Any chance of an actual, coincidental hardware failure? – mattdm Apr 29 '16 at 17:06
  • @mattdm Ok so i was able to extract the log with the help of a f23 live usb medium. The devices all seemed to mount fine with the live medium and i haven't found any issues with my Windows partition so i'm led to believe that a hardware failure seems rather improbable. – sobek Apr 29 '16 at 17:17
7

This worked for me.

Add the following to your kernel parameter.

selinux=1 enforcing=0

This sets the SELinux enforcement mode from strict to permissive.

This is a temporary solution until I figure out what is going on, or until an update fixes the problem.

2

The solution I used was

  1. Change default.target to multi-user.target (Was graphical.)
  2. setenforce 0
  3. systemctl isolate graphical
2

For the sake of completeness, i will add that this is a problem with selinux-policy and selinux-policy-targeted version 3.13.1-183.fc24. Downgrading these to previous versions or using 3.13.1-184.fc24 fixes this issue.

Also see bugzilla entries here and here.

2

This is caused by a bug in the SELinux policy. See https://bugzilla.redhat.com/show_bug.cgi?id=1331668 — as of May 2, 2016, there is an update in testing which should resolve the issue.

In the meantime, booting with enforcing=0 will work around the problem.

protected by Community May 1 '16 at 14:06

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.