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 
9
  • I think that error may be a red herring. What do you see with journalctl -xb -p3? Commented Apr 29, 2016 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. Commented Apr 29, 2016 at 16:29
  • What are the errors about failed device mounts, exactly? What's the first one? What hardware is this? (What storage type?) Commented Apr 29, 2016 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? Commented Apr 29, 2016 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. Commented Apr 29, 2016 at 17:17

4 Answers 4

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
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.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.