Description of problem:isodumper is non-functional (64bit and 32bit) Version-Release number of selected component (if applicable):1.44-3 How reproducible:open isodumper, try an operation Steps to Reproduce: 1.start isodumper and insert thumb drive 2.choose drive to work on from list 3.All option check boxes are greyed out
Summary: isodumper 1.44-3 non-functional, will not write or firmat => isodumper 1.44-3 non-functional, will not write or format
Starting from console: germ@localhost ~]$ isodumper UDisks2 OK This is the only output. Same behavior as root.
Have you tried different USB sticks? Tried formatting it as plain FAT32 or ext4, first? In forum: https://forums.mageia.org/en/viewtopic.php?t=14922 CC packager and other people who have touched this.
CC: (none) => anaselli, fri, geiger.david68210, yves.brungard_mageia
Yes, I have tried that. I can't even tick the boxes for the operations. I can format in MCC and gnome-disks.
Which Desktop do you use? Does it run in Gtk mode or Qt mode ?
I use Plasma. I tried isodumper-qt and isodumper-gtk. Same behavior on both.
Created attachment 13822 [details] Showing mga9 isodumper working $ rpm -qa|grep isodumper isodumper-qt-1.44-3.mga9 isodumper-1.44-3.mga9 As shown in the attached image, isodumper is working for me. This is an m9 x86_64 plasma install.
CC: (none) => davidwhodgins
Check (as root) the output of the command dmesg and the output of the command "journalctl -b --no-h|tail -n 20" for error messages.
How the device is reported (the full line labelling it)? Are you sure you don't select the void line? Is something reported in the text box?
maybe it's me that i don't get it well, but could you please add a screenshot of isodumper after you inserted the key and chose it?
and btw have you chosen the iso to write?
isodumper will not let me choose anything but the drive to work on. Every other choice, iso to use, format, etc. will not let me check a box for the choice. I can't browse for an iso. Nothing.
Previous versions worked. 1.44-3 does not. It's a simple app. I've been using computers since they were green screen little boxes. I've been using linux since the mid-90s. All these questions about the right selection, have I chosen the iso, etc. are non-productive
didn't mean to offend, just understand. And i recall that screens were also orange... :)
I apologise. Just frustrated. Two different machines. same problem.
We understand your frustration. Wonder what the problem is. I have tried isodumper on mga9 on both my laptop and workstation, four different USB sticks, Plasma and Xfce, and all work. --- While having the devs here: small nit-picks: 1) When there is no USB stick plugged in there is a popup window warning that there is no USB stick plugged in to write ISO to. As this tool can be used for only formatting, or backupping, why not skip that message about ISO, and also skip Warning", instead just a plain one line text: "Please plug in a USB media." 2) When having selected to create a persistent partition, the label field should be greyed (or even better be locked and show "mgalive-persist". 3) The Word persistent in that selection have a basically correct for for the situation funny translation in Swedish. Better use English "persistent" which is also usable in Swedish in this technical context, ans is used in documentation.
Are you using wayland by any chance? If so, try switching to xorg.
is the outcome different if you invoke Isodumper from a root terminal?
CC: (none) => westel
Dave: No. I use xorg Ben: No. Same behavior.
disregard comment 17- reread comment1 - sorry.
when you select the USB, is there any text in the info box at the bottom regarding the USB? see also comment8
Created attachment 13823 [details] journal trying to run isodumper journalctl output.
Ben: No, nothimg.
dmesg output when you plug in the USB?
And the output of "urpmq --list-url|grep 'distrib1)'" I'm wondering if it's a stale mirror.
Created attachment 13824 [details] urpmi distrib
Created attachment 13825 [details] dmesg when plugging in a drive
Please also post or attach the output of "urpmq --not-available" (Trying to think of things that might cause the issue on that system, but not on others).
just booted into a newish x86_86 XFCE without isodumper. adding isodumper brings in all these packages: urpmi isodumper In order to satisfy the 'isodumper-gui' dependency, one of the following packages is needed: 1- isodumper-gtk-1.44-3.mga9.noarch: IsoDumper for GTK (to install) 2- isodumper-qt-1.44-3.mga9.noarch: IsoDumper for Qt (to install) What is your choice? (1-2) 1 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release (distrib1)") isodumper 1.44 3.mga9 noarch isodumper-gtk 1.44 3.mga9 noarch (recommended) lib64keccak1 1.2 3.mga9 x86_64 lib64yui-gtk16 2.52.3 3.mga9 x86_64 (recommended) lib64yui-mga-gtk16 1.2.0 7.mga9 x86_64 (recommended) lib64yui-mga-ncurses16 1.2.0 3.mga9 x86_64 lib64yui-mga16 1.2.1 5.mga9 x86_64 lib64yui-ncurses16 4.4.4 3.mga9 x86_64 lib64yui16 4.4.4 3.mga9 x86_64 python3-gettext 4.0 6.mga9 noarch python3-gnupg 0.5.0 1.mga9 noarch python3-manatools 0.0.4 3.mga9 noarch python3-parted 3.11.7 3.mga9 x86_64 python3-psutil 5.9.2 1.mga9 x86_64 python3-pydbus 0.6.0 9.mga9 noarch python3-yaml 6.0 1.mga9 x86_64 python3-yui 4.4.4 3.mga9 x86_64 sha3sum 1.1.5 3.mga9 x86_64 9.6MB of additional disk space will be used. 2.3MB of packages will be retrieved. Proceed with the installation of the 18 packages? (Y/n) y isodumper then invoked correctly and wrote an .iso file to USB. do you have all these packages. I'm thinking that you may have had an interrupted update, and something failed to update correctly. alternate would be to remove isodumper and re-install.
My presumption is that the name of the USB device is not what the application expects. What is the ouput of: udisksctl info -b /dev/sdb (change sdb to what is the path to the USB device)
And the answer to my question of comment 8: How the device is reported (the full line labelling it)? The questions have now eliminated all problems between the chair and the keyboard. It is time to consider that the application is the culprit.
And isodumper never needs to be launched in root session.
It's possible an interrupted update is the culprit. But kind of odd that isodumper displays the same behavior on 2 different machines/installations. I'll have to answer the rest when I get home. I'm at work now.
I agree that to UNinstall isodumper, both versions urpme isodumper[-gtk|qt] and clear orphans: urpme --auto-orphans Clear the RPM cache: urpmi --clean and re-install the application, is very worthwhile when you are the only victim. Too many people are saying it works; if it does not for you -and on 2 machines! - there is a problem to find... I did not notice any note of the origin of the systems involved: pure Cauldron, from a Mageia 9 ISO, or upgrade from Mageia 8 with the Classic ISO.
CC: (none) => lewyssmith
Lewis: I did as you suggested. No joy, same behavior. Box 1: online upgrade from mga 8. I keep it fully updated. Box 2: clean install using alpha1. I keep it fully updated.
Created attachment 13828 [details] udisksctl
Created attachment 13829 [details] urpmq --not-available
Ben: I'm trying to use isodumper-qt. When I try installing isodumper-gtk from command line it to wants to install half the gnome desktop! maybe an exaggeration, but its 284mb of packages.
(In reply to papoteur from comment #8) > How the device is reported (the full line labelling it)? The question is still pending
(In reply to Stephen Germany from comment #35) > Created attachment 13828 [details] > udisksctl And now, I would like to have: udisksctl info -d Generic_Flash_Disk_0821F3F0 The application uses a combination of Vendor and Model fields, and I suppose that they are void.
papoteur: isodumper identifies it as: Generic Flash Disk (dev/sdc) 29.297 GiB Nothing in the report text box below.
Created attachment 13830 [details] udisksctl info -d Generic_Flash_Disk_0821F3F0
And before anyone asks, yes I have tried different thumb drives.
lib64yui12-3.10.0-3.mga8.x86_64 lib64yui12-mga-qt-1.1.0-4.mga8.x86_64 lib64yui12-ncurses-2.55.0-2.mga8.x86_64 lib64yui12-mga-ncurses-1.1.0-4.mga8.x86_64 are still in mga8 release. This is not expected. You should have: lib64yui16-4.4.4-3.mga9 lib64yui-mga16-1.2.1-5.mga9 lib64yui-ncurses16-4.4.4-3.mga9 lib64yui-mga-ncurses16-1.2.0-3.mga9 lib64yui-qt16-4.4.4-3.mga9 lib64yui-mga-qt16-1.2.0-3.mga9 I presume that the mix of version don't allow the event managing in the application to work.
(In reply to papoteur from comment #29) > My presumption is that the name of the USB device is not what the > application expects. > What is the ouput of: > udisksctl info -b /dev/sdb > (change sdb to what is the path to the USB device) This is not valid assumption.
OK. I'll work on that when I get home. Thank you. I didn't think to check versions. Will report back.
papoteur: I removed the mga8 packages and made sure the mga9 packages were installed. reinstalled isodumper and isodumper-qt. No change in behavior.
OK. Long strange trip... I formatted a thumb drive in MX-Linux and the MX utility labeled it different: VendorCo ProductCode (/dev/hdc) 29.297 GiB Still the same behavior from isodumper. I tried a brand new thumb drive out of the box. Same behavior from isodumper. I have an old hard drive that I hooked up as usb. Isodumper worked on it just fine. This is all just so strange...
Hi Stephen, I committed a modification for isodumper Are you able to apply this change to your installation? The file to change is /usr/lib/python3.10/site-packages/isodumper/isodumper.py I don't know if this will be enough, because I don't understand well were the problem is. This is a try.
I missed the link to the patch: https://gitweb.mageia.org/software/isodumper/commit/?id=8e7b8a4c3f47662489023f0ddd1dbf528b89b6da
OK. Thank you. I'll give it a try. Hopefully, that will do it.
[germ@localhost ~]$ python3 /home/germ/Downloads/isodumper.py File "/home/germ/Downloads/isodumper.py", line 2 index da79323..076c529 100755 ^ SyntaxError: invalid decimal literal [germ@localhost ~]$
Hi Stephen, You can use this link to get directly the new isodumper.py file https://gitweb.mageia.org/software/isodumper/plain/lib/isodumper.py?id=8e7b8a4c3f47662489023f0ddd1dbf528b89b6da
OK. Thank you.
[germ@localhost ~]$ python3 /home/germ/Downloads/isodumper.py Traceback (most recent call last): File "/home/germ/Downloads/isodumper.py", line 32, in <module> from isodumper import version ImportError: cannot import name 'version' from partially initialized module 'isodumper' (most likely due to a circular import) (/home/germ/Downloads/isodumper.py) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/germ/Downloads/isodumper.py", line 32, in <module> from isodumper import version File "/home/germ/Downloads/isodumper.py", line 34, in <module> import version ModuleNotFoundError: No module named 'version' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/germ/Downloads/isodumper.py", line 34, in <module> import version ModuleNotFoundError: No module named 'version' [germ@localhost ~]$
Yves, I appreciate you trying to help but if you are getting tired of it, I undertaand. I can write ISOs with Rosa or Etcher and if I need to format I can use gparted or MCC. Thanks for trying.
@Stephen i suspect you need to replace the file over the installed one (maybe back up it first). version is installed by the rpm package.
OK. I will try that. Thank you.
Didn't work.
(In reply to Stephen Germany from comment #58) > Didn't work. Hi Stephen, What didn't work? The copy of the file? The launch of the new isodumper? The selection of the device?
isodumper would not start. (Sorry for the late reply. I had doctor appointments yesterday.)
With same error?
No error. Just wont start. I didn't try in a terminal.
Created attachment 13853 [details] isodumper from console
Running isodumper up to the point of having selected a usb drive under strace ... # grep import strace.txt |grep -v such 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib/__init__.py", {st_mode=S_IFREG|0644, st_size=6089, ...}, 0) = 0 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib/__init__.py", {st_mode=S_IFREG|0644, st_size=6089, ...}, 0) = 0 67072 openat(AT_FDCWD, "/usr/lib64/python3.10/importlib/__pycache__/__init__.cpython-310.pyc", O_RDONLY|O_CLOEXEC) = 3 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 67072 openat(AT_FDCWD, "/usr/lib64/python3.10/importlib", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib/util.py", {st_mode=S_IFREG|0644, st_size=11487, ...}, 0) = 0 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib/util.py", {st_mode=S_IFREG|0644, st_size=11487, ...}, 0) = 0 67072 openat(AT_FDCWD, "/usr/lib64/python3.10/importlib/__pycache__/util.cpython-310.pyc", O_RDONLY|O_CLOEXEC) = 3 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib/_abc.py", {st_mode=S_IFREG|0644, st_size=1852, ...}, 0) = 0 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib/_abc.py", {st_mode=S_IFREG|0644, st_size=1852, ...}, 0) = 0 67072 openat(AT_FDCWD, "/usr/lib64/python3.10/importlib/__pycache__/_abc.cpython-310.pyc", O_RDONLY|O_CLOEXEC) = 3 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib/machinery.py", {st_mode=S_IFREG|0644, st_size=831, ...}, 0) = 0 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/importlib/machinery.py", {st_mode=S_IFREG|0644, st_size=831, ...}, 0) = 0 67072 openat(AT_FDCWD, "/usr/lib64/python3.10/importlib/__pycache__/machinery.cpython-310.pyc", O_RDONLY|O_CLOEXEC) = 3 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/site-packages/gi/importer.py", {st_mode=S_IFREG|0644, st_size=5498, ...}, 0) = 0 67072 newfstatat(AT_FDCWD, "/usr/lib64/python3.10/site-packages/gi/importer.py", {st_mode=S_IFREG|0644, st_size=5498, ...}, 0) = 0 67072 openat(AT_FDCWD, "/usr/lib64/python3.10/site-packages/gi/__pycache__/importer.cpython-310.pyc", O_RDONLY|O_CLOEXEC) = 3 and the version module ... # rpm -q -f /usr/lib/python3.10/site-packages/isodumper/__pycache__/version.cpython-310.pyc isodumper-1.44-3.mga9 Is the file ... /usr/lib/python3.10/site-packages/isodumper/__pycache__/version.cpython-310.pyc present on that install?
Also, the strace shows it's using the following python packages ... lib64python3.10 \ lib64python3.10-stdlib \ python3-cairo \ python3-gnupg \ python3-gobject \ python3-gobject-base \ python3-manatools \ python3-psutil \ python3-pydbus \ python3-yui \ (Ignore the trailing backslashes).
(In reply to papoteur from comment #48) > The file to change is > /usr/lib/python3.10/site-packages/isodumper/isodumper.py Hi Stephen, I see in the traces that there is a file: /usr/bin/isodumper.py This is not the good place. See above.
$ locate isodumper.py /usr/lib/python3.8/site-packages/isodumper/isodumper.py Unfortunately I'm not using cauldron here so the python version could be different. But if you look for isodumper.py as i did above you should find the right place. If you copied new version into /usr/bin you have to remove it. comment 52 was menat to help in finding a solution quickly it isn't the normal way to proceed, sorry if it was confusing you.
@papoteur OK, got the new isodumper.py in the right place now. Unfortunately the behavior of the app did not change. @Dave yes, I have all those packages installed.
@Angelo Yes, I got that sorted.
And the error is always related to version?
Yes
hmm, something odd here, i don't recall we did anything different for version in installed version, but i maybe wrong Location on my cauldron: [anaselli@localhost isodumper (master)]$ locate isodumper.py /usr/lib/python3.10/site-packages/isodumper/isodumper.py [anaselli@localhost isodumper (master)]$ locate version.py | grep isodumper /usr/lib/python3.10/site-packages/isodumper/version.py [anaselli@localhost isodumper (master)]$ ls /usr/lib/python3.10/site-packages/isodumper/ isodumper.py __pycache__/ raw_write.py version.py [anaselli@localhost isodumper (master)]$ cat /usr/lib/python3.10/site-packages/isodumper/version.py RELEASE='1.44' can you post the error again? just to be sure that the right isodumper.py is called.
As said this is not the normal way to proceed, anyway: [anaselli@localhost isodumper (master)]$ su Password: [root@localhost isodumper]# cp lib/isodumper.py /usr/lib/python3.10/site-packages/isodumper/ cp: sovrascrivere '/usr/lib/python3.10/site-packages/isodumper/isodumper.py'? s [root@localhost isodumper]# exit [anaselli@localhost isodumper (master)]$ diff -up /usr/lib/python3.10/site-packages/isodumper/isodumper.py lib [anaselli@localhost isodumper (master)]$ isodumper Started
OK. Apparently I got it right this time. isodumper is working again. I started it from console thinking to give you the error message but it started and let me work with a drive. Thank you to everyone for all the help. Special thanks to papoteur. I'm still not sure why it stopped working. It stopped after the last update. But its good now.
Now I'm going to try the clean install of cauldron.
All the right packages/depends are installed but isodumper does not work on the clean install of cauldron. Same behavior as before. *heavy sigh*
Indeed the isodumper.py file is different from the installed one. I think papoteur needs to prepare an updated for isodumper
After a reboot isodumper works on the clean install of cauldron. It's working on both machines now.
Thanks for the update. Closing as invalid as it's not clear what caused the problem, and no changed were made to the packages to fix it. Please reopen if you can figure out how to reliably create the problem.
Resolution: (none) => INVALIDStatus: NEW => RESOLVED
Just a note: It stopped working on the new machine again (cauldron upgrade from mga8). Same behavior as before. Absolutely nothing has changed on the setup of this computer. All I have done is apply updates through the mga update applet. This is absolutely driving me crazy.
The previous version of isodumper worked fine on both machines...
I'm inclined to suspect a hardware problem such as a poorly connecting usb plug that sometimes works, but sometimes doesn't. Try re-seating the connector.
highly unlikely since the problem occurs on 2 different machines. On both computers it lets me choose the drive to work on but all the operations checkmarks are greyed out. I can't choose one.
CC: lewyssmith => (none)
@Dave I have also tried different USB Drives.
Did you try different sockets on the system? Strange that no one else can recreate the problem.
Yes. I have 4 USB sockets on one machine and 3 on the other. I tried them all. I can read/write all the thumb drives on both machines. No problems. It's just isodumper. Makes no sense, I know, but that's the way it is. If it was just one computer, I would blame it. But both computers? its got to be something else. Some package missing? I don't know. As far as I know everything is installed for isodumper to work. And it did work before on both machines.
Created attachment 13855 [details] urpmi command to install all packages used by isodumper The attached urpmi command was generated using a script that parses strace output. The script does a lookup of every file accessed by isodumper in my fully up-to-date m9 vb guest running plasma kde where isodumper is working, at least up to the point of selecting the device to write. Download the urpmicmd.txt and run it by entering ". path-to-download/urpmicmd.txt" in a root terminal. It includes the --test option so it will only download the packages, not install them. Once you're satisfied the list is ok, save the output of "ls -l /var/cache/rpms" to get a list of what it wants to install. Then install them with "urpmi /var/cache/rpms/*" and see if that fixes the problem. If it does, then it probably is a missing requires.
OK, thanks. I'm at work now. When I get home I'll give it a go.
Hello, I have packaged the latest file in 1.45. Thus, there is no more need to manually install any file.
Resolution: INVALID => FIXED
Once again, thank you to everyone. @papoteur It is all good now. Still not sure what the exact problem was, but thank you.
@Stephen, you are not alone; Bug 31978 - isodumper is not functional at all
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=31978
Well that's comforting, but not so much. It is working for me now.
You could try that update and see if it breaks anything ;)
Yes, I am going to. Following 31978 now. :)
isodumper 1.46 seems to have fixed the problem. Comment here: https://bugs.mageia.org/show_bug.cgi?id=31978