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