libreport version: 2.0.7 abrt_version: 2.0.6 cmdline: /usr/bin/python -tt /usr/sbin/liveusb-creator executable: /usr/sbin/liveusb-creator kernel: 3.1.2-1.fc16.x86_64 reason: creator.py:451:handle_reply:UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 1: ordinal not in range(128) time: lun. 05 déc. 2011 14:16:45 CET uid: 0 username: root backtrace: Text file, 2442 bytes
Created attachment 548578 [details] File: backtrace
I'm also seeing this. My USB key named "tsurugi" cannot be handled by Fedora's liveusb-creator. On startup, I get: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 586, in msg_reply_handler reply_handler(*message.get_args_list(**get_args_opts)) File "/usr/lib/python2.7/site-packages/liveusb/creator.py", line 451, in handle_reply 'label': str(dev.Get(device, 'IdLabel')).replace(' ', '_'), UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 1: ordinal not in range(128) Then if I try to launch the process notheless, I get: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/liveusb/gui.py", line 458, in begin self.live.drive = self.get_selected_drive() File "/usr/lib/python2.7/site-packages/liveusb/creator.py", line 70, in <lambda> fset=lambda self, d: self._set_drive(d)) File "/usr/lib/python2.7/site-packages/liveusb/creator.py", line 367, in _set_drive raise LiveUSBError(_("Cannot find device %s" % drive)) liveusb.creator.LiveUSBError: Cannot find device None
Actually, I'm pretty sure this is due to accents in the path/filenames. /home/jeff/Téléchargements/Fedora 16.iso ...does not work, but the following does: /home/jeff/F16.iso
Hmm, though what I just noted in comment 3 might be a different issue, since it was with a different usb stick.
This issue should be resolved in liveusb-creator-3.11.7-1.fc17. Please open new bugs for other unicode issues you hit with this new release. Thanks! https://admin.fedoraproject.org/updates/FEDORA-2012-9384/liveusb-creator-3.11.7-1.fc17
*** This bug has been marked as a duplicate of bug 590232 ***