Bug 1008732

Created attachment 798477 [details]
File: anaconda.log

Created attachment 798478 [details]
File: environ

Created attachment 798479 [details]
File: lsblk_output

Created attachment 798480 [details]
File: nmcli_dev_list

Created attachment 798481 [details]
File: os_info

Created attachment 798482 [details]
File: program.log

Created attachment 798483 [details]
File: storage.log

Created attachment 798484 [details]
File: syslog

Created attachment 798485 [details]
File: ifcfg.log

Created attachment 798486 [details]
File: packaging.log

Created attachment 798487 [details]
File: anaconda-tb

overriding LUKS LVM

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base --lang en_US.UTF-8
cmdline_file:   initrd=initrd0.img root=live:UUID=b167fd7b-0e02-41e8-a2fa-f4b7a119663f rootfstype=ext2 ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.11.6-301.fc20.x86_64
other involved packages: python-libs-2.7.5-8.fc20.x86_64, python-blivet-0.23.2-1.fc20.noarch
package:        anaconda-20.25.4-1.fc20.x86_64
packaging.log:  
product:        Fedora
reason:         LUKSError: luks device not configured
release:        Fedora release 20 (Heisenbug)
version:        20

Trying to re-install Fedora 20 Beta RC4 to a previously installed hard drive, using custom partitioning.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base --lang en_US.UTF-8
cmdline_file:   BOOT_IMAGE=/syslinux/vmlinuz0 root=live:UUID=EB50-4153 rw rd.live.image overlay=UUID=EB50-4153 quiet rhgb
hashmarkername: anaconda
kernel:         3.11.6-300.fc20.x86_64
other involved packages: python-libs-2.7.5-8.fc20.x86_64, python-blivet-0.23.3-1.fc20.noarch
package:        anaconda-20.25.5-1.fc20.x86_64
packaging.log:  
product:        Fedora
reason:         LUKSError: luks device not configured
release:        Fedora release 20 (Heisenbug)
version:        20

What have I done? This:
Firstly I installed Fedora using whole disk (I reclaimed space) and created default encrypted layout. There were /boot on standard partition, swap, /home and / on encrypted LVM.

Then I tried to make a new installation. I chose the same disk as in previous installation. Then I went to custom partitioning (with non-encrypted LVM chosen).

Here I decrytped the volume group with /, /home and swap. Anaconda didn't show partitions on that VG, I could see only whole VG. I clicked on refresh. After that there were all partitions listed.

Then:
I chose old /boot, clicked on reformat as new /boot.
I chose old swap, clicked on reformat as new swap.
I deleted /home (anaconda didn't add new free space, that's probably related to bug 1027714).
Then I choose old / and clicked on reformat and chose to encrypt. I also tried to increase the size, but due to bug mentioned above nothing was added)

Then I clicked on done and started the installation.

It crashes after a while.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020-Beta\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.11.6-301.fc20.x86_64
package:        anaconda-20.25.6-1
product:        Fedora
reason:         LUKSError: luks device not configured
release:        Cannot get release name.
version:        20-Beta

I also should add that I tried to reproduce bug 1027682

I'm proposing this as a blocker because it violates the beta criterion: "When using the custom partitioning flow, the installer must be able to: Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"

Discussed in the 2013-11-07 Go/No-Go meeting [1]. Voted as a RejectedBlocker for beta and an AcceptedBlocker for final. It violates the following F20 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." [2]

[1] http://meetbot.fedoraproject.org/meetbot/meetbot/fedora-meeting-2/2013-11-07/
[2] https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Disk_layouts

