Hide Forgot
# systemctl |grep failed dev-sda2.swap loaded failed failed /dev/sda2 dev-sdb2.swap loaded failed failed /dev/sdb2 # grep swap /etc/fstab UUID=ec420dbe-b6a9-48d4-ae67-1d3a0310ffb2 swap swap defaults 0 0 UUID=03924499-649c-41b8-9f63-d389a473c02f swap swap defaults 0 0 # rpm -qa systemd*|sort systemd-30-1.fc16.x86_64 systemd-gtk-30-1.fc16.x86_64 systemd-sysv-30-1.fc16.x86_64 systemd-units-30-1.fc16.x86_64
Please attach the output of "dmesg" after booting with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg".
Created attachment 515550 [details] dmesg
From the log I can see you booted with "single" and then switched to graphical.target. Is this a necessary step to reproduce the bug? The two swap partitions were successfully activated in the rescue target: [ 25.109248] systemd[1]: Installed new job dev-disk-by\x2duuid-03924499\x2d649c\x2d41b8\x2d9f63\x2dd389a473c02f.swap/start as 35 ... [ 25.109317] systemd[1]: Installed new job dev-disk-by\x2duuid-ec420dbe\x2db6a9\x2d48d4\x2dae67\x2d1d3a0310ffb2.swap/start as 37 ... [ 37.331725] systemd[1]: Job dev-disk-by\x2duuid-ec420dbe\x2db6a9\x2d48d4\x2dae67\x2d1d3a0310ffb2.swap/start finished, result=done ... [ 37.353287] systemd[1]: Job dev-disk-by\x2duuid-03924499\x2d649c\x2d41b8\x2d9f63\x2dd389a473c02f.swap/start finished, result=done Then during the switch to graphical.target there was another attempt to activate the swap partitions, using different names though: [ 53.350873] systemd[1]: Installed new job dev-sdb2.swap/start as 146 [ 53.353152] systemd[1]: Installed new job dev-sda2.swap/start as 157 ... [ 56.185168] swapon[1091]: swapon: /dev/sda2 : « swapon » a échoué: Périphérique ou ressource occupé [ 56.196594] swapon[1092]: swapon: /dev/sdb2 : « swapon » a échoué: Périphérique ou ressource occupé That is, not surprisingly, "Device or resource busy". Can you confirm that the swap partitions are in fact active, using "swapon -s"? I wonder from where systemd got the idea to activate dev-sd[ab]2.swap. Could you attach the output of "systemctl dump" from both the single user shell and from the booted graphical.target?
(In reply to comment #3) > From the log I can see you booted with "single" and then switched to > graphical.target. Is this a necessary step to reproduce the bug? It was due to bug #726005 but it seems that removing rhbg is sufficient to make the system boot (it was removed as a side-effect of booting in single mode)
(In reply to comment #3) > Can you confirm that the swap partitions are in fact active, using "swapon -s"? $ systemctl |grep failed dev-sda2.swap loaded failed failed /dev/sda2 dev-sdb2.swap loaded failed failed /dev/sdb2 $ swapon -s Filename Type Size Used Priority /dev/sdb2 partition 2096476 0 0 /dev/sda2 partition 2096476 0 0
Created attachment 515969 [details] output of "systemctl dump" from the booted graphical.target? > I wonder from where systemd got the idea to activate dev-sd[ab]2.swap. Could > you attach the output of "systemctl dump" > from the booted graphical.target?
Created attachment 515970 [details] output of "systemctl dump" from both the single user shell >I wonder from where systemd got the idea to activate dev-sd[ab]2.swap. Could > you attach the output of "systemctl dump" from both the single user shell
(In reply to comment #3) > From the log I can see you booted with "single" and then switched to > graphical.target. Is this a necessary step to reproduce the bug? It seems so
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Ping what's the current status on this? Are you still experiencing this issue?
*** This bug has been marked as a duplicate of bug 789573 ***