I’ve uploaded an updated Kali template for 4.0.You can pull this from https://qubes.3isec.org/Templates
As always, signed by my QubesOS key - you’re trusting me to do the right
thing with this build.
The template works fine except that Kali enforces python-is-python2
when Qubes wants python-is-python3. There’s a helpful warning about this
at the Kali shell and instructions on how to change it. The only effect
seems to be that qvm-copy IN throws an error message, although files
are transferred properly. qvm-copy OUT works fine.
I’ve added terminator by request.
Wireshark works fine out of the box.
As qubes-template-kali-4.0.6-202106091045.noarch.rpm is a Qubes template, I guess it should be installed with a command line in dom0? If so:
What is this command?
How can we install a package in dom0 from a file that has been download from a VM? (since dom0 has no internet access)
Templates like Parrot or Kali are based on Debian testing. To avoid breakage when updating the core Qubes packages are on hold.
Why templates based on Debian Testing can lead to breakage when updating the core Qubes packages? (or what is the difference with templates not based on Debian Testing?)
‘apt-mark unhold’ will remove the hold and allow you to update the Qubes packages.
I’m confused. I don’t understand why there would be not breakage here. Why, in this case, updating the core Qubes package would not cause breakage?
I suggest you restore the hold (apt-mark hold) to make sure that the Qubes packages are not removed when updating other packages.
Does this mean there is a way to:
update all the packages that are not core Qubes packages when the hold is activated and
update only the core Qubes packages when the hold is disactivated?
If so, what are those 2 commands? (to be typed in the Kali template, I assume)
What is the exact command to activate the hold? apt-mark hold core-qubes-package or something of the kind? (also to be typed in the Kali template, I assume)
in dom0 sudo dnf install qubes-template-kali-4.0.6-202106091045.noarch.rpm
You can copy the file in to dom0: this is covered in the docs
Templates like Parrot or Kali are based on Debian testing. To avoid breakage when updating the core Qubes packages are on hold.
Debian testing is, as the name suggests, a testing distribution.
Packages change, and are updated rapidly. If the Qubes packages have
certain dependencies, then the updated packages in Debian or Kali may
break the Qubes packages, and the Qubes packages may be removed. (This
is the source of much confusion and pain for people who don’t check to
see what the package manager will be doing.)
This doesn’t happen in standard versions of Debian, because the package
transitions there are much slower, and the Qubes packages tested against
them.
The same situation can arise in any rolling distribution like Arch.
‘apt-mark unhold’ will remove the hold and allow you to update the Qubes packages.
Does this make it clearer?
To avoid breakage when updating, the core Qubes packages are on hold.
The process is a little complicated.
When the hold is activated, you just run apt update and apt upgrade
as usual. The hold will prevent the Qubes packages from being removed,
so some of the Debian or Kali packages will be held back.
You can update a single package by using apt install <package>. Or you
can use a package manager like aptitude, which will allow you to
select the packages to be updated.
Exactly so.
That’s fine: I hope this is readable.
You could have found the answers to some of this on the Qubes
documentation.
For many commands, man <command> will provide useful information. In
this case man apt-mark will explain about the use of hold and unhold,
as well as other marks you can set.
I thought that method worked only for text file. Thanks for the tip!
Great explanation! Great feeling to understand what’s going on and… Why!
Explained under 3 ==> OK
&6. So if I understand correctly, I should go in my kali template and type:
To update every packages in the template without touching Qubes packages:
sudo apt-mark hold qubes-*
NB: I get (among many other lines): qubes-core-agent set on hold.
Or would have sudo apt-mark hold qubes-core-* been sufficient?
sudo apt update && sudo apt upgrade
I am applying those commands to a kali template I had made by myself (which might be “broken” as a consequence of what you explained in 3) and I get as as result (among many other lines): Processing triggers for qubes-core-agent (4.0.61-1+deb11u1) ...
Is it normal that I see this line? I mean qubes-core-agent was supposed to be set on hold, so how can triggers for a package on hold be processed?
Then to upgrade the qubes-* packages:
sudo apt-mark unhold qubes-*
sudo apt-mark showhold
Noting appears ==> Fine!
sudo apt update && sudo apt upgrade
I guess the sudo apt update is not really necessary here since apt was anyway updated just before.
NB: Only qubes-usb-proxy needs to be upgraded in my present case ==> Fine
Prepare for the next update && upggrade a.k.a. restoring the hold:
sudo apt-mark hold qubes-*
It is exactly the kind of explanations I was looking for!! The feeling of understanding is great!!
I can confirm this! It was due to a lack of knowledge, though. So great to know it won’t happen anymore!!!
Could you check my last questions here above to be sure I fully understand the details? Hopefully, this will be a great resource on the forum too because I’m pretty sure I was not the only guy not understanding what is happening!
Great.
From your comment and questions you seem to have everything in hand.
Personally, I hold everything with qubes*, but probably
qubes-core-agent would be enough to keep you out of trouble.
The Processing triggers for qubes-core-agent... is to be expected.
Even if the package is on hold, (so cant be upgraded or removed), it may
have interactions with other packages that should be processed.
Incidentally, if you use aptitude, you can set a hold by = , and then
remove it by + .
aptitude is a great package manager and will let you see clearly what is
going to happen. Strongly recommend if you are manually updating.
Incidentally, the Qubes update tool should honour your “holds” and
clears, so you can set them manually and the use the update tool as
normal.
I have also converted the kali linux template to HVM mode and installed the latest kali linux kernel in it so as to fully convert it to kali linux.
Now I am about to install my required kali linux packages.
My question is can I install desktop environment in this template without breaking the qubes packages?
I had earlier created a standalone HVM of kali linux from the iso supplied in their website complete with a XFCE GUI desktop. However I could not install the qubes os packages there.
So it would be of much help if you could help me in this issue.
Also with regards to the kali linux template itself, is the template given by you any different from the one that is made from the existing debian one ? (apart from the build procedure. I guess you have probably used qubes builder scripts)
I have also converted the kali linux template to HVM mode and installed the latest kali linux kernel in it so as to fully convert it to kali linux.
Now I am about to install my required kali linux packages.
I’m not clear on what it is that you want from a desktop environment
in the qube. I’m almost certain that doing this wont give you what you
want.
Saying “I could not install the qubes os packages there” is not helpful.
There are known issues in installing Qubes packages in to standalones,
and you may have hit one of these. Sometimes you can work around them,
but without knowing what problem you had no one can help.
It’s a standard bullseye build using the Qubes build infrastructure and
then loading kali on top.
It will be different in that you have dist-upgraded from buster.
Actually I had installed kali linux from the iso in their website. However the installed os itself was kind of lagging a lot I’m qubes. Also I was not able to transfer files from this standalone vm to my vault vm as the qubes packages won’t install. I had to use an external hard drive for the same.
Hence I was trying to find out whether this thing worked the other way round i.e. install a desktop environment after dist-upgrading from a debian environment.
It’s not the Qubes way to run a desktop environment except in a
Standalone.
What is it that you think a desktop environment will give you?
You already have one working in dom0.
As to the issue with installing qubes packages “qubes packages won’t
install” is really unhelpful.
If you want to pursue that line tell us what the problem is in enough
detail that we can resolve it, if possible. I mean what specifically
means it wont install? What error or warning messages do you get?
