Re: [qubes-users] XSAs released on 2021-11-23

2022-07-17 Thread Qubes

Frédéric Pierret wrote:



Le 11/28/21 à 10:10, Qubes a écrit :

'awokd' via qubes-users wrote:

Qubes:


Are you currently running it, can you give any feedback?


Yes, running 4.1. Haven't tried gui or audio domains yet, but so far 
everything works fine. Think a couple people have run into no QWT 
being available for 4.1, but it's not something I need.




A couple of things I am not sure of doing a backup, fresh install of 
4.1 rc2, and then restoring, is for example current templates, like 
Debian 10 as well as all the clones of this template for example and 
the customizations done to each. Is it possible to directly 'transfer' 
Templates via backup/restore method to 4.1 rc2. Does one need to 
perhaps install new qubes-specific-packages for new 
features/integration/or-the-like things to work. Or should everything 
pretty much work out the 'box'?




It does not work out of the box. Migrating your template from R4.0 to 
R4.1 need manual steps like adding Qubes R4.1 repositories and upgrade 
your templates. As you will not be able to have GUI once your template 
from R4.0 are restored into R4.1, you will need to use "virsh console" 
into dom0 to access your templates.




Following on from this conversation i have upgraded all of my templates 
on Qubes 4.0 to Debian-11 and Fedora-35 (i will upgrade to Fedora-36 on 
4.1). My question is now if someone can be more specific about what i 
would need to do to my Debian-11 and Fedora-35 templates on 4.1 if i do 
a backup on 4.0 which i restore to 4.1.


I may have overlooked it but is there documentation that covers this? I 
don't know off the cuff how to change the repos in my templates to 4.1. 
Then, if i change the repos in the templates to 4.1 do i just need to 
perform a regular update using the update widget and the update process 
will take care of the rest? Or(And)?


Looking at it at from a one to one perspective, how do i make a template 
restored from 4.0 to 4.1 work exactly like the same template created on 4.1.


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4f9bd950-75bc-2770-565e-720a2912a0cc%40ak47.co.za.


Re: [EXT] Re: [qubes-users] XSAs released on 2021-11-23

2021-11-30 Thread Ulrich Windl

On 11/27/21 11:03 AM, 'awokd' via qubes-users wrote:

Qubes:

Is there Qubes documentation outlining the steps to increase the size 
of /boot, or does one follow general disk management, with tools like 
using GParted for example. Although the disk is a LUKS encrypted 
volume. Can one decrypt, use GParted to resize, and then encrypt again?


Note that /boot itself is not encrypted, but you're right, you would 


Since GRUB can load LUKS-encrypted /boot, one could even encrypt /boot, 
but a part of GRUB is also encrypted then, it seems. At least there 
isn't much GRUB functionality until the LUKS volume is unlocked.
And it seems you only have one attempt to enter the passphrase 
correctly. Also GRUB decryption seems much slower than kernel decryption...


have to decrypt the rest to resize it. No Qubes specific docs. Procedure 
you describe should work, but might be further ahead by backing up your 
VMs to a removable encrypted drive, doing a fresh install of R4.1 (rc2 
last I saw) and adjusting the boot partition size on the installer 
screen, then restoring?




--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/492c9a9c-e566-38c1-bb6d-81fd792282db%40rz.uni-regensburg.de.


Re: [EXT] Re: [qubes-users] XSAs released on 2021-11-23

2021-11-30 Thread Ulrich Windl

On 11/26/21 3:47 PM, Qubes wrote:

'awokd' via qubes-users wrote:

Qubes:


And that is it. When I run update from CLI I get this,

"Error Summary
-
Disk Requirements:
    At least 33MB more space needed on the /boot filesystem."

Is that normal behavior? The disk /boot lives on is not full, the 
complaint is with /boot specific.


What does "df -h" say about /boot? If it's full and you've been 
updating the system for a while, check for old EFI images that haven't 
been cleaned up.




df -h shows /boot is full, 100% used.

I am not sure how to fix this, can you please give me advice?

Looking at ls -l for /boot I can see a lot of old images, but I guess 
that is because I have set my system to keep 15 kernels. However, I have 


Interestingly I see three kernels (and corresponding initramfs) here, 
but only one Xen version. So it seems kernels have versioning, but not Xen.

Of my 700MB /boot 41% (283MB) are used.

been on the 5.xxx kernel now since it was launched so I can safely 
remove the 4. kernels. How does one clean this up properly. If I 
just delete the files from /boot the system may still think they are 
there, is there a built-in process/procedure to follow for this?




--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7b6775ba-b76d-5908-3ffc-e0c1013b8984%40rz.uni-regensburg.de.


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-28 Thread 'awokd' via qubes-users

