3.2.1 / An updated 3.2 iso?

[Vincent Adultman]

Hi all

We were chatting today in IRC about current user expectations and experiences with the 4 release candidates. While many are happily testing there are indeed some visitors who drop by with the requirement of a daily driver stable system, but have some newer hardware than the kernel on the current 3.2 iso will support. These users seem to be in a somewhat painful position, the bravest are attempting to build their own isos or perform some cross install using a machine that will work. Some fail / give up.

https://www.qubes-os.org/doc/supported-versions/ suggests that at some point a 3.2.1 release was/is planned, h01ger suggested to me all focus is currently on 4, but can I ask:

1. What are the current plans for 3.2.1? (if it was planned to be anything other than an updated iso)

2. Regardless of 1. is there a possibility of getting an updated 3.2 iso for Christmas, given that some will undoubtedly use the holiday time to try Qubes, quite possibly on shiny new hardware :)

Thanks for your time.

V

[cooloutac]

sounds like an inherent linux problem, not much qubes can do about that.

[Mike Freemon]

A number of the problems encountered by people trying to install R3.2 on
newer hardware would be avoided if the installation ISO contained a more
recent version of the linux kernel.

For example, see:
https://groups.google.com/forum/#!msg/qubes-users/fE2HCAdF-U0/eLovum3xAgAJ

That's what the OP was asking about, if I'm reading it correctly.

I completely support and appreciate the work of the Qubes team. I can
imagine that updating R3.2 at the same time as finalizing R4 would be
asking a lot. But with the extended support for R3.2[1] driven by the
new minimum hardware requirements, and also considering the lack of a
management GUI, I suspect that the value of a newer R3.2 ISO will become
clear.

Yes, count me as a technically-savvy person who uses the Qubes Manager
GUI continuously. However, the Qubes team should not take this as a
criticism. I understand the need to prioritize, and I don't disagree
with the decisions that were made. But I do wonder to what extent the
lack of a GUI will slow the adoption of R4.

[1]
https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/

[Mike Freemon]

On 12/19/2017 01:04 PM, cooloutac wrote:

[Andrew David Wong]

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

We do still plan to have a 3.2.1 release, but I'm afraid we have no
estimated release date for it yet. We'll make an announcement as soon
as we know more.

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

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJaOfsrAAoJENtN07w5UDAwnjQQAI493E4S2rLQH7vfSuoRb4ct
nU8BqPLCWakMPsJRDvc9I04gQ8JCW2NCLoD5jVXhmTeQwsth8VavEcI/p85PdceE
culawn5PAL+huWftTr/ClDBzsQN495g3TrTqwHCpYER0IJLz8sjMNLjJniSJdPM+
87l7g+aq9QFvEVjqKoCE4aZFpIJm/63mPa0CvpsXXjeLhzHmhyqifyzaIM6VCkQo
yIZlFBlwmF/8LsXW8xutrAw6RcZ7UgOnagE+MqWwC55bnUu7gew4Aok+KBOrKc2J
+1B2tGitFSVmCj7EPIluDu1F1wrOef4RYaQHpD+aYvc0KPSMnU0TwkTxic+YD6pK
VcH8PWF/zeF+I/s0aoA8tovk1xxdKyZj4qZp8RaOddG2cJtq8jVzrTMhAyENtiN3
BFyl3WZ7Lp/iIBKUnVOkut8le5QffiQko9CUIl3698GcW462RgYFwjsMN7wPYsh9
ZPDwxdppgOjoxhGCfP94b+TKbJuWtA1haqRxVY6IxwnDGpUD7/DJpaTzYbZR+4/W
dVuHSobZaD2zyLpF1dPIqF5/tSxt4BPscXB+TSFh6S44AELGe4uNp0U80uAZzQGA
CDOOCv+ApJdoIOhxfzjE4BrtOkNoalYa95P0MPRtGUkFP9EgoK8N5R0MC6bdljnk
UAJZ+t98k7efTgjvvuUf
=n/RE
-----END PGP SIGNATURE-----

[awokd]

On Wed, December 20, 2017 5:55 am, Andrew David Wong wrote:

> We do still plan to have a 3.2.1 release, but I'm afraid we have no
> estimated release date for it yet. We'll make an announcement as soon as we
> know more.

I have some free time and have done a full 3.2 build before. If I know
what kernel version to target and what build of 3.2 to git I think I could
pull a fully reproducible list of steps and code together. Might need
access to a developer if I hit any code issues. Would that help?

[cooloutac]

Well if its included in the stable eol release of fedora I don't see why it shouldn't be default for Qubes.

