fedora 24 ne démarrera pas après la mise à jour de dnf

La nuit dernière, j'ai fait une mise à niveau sur mon fedora 24 alpha install et lors du démarrage de la première fois aujourd'hui, je me suis retrouvé avec un écran noir.

Ensuite, j'ai essayé de démarrer en mode de secours, ce qui m'a laissé un shell après avoir montré l'écran de chargement fedora. J'ai essayé de revenir sur la dernière mise à jour listée avec dnf historylist undo id# , mais cela a échoué car il ne se connecte pas au réseau.

Dans le shell, il affiche cette ligne avant de requestr la racine pwd:

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

Des idées comment je pourrais revenir sur la dernière mise à jour?

MODIFIER:

J'ai regardé à travers le journal fourni par journalctl -xb et il semble y avoir beaucoup d'erreurs systemd liées au assembly de toutes sortes de disques, donc c'est probablement la raison pour laquelle il ne démarrera pas. La chose drôle est que ma configuration matérielle n'a pas changé un bit, les disques fonctionnent tous comme prévu.

J'ai oublié d'append que j'ai essayé de démarrer dans les deux versions précédentes du kernel alpha en vain (même si les deux fonctionnaient avant la mise à jour d'hier).

EDIT2:

Ouput de 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:

Contenu de /etc/systemd/system/default.target

 # This file is part of systemd. # # systemd is free software; you can redissortingbute 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 

Cela a fonctionné pour moi.

Ajoutez ce qui suit au paramètre de votre kernel.

 selinux=1 enforcing=0 

Ceci définit le mode d'exécution SELinux de ssortingct à permissif .

C'est une solution temporaire jusqu'à ce que je trouve ce qui se passe, ou jusqu'à ce qu'une mise à jour corrige le problème.

J'espère que cela aide.

La solution que j'ai utilisée était

  1. Changez default.target en multi-user.target (était graphique.)
  2. setenforce 0
  3. systemctl isolate graphical

Pour être complet, j'appendai que c'est un problème avec selinux-policy et selinux-policy-targeted target version 3.13.1-183.fc24. La rétrogradation de ces versions antérieures ou l'utilisation de 3.13.1-184.fc24 résout ce problème.

Voir aussi les inputs bugzilla ici et ici .

Ceci est dû à un bogue dans la politique SELinux. Voir https://bugzilla.redhat.com/show_bug.cgi?id=1331668 – en date du 2 mai 2016, il existe une mise à jour des tests qui devrait résoudre le problème.

Entre-time, démarrer avec enforcing=0 contournera le problème.