so, shouldn’t this:
say something about changing I don’t know; the template and dom0 to “testing” ? ;
I am seeing no : sudo qubes-dom0-update -y qubes-dist-upgrade
I presume it is only in -testing, after engaging testing 1st , the doing dom0 update?
in general how long would this 4.1 likely be till it is “stable” version ?
To answer your second question, the scheduled date to determine whether 4.1.0-rc2 should become the current stable release is 2021-11-29. You can consider that the scheduled release date.
1 Like
RC1 = Release Candidate 1.
In other words:
Not commercially-supported - but feedback is very very much appreciated
Clodius
October 16, 2021, 10:34pm
4
guess I’d need to know, how to get sudo qubes-dom0-update -y qubes-dist-upgrade ?
maybe its obvious, but be nice to hear it ; it will be upgrade from what I think I have being 4.0.4, never quite sure of that either
4.1b was sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-dist-upgrade
so from this which qubes would you say I am “on”?
dnf list |grep qubes
qubes-anaconda-addon.noarch 4.0.11-1.fc25 @qubes-dom0-cached
qubes-artwork.noarch 4.0.1-2.fc25 @anaconda
qubes-core-admin-addon-whonix.noarch 4.0.2-1.fc25 @anaconda
qubes-core-admin-client.noarch 4.0.33-1.fc25 @qubes-dom0-cached
qubes-core-dom0.x86_64 4.0.58-1.fc25 @qubes-dom0-cached
qubes-core-dom0-linux.x86_64 4.0.30-1.fc25 @qubes-dom0-cached
qubes-core-dom0-linux-kernel-install.x86_64
4.0.30-1.fc25 @qubes-dom0-cached
qubes-db.x86_64 4.0.16-1.fc25 @qubes-dom0-cached
qubes-db-dom0.x86_64 4.0.16-1.fc25 @qubes-dom0-cached
qubes-db-libs.x86_64 4.0.16-1.fc25 @qubes-dom0-cached
qubes-desktop-linux-common.noarch 4.0.22-1.fc25 @qubes-dom0-cached
qubes-desktop-linux-manager.noarch 4.0.25-1.fc25 @qubes-dom0-cached
qubes-gpg-split-dom0.x86_64 2.0.53-1.fc25 @qubes-dom0-cached
qubes-gui-dom0.x86_64 4.0.14-1.fc25 @qubes-dom0-cached
qubes-img-converter-dom0.x86_64 1.2.10-1.fc25 @qubes-dom0-cached
qubes-input-proxy.x86_64 1.0.24-1.fc25 @qubes-dom0-cached
qubes-input-proxy-receiver.x86_64 1.0.24-1.fc25 @qubes-dom0-cached
qubes-libvchan-xen.x86_64 4.0.9-1.fc25 @qubes-dom0-cached
qubes-manager.noarch 4.0.45-1.fc25 @qubes-dom0-cached
qubes-menus.noarch 4.0.22-1.fc25 @qubes-dom0-cached
qubes-mgmt-salt.noarch 4.0.26-1.fc25 @qubes-dom0-cached
qubes-mgmt-salt-admin-tools.noarch 4.0.26-1.fc25 @qubes-dom0-cached
qubes-mgmt-salt-base.noarch 4.0.4-1.fc25 @qubes-dom0-cached
qubes-mgmt-salt-base-config.noarch 4.0.2-1.fc25 @qubes-dom0-cached
qubes-mgmt-salt-base-overrides.noarch 4.0.2-1.fc25 @anaconda
qubes-mgmt-salt-base-overrides-libs.noarch
qubes-mgmt-salt-base-topd.noarch 4.0.2-1.fc25 @qubes-dom0-cached
qubes-mgmt-salt-config.noarch 4.0.26-1.fc25 @qubes-dom0-cached
qubes-mgmt-salt-dom0.noarch 4.0.26-1.fc25 @qubes-dom0-cached
qubes-mgmt-salt-dom0-qvm.noarch 4.0.10-1.fc25 @qubes-dom0-cached
qubes-mgmt-salt-dom0-update.noarch 4.0.10-1.fc25 @qubes-dom0-cached
qubes-mgmt-salt-dom0-virtual-machines.noarch
4.0.17-1.fc25 @qubes-dom0-cached
qubes-pdf-converter-dom0.x86_64 2.1.12-1.fc25 @qubes-dom0-cached
qubes-release.noarch 4.0-10 @qubes-dom0-cached
qubes-release-notes.noarch 4.0-10 @qubes-dom0-cached
qubes-rpm-oxide.x86_64 0.2.2-1.fc25 @qubes-dom0-cached
qubes-template-debian-10.noarch 4.0.1-201906201854 @anaconda
qubes-u2f-dom0.noarch 1.2.9-1.fc25 @qubes-dom0-cached
qubes-usb-proxy-dom0.noarch 1.1.1-1.fc25 @qubes-dom0-cached
qubes-utils.x86_64 4.0.34-1.fc25 @qubes-dom0-cached
qubes-utils-libs.x86_64 4.0.34-1.fc25 @qubes-dom0-cached
.fc25
in the names of packages suggest Qubes 4.0.
so not 4.0.4 ?
if not what do I need to do ?
sudo qubes-dist-upgrade --all
seems my sys-net-disp, is causing it to fail, trending towards a broken system ; though its more my test machine thinkpad T530 legacy install
step 1 for fedora-33, is saying failed to return clean data so ERROR, otherwise OK
…so it exits and doesn’t go to step 2
wondering if I’m going to be able to do step 5 setup efi-grub, since I’ve 2 SSDs one with qubes, one with debian ; not using grub to multiboot?
https://www.qubes-os.org/doc/upgrade/4.1/
well after removing templates that failed, and retrying finally sys-net won’t start qrexec-daemon startup failed, so looks like will have to burn a USB installer and reinstall, sigh
Clodius
October 19, 2021, 5:51pm
10
not a surprise, reinstall is faster, on the T530, I did choose to make network use USB or so, so now I’ve no sys-usb, so is sys-net what controls USB devices then,
nice to see the sys-net-disp is a config creation choice, can see it as a -dvm though in qvm-pci just says sys-net
not yet a fan of the 3d qube icons, find it visually confusing, maybe I’ll adapt,
thanks qubes team