Frédéric Pierret:



Le 11/28/21 à 10:10, Qubes a écrit :

'awokd' via qubes-users wrote:

Qubes:


Are you currently running it, can you give any feedback?


Yes, running 4.1. Haven't tried gui or audio domains yet, but so far 
everything works fine. Think a couple people have run into no QWT 
being available for 4.1, but it's not something I need.




A couple of things I am not sure of doing a backup, fresh install of 
4.1 rc2, and then restoring, is for example current templates, like 
Debian 10 as well as all the clones of this template for example and 
the customizations done to each. Is it possible to directly 'transfer' 
Templates via backup/restore method to 4.1 rc2. Does one need to 
perhaps install new qubes-specific-packages for new 
features/integration/or-the-like things to work. Or should everything 
pretty much work out the 'box'?




It does not work out of the box. Migrating your template from R4.0 to 
R4.1 need manual steps like adding Qubes R4.1 repositories and upgrade 
your templates. As you will not be able to have GUI once your template 
from R4.0 are restored into R4.1, you will need to use "virsh console" 
into dom0 to access your templates.


Most (but not all, now that you mention it) of my Debian 10 templates & 
AppVMs restored to 4.1 as is and remained usable. I ended up having to 
mount the private volume of one that wouldn't and copying the data out. 
I'm taking advantage of the re-install to rebuild the templates I use as 
fresh Debian 11 versions, and switching AppVMs over to them as I go.


--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/74628e00-160d-a350-90b4-05db6d042774%40danwin1210.me.


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-28 Thread Frédéric Pierret



Le 11/28/21 à 10:10, Qubes a écrit :

'awokd' via qubes-users wrote:

Qubes:


Are you currently running it, can you give any feedback?


Yes, running 4.1. Haven't tried gui or audio domains yet, but so far everything 
works fine. Think a couple people have run into no QWT being available for 4.1, 
but it's not something I need.



A couple of things I am not sure of doing a backup, fresh install of 4.1 rc2, 
and then restoring, is for example current templates, like Debian 10 as well as 
all the clones of this template for example and the customizations done to 
each. Is it possible to directly 'transfer' Templates via backup/restore method 
to 4.1 rc2. Does one need to perhaps install new qubes-specific-packages for 
new features/integration/or-the-like things to work. Or should everything 
pretty much work out the 'box'?



It does not work out of the box. Migrating your template from R4.0 to R4.1 need manual 
steps like adding Qubes R4.1 repositories and upgrade your templates. As you will not be 
able to have GUI once your template from R4.0 are restored into R4.1, you will need to 
use "virsh console" into dom0 to access your templates.

Best regards,
Frédéric

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9c98cb56-173b-14e9-7018-d05350b958ec%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-28 Thread Qubes

'awokd' via qubes-users wrote:

Qubes:


Are you currently running it, can you give any feedback?


Yes, running 4.1. Haven't tried gui or audio domains yet, but so far 
everything works fine. Think a couple people have run into no QWT being 
available for 4.1, but it's not something I need.




A couple of things I am not sure of doing a backup, fresh install of 4.1 
rc2, and then restoring, is for example current templates, like Debian 
10 as well as all the clones of this template for example and the 
customizations done to each. Is it possible to directly 'transfer' 
Templates via backup/restore method to 4.1 rc2. Does one need to perhaps 
install new qubes-specific-packages for new 
features/integration/or-the-like things to work. Or should everything 
pretty much work out the 'box'?


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/de6efc7d-11cf-d52e-efbb-38eb4d479538%40ak47.co.za.


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-27 Thread 'awokd' via qubes-users

Qubes:


Are you currently running it, can you give any feedback?


Yes, running 4.1. Haven't tried gui or audio domains yet, but so far 
everything works fine. Think a couple people have run into no QWT being 
available for 4.1, but it's not something I need.


--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6784f06e-563e-ae15-8460-f0b019d4ab8b%40danwin1210.me.


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-27 Thread Qubes

'awokd' via qubes-users wrote:

Qubes:

Is there Qubes documentation outlining the steps to increase the size 
of /boot, or does one follow general disk management, with tools like 
using GParted for example. Although the disk is a LUKS encrypted 
volume. Can one decrypt, use GParted to resize, and then encrypt again?


Note that /boot itself is not encrypted, but you're right, you would 
have to decrypt the rest to resize it. No Qubes specific docs. Procedure 
you describe should work, but might be further ahead by backing up your 
VMs to a removable encrypted drive, doing a fresh install of R4.1 (rc2 
last I saw) and adjusting the boot partition size on the installer 
screen, then restoring?




