Description of problem: Isodumper fails to launch in both M7.1 and M8 Either from a desktop icon or from a terminal. When lauching in terminal the following errors are reported: [root@localhost wilcal]# isodumper Traceback (most recent call last): File "/usr/bin/isodumper", line 24, in <module> app = isodumper.IsoDumper() File "/usr/lib/python3.7/site-packages/isodumper/isodumper.py", line 582, in __init__ level=level) File "/usr/lib64/python3.7/logging/__init__.py", line 1895, in basicConfig h = FileHandler(filename, mode) File "/usr/lib64/python3.7/logging/__init__.py", line 1087, in __init__ StreamHandler.__init__(self, self._open()) File "/usr/lib64/python3.7/logging/__init__.py", line 1116, in _open return open(self.baseFilename, self.mode, encoding=self.encoding) FileNotFoundError: [Errno 2] No such file or directory: '/root/.isodumper/isodumper2.log'
It's working in my m7.1 install. What's the output of the following commands as root ... # ls -ld /root/.isodumper/ # ls -l /root/.isodumper/ # systemctl -a status magiback.service
CC: (none) => davidwhodgins
(In reply to Dave Hodgins from comment #1) I used a Vbox M8 Plasma Client that did not have isodumper installed I installed Isodumber from the MCC and got the same errors when launched from a terminal. Per your request: [root@localhost wilcal]# ls -ld /root/.isodumper/ ls: cannot access '/root/.isodumper/': No such file or directory [root@localhost wilcal]# ls -l /root/.isodumper/ ls: cannot access '/root/.isodumper/': No such file or directory [root@localhost wilcal]# systemctl -a status magiback.service ● magiback.service - Magiback backend Loaded: loaded (/usr/lib/systemd/system/magiback.service; disabled; vendor preset: disabled) Active: inactive (dead)
Recreated and figured out a work around that works on the system I was using. As root run mkdir "/root/.isodumper". No idea how that was previously working and then stopped. Passed qa testing as everyone testing had previously used isodumper when it did create the directory.
Assignee: bugsquad => yves.brungard_mageia
I'm still having problems here I do have a working system and it does not have a /root/.isodumper directory. Rats, this is an important application
Thanks for the report. I will correct that. Indeed, the directory could to be not present. However, isodumper is intended to be launched as user. There is no need to launch it as root.
(In reply to papoteur from comment #5) > Thanks for the report. > I will correct that. Thanks papoteur. This appears to effect both M7.1 and M8. And we are right in the middle of testing the new M8 Beta 2 ISOs So this is an important part of the process.
(In reply to Dave Hodgins from comment #3) > Recreated and figured out a work around that works on the system I was using. > > As root run mkdir "/root/.isodumper". This is the workaround when launching isodumper as root (what I don't recommend). Or the same in user space: mkdir ~/.isodumper
Ping! We are about to announce Mageia 8 beta 2 within a day. It should be easy for mageians to use the tool we advise to try it.
Severity: normal => majorPriority: Normal => HighCC: (none) => fri
I have pushed 1.30 on git. Now it checks for signatures detached or not. And display a warning if not correct instead of a success.
OK: Launching: It now create ~/.isodumper
Whiteboard: (none) => MGA7TOO, MGA7-64-OK
isodumper 1.33 is now in testing. There a new feature : it detects adding and removing of sticks.
Assignee: yves.brungard_mageia => qa-bugsStatus: NEW => ASSIGNED
Just as I was about to validate it. Oh, well... Since there is no package list, I used the wild card feature of QA Repo to get the three isodumper packages. isodumpre and isodumper-qt were updated. No installation issues. Ran it as root, tried plugging in and out a usb stick, but nothing else. Removal of the stick was detected, but "refresh" in the popup had to be used to know a device had been inserted. Ran it as a user, and this time wrote an iso onto the stick, after which I pulled the stick out when the popup said it was OK. The action was again detected. Looks like it's still OK here. Validating. It still needs an advisory and a package list.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
Hold the phone! Tried out isodumper with gtk and it failed. Begging your pardon TJ but can we hang on to it a little while longer? Version 1.32 was working with gtk but not the update. Continuous stream of this message: return _yui.YDialog_waitForEvent(self, timeout_millisec) /usr/lib64/python3.7/site-packages/yui.py:1943: Warning: Source ID 204 was not found when attempting to remove it return _yui.YDialog_waitForEvent(self, timeout_millisec) Sorry about that.
CC: (none) => tarazed25Keywords: validated_update => (none)Whiteboard: MGA7TOO, MGA7-64-OK => MGA7TOO
Nor can I get isodumper-qt to launch - same error messages. And Magiback is dead. Restarted it successfully but no improvement. So maybe my system lacks something that TJ's has.
When I installed isodumper-gui the application launched but still filled the terminal with messages, past 2000 already, same warnings as before. As TJ said, it works fine in all other respects. Reinstating the OK. Sorry for the noise.
Keywords: (none) => validated_updateWhiteboard: MGA7TOO => MGA7TOO, MGA7-64-OK
CC: (none) => ouaurelienSource RPM: (none) => isodumper-1.28-1.mga7.src.rpmWhiteboard: MGA7TOO, MGA7-64-OK => MGA7-64-OKVersion: Cauldron => 7
Yes, I see the collection of warnings. They are not triggered in cauldron. I leave that, because isodumper isn't normally launched from console.
CC: (none) => yves.brungard_mageia
Advisory ======================== This release fixes a crash when ~/.isodumper directory didn't exist (mga#27786). It fixes also that Isodumper log and window warn user checksum error, but dialogue say success (mga#27667). It now verifies signatures also when they are detached (mga#27667) It displays warning instead of success when sums or signatures doesn't match (mga#27667) It adds also detection of adding and removing devices. ========================
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2021-0013.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED