Bug 504986
| Summary: | F11-F13 x86-64 LiveUSB backtrace | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bastien Nocera <bnocera> | ||||
| Component: | anaconda | Assignee: | David Lehman <dlehman> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 13 | CC: | a_thing, awilliam, horsley1953, jlaska, rmaximo, stickster, vanmeeuwen+fedora | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | anaconda_trace_hash:7cd12fd4cd7d2aa144056e3e0aa74b41c1a16ad85e432ef93c55b85f61921aad | ||||||
| Fixed In Version: | anaconda-13.41-1.fc13 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-05-19 00:06:28 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: | 507681 | ||||||
| Attachments: |
|
||||||
Created attachment 347184 [details]
Attached traceback automatically from anaconda.
This happens after doing an installation with a custom hard drive layout. Some existing partitions were kept (/home and /home/data) and all the other ones wiped. No partition changes were made, /boot was formatted as ext3, / as ext4 and the swap reformatted as well. No encryption options were selected. I think the problem is because it tries to umount /home without having umounted /home/data. Will try an installation to verify that this works around the problem. Verified. I didn't add a mountpoint for /home/data, and it finished the installation properly. *** Bug 505704 has been marked as a duplicate of this bug. *** Fixed for rawhide *** Bug 518327 has been marked as a duplicate of this bug. *** I have a LiveUSB that I created from the F12 Alpha x86_64 image, updated it to anaconda-12.16-1, and this is still not working. I have separate /var/www/fedora and /var/www partitions that are still triggering this problem. Yesterday I had this problem with 12.15-1, and filed bug 518327. Didn't get a chance to rewrite the LiveUSB and retry until this morning, but I did update to 12.16-1 before attempting a liveinst. I'm filing a new bug using the Save to Bugzilla feature so someone can take another gander at this. Sorry, Save to Bugzilla means my TB got appended to bug 518327. Are you sure that you had the update? The code looks right (my rawhide live install is failing for other reasons at the moment) Check the latest traceback attached to bug 518327: https://bugzilla.redhat.com/attachment.cgi?id=358070 Note the 12.16-1.fc12... The installation wouldn't work properly until I tried leaving out the /var/www/fedora partition. I did a normal 'yum update anaconda' to get that latest version, and the update completed properly. It worked for me just now, but I've fixed something that could possibly be related and also added a fair bit more debugging. So should hopefully be good in 12.1.7 and if not, we'll have more info on why not :) I'm not sure what version is on the F13 Beta KDE Live CD but I just added a traceback to bug 518327 from an attempt to install it on hard disk. I was indeed using a custom layout: / /dev/sda5 reformat as ext4 /boot /dev/sda1 reformat as ext3 /space /dev/sda6 keep existing ext4 partition /win98 /dev/sda2 keep exiting vfat partition swap /dev/sdb1 /spike /dev/sdb5 keep exiting ext3 partition Reopening against F13. I'm also setting "F13Blocker," not because I'm sure this is a blocker, but because I'd like someone more informed than us to make that call, since this appears to be a regression. I also have a traceback attached to bug 518327 gathered from liveinst on the F13 Beta x86_64 Desktop Live image. The traceback and other attachments have the full partition information, but just to sum up: /dev/sda1, /dev/sda2 -- Dell OEM stuff (keep) /dev/sda3 -- /boot -- reformat ext4 /dev/sda5 -- Linux LVM: / -- reformat ext4 /home -- keep ext4 swap -- reformat swap /var -- reformat ext4 /var/lib/mysql -- keep ext4 /var/www -- reformat ext4 (*) /var/www/fedora -- keep ext4 (*) /var/lib/libvirt/images -- keep ext4 (*) appears to have caused the problem, not properly unmounting and tearing down /var/www/fedora before trying to unmount and tear down /var/www. When I reran, and had anaconda ignore the /var/www/fedora, /var/lib/libvirt/images, and /var/lib/mysql partitions, everything went swimmingly. However, it would be far preferable for system owners not to have to figure this part out on their own. Discussed at 2010/04/23 blocker review meeting. Agreed that this is a blocker. Anaconda team will investigate and try to fix. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Is there anyone who can reliably reproduce this failure? I have been unable to do so. I suspect it has something to do with the contents or state of some of these preexisting filesystems. As long as we are suspecting, I suspect it has something to do with partition boundary alignment. Apparently there are rules for what cylinder boundaries partitions are supposed to be on, and every single operating system distro as well as every single partitioning tool has those rules built into it. Unfortunately, absolutely all of the rules conflict and produce partition layouts the other tools honk about :-). The system that generated my backtrace had Windows 98 installed on it, then ubuntu with some new partitions created, then fedora 13 with the KDE live CD (where I got the error attempting to mount all the existing partitions in the initial fstab), and now has had f13 from the dvd image installed on it successfully (by not mounting any other filesystems till after the primary install was completed). Even after that success, I had to install the DOS version of grub on the MBR to be able to get Windows 98 to boot as the f13 grub seems to confuse win98 completely when chainloading. The fundamental problem is a failure to unmount a filesystem. If the problem was related to partition alignment we would likely have seen the failure when trying to mount. I'm still interested in identifying anyone who can hit this at will. Dave, I think my case above is fully reproducible, if that's what you mean. If I didn't provide enough info, though, let me know and I'll be happy to help, especially since I brought up the blocker status. (In reply to comment #19) > Dave, I think my case above is fully reproducible, if that's what you mean. If > I didn't provide enough info, though, let me know and I'll be happy to help, > especially since I brought up the blocker status. I tried to reproduce by creating a vg with separate lvs for /, swap, /home, /var, /var/www, and /var/www/fedora. I completed that install, then started another. In the second install, I chose to reformat /, swap, /var, and /var/www, but not /var/www/fedora. It completed successfully, so the idea that the /var structure you used is sufficient to reproduce seems to be inaccurate. Feel free to completely disregard comment 20. I am so used to non-live installs that as soon as I saw the bootloader config screen I assumed I was in the clear. Not so. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Reassigning to dlehman per discussion at 2010-04-30 blocker review meeting. Ping, Dave? Patch just sent out for review: https://www.redhat.com/archives/anaconda-devel-list/2010-May/msg00126.html anaconda-13.41-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.41-1.fc13 (In reply to comment #13) Yesterday I installed the RC2 Live CD (i686) on this same machine, told anaconda to mount all the same partitions I had problems with before, and this time it worked fine. So there was either something specific to the KDE live cd (which I used the first time), or the problem is now fixed for me. Yeah, it should be fixed in RC2, good to get confirmation. Can anyone else confirm this? well, let's close it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers |
The following was filed automatically by anaconda: anaconda 11.5.0.59-1.fc11 exception report Traceback (most recent call first): File "/usr/lib/anaconda/isys.py", line 198, in umount rc = _isys.umount(what) File "/usr/lib/anaconda/storage/formats/fs.py", line 612, in unmount rc = isys.umount(self._mountpoint, removeDir = False) File "/usr/lib/anaconda/storage/formats/fs.py", line 802, in teardown return self.unmount(*args, **kwargs) File "/usr/lib/anaconda/livecd.py", line 286, in _doFilesystemMangling e.format.teardown() File "/usr/lib/anaconda/livecd.py", line 349, in doPostInstall self._doFilesystemMangling(anaconda) File "/usr/lib/anaconda/backend.py", line 285, in doPostInstall anaconda.backend.doPostInstall(anaconda) File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1339, in nextClicked self.anaconda.dispatch.gotoNext() File "/usr/lib/anaconda/iw/progress_gui.py", line 79, in renderCallback self.intf.icw.nextClicked() File "/usr/lib/anaconda/gui.py", line 1360, in handleRenderCallback self.currentWindow.renderCallback() SystemError: (2, None)