| Summary: | systemd does not manage swap properly | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nicolas Mailhot <nicolas.mailhot> | ||||||||
| Component: | systemd | Assignee: | systemd-maint | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | rawhide | CC: | harald, johannbg, johannbg, lpoetter, metherid, mschmidt, notting, plautrba | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-02-27 12:26:04 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Attachments: |
|
||||||||||
|
Description
Nicolas Mailhot
2011-07-27 10:30:29 UTC
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 *** |