Bug 742708
| Summary: | Cannot create file in /tmp and /var/tmp after resume from hibernation (ext4) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas Jollans <t> |
| Component: | kernel | Assignee: | Eric Sandeen <esandeen> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-07-11 17:54:07 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 781749 | ||
|
Description
Thomas Jollans
2011-10-01 20:38:00 UTC
why is vg_zarniwoop-lv_root mounted on /, /tmp, and /var/tmp ... are those bind mounts or something? I haven't a clue. This is the configuration anaconda produced. /tmp and /var/tmp do not appear in /etc/fstab: # # /etc/fstab # Created by anaconda on Thu Sep 22 16:14:31 2011 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/vg_zarniwoop-lv_root / ext4 defaults 1 1 UUID=d181aee8-2b6f-4dfa-99f0-9de33fda7fec /boot ext4 defaults 1 2 /dev/mapper/vg_zarniwoop-lv_home /home ext4 defaults,user_xattr,noatime 1 2 /dev/mapper/vg_zarniwoop-lv_swap swap swap defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 In addition to that, while /tmp, /var/tmp, and / appear to be identical, they all have distinct contents, and, before hibernation, the system acts as it should if /var/tmp and /tmp weren't somehow separate mounts. This may of course not be a bug in the kernel, it could be an unforseen side effect of whatever is creating these illogical mount points, whatever that may be. Very weird - so /tmp & /var/tmp aren't even listed in fstab, yet somehow /etc/mtab thinks they are mounted from the root fs... What does /proc/mounts say, hopefully it looks saner? I don't know if this is related to the actual problem or not, but it seems odd. Okay, after some extensive grepping through /etc, I found the reason for the mysterious /tmp and /var/tmp: /etc/init.d/sandbox. This script does:
mount --make-rshared / || return $?
mount --rbind /tmp /tmp || return $?
mount --rbind /var/tmp /var/tmp || return $?
mount --make-private /tmp || return $?
mount --make-private /var/tmp || return $?
I don't think I need this, so I disabled the service, and everything works - but it looks like this mount configuration messes up ext4 in ways that it shouldn't.
/etc/init.d/sandbox is installed by policycoreutils-2.0.86-7.fc15.x86_64
So just to be clear - did disabling it have any effect on the post-hibernation problem? And if so, was it 100% reproducible before, and 0% reproducible after? :) Yes, exactly. With sandbox enabled, the post-hibernation problems are always there, with it disabled, they don't exist. Wild. Ok, let me ponder that one :) I've been unable thus far to repro even w/ sandbox turned on. Argh! [Mass hibernate bug update] Dave Airlied has found an issue causing some corruption in the i915 fbdev after a resume from hibernate. I have included his patch in this scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3940545 This will probably not solve all of the issues being tracked at the moment, but it is worth testing when the build completes. If this seems to clear up the issues you see with hibernate, please report your results in the bug. Fedora 15 has reached it's end of life as of June 26, 2012. As a result, we will not be fixing any remaining bugs found in Fedora 15. In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. Thank you for taking the time to file a report. We hope newer versions of Fedora suit your needs. |