(In reply to Petr Schindler from comment #14)
> What have I done? This:

I tried the same procedure except that I forgot to remove home lv. Packages are installing now. If it's possible, please attach all files matching /tmp/anaconda-tb-* to this report. Thanks.

As a side note, choosing encrypted automatic partitioning causes the installer to encrypt the PVs, which means the entire VG is encrypted. Therefore it makes little sense to encrypt the root LV during a reinstall.

It would be very helpful if anyone could come up with a detailed, reliable, reproducer for this bug.

collura cleared needinfo without actually providing any info. re-setting it.

I tried several times to reproduce comment 14, but didn't succeed. When following the steps verbatim, I hit bug 1027682 instead. The difference might lie in this:
(In reply to Petr Schindler from comment #14)
> Anaconda didn't
> show partitions on that VG, I could see only whole VG. I clicked on refresh.
> After that there were all partitions listed.

In my case, I unlocked the previous installation correctly on the first attempt every time. But I saw Petr and I can confirm that in his case, he saw only "Unknown partitions" or something similar after unlock, and he had to use the refresh button. But I don't know how to reproduce that.

(In reply to David Lehman from comment #17)
> As a side note, choosing encrypted automatic partitioning causes the
> installer to encrypt the PVs, which means the entire VG is encrypted.
> Therefore it makes little sense to encrypt the root LV during a reinstall.

I understand what you mean, but the original intention was different. We didn't think about technical details and expected anaconda to automagically make the VG unencrypted and only the single LV encrypted. I suggested some ideas how to improve the clarity of the installer in this area in bug 1030416.

0. Guided partitioning install F20 final TC1, default partition scheme LVM, checked encrypt option. Install. Reboot, confirm the install works.
1. Boot the same installer.
2. Installation options left at default (LVM, encrypt NOT checked), click custom partitioning button.
3. Reveal items under Unknown, click on Encrypted(LUKS) option, enter passphrase and Unlock. The underlying LVs (root and swap) automatically appear under an existing Fedora 20 installation. I did not click refresh.
4. Click on / "fedora-root" and delete it with - button.
5. click add button + to create new / mount point 20gb.

The mountpoint is added, but its Encrypt button is grayed out, so I'm not sure how this bug is triggered.

6. Remove the two mountpoints, LVs fedora-root and fedora-swap.
7. Set existing /boot as /boot mount point and check reformat. At this point the previous Fedora 20 installation isn't listed anymore.
8. Add / mount point 20gb.
9. Check its Encrypt button, which is not grayed out.
10. Add swap, leave it not encrypted.
11. Begin installation

Installation successful, reboot successful, confirmed that only the fedora-root LV is encrypted, not the PV.

Dunno, this seems to work as I'd expect.

Discussed at 2013-11-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.log.txt . Although this was accepted as a blocker, it now seems to be vague and unreproducible. We're leaving it as-is for now, but unless someone can come up with a clear concrete reproducer or dlehman has a brainwave as to what the initial bug was and still considers it critical, we'll likely drop its blocker status soon.

We didn't make it to AcceptedBlockers at this week's meeting, so this stayed on the slate. I'm formally calling for a re-evaluation of this one at this point, by dropping AcceptedBlocker, per c#22. No new information has shown up.

In case I can't attend today's blocker bug meeting, I vote -1 blocker. We can't reproduce this and we haven't had any fresh crash reports for a while now.

Discussed at 2013-12-02 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-02/f20-blocker-review-%234.2013-12-02-17.02.log.txt . Now rejected as a blocker, as we can no longer reproduce this or even be sure on exactly what the problem was in the first place.

Tryed to install with following partition layout (or similar):
vda1 /boot
vda2 /
vda3 swap
vda5 /var
vda6 /home

Layout that was before installation:
vda1 /boot
vda2 luks
vda3 luks

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=Fedora-Live-KDE-x86_64-20-TC5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.11.10-300.fc20.x86_64
other involved packages: python-blivet-0.23.8-1.fc20.noarch, python-libs-2.7.5-9.fc20.x86_64
package:        anaconda-20.25.14-1.fc20.x86_64
packaging.log:  
product:        Fedora
reason:         LUKSError: luks device not configured
release:        Fedora release 20 (Heisenbug)
version:        20

Reproduced with TC5, so adding as a blocker.

Steps to reproduce:
Start partitioning just like in bug#1038969 i.e. /boot and two luks VG's.
Run install and let it crash.

Next, without restarting start second installation. Remove all paritions from previous installation and add usual partitions without LVM. It leads to crash as described.

Not sure does it counts as a blocker or not, but seems to be eligible for re-evaluation - at least it is reproducible.

Second case how it could be reproduced "normal" way:
1. Start install with default LVM encrypted layout
2. Interrupt it at package installation (just not to wait)

3. Reboot second time
4. Open created LUKS device using DE tools (I'm using KDE, if that does matter)
5. Close dolphin/nautilus and start installation
6. Select default LVM partitioning - remove all partitions that were created before and use auto-partitioning
7. Begin install - it will crash

Seems like anaconda doesn't umount/closes luks device before removing it...

(In reply to Alexey Torkhov from comment #29)
Please post the /tmp/anaconda-tb file.

Created attachment 834281 [details]
anaconda-tb

Trying to reproduce bug 1008732 comment 28. Followed verbatim (in GNOME).

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-TC rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.11.10-300.fc20.x86_64
other involved packages: python-blivet-0.23.8-1.fc20.noarch, python-libs-2.7.5-9.fc20.x86_64
package:        anaconda-20.25.14-1.fc20.x86_64
packaging.log:  
product:        Fedora
reason:         LUKSError: luks device not configured
release:        Fedora release 20 (Heisenbug)
version:        20

Discussed in 2013-12-09 Blocker Review meeting [1]. Voted as a RejectedBlocker as it requires you to fiddle around with partitions prior to running anaconda, and anaconda team is on record as not being willing to block on that kind of case. 

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-09/

Reproduced on install DVD following way:

1. Have layout of default LVM encrypted installation on disk
2. Start installed, go to custom partitioning, select LVM without encryption
3. Open LUKS device
4. Delete all partitions
5. Press refresh disks
6. Delete all partitions
7. Auto-create default layout and start installation

Bringing it back to re-evaluation.

still -1, you're still fairly artificially creating a scenario where you access a LUKS device then wipe it. i'm not convinced it's something that's actually going to happen much.

I can't reproduce this as described in c34. At step 5, upon rescanning, I'm booted out of Manual Partitioning, and I'm back to Installation Destination to choose the device again. I do so, and whether I use Manual Partitioning for step 6/7 or guided partitioning, I don't end up with a crash or other problem.

(In reply to Adam Williamson from comment #35)
> still -1, you're still fairly artificially creating a scenario where you
> access a LUKS device then wipe it. i'm not convinced it's something that's
> actually going to happen much.

The use case here is simple - reinstall previous encrypted installation using non-encrypted LVM while doing something in custom partitioning screen. While method might be a bit artificial it 

(In reply to Chris Murphy from comment #36)
> I can't reproduce this as described in c34. At step 5, upon rescanning, I'm
> booted out of Manual Partitioning, and I'm back to Installation Destination
> to choose the device again. I do so, and whether I use Manual Partitioning
> for step 6/7 or guided partitioning, I don't end up with a crash or other
> problem.

Ah, sorry, step 4 was excess. Here is correct reproduction steps:

1. Have layout of default LVM encrypted installation on disk
2. Start installed, go to custom partitioning, select LVM without encryption
3. Open LUKS device
4. Press refresh disks - it throws you back to installation destination spoke
5. Go to custom partitioning, select LVM without encryption
6. Delete all partitions
7. Auto-create default layout and start installation

Having 100% reproducible with this. I can make a video if needed.

(In reply to Alexey Torkhov from comment #37)
> While method might be a bit artificial it 
...also could reflect other real-world situations too.

For example, I'm getting this error also this way:
-- first 5 steps are same --
1. Have layout of default LVM encrypted installation on disk
2. Start installed, go to custom partitioning, select LVM without encryption
3. Open LUKS device
4. Press refresh disks - it throws you back to installation destination spoke
5. Go to custom partitioning, select LVM without encryption
-- now changes: --
It has currently old boot, old root on lvm and old swap on lvm in partition list.
6. Delete old root
7. Add new mount point, use / and don't enter size to fill it all free space
8. Select reformat /boot and set mount point for it
9. Start installation => it crashes

So, seems on install DVD this happens after refreshing open LUKS device.

Reproducing bug 1008732 comment 37.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020-TC5\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.11.10-300.fc20.x86_64
package:        anaconda-20.25.14-1
product:        Fedora
reason:         LUKSError: luks device not configured
release:        Cannot get release name.
version:        20-TC5

The problem here is that people might use the Rescan button instead of Reset All button, to reset their layout to previous configuration if they make any mistake. The button is there to be clicked, that's its purpose. It even says "All storage changes made using this installer will be lost when you press 'Rescan Disks'". It's reasonable to believe it's going to be used by users.

Note: Reset All button works fine, just Rescan crashes the installer.

Created attachment 834899 [details]
anaconda-tb reproducing c37 steps

c37 steps cause a reproducible crash for me, and this is the anaconda-tb file. Reproduced on F20 in qemu/kvm. 

I would never do this, because I'm familiar with the UI. But I suspect at least a significant minority of users do a lot of clicking around and back and forth, if they use Manual Partitioning at all.

This seems blocker worth as the existing and new layouts are valid, the installer just barfs. So I'm in favor of the safer solution: a documented work around to avoid this crash vs fixing it. At the moment I'm +1FE, and on the fence for blocker.

Created attachment 834926 [details]
anaconda-tb reproducing c37 steps

Replacing with a simpler to follow anaconda-tb.

Is reproducible when 1st (successful), and 2nd (crashes) attempts are either LVM or LVMthinp based. And reproducible if the file system is ext4 or xfs.

If both installs are standard partition devices, there is no crash. I didn't try changing device types from 1st to 2nd installs, they were kept the same.

So this might be LVM related. I'd like to know more about the cause, and whether there's something buggy about the refresh disks feature that might affect other (untested) scenarios.

Discussed in 2013-12-11 Blocker Review Meeting [1]. Voted as an RejectedBlocker and an AcceptedFreezeException. This is a fringe use case that might not hit many users. We will add it to CommonBugs and warn users they should not change the state of partitions (unlock them) before starting the installer, or do the same use the Rescan button. Timely patch will be considered.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-11/

Another user experienced a similar problem:

twice reproduced on validated fedora 20 iso ----complaining of python 2.7 failure at install point.


using thinkpad x201T (fpaste --sysinfo data to come)

cryptsetup luksFormat -c serpent-xts-plain64 -s 512 -h whirlpool -i 150000 -T 3 -t 30 --use-urandom  /dev/sda4 used for cipher   which was created on linuxmint 17 (dualboot from inside the luksContainer) 


sda1    biosboot

sda2/3 /boot 1 for lm17; 1 for f20 

sda4 crypt


lm17 previously installed no issues 

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=F20-x86_64-LIVE-XFCE-20140902 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.15.10-201.fc20.x86_64
other involved packages: python-blivet-0.23.9-1.fc20.noarch, python-libs-2.7.5-13.fc20.x86_64
package:        anaconda-20.25.16-1.fc20.x86_64
packaging.log:  
product:        Fedora
reason:         LUKSError: luks device not configured
release:        Fedora release 20 (Heisenbug)
version:        20

I used the "Disk" tool to create a primary /dev/sda1 partition and an extended /dev/sda5 to be used as a LUKS device.  I manually pvcreate'd the LUKS device, vgcreate'd and lvcreate'd logical volumes on it.  That was the resulting layout:

[liveuser@grimlock ~]$ sudo pvs
  No device found for PV NUec7P-VgQn-j9vR-jrra-uAET-hcLH-UyhfTd.
  PV                                                    VG          Fmt  Attr PSize   PFree  
  /dev/mapper/luks-dcb6828f-05c1-4952-b0b0-8c9f6059873e vg_grimlock lvm2 a--  476.45g 282.45g
[liveuser@grimlock ~]$ sudo lvs
  No device found for PV NUec7P-VgQn-j9vR-jrra-uAET-hcLH-UyhfTd.
  LV     VG          Attr       LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  home   vg_grimlock -wi-a----- 120.00g                                             
  opt    vg_grimlock -wi-a-----  10.00g                                             
  rootfs vg_grimlock -wi-a-----  10.00g                                             
  swap   vg_grimlock -wi-a-----   4.00g                                             
  tmp    vg_grimlock -wi-a-----  10.00g                                             
  usr    vg_grimlock -wi-a-----  30.00g                                             
  var    vg_grimlock -wi-a-----  10.00g                                             
[liveuser@grimlock ~]$ 

I then went to the "Installation to Disk" tool, selected the manual disk setup.  I chose to reformat all the LVs I created and picked the right mount points for them.  After starting the installation I got that error.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-1 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
other involved packages: python-blivet-0.23.9-1.fc20.noarch, python-libs-2.7.5-9.fc20.x86_64
package:        anaconda-20.25.15-1.fc20.x86_64
product:        Fedora
reason:         LUKSError: luks device not configured
release:        Fedora release 20 (Heisenbug)
version:        20

*** Bug 983099 has been marked as a duplicate of this bug. ***

*** Bug 1172333 has been marked as a duplicate of this bug. ***

this still happens on fedora 22

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

(In reply to Corey Sheldon from comment #50)
> this still happens on fedora 22

Thanks, Corey, for confirmation. Could you please provide fresh logs from F22? A file named anaconda-tb-* should be created in /tmp after crash. Or you can gather the log files from /tmp manually. Thank you.

Sorry no recent  builds   handy but can fire one up over the  weekend to  reproduce ---sorry for  delay been super  busy with a new venture...

Probably related to: https://github.com/rhinstaller/anaconda/pull/140.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.