"Make an Alpha!"

[Rusty Bird]

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

Marek, the masses are chanting it!!
https://www.youtube.com/watch?v=sq5g-V63Q30&start=1511

Less shitpostingly, I was about to comment on #6041 with how to move
from ext4/file to btrfs/file-reflink but noticed that btrfs-convert
had a nasty bug that's fixed* in fc32. It would be bad to to encourage
users to boot untrusted openQA .iso blobs, so I'm just adding this to
the list of reasons why it would be neat to have a signed (pre-)alpha
R4.1 iso.

Rusty

* https://github.com/kdave/btrfs-progs/commit/0ff7a9b5210723bd4ad0d9d78dbbb18ee8fdd2b1
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl9nkmZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt+06g//fAyvHV7zOyscHMruHqP0+3+2FGY0gJUMhr6+rOphKlsBx6NDP5rgFQxm
NFkJZzEhMcvJBJS+KYXCWHICqIXZjtzrD6zJBjKE9wl5OctOIHrjknTYt8yg6hYv
lXug+WBHHJo2gL2DT+EEms8Sd7hnPX5SErWO00g5nl7RTbT9UlY2vf+aFOZMRChV
HlsUgFPzw3XMnl5zmcWEoiOv6GU+xy91s8DOPS0hOW8UBNsxp6LlAelraIGof86h
jb1vT/zTvWxZ0J8BcLX9y/eDsFl4/aVoI1u9Si10wEaszzIJFKxPTgZ42CNTwPL+
GHLp6Cmm/K473JtL22BVqqna41b/c+6u6jVKx9PX05b4uyrxEiaHdCiJzCneEQGR
PyGyh8e3VSi5DPGSsD2XPkz9VXSf1Rr5UnbKqnJvxSY7iuDYbHWksI4Z/vYc8NdI
tZJ4gZkteBigsTOp4SCnerXuGkYh6OaT8MgB8Vu9PnFbDDLWBsh584vSo0oG5oyr
DU+UVg5Uo3GH685kE4vYVQlaaKx2GvjWL6jattKMJ+eEiWIOxqap1h4tMmGTfw6B
h+Sz/Ma/wCO5IJW3/fiI1D4lQrQd0FEGp41z6thj0byGFSbx/zMo8gHQU/IT44sr
UgffbCg4DTkxV6hvcDT8naTLtjLAcmLJJfa+xwG0VXc1alkVcYg=
=33ZD
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Sun, Sep 20, 2020 at 05:33:26PM +0000, Rusty Bird wrote:
> Marek, the masses are chanting it!!
> https://www.youtube.com/watch?v=sq5g-V63Q30&start=1511
>
> Less shitpostingly, I was about to comment on #6041 with how to move
> from ext4/file to btrfs/file-reflink but noticed that btrfs-convert
> had a nasty bug that's fixed* in fc32. It would be bad to to encourage
> users to boot untrusted openQA .iso blobs, so I'm just adding this to
> the list of reasons why it would be neat to have a signed (pre-)alpha
> R4.1 iso.

I hear you. I have quite busy this week, but should be able to do the
build early next week (feel free to remind me).

In the meantime, I could use some help with debugging suspend issues[2]
which I consider one of the very few blockers before I switch to R4.1
myself :)
If there are no better ideas, perhaps even bisecting Xen between 4.13
and 4.14 would work.

> * https://github.com/kdave/btrfs-progs/commit/0ff7a9b5210723bd4ad0d9d78dbbb18ee8fdd2b1

[2] https://github.com/QubesOS/qubes-issues/issues/6066

- --
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/THMrX1ywFAl9nmXMACgkQ24/THMrX
1yysgwgAjhNkvwab2P+jPdJwXQkFx28iP4CfCn2INCe6XI9f/DvhgkKkfDwFthLP
/rnRTRJ+Cjjdcx00dRE++Sje3HYVn5b/jYQW4Ksda5s9ZU/QarqbZ1rlmtJI028p
gqY8MQFw92Zvjthb0fsDvQYFJUFG/1tzyO8otXJfEjpSJNQsr/UdecRh1E0OLeUr
AKTv8/Hu2y19L9EjyHCsJNMf2HhCDggkm1QWPtK68Qw0mQEJaYDQjDIcis7lISnY
5AYvArKS85iZsOF+ufvLRkyFMZkF6lLfO3iEmZhNQtRS0u6yZ/6DvsKffSMCCr4E
dfgpDBgdVkl/47VDBy87V6tpb8a6uw==
=5bFv
-----END PGP SIGNATURE-----