People already complain iso is big though. isn't linux kernel like over 100mb?

There is a thread on here about how to boot into text mode and then from there maybe you can compile newer kernel for dom0 using reg tianghas instructions.

Also buying that newer hardware doesn't shout someone who truly cares about security to me. Sounds like More for gaming imo.

I have a 7700k on a less then a year old board but I use windows on it for gaming. want anything sensitive on that hardware. Not even worth the space for Qubes and gaming machine with ssd drives popular now.

[cooloutac]

Ya I'm not sure I would want the bleeding edge kernel to be replace default on the iso though. I'd rather be using the most "secure" one.

[cooloutac]

On Wednesday, December 20, 2017 at 1:50:43 PM UTC-5, cooloutac wrote:
> Ya I'm not sure I would want the bleeding edge kernel to be replace default on the iso though. I'd rather be using the most "secure" one.

I would even be in favor of replacing fedora 25 with debian stable for "security" reasons haha, but then more people would probably have hardware problems.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, that would definitely help.

Try building ISO based on example-configs/qubes-os-3.2.conf, with
changed:

DISTS_VM = fc26 stretch
BRANCH_linux_kernel = stable-4.9

And adjusted qubes-src/installer-qubes-os/conf/comps-qubes.xml for
qubes-template-fedora-26 and qubes-template-debian-9 (simply modify
existing entries to updated versions).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlo64pAACgkQ24/THMrX
1yxp7Af9Egelz8Qu8L1Gv2g58WsxSJTJpdq6+znz3F++vesjqo2pyEcox4V13OdG
XzSAryPAilC/Djbf2zLSmTol4hjec/iZf8q8nAThyh2VgpBn5d7OzqWW1p7HJ3GR
rIf+uB82Al2bbf0kvOlhJ43G9mF9dLWWMfSXdlck90ZzYDS+av9ONtqBNhXkuk+1
tpBR8pNzVqoLMn8799I/LlHfWt1B3EYvOhUIeSf/8L76RwYgtjk0rP7Z9OV23WtV
2y+s+aSyUiE0IE02xFXla+qF/0CUDnY/A/AWb66GMjfFnViNyiCoFhyZJ024HudU
apHWnwjGeU1oocegkJDXpO8LCUC2eA==
=XssL
-----END PGP SIGNATURE-----

[awokd]

On Wed, December 20, 2017 10:22 pm, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> On Wed, Dec 20, 2017 at 12:38:47PM -0000, 'awokd' via qubes-users wrote:
>
>> On Wed, December 20, 2017 5:55 am, Andrew David Wong wrote:
>>
>>
>>> We do still plan to have a 3.2.1 release, but I'm afraid we have no
>>> estimated release date for it yet. We'll make an announcement as soon
>>> as we know more.
>>
>> I have some free time and have done a full 3.2 build before. If I know
>> what kernel version to target and what build of 3.2 to git I think I
>> could pull a fully reproducible list of steps and code together. Might
>> need access to a developer if I hit any code issues. Would that help?
>
> Yes, that would definitely help.
>
>
> Try building ISO based on example-configs/qubes-os-3.2.conf, with
> changed:
>
>
> DISTS_VM = fc26 stretch
> BRANCH_linux_kernel = stable-4.9
>
>
> And adjusted qubes-src/installer-qubes-os/conf/comps-qubes.xml for
> qubes-template-fedora-26 and qubes-template-debian-9 (simply modify
> existing entries to updated versions).

On it. Would be nice to upgrade dom0 from fc23 while I'm at it but I know
that's a lot harder than it appears...

[awokd]

Still working this. My internet connection isn't the most reliable and the
build takes a long time, so depending which file fails to download it's
sometimes forcing me to start over. Once I do get a successful full build
I'll test installing the ISO.

[awokd]

On Fri, December 22, 2017 1:33 pm, 'awokd' via qubes-users wrote:
> On Wed, December 20, 2017 11:51 pm, 'awokd' via qubes-users wrote:
>
>> On Wed, December 20, 2017 10:22 pm, Marek Marczykowski-Górecki wrote:
>>
>
>>> Try building ISO based on example-configs/qubes-os-3.2.conf, with
>>> changed:
>>>
>>>
>>>
>>>
>>> DISTS_VM = fc26 stretch
>>> BRANCH_linux_kernel = stable-4.9
>>>
>>>
>>>
>>>
>>> And adjusted qubes-src/installer-qubes-os/conf/comps-qubes.xml for
>>> qubes-template-fedora-26 and qubes-template-debian-9 (simply modify
>>> existing entries to updated versions).

