Long-time Beta Users, do you wipe or upgrade?
Eric Duncan
To all of you long-term beta users of 3.x and now 4.x...
1a) Are upgrades simple to RTM versions of Qubes?
Or 1b) Do you wipe and format each time a beta or RC comes out?
I'm debating install Qubes 4.0 beta/rc, and going for the upgrade.
Alternatively... Is there a way to use some type of "Testing" repo for Qubes? Something like rolling updates of Debian Testing does?
I was perfectly happy with Debian Testing on a previous build, until I moved to Arch which was a bit more stable with its rolling releases.
I wouldn't mind installing a "rolling release" of Qubes under a Testing repo, if there is one.
Thanks!
Noor Christensen
> Alternatively... Is there a way to use some type of "Testing" repo for
> Qubes? Something like rolling updates of Debian Testing does?
>
> I was perfectly happy with Debian Testing on a previous build, until I
> moved to Arch which was a bit more stable with its rolling releases.
>
> I wouldn't mind installing a "rolling release" of Qubes under a
> Testing repo, if there is one.
qubes-dom0-current-testing testing packages that will eventually land in the stable (current) repository
qubes-dom0-security-testing a subset of qubes-dom0-current-testing that contains packages that qualify as security fixes
qubes-dom0-unstable packages that are not intended to land in the stable (qubes-dom0-current) repository; mostly experimental debugging packages
See the "Testing repositories" section of the official docs:
https://www.qubes-os.org/doc/software-update-dom0/#how-to-update-software-in-dom0
-- noor
|_|O|_|
|_|_|O| Noor Christensen
|O|O|O| no...@fripost.org ~ 0x401DA1E0
Eric Duncan
Thanks! Yep, I found that wiki after I posted (oops).
One question: would these repos be considered "Rolling" releases? I mean, they aren't cut as releases, but would always have the "Tip" of packages, fixes and updates?
qubes-dom0-current-testing testing packages that will eventually land in the stable (current) repository
qubes-dom0-security-testing a subset of qubes-dom0-current-testing that contains packages that qualify as security fixes
I do not plan on running unstable. :)
Thanks!
cooloutac
upgrading to the latest release from previous version didn't go well for me. There are instructions on how to do so and maybe I did something wrong. But I had to reinstall fresh and restore backups which went smooth.
Most Qubes users are paranoids and probably wipe their drive occasionally anyways.
I wouldn't consider Qubes a rolling release Its one big huge version update. Next Qubes version I think will be 4.0.
Eric Duncan
>
> upgrading to the latest release from previous version didn't go well for me. There are instructions on how to do so and maybe I did something wrong. But I had to reinstall fresh and restore backups which went smooth.
>
> Most Qubes users are paranoids and probably wipe their drive occasionally anyways.
>
> I wouldn't consider Qubes a rolling release Its one big huge version update. Next Qubes version I think will be 4.0.
Yeah, I don't plan to upgrade. This will be another clean install.
That's what I am trying to get.. 4.0, or the latest "tip" of Qubes that everyone is using for development and submitting updated packages for.
Would I get "4.0" from just a fresh install, and then enabling the Testing/SecurityTesting repos and upgrading?
Or, is Qubes not setup to roll the latest from a tip? But instead, there are separate branches for each release (3.1, 3.2, 4.0, etc) and a "Testing" branch for each one of them?
That's kind of how Kali used to do it (I think) which annoyed some of us that wanted to contribute, but our contributions got lost in the older versions or wasn't merged to the latest branches, etc. Then Kali switched to Rolling releases, with a single Tip/Testing branch - and snapshots (with branches) for official releases.
Ps: Heh, paranoids - wiping often. I did that a lot w/Windows, mostly cause of instability after 6mos.
Franz
--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0b19516a-f1cb-490c-bbdf-e369ea769355%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
cooloutac
> On Mon, Jun 26, 2017 at 3:21 PM, Eric Duncan <edunc...@gmail.com> wrote:
> On Monday, June 26, 2017 at 1:27:19 PM UTC-4, cooloutac wrote:
>
> >
>
> > upgrading to the latest release from previous version didn't go well for me. There are instructions on how to do so and maybe I did something wrong. But I had to reinstall fresh and restore backups which went smooth.
>
> >
>
> > Most Qubes users are paranoids and probably wipe their drive occasionally anyways.
>
> >
>
> > I wouldn't consider Qubes a rolling release Its one big huge version update. Next Qubes version I think will be 4.0.
>
>
>
> Yeah, I don't plan to upgrade. This will be another clean install.
>
>
>
> That's what I am trying to get.. 4.0, or the latest "tip" of Qubes that everyone is using for development and submitting updated packages for.
>
>
>
> Would I get "4.0" from just a fresh install, and then enabling the Testing/SecurityTesting repos and upgrading?
>
>
>
> Or, is Qubes not setup to roll the latest from a tip? But instead, there are separate branches for each release (3.1, 3.2, 4.0, etc) and a "Testing" branch for each one of them?
>
>
>
> That's kind of how Kali used to do it (I think) which annoyed some of us that wanted to contribute, but our contributions got lost in the older versions or wasn't merged to the latest branches, etc. Then Kali switched to Rolling releases, with a single Tip/Testing branch - and snapshots (with branches) for official releases.
>
>
>
>
>
>
>
> Ps: Heh, paranoids - wiping often. I did that a lot w/Windows, mostly cause of instability after 6mos.
>
>
>
>
>
> Rolling releases work well with more mature systems like Arch. But each new major version of Qubes included important architectural changes. So what could be passed easily to the next was only the backup of applVMs.
>
>
> Also these major changes were mostly motivated by security reasons. So why keep something that was generated in a less secure environment?
>
> Best
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
>
> To post to this group, send email to qubes...@googlegroups.com.
>
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0b19516a-f1cb-490c-bbdf-e369ea769355%40googlegroups.com.
>
>
>
> For more options, visit https://groups.google.com/d/optout.
I guess just use testing or unstable repos if you want to have the latest for now. I have no idea where to get the beta for 4.0 if thats what you're asking.
cooloutac
if you worried about having the latest security releases I use security testing repo.
Eric Duncan
> I guess just use testing or unstable repos if you want to have the latest for now. I have no idea where to get the beta for 4.0 if thats what you're asking.
Yes, that's partly what I am asking. I read where 4.0 is going to have a bit more restrictive requirements and while I have tested most of my hardware, I still want to use the latest 4.0 "beta" for now.
Yeah, where do you get 4.0 beta? I see the source seems to point to version 4.0.0:
I also see "branches" of each release, such as Release 3.2:
https://github.com/QubesOS/qubes-core-admin/tree/release3.2
Are we supposed to pull the 4 main repos and build 4.0 ourselves? It doesn't look that difficult.
Overall, I am wondering if there basically is a way to enable a "repo" and just update to mostly what the devs are pushing to.
But yeah, if there are separate branches... I guess I can just pick a version and stick to it.
I replace Xfce with i3wm anyways... Which removes the vast majority of the GUI work by the team. All that is left is basically the hypervisor and inner-VM communications (and Display VM - which has some issues with i3wm, such as that I haven't found a way to fullscreen something yet).
If there has been significant infrastructure changes to those, I see the point of repaving and restoring. Then again, Arch is more than happy to break your current installation with its rolling release because of a change (e.g. the move to "systemd" one sunny day that shocked everyone).
Jean-Philippe Ouellet
state. I am nearly certain there are yet-unknown corner cases. This is
even true within the same Qubes release [1].
By upgrading R3.1 -> R3.2 I've ended up with a somehow messed up pam
config preventing any graphical logins, an application menu with stale
and broken entries, broken sound (residual xfce volumed not un-muting
the master channel bug), degraded trackpad drivers (leftover synaptics
drivers configured to take precedence over libinput) and undoubtedly
other things I didn't notice. I now reinstall and restore VMs every
time.
Upgrading is "supported" [2], but personally I think we should just
drop support for upgrading all together and force people to back up
their AppVMs and restore them onto the new install. People should be
doing backups anyway, re-importing with paranoid mode allows making a
clean break from potential old compromises, and upgrading isn't
actually as well tested as people may be lead to believe by the
existence of the upgrade docs.
Good luck,
Jean-Philippe
[1]: https://github.com/QubesOS/qubes-issues/issues/2742
[2]: https://www.qubes-os.org/doc/upgrade-to-r3.2/