[Chris Laprise]

On 9/20/20 2:03 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Sun, Sep 20, 2020 at 05:33:26PM +0000, Rusty Bird wrote:
>> Marek, the masses are chanting it!!
>> https://www.youtube.com/watch?v=sq5g-V63Q30&start=1511
>>
>> Less shitpostingly, I was about to comment on #6041 with how to move
>> from ext4/file to btrfs/file-reflink but noticed that btrfs-convert
>> had a nasty bug that's fixed* in fc32. It would be bad to to encourage
>> users to boot untrusted openQA .iso blobs, so I'm just adding this to
>> the list of reasons why it would be neat to have a signed (pre-)alpha
>> R4.1 iso.
>
> I hear you. I have quite busy this week, but should be able to do the
> build early next week (feel free to remind me).
>
> In the meantime, I could use some help with debugging suspend issues[2]
> which I consider one of the very few blockers before I switch to R4.1
> myself :)
> If there are no better ideas, perhaps even bisecting Xen between 4.13
> and 4.14 would work.
>
>> * https://github.com/kdave/btrfs-progs/commit/0ff7a9b5210723bd4ad0d9d78dbbb18ee8fdd2b1
>
> [2] https://github.com/QubesOS/qubes-issues/issues/6066

FYI, I'm seeing a few glaring issues with 4.1 installation:

* Excluding all templates and vm kernels

* Allocating a thin lvm pool and then using the plain file pool type

* VMs ignoring the selected keyboard layout

* Incompatibility with a popular Intel wifi card

Those first few are pretty rough.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Rusty Bird]

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

> On 9/20/20 2:03 PM, Marek Marczykowski-Górecki wrote:
> > In the meantime, I could use some help with debugging suspend issues[2]
> > which I consider one of the very few blockers before I switch to R4.1
> > myself :)

Oh shit, I'm like the least qualified person to help with this. I've
never even attempted to suspend any OS to RAM or to disk in my life.

Chris Laprise:

> * Allocating a thin lvm pool and then using the plain file pool type

Can you expand on what you're trying to do and how it's going wrong?

> * Incompatibility with a popular Intel wifi card

AX200? Then at least it's not a regression from R4.0.3.

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

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl9nqUJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt+DuA//W2vLfIA3LFX+xyNWXJSMkRAOYJv/xhH4E0b+DcjJR1LiHgXeylCIt4RL
u0VLqqAgS5bRIi33DrAvlpxKbkNRWaQp8CsJDxn1G06wTfFvCN6NsPKP81nEgFq8
aEJo8LXZdc9rs7CBAgnTXBYe1LfhJB711pDKJcsVysHOFDH1jbJwM/vvxGBOUFPU
ycJzvY0/AlOolrC7rTEBw4RTFPzcxajdaIH/3p+2IkVD3y10OnRy3Ie56dEyYTAT
+F32N2/Sxqiq/9kP9NQVP1GfqYW1l8I2YpT9gzs+WRCmlMK5kjZBl98I9xT8iVNF
0DdGFV0PpRp/2spTwgqoP1U/aAw/Md+qaI9yxCvAGQT5zUnC/mBXqfQLaL8Zz4Lm
cAaw7hqTKwdVIDTTIaPFmSiwx9nxRuaDT3xk5m2H9/bV75BgzjCQuMEWIC9Sls0x
nbpeNrPoxFAI/yO7zw9umL4BOepl4bkzYCGu71s8b5+0tZakXP1nrb0BZqd/WVrM
zwW9RWeR63XvA6+SpidXh3jQI5wllBnJckuWWNLGbRwukbq3jezMpPUIpBtIZPjT
8XAe39r3Xf9+w1qeXxE9FbJ3/zbs6R/Eyn2L1GtXND2h2e2dTdpe3P/gskHH5Aso
RDD/xbgyraghC/aVYR/Voz0OjJm2M06ielR2/DKs9V8aDPXmXUc=
=rcss
-----END PGP SIGNATURE-----

[Dylanger Daly]

> I could use some help with debugging suspend issues[2]

