I’m trying to set the autostart on a guest, and no matter what I do it will not allow it, even using root to set the property. I even manually set it in the XML, and that didn’t change anything either.
“ERROR: Basic tab:
Failed to access ‘autostart’ property”
I have it there, the variable is there in the XML, but it can’t access it?
Why am I not able to set things up properly?
Hope someone can help, thanks.
You didn’t say exactly how you were trying to change its value. I just tested on my system which worked, and the command is:
qvm-prefs --set VMNAME autostart 1
or
qvm-prefs --set VMNAME autostart True
to verify:
qvm-prefs --get VMNAME autostart
This should not be done as root.
I have tried manually in the XML, I have tried through the GUI, I have tried through qvm-prefs.
I tried as the end user, and it said it couldn’t access it, so I tried as root, and that couldn’t access it either. So I was providing that information so that people knew that it wasn’t just a permission issue.
As I say, error is the following…
“ERROR: Basic tab:
Failed to access ‘autostart’ property”
Using CLI, the error is only slightly different.
"qvm-prefs: error: Failed to access ‘autostart’ property ”
It is only the source that is different for the error.
But even having it set in the XML set so that it should start at boot, it doesn’t.
What happens with the command below?
Does this return an error as well? It would also need to access the same property.
I assume the permissions here are correct?
[name@dom0 ~]$ ls -al /var/run/qubesd.sock
srwxrwx--- 1 root qubes 0 Feb 20 12:19 /var/run/qubesd.sock
Do you have a qubesd server running in that VM?
[name@dom0 ~]$ ps -ef | grep qubesd
root 2022 1 0 12:19 ? 00:00:00 /usr/sbin/qubesdb-daemon 0 dom0
root 2029 1 0 12:19 ? 00:00:35 /usr/bin/python3 /usr/bin/qubesd
name 2912 1 0 12:19 ? 00:00:00 /usr/sbin/qubesdb-daemon 1 sys-net
name 2951 1 0 12:19 ? 00:00:00 /usr/sbin/qubesdb-daemon 3 sys-firewall
name 3021 1 0 12:19 ? 00:00:00 /usr/sbin/qubesdb-daemon 4 sys-usb
...
name 4445 1 0 13:30 ? 00:00:00 /usr/sbin/qubesdb-daemon 8 MyVM
name 10604 3492 0 17:07 pts/5 00:00:00 grep --color=auto qubesd
No, getting works fine, and it says False, even though in the XML it is set to True.
Permissions are fine. I can set other guests. I can do it to some others, just not that one.
Perhaps the permissions or group of the file is wrong. I have seen many times that I could not even start a vm only because a log file had the wrong ownership and permissions. It sounds suspicious that you can read but not modify it. Check what the permissions are on the vm’s that work properly.
Exactly right, can’t modify that property.
I can modify other things, just not that property, even manually setting it makes no difference.
I’ll put it this way, it’s a storage virtual, literally just storage for files and things I send to the guests when I need to install things in disposables or anything else.
I’m just transferring from one guest to another, I don’t need to store it, but things like ISOs and all, I have in the storage and on those drives. So it’s just a case of needing the drives to be attached to that guest.
And I want to have it start at boot so that the device is attached at boot, and the drives aren’t in use by Domain-0 since they are jsut storage drives.
It would be extremely helpful if you could say what sort of qube this is,
and exactly how you created it. What template are you using? What
version of Qubes?
Does this affect all new qubes using one of the default templates?
If you recreate this storage qube using the same procedure can you set
autostart then?
As a general point, I would suggest not messing with the xml unless you
know exactly what you are doing - you are far more likely to break things.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
In regards to modifying the XML, the issue was hapenning before the changing of the XML, just so you know.
It is just a qube.
I can’t set the autostart of anything at the moment now. I can’t even turn off the autostart on the main network guest.
I think this is all to do with the attempts to create the USB guest. I think the attempts for that may have broken something possibly?
It’s difficult to help you when you give no information when asked.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
What information are you wanting that I didn’t provide?
I’m using the following templates…
d11-net
d11-v
d11-s
f37-adm
d12-xfce
w17-gw
w17-ws
w16-gw
w16-ws
d12-v-dvm
d11-usb
f38-u
d12-v-laz
w7-seamless
w10-seamless
w11-seamless
Qubes is whatever the current is.
What other information do you need?
There’s a simple solution to your problem
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Would love to know…
Is it to do another reinstall?
Oh, I though we were testing each others psychic abilities.
This is very rarely the answer. But if you have nothing invested in the
install and it’s a vanilla set up, then it may be the best thing to do.
Given the number of templates you are working with, I would guess
that you spent some time getting things “right” until you hit the
autostart issue.
If you dont want to back up all the templates and your qubes, or you
dont have a simple way to restore the setup with salt, then you could
consider trying to solve the issue. In this case, provide more
information about the current situation.
Is this a clean install of 4.4?
Are you able to set autostart for any qubes now?
How exactly did you create the qube where you first reported the issue?
What template was in use? Did you change the template and test?
If the problem has spread to other qubes, what exactly did you do to the
system before discovering this?
What edits did you make to the xml file?
Did you keep a backup of the xml file before editing it? If so, what
does a diff between the two show?
It may be that you have found a bug, and are the first reporter. In
which case this is valuable work. It’s up to you where you go from here.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.