No Autostart?

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.

1 Like

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.

2 Likes

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.

1 Like

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
1 Like

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.

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

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?

1 Like

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.

2 Likes

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?

1 Like

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.

2 Likes

But you do realise that one mind reader can’t read another mind readers mind don’t you?

I understand it’s rarely the answer. Unfortunately, I’m rare.
I have a tonne invested in it.

While it is a few templates, there are more guests.

I think I have about 20 templates at the moment that I use regularly.

And I have around 150 guests that I use.

I have custom scripts in Domain-0 to do many things from backup and restore to complete drive customisation.

I have backups. Due to the nature of having to reinstall to upgrade the version, I built my scripts over time since Qubes 1.

The number of times I have had to do re-installations since things went to Qubes 4 is just ridiculous.

Qubes 3 I did not have anywhere near these number of issues. I wanted to do something, it was easy to do.

As for using this SALT, I still don’t understand that really. I use the salt then I have to re-configure everything again…
But first, if I want to use the USB Qube I have to get a new keyboard and mouse to be able to accommodate the fact that it takes all the USB in, then I have to get the PCI card removed form the guest so that I can use that in Domain-0?

Ahh, no… I have plenty of scripts and customisations.

I created it the normal way, using the overloaded and bad GUI system that is called “Qubes Manager”.

As I said, I can’t do it on ANY guest any more.
Changing the template doesn’t do anything, it is just the autostart.

I hadn’t had to do anything with the autostart until now. Since the last reinstallation… how many weeks ago?

The only thing I did was add the “feature” into the XML for that one guest.
That is the only change I made to it manually.

If this is the first time this bug has happenned, then I’ll leave the system with this bug in place so that I can be told what to do and run to find out why it happenned and how to fix it befor eit starts to affect other functionality in the system for other people.

If you have any suggestions, I’m listenning.

As you know, it’s not a bug that is going to break anything at the moment.
I have my backup drive that has my guests in it.
1TB drive, 100 GB of templates, 850 GB of guests.
I think i’ve got a few double ups though, so its more like 750 GB of appvms.
Most of them are about 2GB in size.
But I do have Storage which is 100GB on it’s own. (not the one on my drive at the moment though, this one is small as I’m using the drive for most data instead of the guests image)

At the moment I only have 43 appvms on this machine that I run since I’m running a small, 480GB drive at the moment.
And since running a guest creates the COW file, and the OLD file…
I mean I keep deleting the OLD file and the COW file when I shut the machines down…
Set up to take place in the hook…
So I only have about 200 GB of appvms due to the fact that when I do things, the COW file just grows in size with my changes and tends to cause the drive to get full and crash everything and cause errors and make me loose work.
Need to have that removable and just be a direct write.
Would be a good option to be able to set for the guests.