which I consider one of the very few blockers before I switch to R4.1

I'm surprised people use the suspend feature, it's never really worked for me, and I've always avoided it because of security issues, however I guess with AMD's Memory Bus Encryption (TSME) https://en.wikichip.org/wiki/x86/sme#Transparent_SME

Might feel a little better about suspending.

> If there are no better ideas, perhaps even bisecting Xen between 4.13

and 4.14 would work.

I tried doing this to find whatever commit(s) fixed AMD 4000 on Xen.

[Chris Laprise]

On 9/20/20 3:10 PM, Rusty Bird wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>> On 9/20/20 2:03 PM, Marek Marczykowski-Górecki wrote:
>>> In the meantime, I could use some help with debugging suspend issues[2]
>>> which I consider one of the very few blockers before I switch to R4.1
>>> myself :)
>
> Oh shit, I'm like the least qualified person to help with this. I've
> never even attempted to suspend any OS to RAM or to disk in my life.

Debugging suspend is hard, no? If the system goes catatonic and doesn't
wake up...

Anyway, it does not appear to be working on my Thinkpad T14 AMD.

If you have suggestions for gathering debug info I'll try them.

>
> Chris Laprise:
>> * Allocating a thin lvm pool and then using the plain file pool type
>
> Can you expand on what you're trying to do and how it's going wrong?

After building the iso and storing it on usb flash, I boot it using
additional xen parameters 'dom0_max_vcpus=1 dom0_vcpus_pin'. This is
necessary to get the installer running on a Ryzen 4000 system.

In the GUI, I choose my keyboard layout, then I click on the Install
Destination icon, leave it on automatic, click Done then enter a luks
passphrase. Next it says I need more space so I click on Reclaim Space
and then the Delete All button. Finally, I choose User Creation and give
it a simple user name+pwd.

The result is that Qubes domUs are using qcow image files, despite the
installer having setup lvm with a pool for root (which is being used by
dom0) and a large lvm pool for domUs (which is NOT being used at all).
Installing templates and creating new vms creates img files in
/var/lib/qubes (i.e. using the small root volume).

I didn't check the output of `qvm-pool` etc. but its obvious that its
using the wrong Qubes pool driver.

I could give you more info about how I configured qubes-builder, but all
I did really was copy the 'qubes-os-master.conf' example and change the
dom0 kernel to v5.8.5, and excluded any templates except fc30 to save
space and time.

(BTW, running qubes-builder in fc32 instead of fc30 results in an iso
with an invalid grub config).

>
>> * Incompatibility with a popular Intel wifi card
>
> AX200? Then at least it's not a regression from R4.0.3.

Yes.

[Chris Laprise]

> Chris Laprise:
>> * Allocating a thin lvm pool and then using the plain file pool type
>
> Can you expand on what you're trying to do and how it's going wrong?

From the 'initial-setup-ks.cfg' file on the 4.1 machine:

> %packages
> @^qubes-xfce
> @qubes-ui

And:

> %addon org_qubes_os_initial_setup
> system_vms False
> default_vms False
> whonix_vms False
> whonix_default False
> usbvm False
> usbvm_with_netvm False
> skip True
> default_template None
> templates_to_install
> lvm_pool qubes_dom0/vm-pool
> %end

Output of 'qvm-pool':
> NAME DRIVER
> varlibqubes file
> linux-kernel linux-kernel

[Rusty Bird]

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

Chris Laprise:

> On 9/20/20 3:10 PM, Rusty Bird wrote:
> > Chris Laprise:
> > > * Allocating a thin lvm pool and then using the plain file pool type
> >
> > Can you expand on what you're trying to do and how it's going wrong?

> In the GUI, I choose my keyboard layout, then I click on the Install
> Destination icon, leave it on automatic, click Done then enter a luks
> passphrase. Next it says I need more space so I click on Reclaim Space and
> then the Delete All button. Finally, I choose User Creation and give it a
> simple user name+pwd.
>
> The result is that Qubes domUs are using qcow image files, despite the
> installer having setup lvm with a pool for root (which is being used by
> dom0) and a large lvm pool for domUs (which is NOT being used at all).
> Installing templates and creating new vms creates img files in
> /var/lib/qubes (i.e. using the small root volume).

