It seems it does. At least for the Template Manager installation.
Anyway, if I just switch the Debian system qubes to Fedora template it will not work, right? It would work if these qubes were initially Fedora based. But since they’re Debian based they have a different “filling” and can’t be just switched to Fedora. Am I reasoning correctly? Ideally, I should find special commands with which I can install ready-made system qubes.
It seems I have found a command of this type in my stash. Here it is: sudo qubesctl state.sls qvm.whonix-workstation-dvm Is there a command to create ready-made system qube? If it were something like this, where you just need to change the name of the qube and everything will be installed, it would be cool.
If I change it like this sudo qubesctl state.sls qvm.sys-usb will it be what I need? But there somehow must be specified the necessary template.
Should all system qubes be based on the same template or I can create only based on Fedora sys-usb and leave other sys qubes to be based on Debian? Will it work?
When I tried replace Debian 13 system qubes with Fedora based ones this not only did backfire, but now that I’ve reverted everything back, the stick has completely stopped showing up in sys-usb. It still shows up in its terminal, but it no longer appears in the device list. People, who have Huawei E3372 USB stick, could you confirm, please, that you also have problems with the compatibility of this stick with the latest versions of Linux distros? In particular: Fedora 43 and Debian 13. Or maybe this issue caused by the Qubes itself? Or maybe my stick is broken? Strange if so, because during almost month when I fixed the consequences of installing Qubes 4.3 with an external bootloader, the stick was just lying there and no one touched it. It worked well before and the last time when I used it with Qubes 4.2. Then the problems started already with the first plugging in to the Qubes 4.3.
Just tried the stick in Tails, moreover - tried Tails in both computers - and it works fine! From the very start! The fact that Tails now is based on Debian 13 and that the stick started working from the very start, and each time I plugged it later, prooves that the problem is not in the new distros compatibility issues but in Qubes 4.3 itself. I tried different kernels, different templates based system qubes. Nothing helps. It looked more like it somehow depends more on boot session than on something else, because during all this problem’s period if stick worked sometimes - it started working on its own. Not because of any edits, but simply from the very beginning of the session. And at the beginning of another session, just like that, for no apparent reason, it stopped working. So now I would ask you to perceive this thread as a bug report. With all my efforts over the course of a month, I finally determined that the problem was localized specifically in Qubes 4.3. I would like to ask someone from the Qubes team to tell me where and how I can get the necessary logs so that I can provide them here and help the Qubes team determine the cause of this bug and, if possible, fix it.
I am not sure if this is going to help firmware bug, but can you try with latest-kernel?
Install the kernel, on Global Config, change the kernel to the newer one. Reboot your system and try again. Rebooting sys-usb might be enough, but reboot the system in any case. Share the journal. If it doesn’t help, please open a bug report on github linking to this forum thread and posting this kernel message.
You don’t believe me but I just was going to do exactly the same today but that qubes boot issue prevented me from doing this and I spent the whole day on it.
Does it mean that I could install kernel without network connection? Because without the stick I basically don’t have it on this Qubes. I was going to make the stick to work in hilink mode first. But if it doesn’t need Internet for the kernel installation then it’s cool.
At the moment I re-installed Qubes 4.3. And what can I say… Immediately after installing the stick worked. First few times it didn’t appear in sys-usb devices list but on third or fourth time it started working. Could connect to the web. And later, I had to plug it several times and it worked. First what I did was installing latest kernel pack (6.17.9-1.fc41 kernel was installed) and downloaded Debian 12 template (to try based on it system qubes if the stick issue returns). Updated both Debian templates for any case. During all this time I unplugged and plugged stick back several times and all these times stick worked. BUT as soon as I updated dom0 - stick immediately stopped working and the issue returned back… After this nothing helps. I tried all kernels in qubes/templates (there are three kernels: 6.12.59-1.fc41, 6.12.64.-1.fc41, 6.17.9-1.fc41 after dom0 update). I recreated the primary conditions that were before the dom0 update: set 6.12.59-1.fc41 kernel everywhere (this was the only kernel in fresh installed Qubes 4.3), including Global Configs. I even booted Qubes from this kernel. Then, when this didn’t help, I created the Debian 12 based system qubes and replaced old system qubes with them (because in Qubes 4.2, where was Debian 12, stick always worked). Left 6.12.59-1.fc41 as kernel everywhere. Booted from it again. When even this didn’t help I started changing kernels - with no success… MOTHER F+++ING CONCLUSION: In Qubes 4.3 itself, for the most part, everything can be said to work. And it turned out that the real cause that f ed everything up all this time was the dom0 update. There is something in it that ruins everything related to the USB stick Huawei E3372 (and maybe not only this). I REALLY do hope that the devs will fix this bug in some upcomming patch. Because I already broke my head trying to figure out what else I can try to make it work.
P.S. Can someone explain me, what means “provided by qube” option in kernel settings of every qube? Once I thought I understand this but now I’m not sure. Because this option is even in templates. So what qube is meant there? What qube and what it can provide to the template (not mentioning the app qube)? I remember that when the issue first appeared I somehow managed to fix it by setting this option somewhere (don’t remember where and in what quantity). But if this really helped - this helped only once. Tried it later with no success. Maybe because I really didn’t understand this option, so couldn’t use it correctly the next time. I was told that it seems making a qube use kernel provided from template itself, instead of the kernel provided by Qubes/dom0. And as if such a kernel could be more complete compared to the Qubes kernel. If so then why templates themselves have “provided by qube” option too? Where do they get the kernel in this case?
“Provided by qube” kernel uses kernel that was downloaded and installed in template (upstream, not patched and compiled by qubes dev).
You can use other kernels from dom0 (I’ve tested mirage and now I have mirage kernel on the list aside of dom0 kernels).
But kernels provided by qubes don’t work nice with xen (xen errors during start) so it will block your template based qubes from start. It might be viable for standalone, especially those not based on any qube template.
I hear about Mirage kernel for the first time. Made a little search and AI says that this kernel should be built inside Qubes, needs additional packages, and new firewall vm to be created, specifically designed for the Mirage kernel. Search results provide only github with some Mirage-firewall and nothing about the Mirage kernel as something separate from the Mirage firewall. Despite the fact that I even don’t know if it can help me.
While searched found out that it’s possible to downrgade packages in dom0. Is it possible to downgrade a kernel? Since 6.12.59-1.fc41 kernel worked with the stick while Qubes was fresh installed and stopped after dom0 update, maybe this means that this kernel was updated and this broke something that worked well in the kernel? So if I could downgrade it to the previous state then it would work with the stick again.
Also this documentation says that I can install any kernel in Debian template. But what’s about now? Do I understand correctly that by default Debian templates do not have any of their own ( distribution) kernels? I have an idea to find which kernel version is required for my stick model to work and install it in the Debian template. Even if Qubes later prevents it from starting, I can switch the template to the needed kernel already after booting and only then use it for work with the stick. Can it work?
Mirage kernel was an example since installing mirage-firewall means compiling mirage kernel in dom0.
I’ve tried qube provided kernel in sys-vpn that’s on fedora minimal template and it wouldn’t start. Dunno about debian - deleted any template. whonix uses fc37 kernel and choosing qube provided give error:
Start failed: internal error: libxenlight failed to create new domain 'sys-whonix', see /var/log/libvirt/libxl/libxl-driver.log for details
You should not compile any mirage unikernel in dom0, and you don’t even need to compile it in a Qubes system (e.g. we do compile unikernels with github actions, and Qubes is not involved at all here), you can download pre-built image with reproducible hashsums.
But in order to use a mirage unikernel you currently must copy it to dom0 from another AppVM, either manually or with an automated script.
The currently most used mirage unikernel is qubes-mirage-firewall, but I also use others for DNSHole (daily basis) or OpenVPN (from time to time).
The fact is that I don’t really understand them. What does he do to get this line -rw-r--r-- 1 root root 42K Apr 2 15:46 41-huawei_e3372.rules? What command does he use to get it? As I understand from -rw-r--r this line shows what rights created file has. The fact is that I didn’t do anything to change its rights. If this was necessary then maybe this is the reason why this file didn’t affect anything in the system and didn’t change the stick’s mode? How exactly should look the command in Debian 12 template to provide the necessary rights to the file (considering that all this will be done not in a bare Debian 12, but in Qubes 4.3)?
The text below is the repost of my post from Github
“I made decision to re-install the system because I need working stick and it works only on fresh installed version, before dom0 updates. My idea is that I won’t install updates to dom0 until I see that the bug is fixed. I’ll make dom0 and templates backup before any updates. If I see that the bug is listed as fixed I’ll install updates to dom0. If it turns out that doesn’t work, I’ll restore from the backup. And I’ll do this every time until the bug is actually fixed. But the main reason why I’m here is to show the screenshot below. As soon as the stick started working again I made another lsusb -tv output screenshot to see if there will be any difference with the screenshot of the non-working state of the stick. And there were indeed differences. Take a look at the screenshot. It was made during the stick’s working state, before any updates in the system. Hope this can help somehow”.
ed everything up all this time was the dom0 update. There is something in it that ruins everything related to the USB stick Huawei E3372 (and maybe not only this). I REALLY do hope that the devs will fix this bug in some upcomming patch. 
