Description of problem: Crash hit at start of install process when installing from Fedora 21 Final RC1 in Japanese, chose a fairly default install config which works in English. Version-Release number of selected component: anaconda-core-21.48.18-1.fc21.x86_64 The following was filed automatically by anaconda: anaconda 21.48.18-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 530, in execute msg = _("Creating %(type)s on %(device)s") % {"type": self.device.format.type, "device": self.device.path} File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 362, in processActions action.execute(callbacks) File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 365, in doIt self.devicetree.processActions(callbacks) File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 216, in turnOnFilesystems storage.doIt(callbacks) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 191, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg) File "/usr/lib64/python2.7/threading.py", line 766, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 227, in run threading.Thread.run(self, *args, **kwargs) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 11: ordinal not in range(128) Additional info: 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-1 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 executable: /sbin/anaconda 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 product: Fedora" release: Fedora release 21 (Twenty One) type: anaconda version: Fedora
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.