Hmm, I just tried Qubes-4.1-20200914-x86_64.iso from openQA and also
clicked through Reclaim Space -> Delete All. But here it succeeded in
using the LVM pool for everything.

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

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl9pA9NfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt+efg//aKPmxy9la3LLMqdEgeel+FIGbWFx4k+nVkqvtVg4Cn2VUaepH5HCgB21
GZuhUzE1H3KILbVVEX4JUd7HnUx4DQWyhAfVrET8c4iGfit/CAgEBq4miAP0avRH
4JrG07uNV285cDcW6+ybzBUAlxyQKDoSDm7aLb5/oVOEu62+SFW7o37jPAJXM2Tn
qWsTbca18R0JlroP/c5Fn4urZFt7OP0cyCQOYtP11Nu3MODhIuNQeieZPiE9axDd
04S0w3om2Vwt8GOxh6BBWke2+vSvEsz9kEiaeeNTUJABVlRTcv7IRC2o4fuMpgQR
Yi2Iq7gtENYhOIc/nIzdQ+cU99kCWpVtKTj73VfHnyRvIzaK+azXzRXWtuPJDR9J
6UcIVZlEJ8nGdTad/m/mKSO5CuOY+QYo+lw/HPMUJTslPPA9AD1DSpoGsdsNfPdy
8OCY7Ryi3XiEDl8rqS3e7PDw+VGC9Jq38G+3nif1uVMcMP1Z5wt4HYXKJEzP/B7v
ysuKV8ORX1tqzVCFqkJ8JmHbSoeGEgzehpHbgqZFd6ks8qygfTwM42JH3D1Ww2Ee
TerNEdWl4m0aITLXUDqal/b+1m/7aaFTuPudXR26hydrigvlCFPjY42eC+j8GuUX
aTR1UM5VORorzlfGMSdm+Cq73d/a+o1YAIVjP6/CV3xv8vNmXqw=
=I6om
-----END PGP SIGNATURE-----

[Jarrah]

> Hmm, I just tried Qubes-4.1-20200914-x86_64.iso from openQA and also
> clicked through Reclaim Space -> Delete All. But here it succeeded in
> using the LVM pool for everything.
>

I can also confirm that this works fine in my custom built ISO from last
month.

[Dylanger Daly]

I think Chris is mentioning bugs specific to AMD 4000 based devices, Intel based Laptops I suspect would finish cleanly

[Jarrah]

> I think Chris is mentioning bugs specific to AMD 4000 based devices, Intel
> based Laptops I suspect would finish cleanly

This is probably the case, but I would say myself and Rusty Bird wanted
to confirm that this was not a general installer bug on all devices.

[Marek Marczykowski-Górecki]

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

On Mon, Sep 21, 2020 at 09:18:35AM -0400, Chris Laprise wrote:
> > Chris Laprise:
> > > * Allocating a thin lvm pool and then using the plain file pool type
> >
> > Can you expand on what you're trying to do and how it's going wrong?
>
> From the 'initial-setup-ks.cfg' file on the 4.1 machine:
>
> > %packages
> > @^qubes-xfce
> > @qubes-ui
>
> And:
>
> > %addon org_qubes_os_initial_setup
> > system_vms False
> > default_vms False
> > whonix_vms False
> > whonix_default False
> > usbvm False
> > usbvm_with_netvm False
> > skip True

This may be the key part. I haven't verified it now, but selecting to
skip the config may also skip setting default pool...

> > default_template None
> > templates_to_install
> > lvm_pool qubes_dom0/vm-pool
> > %end
>
> Output of 'qvm-pool':
> > NAME DRIVER
> > varlibqubes file
> > linux-kernel linux-kernel
>

- --
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/THMrX1ywFAl9pKMYACgkQ24/THMrX
1yw5XAf9ErJrI5Hz/BTs8sQpbDmqmrS+k3Ma6nkV6QdU3yJ/VDVdYDoFoZR5n6of
VuIzTD6us5ojsemPPOkyTEH7UjbL2G8w8rpYAFAaqW1iUfBN8YK3bo7i6TfHBaaG
5GQ33pAs3zziBImFk4xyHF5yJHgjLNcxAvMAX81p+FTiEQUt+jRd4LCKYgWSDSBL
AufQsQHgWiDTupuG8ZHapdTSTAjWKqJwlzB4mEvavb2tbsA+tsMyLUT8EPXL7cGg
hD/zc+CkqXvWG8vmq/1U8Hs12ngvdwdF/SsjIJgi8IixE2njeVe5/U0RaEHJt/AL
BjM3TmhvfQpBR16PiLfd1AWR1gRc6g==
=7nzF
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Mon, Sep 21, 2020 at 08:18:19AM -0400, Chris Laprise wrote:
> (BTW, running qubes-builder in fc32 instead of fc30 results in an iso with
> an invalid grub config).

