Qubes 3.2 fedora version in Dom0 question?

[somala...@gmail.com]

Hi!
I haven't been using qubes (or computers, for that matter) for a wee bit of time and now that I'm back I see fedora 24 going the way of dinosaurs.

Also, on github, I noticed https://github.com/QubesOS/qubes-issues/issues/2574

Do I understand correctly that Dom0 is Fedora 25 now?

Is that only for Qubes > 4, or will R 3.2 get a Fedora 25 dom0 too (I'd like to stick with R3.2 for the time being)

If Fedora R 3.2 get/got a Fedora 25 in Dom0, what precautions should I observe when updating Dom0 (besides BACKUP EVERY SINGLE THING)

My last Qubes update was around February-March 2017 or somesuch.

[Alex]

Only dom0 in Qubes R4 will be F25; as of now I can't find the e-mail
thread, but I remember that the reasoning was that it's better to keep
the stable release as stable (i.e. not embracing potentially troublesome
upgrade paths), and focus the cutting-edge integration on new releases only.

It makes sense to me: dom0 has the only ungrateful task of supporting
hardware in R3.2, and the main reason for upgrade is VGA hardware
drivers. There are no security implications for remote attack vectors in
the particular version of software in dom0, since it can't directly
access the network and should not be remotely accessible.

In Qubes 4 and later, the roadmap states that VGA support will be
demanded to an appvm, that will be upgraded like any other appVM in the
system - best of both world: isolated UI and updated drivers.

In the unlikely case that R3.2 receives a dom0 upgrade it will likely
still be a fedora distro, just an upgraded version, so the upgrade path
will not be too extravagant. Beside backing up everything (please use
the included backup tool: it will be the only supported way to move to a
newer version or restore the same version it was created on), there
isn't really much to do. If you customized the system beyond your home
directory you should take care of these customizations, but you're
mainly on your own in that case...

--
Alex

[somala...@gmail.com]

On Tuesday, September 19, 2017 at 10:58:35 AM UTC+3, Alex wrote:

Thanks Alex!

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Take a look at this page:

https://www.qubes-os.org/doc/supported-versions/#dom0

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZwdruAAoJENtN07w5UDAwkXsQAKkXhgNg/VGe4oyb+qmjp04N
m1ALP0d58Ibcg2hXUqcpidVptZgGZhz4cJUIvSKylMjnSdHf8NRCoKOsLPOAvUmR
9orvib2NLmgDsd2RnCME+VB5UiFddkYEqSBijiNNofQqFw0QDmJNFX1rACYnGo2E
6x/kMheVrZbnxn7wuEEiwblyl3DnjXINlvPkNsyq15Lug36aJa9IZTDIrDDZM7Gs
VybQJ1EJTDjalnZr9L4+SkJeduU0fUCVOLnXUiAwjMGXEqsRb+hNdLaQPngx5vVH
Z8QUFAXX75iKU3UZDHzjkFLqWwGwqt6/S6VTgg//uNqSyJ/pj9TX6YitXf0+Yvh/
VezZZ6QPmUnGwuaKyvPPkspCRaelQHUB/kyIXGWQc/4E09C7rSW2hWnEMJi+K1wU
9KJlHKbWDFcGmKhkZjEjvX2G6N0CqqeZALuzo5oINDmRf7s87h1aD4Z5N1+WEK8u
UjsYBe9I6i3CDuRB1auI1QuaIniRI6GlYnMTMH58JsNtLxkc71JFsW4fgHszzVRv
/k1Ll7IhtQmLAnmpR8YVH8y9ajfTfZAM5jhRp8THQV1pG7APLo6YxRsSrwiG4ETl
aHW9UZ2if9b8vxRjKkxXUYByWCxdDiXDAa+Llxq8duhCxif6vgMihDJ/VAxuWPuD
V3rHIFW+LEn0MPjOv8KD
=rkC8
-----END PGP SIGNATURE-----

[none]

On 09/18/2017 09:58 PM, Alex wrote:

So, do a qvm-backup on all AppVMs, (though, this won't allow upgrade to
4.0?)
And, also do the "paranoid" backup ?
something like this :
[user@dom0 ~]$ qvm-backup-restore --paranoid-mode --ignore-missing -d
sys-usb /media/disk/backup.bin

I personally don't even have a sys-usb VM , is there some less terse
explanation on how to prep and/or do the "paranoid" backup?

I had stopped looking at it, as it seemed only for those whom suspect a
"compromised" system?

[Alex]

On 09/20/2017 06:18 AM, none wrote:>
> So, do a qvm-backup on all AppVMs, (though, this won't allow upgrade
> to 4.0?) And, also do the "paranoid" backup ? something like this :
> [user@dom0 ~]$ qvm-backup-restore --paranoid-mode --ignore-missing
> -d sys-usb /media/disk/backup.bin
>
> I personally don't even have a sys-usb VM , is there some less
> terse explanation on how to prep and/or do the "paranoid"
> backup?
>
> I had stopped looking at it, as it seemed only for those whom suspect
> a "compromised" system?

Yes, paranoid backup mode has been introduced only to "surgically
restore" only non-critical parts of a backup (i.e. dom0 home, pci
devices, menu entries - see man for more info). It can be useful in
cases of a suspected compromised backup.

So there is no difference between a backup to upgrade dom0 and a backup
to switch to 4.0; just do a full backup.

If you customize templates, like I do, you'll probably have a hard time
restoring to a newer major release because of updated qubes tools,
especially so if you have a sys-net / sys-firewall that are based on the
customized templates: once restored in the newer major release, if the
machines don't boot, there's a lot of work to do to have Internet again
to update the tools ;)

--
Alex

[Alex]

On 09/20/2017 05:05 AM, Andrew David Wong wrote:
>
> Take a look at this page:
>
> https://www.qubes-os.org/doc/supported-versions/#dom0

I know I'm boldly hijacking the thread, but...

Wouldn't it be better to soften a little the wording about support and
update timings in the linked page?

We've been having quite a few people that come to the ML genuinely
worried about the six-months (mentioned at the very beginning of the
page) expiring, or the Fedora distros reaching the exact end-of-life date.

Just by looking at the first table one can actually deduce that older
versions have been supported for way longer than 6 months, and that the
half-year period is more of a wish than an actual deadline.

Since the cut is not black-or-white, and english may not be the first
language for a lot of users, not everybody may understand at a glance
that the Qubes release schedule is not set in stone but rather adjusted
to fit the usual technological and organizational challenges that
complicate product development.

Just my useless 2 cents.

--
Alex

[Unman]

I'm not sure what you mean here - when I look at the top table on that
page it DOES show that older versions expire 6 months after the release
of the next version.
I think the cut is clear, and generally has been followed.
Agreed, the release schedule is flexible, but termination of support
generally isn't.
Of course this doesn't mean that people don't seek help for older
versions, and get it, but the devs wont provide updates etc.