To be honest right after my last post I had exactly the same thought. 
Thank you for making the suggestion as well, I think I will go this 
route. I was very excited when the GUI domain was announced and have 
been waiting for it like a kid getting an ice cream.


Are you currently running it, can you give any feedback?


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0860d2e1-b19e-ddea-0af0-50e7c5dcb338%40ak47.co.za.


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-27 Thread 'awokd' via qubes-users

Qubes:

Is there Qubes documentation outlining the steps to increase the size of 
/boot, or does one follow general disk management, with tools like using 
GParted for example. Although the disk is a LUKS encrypted volume. Can 
one decrypt, use GParted to resize, and then encrypt again?


Note that /boot itself is not encrypted, but you're right, you would 
have to decrypt the rest to resize it. No Qubes specific docs. Procedure 
you describe should work, but might be further ahead by backing up your 
VMs to a removable encrypted drive, doing a fresh install of R4.1 (rc2 
last I saw) and adjusting the boot partition size on the installer 
screen, then restoring?


--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f52a9053-f01f-8a3f-5313-ef0d10adbe2c%40danwin1210.me.


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-26 Thread Qubes

'awokd' via qubes-users wrote:
The steps in 
https://linuxconfig.org/how-to-remove-old-unused-kernels-on-centos-linux 
should work, except the one about package-cleanup command. It's OK to 
skip that step as removing one by one will work.




Thank you. I didn't know you do it through the package manager, that was 
painless.


Is there Qubes documentation outlining the steps to increase the size of 
/boot, or does one follow general disk management, with tools like using 
GParted for example. Although the disk is a LUKS encrypted volume. Can 
one decrypt, use GParted to resize, and then encrypt again?


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ac18e83a-ce4e-a04f-b504-36ec53e0df50%40ak47.co.za.


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-26 Thread 'awokd' via qubes-users

Qubes:


df -h shows /boot is full, 100% used.

I am not sure how to fix this, can you please give me advice?

Looking at ls -l for /boot I can see a lot of old images, but I guess 
that is because I have set my system to keep 15 kernels. However, I have 
been on the 5.xxx kernel now since it was launched so I can safely 
remove the 4. kernels. How does one clean this up properly. If I 
just delete the files from /boot the system may still think they are 
there, is there a built-in process/procedure to follow for this?


The steps in 
https://linuxconfig.org/how-to-remove-old-unused-kernels-on-centos-linux 
should work, except the one about package-cleanup command. It's OK to 
skip that step as removing one by one will work.


--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1a6156e7-b73f-7a3c-ab23-21f885cd2e39%40danwin1210.me.


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-26 Thread Qubes

'awokd' via qubes-users wrote:

Qubes:


And that is it. When I run update from CLI I get this,

"Error Summary
-
Disk Requirements:
    At least 33MB more space needed on the /boot filesystem."

Is that normal behavior? The disk /boot lives on is not full, the 
complaint is with /boot specific.


What does "df -h" say about /boot? If it's full and you've been updating 
the system for a while, check for old EFI images that haven't been 
cleaned up.




df -h shows /boot is full, 100% used.

I am not sure how to fix this, can you please give me advice?

Looking at ls -l for /boot I can see a lot of old images, but I guess 
that is because I have set my system to keep 15 kernels. However, I have 
been on the 5.xxx kernel now since it was launched so I can safely 
remove the 4. kernels. How does one clean this up properly. If I 
just delete the files from /boot the system may still think they are 
there, is there a built-in process/procedure to follow for this?


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6733f575-240e-8df9-dfab-e3252b74b1dd%40ak47.co.za.


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-26 Thread 'awokd' via qubes-users

Qubes:


And that is it. When I run update from CLI I get this,

"Error Summary
-
Disk Requirements:
    At least 33MB more space needed on the /boot filesystem."

Is that normal behavior? The disk /boot lives on is not full, the 
complaint is with /boot specific.


What does "df -h" say about /boot? If it's full and you've been updating 
the system for a while, check for old EFI images that haven't been 
cleaned up.


--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0fef4c1f-1d2e-4898-5418-300ef994c3cc%40danwin1210.me.


Re: [qubes-users] XSAs released on 2021-11-23

2021-11-26 Thread Qubes

Andrew David Wong wrote:

Dear Qubes Community,

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS *is affected*.
Therefore, *user action is required*.



When I run update using the orange sun icon the dom0 update finishes 
with the following text


"Updating dom0

local:
--"

And that is it. When I run update from CLI I get this,

"Error Summary
-
Disk Requirements:
   At least 33MB more space needed on the /boot filesystem."

Is that normal behavior? The disk /boot lives on is not full, the 
complaint is with /boot specific.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5a9edf59-65ed-3d82-4500-d85cc99df8b2%40ak47.co.za.