The only thing out of the ordinary is I have an outdated is the
DisposableVM Template.
On Monday, October 4, 2021 at 3:08:06 PM UTC-5 Rob Townley wrote:
> I certainly may not have run the qubesctl command correctly, but the gui
> based update utility also fails. I had changed the d
I certainly may not have run the qubesctl command correctly, but the gui
based update utility also fails. I had changed the default disposable
template to fedora-34-qubes-core. Does it need to be a centos-8 template
to work?
[root@dom0 ~]# qubesctl --skip-dom0 --targets=centos-8 --show-output
--
~]#
On Tuesday, March 2, 2021 at 7:58:43 PM UTC-6 unman wrote:
> On Tue, Mar 02, 2021 at 03:24:31PM -0600, Rob Townley wrote:
> > I really need this qube to run for over an hour without the hypervisor
> > killing it. Short of buying a much faster brand new machine, how does one
> >
awokd, will try qvm-features --verbose vmName qrexec 0
On Tuesday, March 2, 2021 at 3:43:50 AM UTC-6 awokd wrote:
> Rob Townley:
> > qvm-prefs vmName qrexec_timeout 3600
> > does not return an error message. When read, 3600 is returned.
> > However, the VM is forcibly sto
I really need this qube to run for over an hour without the hypervisor
killing it. Short of buying a much faster brand new machine, how does one
do that?
On Mon, Mar 1, 2021 at 12:19 AM Rob Townley wrote:
> qvm-prefs vmName qrexec_timeout 3600
> does not return an error message. Whe
qvm-prefs vmName qrexec_timeout 3600
does not return an error message. When read, 3600 is returned.
However, the VM is forcibly stopped after 15 minutes.
1800 works
2700 works
3600 is not honored
How can i get by this so this one VM can do finish its upgrade before
forcibly rebooted?
--
You r
Kernel version numbers seem off, way off in some VMs and templates.
Mainly, that /boot/initramfs does not does not match uname -r.
uname -r vs ls /boot/initramfs* vs cat /proc/version vs cat /etc/os-release
OK dom0: 5.4.88-1.qubes, 5.4.88-1.qubes, 5.4.88-1.qubes, 4.0
BAD vm: 5.4.88-1.qubes, 5