Can you post what exactly broken config you've got. The ISO build is run
in a chroot environment that shouldn't depend on the outside
distribution...

- --
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/THMrX1ywFAl9pKRIACgkQ24/THMrX
1yx8EwgAlF1OD9GcxI0pPgQKR4WQzdRZ8z7fdssxGQ2KP9ZrNJadol55mqCq1gYL
8fCSCQoBMTTB9tkBM3/swyHVrR4h3IuYq0yNt8ineN5ArFYqocl74PHSWXyUZn4Z
Gf3Csk581EsfvP9+Jx2vghMcvBjVV0j8eMopkqo4W6YK+RQYa5g/gh1g1+cG27FH
8POIgKXRXURhKBZq5RPh7TjluJJlyTVqV5hgm3XWECYqXSIrhOFUMiWl8wvoco1y
tTrAodhMZdWOF4HRAy1MD04ypzb2Z50uh6wbhQHwgCdWGkpSTXPlIJe3HzX0zPFp
DmnMUohRaz1nrsr2W/DHzmNY314ahg==
=HTID
-----END PGP SIGNATURE-----

[Chris Laprise]

On 9/21/20 6:28 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Sep 21, 2020 at 08:18:19AM -0400, Chris Laprise wrote:
>> (BTW, running qubes-builder in fc32 instead of fc30 results in an iso with
>> an invalid grub config).
>
> Can you post what exactly broken config you've got. The ISO build is run
> in a chroot environment that shouldn't depend on the outside
> distribution...

I don't have it anymore as it existed on the internal ssd of the target
computer, which was running fedora 32 KVM on bare-metal ubuntu at the
time. The config was over-written by the install.

It was pulling from master, and the resulting boot error was IIRC
something like "cannot convert slot 0,0". I think we'll have to leave it
there unless someone else experiences it.

[Chris Laprise]

On 9/21/20 6:27 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Sep 21, 2020 at 09:18:35AM -0400, Chris Laprise wrote:
>>> Chris Laprise:
>>>> * Allocating a thin lvm pool and then using the plain file pool type
>>>
>>> Can you expand on what you're trying to do and how it's going wrong?
>>
>> From the 'initial-setup-ks.cfg' file on the 4.1 machine:
>>
>>> %packages
>>> @^qubes-xfce
>>> @qubes-ui
>>
>> And:
>>
>>> %addon org_qubes_os_initial_setup
>>> system_vms False
>>> default_vms False
>>> whonix_vms False
>>> whonix_default False
>>> usbvm False
>>> usbvm_with_netvm False
>>> skip True
>
> This may be the key part. I haven't verified it now, but selecting to
> skip the config may also skip setting default pool...

Perhaps, but also need to remember the reason why skip was chosen: The
vm kernel and template rpms were built but not included in the iso. I
experienced this with 3 separate builds and Dylanger also experienced it.

>
>>> default_template None
>>> templates_to_install
>>> lvm_pool qubes_dom0/vm-pool
>>> %end
>>
>> Output of 'qvm-pool':
>>> NAME DRIVER
>>> varlibqubes file
>>> linux-kernel linux-kernel

[Chris Laprise]

I need help with the vm keyboard layout. The dom0 layout is working
correctly but domU is stuck on qwerty, so touch typing is not possible.

I'd also like to know which other setup processes where probably left
undone. I have manually fixed the storage pool settings... are there any
others?

Thanks...

[Jarrah]

> I need help with the vm keyboard layout. The dom0 layout is working
> correctly but domU is stuck on qwerty, so touch typing is not possible.

This is a known problem. See
https://github.com/QubesOS/qubes-issues/issues/6030.

[Marek Marczykowski-Górecki]

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

