Error opening image file #454
Comments
|
PS The image folder contains "46 items, totalling 71.6 GB" |
|
Sorry for your experience This was known issue impacting a small number of systems. The root cause was fixed a few weeks ago (#402) but the upcoming version with the fix (Rescuezilla v2.5) has not yet been released. Rescuezilla v2.5 is only awaiting final testing. It will probably be released in less than 2 weeks, but since it seems you really need the release I will try and release it sooner |
Good to hear, thanks for all your efforts! :) I'd be happy to try a beta if available? |
|
Hey @Craigp23, Could you please upload the file named something like It appears this instance of the bug is actually slightly different to the one I fixed a few months ago. Your file will allow me to confirm I've fixed the bug before releasing Rescuezilla v2.5 in the next day or so. Thanks! |
Revert (unreleased) change where "lshw" and "efibootmgr" were producing binary data, and custom 'None' encoding was used. The change is likely valid, but there are other circumstances where things are being handled incorrectly (rescuezilla#454) that require further thought, ideally based on a true reproducible test case. Also "efibootmgr" is used during the restore process so further examination in also warranted. The change will likely be adjusted and reapplied in future. This reverts commit d423de0.
Revert (unreleased) change where "lshw" and "efibootmgr" were producing binary data, and custom 'None' encoding was used. The change is likely valid, but there are other circumstances where things are being handled incorrectly (rescuezilla#454) that require further thought, ideally based on a true reproducible test case. Also "efibootmgr" is used during the restore process so further examination in also warranted. The change will likely be adjusted and reapplied in future. This reverts commit d423de0. Reverts PR rescuezilla#443. Issue references rescuezilla#402, rescuezilla#412, rescuezilla#443, rescuezilla#454
…ing release (#458) Revert (unreleased) change where "lshw" and "efibootmgr" were producing binary data, and custom 'None' encoding was used. **The purpose of the revert is to unblock releasing the existing work (as a quite stable, well-tested rolling release) without introducing behavior different to Rescuezilla v2.4.2 that was only tested against synthetic data** The change is likely valid, but there are other circumstances where things are being handled incorrectly (#454) that require further thought, ideally based on a true reproducible test case. Also "efibootmgr" is used during the restore process so further examination in also warranted. The change will likely be adjusted and reapplied in future. This reverts commit d423de0. Reverts PR #443. Issue references #402, #412, #443, #454
|
Hey Shasheen :)
Does this help?
Thanks!
…On Sun, 26 Nov 2023 at 04:53, Shasheen Ediriweera ***@***.***> wrote:
Hey @Craigp23 <https://github.com/Craigp23>,
*Could you please upload the file named something like sda-pt.parted* (it
may not have the sda in the name) so I can take a look? It's a small text
file contains some non-sensitive information about your system. If you
don't want to upload it here you can send it to rescuezilla at gmail.
It appears this instance of the bug is actually slightly different to the
one I fixed a few months ago.
Your file will allow me to confirm I've fixed the bug before releasing
Rescuezilla v2.5 in the next day or so.
Thanks!
—
Reply to this email directly, view it on GitHub
<#454 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASNCFWVN5KAHVYHJITMYJ7LYGLDM7AVCNFSM6AAAAAA7IBH5VCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRWGUZTEOBUGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I might be missing something, but I can't see the attached file because it looks like you sent it to the GitHub reply email address and it appears that way of responding won't automatically shift email attachments to GitHub it seems. Please reupload it on the GitHub website or email rescuezilla at gmail directly and I'll take a look! |
I'd be grateful for any help with this error when attempting to open an image file with RescueZilla v2.3.1 64bit. TIA :)
MacBookPro-Mid2012-2023-08-20-1723-img-rescuezilla/parts: Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/rescuezilla/image_folder_query.py", line 185, in scan_file
temp_image_dict = ClonezillaImage.get_clonezilla_image_dict(absolute_path, enduser_filename)
File "/usr/lib/python3/dist-packages/rescuezilla/parser/clonezilla_image.py", line 159, in get_clonezilla_image_dict
clonezilla_image_dict[key] = ClonezillaImage(absolute_clonezilla_img_path, enduser_filename, dir,
File "/usr/lib/python3/dist-packages/rescuezilla/parser/clonezilla_image.py", line 255, in init
Utility.read_file_into_string(parted_filepath))
File "/usr/lib/python3/dist-packages/rescuezilla/utility.py", line 278, in read_file_into_string
data = file.read()
File "/usr/lib/python3.10/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbd in position 2: invalid start byte
The text was updated successfully, but these errors were encountered: