Arch Linux

I am having the same issue on Gnome 3 + Cinnamon

Hi, do you get any output if you run unetbootin on the commandline?

No, nothing.

Do you have sudo set up? Could you please open a new bug including information for how to reproduce on Gnome 3 + Cinnamon? Thanks.

I do not use sudo. The thing is, I tried git version from AUR and this one works flawlessly. There is really nothing else, just install it and run, no other stuff to reproduce. I can set up a new bug if you think it is needed, just there is no additional info that I can add to it.

Okay, thanks. I will look into this.

Let me know if you need any additional info.

Do you have either gksudo or kdebase-runtime installed? (optional dependencies)

I believe I have both.
I do have kdebase-runtime as I am running several KDE apps, like Krusader for example.
I have to check the gksudo, but I do get graphical popup asking for root password while running git version of unetbootin. So I believe that I do have it.
I am not at my home pc, will check it at home.

Thanks.

I have these installed:

extra/kdebase-runtime 4.8.2-1
extra/gksu 2.0.2-4
extra/libgksu 2.0.12-4
extra/python2-gksu2 2.25.3-12

Do you have /usr/bin/unetbootin.elf? If you run netbootin from the commandline, do you get absolutely positively no output? I'm so far unable to reproduce the problem.

Ok, when I run from cli as unpriviledged user, I get nothing in cli and popup with aforementioned message. (the git version asks for root password and starts properly after receiving it)

When I run it from cli as root, I get this (program starts, I see the main screen):

(gksudo:11003): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
GConf Error: No D-BUS daemon running


(gksudo:11003): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
GConf Error: No D-BUS daemon running


(gksudo:11003): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
GConf Error: No D-BUS daemon running


(process:11004): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

(process:11004): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

(process:11004): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
QGtkStyle was unable to detect the current GTK+ theme.
Qt: Session management error: None of the authentication protocols specified are supported


I do have unetbootin.elf file in that directory.

Does unetbootin-git from AUR works flawlessly on the same computer?
What happens if you add dbus to DAEMONS in /etc/rc.conf and/or start dbus first?
What happens if you mv /usr/bin/unetbootin.elf /usr/bin/unetbootin and start unetbootin from the menu again?
Thanks for testing.

Does unetbootin-git from AUR works flawlessly on the same computer? YES

My DBus is running.
DAEMONS=(hwclock syslog-ng dbus !network @cpufreq @hddtemp netfs @shorewall sensors sshd crond alsa networkmanager preload)


What happens if you mv /usr/bin/unetbootin.elf /usr/bin/unetbootin and start unetbootin from the menu again?
I have both files there already:

# ls /usr/bin/ | grep unetboo
unetbootin
unetbootin.elf

But, what happens if Exec in /usr/share/applications/unetbootin.desktop points to /usr/bin/unetbootin.elf instead? (Same effect as moving /usr/bin/unetbootin.elf to /usr/bin/unetbootin). Does that make it work for you?
Also, do you happen to know if kdesu or kdesudo is the binary that is executed? (By watching processes, adding echos to /usr/bin/unetbootin, running strace or by other means)

/usr/share/applications/unetbootin.desktop pointed to

/usr/bin/unetbootin

I have changed it to point to /usr/bin/unetbootin.elf and now if I start it from Cinnamon menu, it works and starts with asking for password.

Running it from CLI (as root or unpriviledged user) results in the same behavior as I described before in both cases.

Updated the package. Does unetbootin 568-4 work for you? (Will appear in [community] shortly).