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*.
XSAs that affect the security of Qubes OS (user action required)
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
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.xxxx 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?
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.xxxx 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.
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?
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?
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
Frédéric Pierret:
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.
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.
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...
Frédéric Pierret 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.