On Sun, Sep 20, 2020 at 08:03:31PM +0200, Marek Marczykowski-Górecki wrote:
> On Sun, Sep 20, 2020 at 05:33:26PM +0000, Rusty Bird wrote:
> > Marek, the masses are chanting it!!
> > https://www.youtube.com/watch?v=sq5g-V63Q30&start=1511
> >
> > Less shitpostingly, I was about to comment on #6041 with how to move
> > from ext4/file to btrfs/file-reflink but noticed that btrfs-convert
> > had a nasty bug that's fixed* in fc32. It would be bad to to encourage
> > users to boot untrusted openQA .iso blobs, so I'm just adding this to
> > the list of reasons why it would be neat to have a signed (pre-)alpha
> > R4.1 iso.
>
> I hear you. I have quite busy this week, but should be able to do the
> build early next week (feel free to remind me).

Nest week turned out to be next month, but it's here:
https://ftp.qubes-os.org/iso/Qubes-R4.1.0-alpha20201014-x86_64.iso
and its signature: https://ftp.qubes-os.org/iso/Qubes-R4.1.0-alpha20201014-x86_64.iso.asc

This isn't "release candidate"-stable yet, but most of the things should work already.

- --
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/THMrX1ywFAl+HFYYACgkQ24/THMrX
1ywZXwf+NRSfwOoxDaD/XEnDjNqQZrRMT6mZnQxrcy3xW03vCxrl/LBbDj4ijJ7J
2rxgQGMbZ3HV8kzymxSn8k3jP0S19seNetB7oC8XH/w4mnDEaKZbD+VmjVGwbTg/
v/WgC6rdajUqXXV2gJQKyQ2Nz2V2Lo+mF/anWA1OXRJvfpxY3h3Xn6ea7Ow+2i2M
JNgQtQRT00Xz8Wm/o6NB0lIbWT4I5KLmH/8FxD6QpobyKaXRGT/aIjOh50x3p7+Z
daDNvueD7HbYq0XyfUDEbvM2+kbrR8gZDptETSIXB14JXe8KtH2FdsL5w1tvwClt
ixHZazcNqJwMX4PW4Do6rQMVfbEZIA==
=mUH2
-----END PGP SIGNATURE-----

[Rusty Bird]

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

Marek Marczykowski-Górecki:

> Nest week turned out to be next month, but it's here:
> https://ftp.qubes-os.org/iso/Qubes-R4.1.0-alpha20201014-x86_64.iso
> and its signature: https://ftp.qubes-os.org/iso/Qubes-R4.1.0-alpha20201014-x86_64.iso.asc

Yesss! And congrats on slaying that hydra of Xen S3 resumption bugs.

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

iQKSBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl+HOGZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt8QjA/3bQ3RVx1VftdgzWazecaQI6uPPLKvEfyK2EmNTh9I5VoKy4VGXin5Hx2K
HmTKYLQVPBVQOc+9n3HI34ckrINWtk2OwTuc+Uh1bmo5tI/VPDzaZHFdtbIjTTgH
IB2BYGMIblT4XNwfQXLaeD58kzW+8RPpPnh13cNzZ/G0p11CROWTeklwMGRDePUH
apioIEB4CeVfsq8aFEU8SjrSnLiHILBzMHyco9gH13NoRVN7f3g+oZLzGdSC8Wlp
kPQr/dPBLrOM/TH3BHYG8asp98ZyxocxMm8Jzn3ARY+lQ5FQMjt/iLtUMEDZ/A4r
b7G6XcnWCfx+Bb9NdKkOVowf9mDABoJ6iwaD/dGBNDbNowo2BsB407wfO0A2RjwL
EUHxLHTQEmR97pzNU5fVd0rJgXdqq9MytlwGDxAgBEyxwuSRtuC8N9+ZX80eerRE
grjdPxumPhXBUHlFdTyYucL8MHATwsjinM2cYwzqSJYnspB7LvIftpWSh32+ufxz
WEwmrA27JkZXGyZ3gd+l/+Wro4Mw1YYA43e8sauvLWM5ZrpJaQYb8E6r+RqUkidP
19vHrIRDiGVsPbQypT986/Ty5gqGR84Bmgus0cgeo/9SqTTbfOkdpH4ougGogrVm
/o28wdu6dWwLQwejKhCa0N5y3t6Mh3Bm9CaIg5y4i8gvMECihQ==
=rV3o
-----END PGP SIGNATURE-----