Created attachment 962611 [details]
File: anaconda-tb

Created attachment 962612 [details]
File: anaconda.log

Created attachment 962613 [details]
File: environ

Created attachment 962614 [details]
File: journalctl

Created attachment 962615 [details]
File: lsblk_output

Created attachment 962616 [details]
File: nmcli_dev_list

Created attachment 962617 [details]
File: os_info

Created attachment 962618 [details]
File: program.log

Created attachment 962619 [details]
File: storage.log

Created attachment 962620 [details]
File: ifcfg.log

I'm gonna propose this as a blocker so we give it proper consideration, but it's a subjective call, depending on how important we think the Japanese translation is. This is a violation of "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces. " (or any other 'must be able to install' criterion) in the case that Japanese is used (probably affects non-live as well as live, but I haven't checked yet).

The Japanese translation is not complete, and we've historically considered non-complete translations less likely to block release - quite significant chunks of the installer are still in English so it's kind of arguable you'd have to be able to speak English anyway to use the Japanese translation, therefore you can just use English as a workaround for this. A counterpoint is that at least a decent chunk of the installer is in Japanese, so maybe someone with only minimal English could muddle through the partial translation but not use a completely-English installer.

Also affects Chinese. I'm betting it'd affect Russian too, but Russian in fact crashes earlier - https://bugzilla.redhat.com/show_bug.cgi?id=1169020 for that one.

Also affects French, this one definitely looks like a showstopper.

This one doesn't seem to happen in Beta, looks like it broke somehow between Beta and Final.

offtopic on:
I seems that anaconda translation isn't complete for other languages in general with RC1.
I noticed that parts of anaconda, ie. partition, network part, user creation, wasn't translated to german in server netiso and mate-live too.
But i don't think that is big prob for german users ;)
offtopic off:

PS: the installer didn't crashed.

That's https://bugzilla.redhat.com/show_bug.cgi?id=1169023 . I suspect it is causing some of these crashes, as they don't seem to reproduce with Final TC4.

(In reply to Adam Williamson (Red Hat) from comment #16)
> That's https://bugzilla.redhat.com/show_bug.cgi?id=1169023 . I suspect it is
> causing some of these crashes, as they don't seem to reproduce with Final
> TC4.
That's one point, but the other point may be caused by the new build of pyparted, which is the source of strings causing this crash and also the crash from bug #1169020. I believe we can close them as duplicates, because both cases seem to crash on DiskLabel format's string descriptions.

gah! that's why I couldn't find what had changed, didn't think to look in pyparted :( thanks.

Another user experienced a similar problem:

I started the installation process with default settings, and instantly it stops with this error.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   initrd=/isolinux/initrd0.img root=live:UUID=B9F5-DEED rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 rd.live.check BOOT_IMAGE=/isolinux/vmlinuz0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-blivet-0.61.12-1.fc21.noarch, python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.18-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2: ordinal not in range(128)
release:        Fedora release 21 (Twenty One)
version:        Fedora

(In reply to Michael from comment #19)

As noted by Adam, French is affected by this. The language I used was Canadian French. When using Canadian English it works fine.

Also seen in Chinese.

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

Turns out the root cause of this issue is that the new pyparted build's python modules return unicode objects instead of (byte) strings and such combination of unicode objects and utf8-encoded (byte) strings causes issues. The triggering languages are those that have non-ascii translations of size units (e.g. "MiB") which means that there are some utf8-encoded non-ascii characters in strings that are then concatenated with pyparted's unicode objects causing these issues.

Turns out, Anaconda can quite easily deal with the change in pyparted.

updates.img with a fix for the issue:
http://vpodzime.fedorapeople.org/1169019_updates.img

(In reply to Vratislav Podzimek from comment #25)
> updates.img with a fix for the issue:
> http://vpodzime.fedorapeople.org/1169019_updates.img
This cannot work. It replaces the liveinst script that itself downloads and expands the updates.img.

To test the proposed change, please run:
$ sudo wget -O  /usr/sbin/liveinst http://vpodzime.fedorapeople.org/liveinst

before running liveinst.

(In reply to Vratislav Podzimek from comment #27)
> To test the proposed change, please run:
> $ sudo wget -O  /usr/sbin/liveinst http://vpodzime.fedorapeople.org/liveinst
> 
> before running liveinst.

This seems to fix the issue. The diff is:

+if [ -z $LC_ALL ]; then
+    # LC_ALL not set, set it to $LANG to make Python's default encoding
+    # detection work
+    export LC_ALL=$LANG
+fi

Discussed in 2014-12-01 Blocker review meeting. Voted an accepted blocker: any language with translated size units is likely to crash all over the place in live installs, this violates any 'successful installation' criterion: "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."

The fix for this seems to break translations. I span a smoketest live with anaconda 21.48-20, and the installer is not fully translated, even though the anaconda.mo files are definitely now correct. If I comment this newly-added block out of /usr/sbin/liveinst , the installer is fully translated.

Yeah. Setting LC_ALL as an environment variable appears to have the basic effect of 'locking' the language of quite a lot of strings. The ones that aren't affected seem to be ones that need special handling - e.g. at the main hub, the name of the timezone is translated in the date and time hub's status message, if you look in the code, you see it's provided by a special function get_xlated_timezone().

You can play around with this by just calling LC_ALL=(somelocale) liveinst. If you call LC_ALL=fr_FR.UTF-8 then, no matter what language you pick on the Welcome spoke, a lot of text will be in French, for instance.

So this fix's approach of setting LC_ALL when running liveinst just isn't going to work, it appears, unless there's some magic quick fix to anaconda.

And yes, if I comment out the block, then I can still reproduce the initial crash by running an install in Russian - so having complete translations does not fix the crasher bug. We need a different fix for the crasher bug which does *not* break translations, we can't just drop the bad change.

Hey, here's a blast from the past:

https://bugzilla.redhat.com/show_bug.cgi?id=539904
https://www.redhat.com/archives/anaconda-devel-list/2010-March/msg00284.html

the code added back then is still there, in current anaconda. pyanaconda/sitecustomize.py is present and correct and calling sys.setdefaultencoding('utf-8') . It's just somehow not working on live installs (any more?) - the code that logs the default encoding is also still present, and the log contains "Default encoding = ascii" when you run liveinst without vpodzime's hack.

Note that the live image's default encoding has been ascii for some time, even though #539904 was clearly trying to make anaconda's default encoding be utf-8. f20 logs "Default encoding = ascii" . So does F19. So, in fact, does F14, which is the oldest live image I've got lying around. I think the 'fix' for the default locale in #539904 never actually worked for live.

sgallagh spotted that sitecustomize.py is moved into /usr/lib/python2.7/site-packages in the non-live installer environment, which we're guessing is what makes it actually work properly there. It's in lorax:

share/runtime-postinstall.tmpl:move ${PYTHONDIR}/site-packages/pyanaconda/sitecustomize.py ${PYTHONDIR}/site-packages

this isn't done on the live image, and may well not be a smart thing to do on the live image. So we either have to find another way to set defaultencoding on the live image, or find some way to fix the pyparted interaction so that the strings that come from pyparted don't cause a problem even with the default encoding set to ascii.

sgallagh worked out a possible approach for this - a way to set the python default encoding which works on live as well as non-live. I've sent patches for his approach (one to revert vpod's attempt, one with sgallagh's approach) to the list.

We'd argue this is likely safe because it's pulling live into line with how non-live has done things for years (and it's what vpod was trying to do in the first place, he just didn't quite manage it).

There are other approaches, of course. You could try and handle all the unicode objects from pyparted properly, or patch pyparted back to sending encoded strings.

You could figure out why the locale that's set on the welcome screen is apparently not being used whenever the crash happens, because if it was, python ought to be using the utf-8 encoding, not ascii. sgallagh did spot a possible avenue of investigation for that:

<sgallagh> blivet is always calling 'lc_messages = locale.setlocale(locale.LC_MESSAGES, None)'
 (Note the 'None' there)
 setlocale() will see LC_ALL and switch to that
 I'd also like to point out the comment directly above this line in blivet:
 "This differs from the behavior of gettext.find if $LANGUAGE is being used, but on the other hand no one uses $LANGUAGE."
 $LANGUAGE and LC_ALL are closely tied together in the murky implementation details of .setlocale()
<sgallagh> adamw: https://github.com/dwlehman/blivet/blob/master/blivet/i18n.py

oh, looks like that blivet thing sgallagh saw is only on master not f21, so it's not relevant here.

So, tl;dr: this should be fixed in RC2.

Details:

In the end we (myself, kparal, and vpodzime) revisited the question of why pyparted's behaviour changed in the first place. We think there was a miscommunication between anaconda folks, and pyparted 3.10 was not actually supposed to be pulled in so late.

All builds from mid-June up to and including Final TC4 had pyparted 3.9.5. 3.10.2 was only pulled into Final RC1. The reason a new pyparted was needed at all was to add a new function needed for the fix for #1166598. It seems the people doing the update were probably under the impression that 3.10.1 was already in F21, and all 3.10.2 changed was to add the new function, so it was correct to add 3.10.2.

In fact 3.10.1 never went into F21, so the effect of the update was to cause a significant upgrade from 3.9.5 to 3.10.2, and we're pretty sure that wasn't really intended. The underlying cause of this crasher bug is a behaviour change between 3.9.5 and 3.10.2 which is not at all necessary for the fix for #1166598.

So, I took responsibility for building a pyparted 3.9.5-3, which is 3.9.5-2 with the new function needed for #1166598 backported. vpodzime built anaconda 21.48.21-1, which is anaconda 21.48.20-1 with his initial attempt to fix this bug (the hack to liveinst to set LC_ALL) reverted.

kparal and I ran some tests to verify the combination of pyparted 3.9.5-3 and anaconda 21.48.21-1 works as expected - no crashes, full translations, and #1166598 still fixed - then I filed the final RC2 request with those builds.

One little wrinkle we should note is that python-blivet.spec has this:

%define pypartedver 3.10.2
Requires: parted >= %{partedver}

which you'd think would need to be adjusted for the pyparted downgrade. Happily (for our particular circumstances), however, it happens to be buggy. pyparted has an Epoch of 1, so pyparted-1:3.9.5-3.fc21 satisfies the requirement already. So we don't need a new python-blivet which lowers the requirement (though obviously that bug should be fixed on master).

Confirmed fixed in RC2 and RC4.

All is now translated in German in anaconda, exept the help button and help (yelp) itself. Testeted with TC4 netiso and mate live image, no crashes.

I'm moving this to Rawhide (F22) and dropping the blocker status. The reversion of pyparted effectively addresses the bug for F21, that is by now solidly tested. However, the bug is almost certainly still valid against Rawhide, as Rawhide has pyparted 3.10 and nothing to change the live installer's defaultencoding. I can't test to empirically verify the bug remains, as Rawhide testing is currently blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1167036 , but I can't see any reason to expect it would not happen.

Proposing as an Alpha blocker for F22, as a conditional violation of criterion "The installer must be able to complete an installation to a single disk using automatic partitioning.", the condition being that you're using an affected translation (at least Russian, I haven't checked exactly which languages have non-ASCII characters in translations of text that appears in pyparted unicode objects, which I think is the problem here).

I can see an argument for fudging this to Beta or Final blocker, but let's get it on the list for discussion nice and early.

With an updates.img to avoid #1167036, I can confirm this does affect a current Rawhide nightly.

After a desktop-installtion from "Fedora-Live-Workstation-x86_64-21-5.iso" it is "pyparted 3.9.5-2.fc21 Epoch 1"" from koji-override-0 present.
Is this the right one? Or it is not yet a final solution available?

(In reply to Rolle from comment #43)
> After a desktop-installtion from "Fedora-Live-Workstation-x86_64-21-5.iso"
> it is "pyparted 3.9.5-2.fc21 Epoch 1"" from koji-override-0 present.
> Is this the right one? Or it is not yet a final solution available?
That seems to be the right version for F21. The problem now only exists on Rawhide.

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

Another user experienced a similar problem:

Just clicked the INSTALL TO HARD DRIVE option.  I've tried installing before the TRY and the same error happens.  I don't need to do anything except choose to install on hard drive.
3 message boxes pop up with the same "An error has occured"

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

I have my keyboard to US and running US English.  the image I have is what's refereenced above 21-5.iso I tryed downloading a newer spin but it hasn't changed.  Killing me not to be able to install this.  Wish I could be more help, but I'm a hardware/systems guy and not a hacker.  Let me know if I can help or test in any way.

John: can you please attach the full logs? Your case may be something different. After reproducing the bug, at least 'journalctl -b' output, /tmp/anaconda.log , /tmp/storage.log , and /tmp/program.log . Thanks!

Another user experienced a similar problem:

Installation on Dell D430 / zifs SSD

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat rw rd.live.image rd.live.overlay=LABEL=LIVE quiet acpi_osi=Linux acpi_backlight=vendor rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

installazione

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-MATE-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Clearing abrt_hash to try and get fresh reports, we don't think these bugs are actually all dupes of the unicode encoding issue.

right - found problem for mine ... have had zfs on that drive. After removing zfs from SSD the installer does not crash again.

Created attachment 970689 [details]
Adding logs per request of Adam

Adding my logs per request of Adam W.

Created attachment 970690 [details]
Journalctl log per request

Journalctl log per Adam request.

Created attachment 970692 [details]
program log per request

program.log per request

Created attachment 970693 [details]
Storage log per request

storage.log per request

John, please open a bug against python-blivet with all the logs, especially /tmp/anaconda-tb-* if it exists.

(In reply to bcl from comment #57)
> John, please open a bug against python-blivet with all the logs, especially
> /tmp/anaconda-tb-* if it exists.

Created new bug: Bug 1177674

Discussed at today's blocker review meeting [1]. Accepted as a blocker. This bug is a conditional violation of the Alpha criterion: The installer must be able to complete an installation to a single disk using automatic partitioning.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-01-07/

Another user experienced a similar problem:

an unknown error

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

The anaconda installer has problems to list lvm cache logical volumes. (see the map below)
The problem appears to be on AddRequieredLV function on devicetree.py
(/usr/lib/python2.7/site-packages/blivet/devicetree.py)

[root@localhost liveuser]# lsblk 
NAME                               MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                                  8:0    0    20G  0 disk 
├─sda1                               8:1    0   512M  0 part 
├─sda2                               8:2    0     4G  0 part 
└─sda3                               8:3    0  15.5G  0 part 
  ├─vg_spacial-lv_cache_root_cdata 253:7    0     4G  0 lvm  
  │ └─vg_spacial-lv_root           253:4    0    20G  0 lvm  
  ├─vg_spacial-lv_cache_root_cmeta 253:8    0     1G  0 lvm  
  │ └─vg_spacial-lv_root           253:4    0    20G  0 lvm  
  ├─vg_spacial-lv_cache_home_cdata 253:10   0     4G  0 lvm  
  │ └─vg_spacial-lv_home           253:3    0    60G  0 lvm  
  └─vg_spacial-lv_cache_home_cmeta 253:11   0     1G  0 lvm  
    └─vg_spacial-lv_home           253:3    0    60G  0 lvm  
sdb                                  8:16   0   100G  0 disk 
└─sdb1                               8:17   0   100G  0 part 
  ├─vg_spacial-lv_tmp              253:5    0     5G  0 lvm  
  ├─vg_spacial-lv_varlog           253:6    0     5G  0 lvm  
  ├─vg_spacial-lv_root_corig       253:9    0    20G  0 lvm  
  │ └─vg_spacial-lv_root           253:4    0    20G  0 lvm  
  ├─vg_spacial-lv_home_corig       253:12   0    60G  0 lvm  
  │ └─vg_spacial-lv_home           253:3    0    60G  0 lvm  
  └─vg_spacial-lv_swap_slow        253:13   0     2G  0 lvm  
sdc                                  8:32   1 251.9M  0 disk 
└─sdc1                               8:33   1   251M  0 part 
sr0                                 11:0    1   1.4G  0 rom  /run/initramfs/live
loop0                                7:0    0    12K  1 loop 
loop1                                7:1    0   1.8M  1 loop 
└─live-osimg-min                   253:2    0     6G  1 dm   
loop2                                7:2    0   1.3G  1 loop 
loop3                                7:3    0     6G  1 loop 
├─live-rw                          253:0    0     6G  0 dm   /
├─live-base                        253:1    0     6G  1 dm   
└─live-osimg-min                   253:2    0     6G  1 dm   
loop4                                7:4    0   512M  0 loop 
└─live-rw                          253:0    0     6G  0 dm   /

[root@localhost liveuser]# pvs
  PV         VG         Fmt  Attr PSize   PFree
  /dev/sda3  vg_spacial lvm2 a--   15.50g 5.50g
  /dev/sdb1  vg_spacial lvm2 a--  100.00g 7.00g

[root@localhost liveuser]# vgs
  VG         #PV #LV #SN Attr   VSize   VFree 
  vg_spacial   2   7   0 wz--n- 115.49g 12.49g

[root@localhost liveuser]# lvs
  LV            VG         Attr       LSize  Pool          Origin          Data%  Meta%  Move Log Cpy%Sync Convert
  lv_cache_home vg_spacial Cwi---C---  4.00g                                                                      
  lv_cache_root vg_spacial Cwi---C---  4.00g                                                                      
  lv_home       vg_spacial Cwi-a-C--- 60.00g lv_cache_home [lv_home_corig]                                        
  lv_root       vg_spacial Cwi-a-C--- 20.00g lv_cache_root [lv_root_corig]                                        
  lv_swap_slow  vg_spacial -wi-a-----  2.00g                                                                      
  lv_tmp        vg_spacial -wi-a-----  5.00g                                                                      
  lv_varlog     vg_spacial -wi-a-----  5.00g  
                                                                 


cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

we need to talk to the libreport folks about why these AttributeError: 'NoneType' object has no attribute 'path' crashes are showing up as dupes of this bug, because they *clearly* aren't...

Spacial: Could you please create a separate report against anaconda? Please attach all log files from /tmp.

(In reply to Spacial from comment #61)
> Another user experienced a similar problem:
> 
> The anaconda installer has problems to list lvm cache logical volumes. (see
> the map below)
> The problem appears to be on AddRequieredLV function on devicetree.py
> (/usr/lib/python2.7/site-packages/blivet/devicetree.py)

> reason:         AttributeError: 'NoneType' object has no attribute 'path'
> release:        Fedora release 21 (Twenty One)
> version:        Fedora

Please file it against python-blivet.

(In reply to Kamil Páral from comment #63)
> Spacial: Could you please create a separate report against anaconda? Please
> attach all log files from /tmp.

Sure, on monday I'll upload them.

blc&redhat (ok)

Another user experienced a similar problem:

Just starting Anaconda from the install image causes this error

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 rd.live.check
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

So, aside from all the false dupes, I did try and reproduce this with a recent Rawhide snapshot. I wasn't able to reproduce with the 2015-02-03 Xfce live, but I note that all units seem to be displayed in English, when I choose Russian or Chinese on the Welcome screen. Not sure if that's intentional or a bug.

(In reply to bcl from comment #64)
> (In reply to Spacial from comment #61)
> > Another user experienced a similar problem:
> > 
> > The anaconda installer has problems to list lvm cache logical volumes. (see
> > the map below)
> > The problem appears to be on AddRequieredLV function on devicetree.py
> > (/usr/lib/python2.7/site-packages/blivet/devicetree.py)
> 
> > reason:         AttributeError: 'NoneType' object has no attribute 'path'
> > release:        Fedora release 21 (Twenty One)
> > version:        Fedora
> 
> Please file it against python-blivet.

Opened BUG 1188851 
https://bugzilla.redhat.com/show_bug.cgi?id=1188851

(In reply to Kamil Páral from comment #63)
> Spacial: Could you please create a separate report against anaconda? Please
> attach all log files from /tmp.

I think I don't have the /tmp files anymore.

but tried to be specific to reproduce it.

Another user experienced a similar problem:

I am trying to install on an Samsung Ativ Tablet notebook. When I boot up the live system from a USB, the installation ask me if I want to install on the hard drive. When I indicate that I want to install on the hard drive the system will show an error message and ask me if I want to send a bug report. Then, when I quit, it just sends me back to the live version without installing at all.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/syslinux/vmlinuz0 root=live:LABEL=LIVE ro rd.live.image quiet rhgb nomodeset
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

Run live, select activities, select install to hard drive. Boom.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-i686-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.i686
other involved packages: python-libs-2.7.8-7.fc21.i686
package:        anaconda-core-21.48.21-1.fc21.i686
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

I installed FedoraLive 21 work station.
After trying the distro I want to install it on mi disk.
During the language choise I got the an error of the anagonda installer 

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=UUID=749D-3648 rootfstype=vfat ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.i686
other involved packages: python-libs-2.7.8-7.fc21.i686
package:        anaconda-core-21.48.21-1.fc21.i686
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

1. Boot FedoraLive 21 worktation from USB
2. Played a little bit with Fedora
3. After that I want to install it.
4. Choose the language Nederlands.
5. Error annagonda 

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=UUID=749D-3648 rootfstype=vfat ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.i686
other involved packages: python-libs-2.7.8-7.fc21.i686
package:        anaconda-core-21.48.21-1.fc21.i686
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

Clicked on "install to hard drive" from activtities bar when running on Live USB.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

Clicked on "install to hard drive" when running on LiveUSB.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0  BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

The proposed patch [1] has not been accepted [2] so I no longer consider this bug POST and I must say I don't have any other/better solution for it. By Fedora 23 it could have been gone thanks to the transition to Python 3.

[1] https://lists.fedorahosted.org/pipermail/anaconda-patches/2015-February/016053.html

[2] https://lists.fedorahosted.org/pipermail/anaconda-patches/2015-February/016059.html

If the crash still happens it is clearly an F22 blocker, it is unacceptable to ship with it broken. But I haven't yet been able to reproduce the actual ASCII crasher on F22.

There are other ways to approach the problem, but it could really benefit from being done early, i.e. have someone who knows the code better than I do make sure the .encode() / .decode() dance is done on all the appropriate strings.

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

I still haven't managed to reproduce this with a 22 Alpha TC. I'd be extremely surprised if there weren't still issues of this type lurking about, but it seems it's not at all as easy to hit as it was with 21; you can't trigger it just by doing a regular install in Russian. I think the changes to handling of sizes have affected this somehow (I don't see translations of 'MiB' and 'GiB' when doing the install in Russian).

Given my testing so far I'm withdrawing the blocker nomination for 22 Alpha, I'll try to keep an eye on it for future milestones.

Another user experienced a similar problem:

Clicked "Install to harddrive".  HP Proliant ML350 w/ RAID10

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Xfce-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

use root account to execute liveinst.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/syslinux/vmlinuz0 root=live:UUID=5912-4EB1 rw rd.live.image rd.live.overlay=UUID=5912-4EB1 quiet rhgb
hashmarkername: anaconda
kernel:         3.18.7-200.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

El error ocurrio al intentar instalar el sistema operativo en mi disco duro. Fedora simplemente me impide acceder al programa de instalacion porque se detecta un error.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

Intention is to install into an existing F20 installation, because fedup failed on the job.

Booting with F21 GNOME-Desktop from USB-device generated by liveusb-creator.

Changing Network settings, Hostname, language settings, keyboard settings

Installing some tools (disktype, yumex,...)

Invoke 'Install to Disk' throws exception on first page.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-WS-x86_64-21-5 ro rd.live.image quiet rhgb rd.live.check
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

If the automatically reported bug is not really a dup of 'ordinal not in range' could someone please give a pointer to the parent bug 'NoneType object has no attribute path'?

Or even better treat this bug as if it where 'NoneType object has no attribute path' as all the me-too goes here? This would include to re-assign this bug.

Is there a simple workaround for one of the two?

Unfortunately the NoneType object has no attribute path exception itself is somewhat generic; so far we've found at least two different known bugs that can lead to it:

https://bugzilla.redhat.com/show_bug.cgi?id=1157657 (backup GPT corrupt)
https://bugzilla.redhat.com/show_bug.cgi?id=1188851 (LVM cache)

Of course we'd like to address the bugs people are hitting - it can just be tricky because when libreport decides the bug is a dupe it doesn't upload the logs anywhere :/ I keep meaning to talk to libreport folks about how we can stop bugs appearing as dupes of this one, but never find time for it. Sorry about that.

If you can attach logs from your case, we can try to see what's going on. From the anaconda environment, you can find the logs in /tmp (*.log and also anaconda-tb*), and 'fpaste' is available (so long as your network is up, of course) for getting them out, or you can attach a USB stick and mount it. Thanks, and sorry for the trouble.

Meanwhile i discovered the cause of the problem (not the 'ordinal not in range' but the 'NoneType has no...')

It is not a corrupt GPT (i did gdisk command 'o' just before) nor a weird LVM setup (i avoid LVM whenever i can)

The Install-To-Disk takes some preferences from the running live-image, as the hostname, language setting, keyboard, etc.
So i normally set german keyboard, german language settings, network settings before starting Install-To-Disk.

When i skip the language setting (LANG=de_AT.UTF-8) this bug doesnt show up.

From other comments i see also other languages affected so i believe there is some tool used in the install process which gives unparseable output when used in localized mode. This tool should be isolated and called with LC_ALL=C

This solution is a workaround.
Now i have done a big step forward to
https://bugzilla.redhat.com/show_bug.cgi?id=1172451

Can you please file a new bug for that case? Thanks. Ideally, attach the logs - at least anaconda-tb*.

Another user experienced a similar problem:

After starting the Fedora Anadonda Installer from the live media this error immediately occurs. 

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

I'm trying to install Fedora 21 Workstation in an HP ProLiant (Intel Xeon), but Anaconda crashes when I first open it.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/ubnkern initrd=/ubninit root=live:UUID=73DD-7AEF rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Adding 'see also' links to a bunch of bugs that have showed up in Final TC1 (after we turned anaconda translations into unicode objects). This bug has the most research about the underlying 'default encoding is ASCII in some cases' problem.

Another user experienced a similar problem:

It happens when i try to install Fedora. It doesnt allow me to set an language before crash.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/syslinux/vmlinuz0 root=live:LABEL=LIVE ro rd.live.image quiet rhgb rd.live.check
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Another user experienced a similar problem:

Was trying to install Fedora 21 on a old AMD 64 dual core machine.  I just hit the Install to Hard drive button.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

Cesar, Bill - if you haven't yet, try 22, it should not have this problem.

Another user experienced a similar problem:

Just tried to install fedora from the GUI

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-21-5 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         AttributeError: 'NoneType' object has no attribute 'path'
release:        Fedora release 21 (Twenty One)
version:        Fedora

I have installed the latest Fedora.  Haven’t tested fully, appears to work so far.

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.