Description of problem: [root@fedora ~]# unetbootin X Error: BadAccess (attempt to access private resource denied) 10 Extension: 130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach) Resource id: 0x12d X Error: BadShmSeg (invalid shared segment parameter) 128 Extension: 130 (MIT-SHM) Minor opcode: 5 (X_ShmCreatePixmap) Resource id: 0xaf X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x2000010 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x2000010 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x2000010 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x2000010 Version-Release number of selected component (if applicable): unetbootin-608-3.fc22.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I just checked with my system which is Fedora 22 64 bit and it works fine. Additionally I am on GNOME.
Are you running it as root? Can you copy paste how you run it? e.g. $ id $ sudo - # unetbootin
I've tried it on another computer and it's also broken there.
A workaround is to use: $ sudo -i # QT_X11_NO_MITSHM=1 unetbootin
I tried running it as root and it gives the error as you have mentioned. When trying to run as a normal user (which I did before my lase comment) it says that it needs to be run as root but the GUI loads fine. I didn't try to make any bootable disks though. And yes, your workaround works fine, it brings up the GUI without any issues.
Great, so we are agreed :) Since the only way to use unetbootin is with root rights, will you release an update?
I also experienced the same error with unetbootin on f22 [when run as root and that's the way its supposed to run I guess] and the work around works like a charm. Can anyone explain the issue a little bit deeper (Just to know rather than satisfied with the work around) and how the work around fixes the same? And when can we expect an updated package with the fix for the same in the local mirrors??
The workaround disables shared memory. I don't know why qt has a problem with shared memory though. Maybe the maintainer can help.
(In reply to James Patterson from comment #4) > A workaround is to use: > $ sudo -i > # QT_X11_NO_MITSHM=1 unetbootin same workaround helps with running bacula gui (bat) on F22
@Kalpa Welivitigoda: Shall I open a tracking but for Fedora 22 shared memory QT problems, and link this bug to it?
Sure, please proceed.
@Dušan: could you open a separate bug for the bacula gui issue, then give me the bug number?
(In reply to James Patterson from comment #12) > @Dušan: could you open a separate bug for the bacula gui issue, then give me > the bug number? #1236529
Would also like to chime in that I am having the same issue with unetbootin on Fedora 22.
*** Bug 1246917 has been marked as a duplicate of this bug. ***
Can we expect this bug to be fixed in fedora 23?
(In reply to Anoop C S from comment #16) > Can we expect this bug to be fixed in fedora 23? I'm running the beta right now, and I am still having this issue in F23. I also tested a build in the testing repos with no success either. This issue occurs on my laptop but not my desktop tower (desktop is still F22 however).
Unfortunately Red Hat just doesn't care. I'm so glad I reported this bug! At least people will find the workaround if they google the error message.
For my surprise, I can no longer see this issue on fedora 23. How come this got fixed without any notifications to this bug? Dependent bug also doesn't seem to be resolved. Can you guys verify the same?
WFM in 23 too. The changelog doesn't give any clues: https://github.com/unetbootin/unetbootin/commits/master Maybe something changed elsewhere in Fedora.
I can also confirm that it works for me now, on both the laptop and desktop I mentioned previously. My guess would be that something else changed in Fedora too, I hadn't noticed any updates to unetbootin that fixed this, even when I was testing new updates for unetbootin in Bodhi.
(In reply to Anoop C S from comment #19) > For my surprise, I can no longer see this issue on fedora 23. How come this > got fixed without any notifications to this bug? Dependent bug also doesn't > seem to be resolved. Can you guys verify the same? Maybe it was the fact that some configuration in Xorg got broken so that Xorg was running as root. With this fixed as of xorg-x11-server-Xorg-1.18.0-2.fc23.x86_64 unetbootin is again broken in Fedora 23. So, unetbootin fails when Xorg runs as ordinary user and works correctly when run as root.
(In reply to Alex Villacís Lasso from comment #22) > (In reply to Anoop C S from comment #19) > > For my surprise, I can no longer see this issue on fedora 23. How come this > > got fixed without any notifications to this bug? Dependent bug also doesn't > > seem to be resolved. Can you guys verify the same? > > Maybe it was the fact that some configuration in Xorg got broken so that > Xorg was running as root. With this fixed as of > xorg-x11-server-Xorg-1.18.0-2.fc23.x86_64 unetbootin is again broken in > Fedora 23. > Yes. You are right. With latest updates it broken again. > So, unetbootin fails when Xorg runs as ordinary user and works correctly > when run as root.
Still broken in unetbootin-613-1.fc23.x86_64
Just thought I would mention I got the above error with virtualbox. I went from fedora 21 to 23. I installed virtualbox as the root user and tried running it as the root user when the above error came up - I recall doing the same with fedora 21 without a problem. However, when I went to my admin account and ran virtualbox it came up fine! I guess I'm looking at the above error as a new "feature" that keeps me over-using my root account! But I thought this information might be helpful for anyone looking into what is going on with unetbootin.
Should mention I didn't do any reinstalling.
Affects 24 as well.
I'm getting this running in Wayland. root access for XWayland apps is a known thing. Fortunately QT_X11_NO_MITSHM=1 workaround succeeds.
Kalpa Welivitigoda, Are you still maintaining this package? Please at least comment something on fixing this issue.
Please respond if you are still maintaining this package.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora is adopting Wayland, which is more strict than Xorg regarding GUI programs running as root. Specifically, in Wayland you can't do it and the program is expected to request elevated privileges for only what it needs to do. This will require code changes for Unetbootin. I have filed the following: https://github.com/unetbootin/unetbootin/issues/94 This report should be closed since it's not Red Hat's problem.
> This report should be closed since it's not Red Hat's problem. lol! As if Red Hat cares anyway, this bug was opened for Fedora *22*! If they cared it would have been fixed a long time ago.
@Nate Graham, it does not matter whose "problem" it is. This is open source software and anyone, including distros, can fix it. @James Patterson, I don't think that trolling will solve anything.
@Iiro Laiho, true, but there's no need for duplicate bug reports once the problem has been pinpointed. I filed one for unetbootin's owner: https://github.com/unetbootin/unetbootin/issues/94 If someone from Red Hat wants to fix that, perfect! But it doesn't require having this report open. And I sort of doubt they'll want to given the existence of Fedora Media Writer, which does the same basic thing.