Finally got it. Build321.html are the steps I followed; bold where I
customized with line numbers on the file edits. BRANCH_linux_kernel =
stable-4.9 was already set. Had to add a line in
qubes-src/template-whonix/builder.conf for the current TBB version or that
template failed to build.

Installed in MBR mode on an AMD laptop. Installer warned it was a
pre-release/testing version. Ran into this bug
(https://groups.google.com/forum/?_escaped_fragment_=msg/qubes-users/TS1zfKZ7q8w/JQFkVF4xBgAJ#!msg/qubes-users/TS1zfKZ7q8w/JQFkVF4xBgAJ)
but the workaround still worked. Had the same bug when I installed
official 3.2 on this laptop before. Got a "default-template fedora-23 does
not exist" when I first tried to install the default qubes so edited a
couple more qubes-src files to change the default to 26. Rebuilt
installer-qubes-os and the iso and then they installed.

The Stretch template was a lot easier to build this time than when I did
it a year or so ago! However, it's MIA from my install. I see a 583MB
qubes-template-stretch-4.0.0-201712222308.noarch.rpm in
qubes-src/linux-template-builder/rpm/noarch but it didn't get installed
with the others in there. Do I also need to edit some of the comps.xml
under linux-yum?

Hypervisor command line is just "placeholder"; this caused dom0 to consume
most of my RAM.

Good news is dom0 and the qubes are all on Linux
4.9.56-21.pvops.qubes.x86_64. Haven't done any testing past that. Will try
install on a UEFI Intel later.

For future reference, is it possible to "make -j4 qubes", and/or to make
each component in the order given in "make help" instead of my all or
nothing approach? Also, should I open a qubes-issue to track this build?

["Marek Marczykowski-Górecki"]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Dec 23, 2017 at 07:09:22AM -0000, awokd wrote:
> The Stretch template was a lot easier to build this time than when I did
> it a year or so ago! However, it's MIA from my install. I see a 583MB
> qubes-template-stretch-4.0.0-201712222308.noarch.rpm in
> qubes-src/linux-template-builder/rpm/noarch but it didn't get installed
> with the others in there. Do I also need to edit some of the comps.xml
> under linux-yum?

Just qubes-src/installer-qubes-os/conf/comps-qubes.xml should be
enough...
Oh, I see you've changed group name. Then you need to update it in
qubes-src/installer-qubes-os/conf/qubes-kickstart.cfg.
I think the better solution would be to name it just "debian", to avoid
this problem in the future.

> Hypervisor command line is just "placeholder"; this caused dom0 to consume
> most of my RAM.

On the installed system, or installer itself?

> Good news is dom0 and the qubes are all on Linux
> 4.9.56-21.pvops.qubes.x86_64. Haven't done any testing past that. Will try
> install on a UEFI Intel later.
>
> For future reference, is it possible to "make -j4 qubes", and/or to make
> each component in the order given in "make help" instead of my all or
> nothing approach?

"make -j4 qubes" would not work, because of very primitive dependency
tracking in qubes-builder. But you can execute make with list of
components directly (copy&paste from make help). Then if something
fails, retry starting from that failed component.

> Also, should I open a qubes-issue to track this build?

Some tracking ticket for Qubes OS 3.2.1 related tasks would be useful.

Something even more useful would be, if you could open pull requests
with the changes mentioned below, referencing that ticket (add
QubesOS/qubes-issues#... to the comment). Then we'll have nice summary
about the state in that ticket.

Thanks!

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlo+1UcACgkQ24/THMrX
1ywVkwgAhG2nkKRRO0B1GPEoJNebXz6fzgF2dT1RwTgIybXMEILVktJqQAMjXhCo
fm1JxZe/70aNvCaH/qhXILxxs4JBrbEB936Ir0v75LDpHSyHk2nMq3FnFwpW1aqn
ERaZxc71zNdjeCZVMWr4nZQoRCE1MRuAOlF+dDNYfJ9DVo1iwBUgIXo8X1DBqk24
+bzlcB7GHJoVju/Qj9x9LQfx1hYqwvHwA9F9wgu6LcxdNIwR21z1zsHqcw2/mUt4
g5sbuvz8LGpZbaVccWQHUl+50Kfa7jtJHP9sPPNiOxJNNXiYtu5FE4FzsCaRkjma
mBEA29FIOA2NUdoP0fkodZl44r385Q==
=NHqQ
-----END PGP SIGNATURE-----

[awokd]

On Sat, December 23, 2017 10:14 pm, "Marek Marczykowski-Górecki" wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> On Sat, Dec 23, 2017 at 07:09:22AM -0000, awokd wrote:
>

> Just qubes-src/installer-qubes-os/conf/comps-qubes.xml should be
> enough... Oh, I see you've changed group name. Then you need to update it
> in qubes-src/installer-qubes-os/conf/qubes-kickstart.cfg. I think the
> better solution would be to name it just "debian", to avoid this problem
> in the future.

OK.

>> Hypervisor command line is just "placeholder"; this caused dom0 to
>> consume most of my RAM.
>
> On the installed system, or installer itself?

On the post-installed system.

>> Good news is dom0 and the qubes are all on Linux
>> 4.9.56-21.pvops.qubes.x86_64. Haven't done any testing past that. Will
>> try install on a UEFI Intel later.
>>
>> For future reference, is it possible to "make -j4 qubes", and/or to
>> make each component in the order given in "make help" instead of my all
>> or nothing approach?
>
> "make -j4 qubes" would not work, because of very primitive dependency
> tracking in qubes-builder. But you can execute make with list of components
> directly (copy&paste from make help). Then if something fails, retry
> starting from that failed component.
>
>> Also, should I open a qubes-issue to track this build?
>>
>
> Some tracking ticket for Qubes OS 3.2.1 related tasks would be useful.

https://github.com/QubesOS/qubes-issues/issues/3426

> Something even more useful would be, if you could open pull requests
> with the changes mentioned below, referencing that ticket (add
> QubesOS/qubes-issues#... to the comment). Then we'll have nice summary
> about the state in that ticket.
>
> Thanks!

Thank you too, will update the issue with above and some more testing notes.

[Frédéric Pierret (fepitre)]

Hi, I have also some free time (holidays!), as I have already prepared updated ISO for myself, I will give you some help on it.

[awokd]

On Sun, December 24, 2017 9:47 am, Frédéric Pierret (fepitre) wrote:

> Hi, I have also some free time (holidays!), as I have already prepared
> updated ISO for myself, I will give you some help on it.

Thanks! I'll ping you off list.

[Frédéric Pierret (fepitre)]

I suceed to build a release3.2 with Fedora 25 as dom0. It is done with some adjustments: xen-4.6.6 with a gmp patch, core-libvirt v3.1.0 (due to python version), and just a backport of some commits related to mgmt-salt, and some adjustments in the installer for default template Fedora 26 and Debian 9. In my repos I named it release3.3 (almost finish to push every minor changes). Should I do a complete report for let you rebuild the whole thing Marek or you would like to skip this release?

[awokd]

I emailed you a couple times with no reply, am I getting spam filtered at
your end?

Anyways, the build I'm working on addresses a couple other issues as well
besides changing the default templates. I didn't dare trying to upgrade
dom0. I've been doing full builds and testing the install on physical
machines, so it takes a long time! Maybe our two builds should be merged
somehow, but I'll leave that up to the professionals.

[Frédéric Pierret (fepitre)]

Le mardi 26 décembre 2017 13:36:40 UTC+1, awokd a écrit :
> On Tue, December 26, 2017 10:40 am, Frédéric Pierret (fepitre) wrote:
> > Le dimanche 24 décembre 2017 11:03:56 UTC+1, awokd a écrit :
> >
> >> On Sun, December 24, 2017 9:47 am, Frédéric Pierret (fepitre) wrote:
> >>
> >>
> >>> Hi, I have also some free time (holidays!), as I have already
> >>> prepared updated ISO for myself, I will give you some help on it.
> >>
> >> Thanks! I'll ping you off list.
> >>
> >
> > I suceed to build a release3.2 with Fedora 25 as dom0. It is done with
> > some adjustments: xen-4.6.6 with a gmp patch, core-libvirt v3.1.0 (due to
> > python version), and just a backport of some commits related to
> > mgmt-salt, and some adjustments in the installer for default template
> > Fedora 26 and Debian 9. In my repos I named it release3.3 (almost finish
> > to push every minor changes). Should I do a complete report for let you
> > rebuild the whole thing Marek or you would like to skip this release?
>
> I emailed you a couple times with no reply, am I getting spam filtered at
> your end?

Oops..indeed it was in the SPAM box...(really sorry...i did not checked it on the webmail)

>
> Anyways, the build I'm working on addresses a couple other issues as well
> besides changing the default templates. I didn't dare trying to upgrade
> dom0. I've been doing full builds and testing the install on physical
> machines, so it takes a long time! Maybe our two builds should be merged
> somehow, but I'll leave that up to the professionals.

Sure. Let Marek decides what ever we should adopt as strategy.