Qubes 4.3: USB Stick suddenly started plugging-in in sys-usb only in storage mode. Can't install usb_switch because have no other Internet access except USB stick

User Support General
1

Recently I made fresh installation of Qubes 4.3, using this method of installing Qubes with external bootloader. Never had problems with USB Stick on previous version. On 4.3 problems appeared from the very beginning. Yesterday, when I plugged it for the first time, it often didn’t appear in USB devices list. But when appeared it was in hilink mode, as it should. Too bad then was internet shut down so I couldn’t connect to the Internet and update dom0, download all needed updates, drivers. Today stick connects to sys-usb (disposable) only in storage mode. Often connects and immidiatley disconnects from sys-usb or just doesn’t appear there from the very begginning. I have no idea why this happens. Did nothing wrong with stick and yesterday dettached it from sys-net before unplugging, so it shouldn’t to be brocken or corrupted.
When I try to attach it to any qube it gives the same error message in notifications:

Attaching device USB_Storage:Huawei Technologies Co., Ltd. E353/E3131 (Mass storage mode) to sys-net failed. Error:QubesDaemonAccessError - Got empty response from qubesd. See journalctl in dom0 for details.

When I try journalctl it shows this log:

янв 25 07:36:53 localhost kernel: Linux version 6.12.59-1.qubes.fc41.x86_64 (mockbuild@83523eb769ad463199935c0aecf3b97e) (gcc (GCC) 14.3.1 20251022 (Red Hat 14.3.1-4), GNU ld>
янв 25 07:36:53 localhost kernel: Command line: placeholder root=UUID=ff4f01cf-63b0-479a-934c-214bf7f17c09 ro rootflags=subvol=root rd.driver.pre=btrfs plymouth.ignore-serial>
янв 25 07:36:53 localhost kernel: [Firmware Bug]: TSC doesn't count with P0 frequency!
янв 25 07:36:53 localhost kernel: initrd moved from [mem 0x04000000-0x0f91a62f] to [mem 0x1011d000-0x1ba3762f]
янв 25 07:36:53 localhost kernel: Released 0 page(s)
янв 25 07:36:53 localhost kernel: BIOS-provided physical RAM map:
янв 25 07:36:53 localhost kernel: Xen: [mem 0x0000000000000000-0x000000000007ffff] usable
янв 25 07:36:53 localhost kernel: Xen: [mem 0x0000000000080000-0x00000000000fffff] reserved
янв 25 07:36:53 localhost kernel: Xen: [mem 0x0000000000100000-0x0000000009eeffff] usable
янв 25 07:36:53 localhost kernel: Xen: [mem 0x0000000009ef0000-0x0000000009ffffff] reserved
янв 25 07:36:53 localhost kernel: Xen: [mem 0x000000000a000000-0x000000000a1fffff] usable
янв 25 07:36:53 localhost kernel: Xen: [mem 0x000000000a200000-0x000000000a20efff] ACPI NVS
янв 25 07:36:53 localhost kernel: Xen: [mem 0x000000000a20f000-0x00000000b5883fff] usable
янв 25 07:36:53 localhost kernel: Xen: [mem 0x00000000b5884000-0x00000000b59dafff] reserved
янв 25 07:36:53 localhost kernel: Xen: [mem 0x00000000b59db000-0x00000000b5a4efff] ACPI data
янв 25 07:36:53 localhost kernel: Xen: [mem 0x00000000b5a4f000-0x00000000b7141fff] ACPI NVS
янв 25 07:36:53 localhost kernel: Xen: [mem 0x00000000b7142000-0x00000000bcbfdfff] reserved
янв 25 07:36:53 localhost kernel: Xen: [mem 0x00000000bcbfe000-0x00000000bdffffff] usable
янв 25 07:36:53 localhost kernel: Xen: [mem 0x00000000be000000-0x00000000bfffffff] reserved
янв 25 07:36:53 localhost kernel: Xen: [mem 0x00000000f0000000-0x00000000f7ffffff] reserved
янв 25 07:36:53 localhost kernel: Xen: [mem 0x00000000fd000000-0x00000000fdffffff] reserved
янв 25 07:36:53 localhost kernel: Xen: [mem 0x00000000fe700000-0x00000000fe700fff] reserved
янв 25 07:36:53 localhost kernel: Xen: [mem 0x00000000feb80000-0x00000000fec01fff] reserved

When I try lsusb in sys-usb, stick always is there (even when it’s absent in sys-usb devices list. It has Vendor ID 12db and Product ID 14db. Strange, but it shows wrong model numbers. Real stick is Huawei E3372, but it shows E353/E3131

IMPORTANT DETAIL: when I installed Qubes 4.3 with method I mentioned above, I had the same problems with disk unlocking as people who mentioned it in that manual comments section. Litterally these. I tried re-install Qubes with additional commands provided by @merowing It solved the problem, but can it be the reason why I have now these problems with USB stick? Could these additional commands make Qubes 4.3 installation incorrect and make Qubes 4.3 buggy?

Anyway, I made a search and everywhere usb_switch is suggested for USB stick mode changing. The problem is that I can’t install it in Debian template because USB stick was the only way to have Internet access (they really should make it pre-installed). SO, we’re returning to the question from the thread title: is there a way to switch USB stick mode without usb_switch using? Or maybe you see from provided logs other causes of the problem and therefore - their solution?

P.S. You probably ask yourself how could I then post this post if USB stick is the only Internet access for me? :grin: It’s the only anonimous Internet access for me. To post this post I used other OS and home Internet. I use Qubes only with anonimous Internet connection.

2

I just pulled simcard out from USB stick (in order to prevent its connection to the cell tower with this sim) and plugged stick in other computer with other Qubes 4.3 (upgraded in-place from 4.2 and initially installed by default way), that I use only for home usage, to see if stick will work normally there. But each time I plugged it it even never appeared in sys-usb devices list. Nevertheless it still desplayed in sys-usb terminal via lsusb Desplayed the same way as in previous Qubes: USB_Storage:Huawei Technologies Co., Ltd. E353/E3131 with its IDs. In theory, since sys-usb is disposable in each of these Qubes, every time I plugged stick it installed its drivers again and again. But it always was OK with it before. I used stick about five months and nothing prevented it from working until today.
Does this mean that stick is dead? Or it can appear in sys-usb devices list only when simcard is inserted? I don’t think so. In theory it should appear there no matter sim is in or out. Because it’s still USB device. Correct me if I’m wrong.

3

I tried plugging stick in the second Qubes on the second computer again. First it didn’t appear in the devices list few times, but next time it appeared and was in hilink mode. Then I tried to do the same on initial Qubes and initial computer, where I initially always used it and it either doesn’t appear there initially, or it is still in the same storage mode. So this means that on the one hand there really is something wrong with the stick, but on the other hand it can still work in hilink mode and does not work in it on that particular Qubes and particular computer. Why this could happen? I would understand if sys-usb was persistent. Then I could assume that the reason is the drivers, installed incorrectly or not installed at all. But sys-usb is disposable and I don’t understand why these symptoms recur on this particular OS and this particular computer, especially when sys-usb is disposable and every errors it could have, should not survive the reboot. Or sys-usb really could be the cause? Would reinstalling it help?

4

Both system is updated same? Or one is older and one is newer?

5

Both are Qubes 4.3. But the one is fresh installed. Initially on that computer was installed Qubes 4.2 and I always used the stick there. Then I tried in-place upgrade to 4.3 but it failed because of the way the OS was installed (external bootloader). So I had to perfom the fresh installation of Qubes 4.3 (again with external bootloader but with a little corrected commands). The other Qubes 4.3 (installed on the other computer), that I used to test the stick’s operation, was 4.2 upgraded in-place to 4.3. This OS installed by default way (internal bootloader).

6

On both computers check which driver/kernel module is used.

7

I feel it’s good suggestion. There are really two different kernels. Debian template (I didn’t install Fedora, so my sys-net, sys-firewall and sys-usb based on Debian) of in-place upgraded Qubes, installed default way (let’s call it “Home Qubes”) has default kernel 6.12.63-1.fc41. There are another two kernels: 6.12.59-1.fc41, and 6.12.59-1.fc37. I should add that I’m not sure if I really upgraded Debian to 13 on that Qubes. Don’t know yet how to check it. Probably will go look for the command for this. If it’s still 12 so maybe that’s the reason why kernels different.
Anyway, fresh installed Qubes (let’s call it “work Qubes”), where stick in storage mode, has kernel 6.12.59-1.fc41 and this is the only kernel there is. There is the same set-up: no Fedora, Debian based service qubes. I think that kernels are also the driver modules? In both templates watched kernels in template settings window. Advanced tab.

8

Yeah, I knew it! Found command lsb_release -a and it showed the 12th release. Maybe that’s why kernels are different. I probably missed something in manual. Used this one.

1 Like
9

There is another one option in template kernel list - “provided by qube”. Each of two Qubes have this. What does this option do? Since in “work Qubes’” Debian template is only one kernel then this is the only one alternative option that left.
What could I do with all these kernel variants anyway? By your advice, did you mean to try changing the kernel? Or did you mean setting a specific kernel?

10

You can have kernels provided by template (upstream from distro) or by qubes os from dom0.

Ad what I meant by saying to check kernel modules. Sometime in newest kernels some newest modules/drivers/firmware merge few drivers into one and introduce regressions. Thing that worked with old drivers stop working with new one but as kernel detects newest modules it uses it by default.
So check what drivers/modules are used with both machines and said usb stick and try to force to use same driver that works on machine that don’t works.

[edit] you can also check udev rules for this usb stick

11

As I said, Debian template from “work Qubes” has only one kernel and option “provided by qube”. This is not the same kernel as on “home Qubes” where stick still works somehow. What should happen when I choose option “provided by qube”? I did it and no additional kernels appeared there. All this I see and do in template settings window, in “Advanced” tab. Is it the correct place for configuring actions that you suggest or I look in the wrong place?

12

I believe that I found rules file of the USB stick. I copied its content and post here:

# GPS NMEA port on MU909
SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="ff", ATTRS{bInterfaceSubClass}=="01", ATTRS{bInterfaceProtocol}=="14", SUBSYSTEM=="tty", ENV{ID_MM_PORT_TYPE_GPS}="1"
# GPS NMEA port on MU906e
SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="ff", ATTRS{bInterfaceSubClass}=="06", ATTRS{bInterfaceProtocol}=="14", SUBSYSTEM=="tty", ENV{ID_MM_PORT_TYPE_GPS}="1"

# Only the standard ECM or NCM port can support dial-up with AT NDISDUP through AT port
SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="02", ATTRS{bInterfaceSubClass}=="06", ATTRS{bInterfaceProtocol}=="00", ENV{ID_MM_HUAWEI_NDISDUP_SUPPORTED}="1"
SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="02", ATTRS{bInterfaceSubClass}=="0d", ATTRS{bInterfaceProtocol}=="00", ENV{ID_MM_HUAWEI_NDISDUP_SUPPORTED}="1"

# Airtel branded E3372h-607, using huawei-cdc-ncm driver but with unresponsive cdc-wdm port
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1506", ENV{ID_MM_HUAWEI_NDISDUP_SUPPORTED}="1"

# R215, Disable CPOL based features
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1588", ENV{ID_MM_PREFERRED_NETWORKS_CPOL_DISABLED}="1"

# E226, Disable CPOL based features
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1003", ENV{ID_MM_PREFERRED_NETWORKS_CPOL_DISABLED}="1"

LABEL="mm_huawei_port_types_end"

Wouldn’t say that I fully understand its content but there are few things that catch my attention:

  1. Different product IDs. Don’t know what it should mean.
  2. These two lines:
# R215, Disable CPOL based features
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1588", ENV{ID_MM_PREFERRED_NETWORKS_CPOL_DISABLED}="1"

# E226, Disable CPOL based features
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1003", ENV{ID_MM_PREFERRED_NETWORKS_CPOL_DISABLED}="1"

Anyway, I don’t know yet what these parameters could mean, so for now I can only guess. What can I do with all this?

13

Don’t know. How it’s working on second computer without usb_modeswitch?

14

I finally realized what you meant. The single kernel that work Qubes’ Debian template had was provided by dom0 and “provided by qube” option is the kernel provided by Debian template itself. First I thought otherwise so it stopped me from realizing. I set “provided by qube” and stick started working. Updated all and there appeared another one kernel. Just the same as in my home Qubes. So I set it next. Though stick still appears in devices only from time to time. On both Qubes. I have to insert it 5-6 times until it will finally appear in devices. This didn’t happen at all before upgrading both OSes. I don’t know what to think. Either the stick is broken, or something in Qubes has changed for the worse. Could be a bug.

15

I’m already tired of it! :sob: Today it boots only in storage mode again! This time no kernels options help. Everything returned to the day before yesterday state! I have no idea why this happens again! :sob: I spent the whole day today trying to find out what is written in the udev rules and correcting these rules, but all in vain… Stick begun booting in storage mode even on home Qubes (what didn’t happen before), but still, on home Qubes it can boot sometimes in hilink mode despite the fact that both versions of Qubes use the same kernel (though home Qubes still has Debian 12. This most likely is related). Anyway, there was nothing wrong with the stick when this was 4.2 version. And it started from the very first day of Qubes 4.3. It seems there is really some very big problem with the drivers in this version.
Devs, please, add working drivers for USB stick Huawei E3372! :pray: :sob:

16

And I would like to ask people to take a closer look at the contents of this file. Maybe there is a clue hidden there as to why this is all happening? Maybe need just to correct something there to make it work? :disappointed_relieved:
Or maybe some of you have other ideas?