Bug 722952

Created attachment 513637 [details]
Attached traceback automatically from anaconda.

Clyde, have you tried again to see if you can reproduce this at will? If you can, I'd like you to do so with an updates.img so I can collect some more information.

I have tried, but no luck so far. Other errors occur, however, and am trying to get info together to report them.  They did not throw an exception like this, just an error msg box with an ok button.

Will try again (and again).

preview bzs:  selecting preexisting home lv fails with error.
              an error occuring during bootloader installation
              (after fixing bootloader) grub2-install fails to populate kernel cmd line with rd_MD_UUID=... and rd_LVM_LV=root lv.

These will be in later today and, hopefully, retests for this bz.

Cannot reproduce this after 5 ties.  Closing.

Have reproduced this twice using following options:
1. Select "Use All Space"
2. Install Target Device, select a USB stick which is brand new (no prior writes), and select the "Boot Loader" option.

Reopening. I reproduced this problem with my custom layout. The important part is that the disk partitions must already exist, anaconda then crashes.

First I created a new custom layout:
vda1 - bios boot
vda2 - /boot ext4
vda3 - encrypted LVM vg_opt
vda4 - LVM vg_main

vg_opt:
lv_opt - /opt ext4

vg_main:
lv_root - / encrypted ext4
lv_swap - swap

First installation went fine. After that I repeated the installation re-using the existing partitions. Then anaconda crashed.

Appending logs.

anaconda 16.17

Created attachment 523350 [details]
existing_layout.png

Created attachment 523351 [details]
new_layout.png

Created attachment 523352 [details]
anaconda.log

Created attachment 523353 [details]
anaconda-tb-Ddv7Ye

Created attachment 523354 [details]
program.log

Created attachment 523355 [details]
storage.log

Created attachment 523356 [details]
syslog

Proposing as Final blocker, since:

The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above
https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria

An updates image is available for those who would like to test/verify a fix. Add the following to the boot command line if interested:

  updates=http://dlehman.fedorapeople.org/updates-lvm.img

we are also interested in general testing of RC1 with the updates image, not
just specific testing to see if it resolves this bug, but also to see if it
causes any other problems.

I can confirm that the update.img from comment 15 fixes this particular issue.

This will be in anaconda-16.19-1.

anaconda-16.19-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/anaconda-16.19-1.fc16

anaconda-16.19-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

I've just downloaded the x86_64 Fedora 16 Beta from the fedora project site.
It's running Anaconda 16.20.

Using a custom layout, I get the results indicated previously.  In other words, it still crashes.

Created attachment 528776 [details]
Anaconda 16.20 traceback

Created attachment 528779 [details]
BZIP2 tarball of /tmp/anaconda.log and anaconda traceback

NB: The crash *did* occur inside a virtual machine.
Specifically, a VirtualBox virtual machine environment running on a Dell Dimension 9150 under Windoze 7 x64.

The intention was to test Fedora 16 in various scenarios:
* A clean installation
* An upgrade from Fedora 15
* An upgrade from Fedora 14 (because I want to avoid the alpha point zero release of Gnome 3 present in Fedora 15)

So the question I now have is whether the update.img fix mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=722952#c15 is still viable given that the installation media I am using has a later version of anaconda than was originally logged?

(In reply to comment #24)
> So the question I now have is whether the update.img fix mentioned in
> https://bugzilla.redhat.com/show_bug.cgi?id=722952#c15 is still viable given
> that the installation media I am using has a later version of anaconda than was
> originally logged?

The fix from that image is now in anaconda. You have found a way to hit a similar, but different, bug. I think I can reproduce it here. I'll let you know when I have a fix to test.

adamw: do you want this handled in a separate bug for tracking purposes?

(In reply to comment #25)
> 
> The fix from that image is now in anaconda. You have found a way to hit a
> similar, but different, bug. I think I can reproduce it here. I'll let you know
> when I have a fix to test.
> 

I had been deciding which layout method I was going to use out of "replace existing system" or "custom layout".
I had started down the replace existing system track (thinking it would upgrade using the existing layout), but didn't like the way the default (replacement) layout it was going to use, so back-tracked to the selection menu and went down the custom layout track instead.
This read the existing LV structure I had from the Fedora 15 VM, and presented them to me for allocation to various file-systems.
I elected at this point to create 3 additional LVs in addition to assigning the existing LVs to swap and ext4 file-systems.

Now I don't know whether the crash was because I'd started down a different installation path before backing up to choose a custom layout, or not.
However, that was what I'd done, so if you're having trouble re-creating the scenario, this may help.

It definitely has to do with the fact that you tried initially to reuse your existing root lv without reformatting it. Anyway, I reproduced a bug and I'm fairly certain it's the same one you hit. I have an updates image you can try out if you like:

  http://dlehman.fedorapeople.org/updates-lvm.2.img

(In reply to comment #27)
> It definitely has to do with the fact that you tried initially to reuse your
> existing root lv without reformatting it. Anyway, I reproduced a bug and I'm
> fairly certain it's the same one you hit. I have an updates image you can try
> out if you like:
> 
>   http://dlehman.fedorapeople.org/updates-lvm.2.img


Okay, I've added the "updates=http://dlehman.fedorapeople.org/updates-lvm.2.img" argument to the boot line, and that appears to have fixed the problem.

I repeated the actions outlined earlier, and this time the system rewrote the LVM structure as I'd defined it.

I will repeat the process later with another copy of a VM that I have just to ensure consistency, and will report back when done (probably a couple of days or so).

Anyway, so far, so good.

anaconda-16.22-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/anaconda-16.22-1.fc16

anaconda-16.22-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.