Upgrading from rc2 to release.

[jkitt]

Is this just a case of running a Dom0 update? Or would I have to manually install the stable release?

FYI: I'm still on 3.2.

[Yuraeitha]

On Tuesday, November 7, 2017 at 3:35:59 AM UTC, jkitt wrote:
> Is this just a case of running a Dom0 update? Or would I have to manually install the stable release?
>
> FYI: I'm still on 3.2.

Unlike for example Fedora and Debian, you can't change repository and update Qubes between release versions. You'll need to completely re-install Qubes dom0/hypervisor.

Albeit as I'm sure you already know, you can backup all your AppVM's or exotic templates to an external drive or similar, and just move them over. But do keep in mind that backup-restore is a bit broken as we speak in Qubes 4. I don't know if it has been fixed yet, but it appears like its a high priority to fix, and my guess is its probably soon fixed. I use Qubes 4, and my backup-restore succeed. But I may have gotten lucky, I've read others had a lot of issues.

There are also other issues in Qubes 4, of which you might want to wait until they are fixed. Though as far as I can tell, Qubes 4 is getting close to be stable, but it's just a feeling I have from using it. I can't tell you for sure.

btw keep in mind Qubes 4 requires you to backup and backup-restore through the command-line since there is no longer a graphic tool, and also the new admin python code makes it a hassle to use in dom0. It works much better through an AppVM. Therefore its best to backup and backup-restore through AppVM's now, not only for security, but also for transfer speeds and to avoid errors, which seem to happen if using python/adminVM-tools in dom0, and backup now uses admin tools by default. Well backup shouldn't be used in dom0 anyway. The admin tools in Qubes 4 is also likely the reason why the backup tool got messed up, since the admin tools is apparently not all fixed for bugs yet.

Also there are to my understanding multiple of reasons why Qubes dom0/hypervisor requires a full re-install. It's not only a lack of resources to implement this, considering resources is better spent on other things than making it upgrade-able. It's also a matter of security as well. Dom0 isn't perfect isolated yet, and perhaps it'll never be. But it won't stop Qubes from trying isolating it as much as possible, and no matter what, a small attack surface is always better than a big messy one that most other OS systems have. Also Qubes 4 offers better dom0 protection than what 3.2 provided. Albeit dom0 attacks should be zero-days and therefore few or no one know about them yet, or they are exotic or hard to pull off. Basically its not all that likely that you were attacked, but the risk is there. Also given how secure Qubes is known to be, and still how few people use Qubes, there is likely some hackers around the world seeking Qubes systems to attack, if nothing else but to learn or even have fun with it, bug also more serious reasons. Like I can't imagine organizations like NSA or the likes, won't stop to spend time to find zero-days in Qubes. This is just speculation though, but knowing them, they'd be stupid morons if they didn't mess around with Qubes, considering all the many many known things from A to Z which they try to exploit. Qubes just seems like an obvious goal for them to look into. But aside from resourceful organizations, there probably aren't many that skilled interested in attacking Qubes, but so too aren't many using Qubes yet. Also if you used insecure or infected USB in dom0, or if you installed packages with bad code in dom0, it'll cause issues too. It makes sense to re-install dom0, and it's probably another reason why the Qubes team won't spend time and resources on making it upgrade-able. A complete re-install goes hand in hand with Qubes's philosophy and goals, at least until perfect or near perfect dom0 isolation has been reached.

So too, does it make for anyone using Qubes, to from time to time, make a re-install. Just to be safe.

Also to my knowledge, major upgrades can cause system instabilities, or even introducing further/extra bugs or exploitable security holes. Especially with scarce resources to test it out. As far as I can tell as a non-programmer, it makes better sense to just release a re-install version, in order to avoid bugs and exploitable zero-days, which again aligns with the Qubes teams goals and philosophy.

So indeed, you need to re-install, for more than just one reason.

Also I'd wait until the backup and backup restored errors are cleared out, in case you should have to re-install Qubes 4 again before it gets fixed. I'm not sure of its current status though.

[Holger Levsen]

On Mon, Nov 06, 2017 at 07:35:58PM -0800, jkitt wrote:
> Is this just a case of running a Dom0 update? Or would I have to manually install the stable release?
> FYI: I'm still on 3.2.

you need to backup 3.2, install 4.0 and restore the backup. this is
described in the release notes.


--
cheers,
Holger

[Yuraeitha]

Do you happen to know if issues of the backup and backup-restore has been fixed though? It shouldn't just be so straight forward if he runs into unrecoverable or time consuming tasks to fix issues on something as important as backup data, especially since it's still technically a beta release.

[Holger Levsen]

On Tue, Nov 07, 2017 at 06:56:00AM -0800, Yuraeitha wrote:
> Do you happen to know if issues of the backup and backup-restore has been fixed though?

no, it will need brave testers like you to find out ;)

I'd suggest to backup 3.2, install 4.0 on a new/another disk and see if
restore works. If it doesnt, well you still have the old disk with 3.2
and you can continue to work. (just please file a bug in that case so
the bug becomes visible and can be fixed!)

as you say, it's still an release candidate...

personally I'm happy with 3.2 and don't plan to upgrade before 2 months
after the official 4.0 release or so. Sometimes I'm conservative.


--
cheers,
Holger

[Yuraeitha]

lmao, true, I might be challenging my fate a bit too much, one day falling into the pit of misery. But nontheless, no regreets for now (at least I did not loose anything), despite the hours used to fix various Qubes 4 RC-2 issues.

As for your suggestion Holger, I agree, but I just want to add one thing. If installing over UEFI/EFI instead of BIOS/Legacy-Boot, then be extra careful. At least in my anecdotal case, I've run into some efibootmgr issues with Qubes 4 release, when I tried to swap out various Qubes installs on my UEFI system.

For some reason or another, efibootmgr failed when I tried to fix a EFI boot setting in the UEFI. Since installing a new Qubes replaces the old in the UEFI settings, it might still be a risk, despite all the data still being available. It used to always work in previous times, like with Qubes 3.2. Something seems different here with Qubes 4.

So I'd like to add to only try this on a machine where Qubes 3.2. is already installed with BIOS/Legacy, and perhaps also pull out or disable the drive with Qubes 3.2 on it, just to be 100% sure nothing goes wrong.

or yeah, alternatively rely on a Qubes backup to fallback on Qubes 3.2, despite the extra work. But it never hurts to be extra safe.