Debian-12 with debian kernel -- can't network

User Support
1

(Yes I searched. There were hits that weren’t quite this.)

Decided to create debian-12-minimal-based templates where the kernel would be built into the template (and appropriate for debian-12).

Sys-net of course is an HVM, and for that, one should set the kernel to “provided by qube”.

When I do so, however, I’m unable to connect to the network; I end up having to switch to the dom0-provided template in just that qube.

I’ve regenerated almost all VMs this way, networking doesn’t work and veracrypt decypting has a glitch I’ll ask about in another post. Everything else does work so far as I know, including sys-usb (which is also an HVM). So I don’t think I messed up installing the kernel itself.

What am I missing? How can I figure out why the network won’t work.

2

What’s your network devices?
Maybe you have some custom driver in your template and you didn’t rebuild it for kernel provided by qube?

1 Like
3

It actually works the other way around. I cloned debian-12-minimal, added the kernel to the clone, then build everything, including sys-net off of clones of that “debian-12-minimal-kernel” template. (I have scores of VMs based ultimately on debian-12-minimal, and all but three of them work with the Debian kernel [two of those three do networking]. I’ve been busy since you taught me how to install it in the other thread.)

I can (and did) switch my sys-net (with debian kernel) to use the dom0-provided (and fedora-based) kernel, and it works with that kernel. So I have a workaround, but it bugs me my networking doesn’t get along with Debian kernels.

That makes me fairly confident that if there IS a missing piece of software, it’s something that’s only needed by Debian kernels, rather than Fedora ones. Similarly for configuration options and so on. Or maybe there is a special “Debian” version of some of the Qubes packages that I don’t know about? Or maybe there needs to be such a version?

4

Which kernel version provided by dom0 is working?
Which kernel version provided by qube is not working?
What’s your network device model (VID:PID)?
Check the journalctl in the sys-net to see if there are any errors related to your devices initialization.

5

dom0 kernels: both 6.1.75-1.fc37 and 6.6.48-1.fc37 worked. I’m currently using the former. (Recall that I couldn’t get zfs to install on a qube based on 6.6; which is what started this whole journey. zfs doesn’t get installed on sys-net so until I was convinced that I should just 6.1 everywhere [one step before trying to use debian templates, which is “we are here”], i was using 6.6 on it.)

now of course it’s pvgrub2.pvh on all pvhs (which as I understand it allows me to use the “provided by qube” template), and “provided by qube” for HVMs like sys-net. None of which answers your question; the kernel being referenced is, according to hostnamectl, Linux 6.1.0-25-amd64

Not sure how to answer the third question. qvm-device pci gives “dom0:58_00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-lm” used by sys-net-ether.

There’s nothing obviously relating to networking in the journalctl since the last boot of sys-net-ether. But it fails to activate org.freedesktop.systemd1 twice (once when requested by :1.0 and again when requested by :1.1). There’s also an error concerning a non-existent cvt comand in /etc/qubes-rpc/qubes.SetMonitorLayout. Trying to ping my NAS returns “ping: connect: Network is unreachable” which if memory serves is the error I get trying to ping google.com on sys-net-wifi when I use the built in kernel on it.

shutting down, setting the kernel to 6.6.48-1.fc37 and restarting, hostnamectl confirms I am now using 6.6.48-1.qubes.fc73.x86_64. Pinging my NAS works. Journalctl shows those same errors (no surprise, they look totally unrelated).

By the way:

Up to now I’ve been simplifying my situation. I actually have two sys-nets, a sys-net-ether and a sys-net-wifi, separately handling the two networks. (Neither of them work with the qube-supplied kernel.) So I am using sys-net-ether for this troubleshooting, because sys-net-wifi handles my internet connection. I can bork sys-net-ether all I want without messing up my internet, so that’s what I am doing. (I didn’t think this detail mattered, but just in case…)

If there’s anything else you need, please let me know.

By the way, since this is a disposable sys-net-ether, should it not be wiping out journalctl every time I restart it? It does not; I have to scroll down well over a thousand lines to get to “this” run of sys-net-ether.

Another note: I tried running the disposable template as well, just in case this is somehow related to being a disposable; it doesn’t work either.–NEVERMIND, test defective, device not assigned. Will re-run.

6

Run this command in dom0:

lspci -nn | grep I225

What’s the VID:PID at the end in the square brackets [XXXX:XXXX]?

In sys-net-ether do you see your Ethernet controller interface in this command output?

ip a

I guess it’s the log from template.

7

lspci -nn | grep I225 yields [8086:15f2] (rev 03)

ip a was initially confusing to me. But ultimately, it cracked the case. I ran it with both kernels.

With kernel set to linux 6.6.48-1.qubes.f37.x86_64: ping works.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 48:21:0b:26:32:39 brd ff:ff:ff:ff:ff:ff
    altname enp0s6
    inet 192.168.61.6/24 brd 192.168.61.255 scope global enp0s6
       valid_lft forever preferred_lft forever
    inet6 fe80::4a21:bff:fe26:3239/64 scope link 
       valid_lft forever preferred_lft forever

If my controller is somehow absent from the in-qube kernel, but present here, I should see it. I don’t see anything here that is obviously my controller.

But with kernel set to 6.1.0-25-amd64 (the debian kernel as installed in my template), I get:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 48:21:0b:26:32:39 brd ff:ff:ff:ff:ff:ff
    altname enp0s5

Much shorter. The difference is nothing after altname enp0s6 in the first case is present here.

ALSO different, though is that in THIS dump it’s enp0s5 NOT enp0s6.

So if I go into my template and change /etc/network/interfaces to reference enp0s5, shut down the template and restart sys-net-ether…IT WORKS!

I strongly suspect something similar is at play with sys-net-wifi, but of course I’d have to go offline to test it.

The difficulty I now face is deciding what to do about this. The kernel I use affects the proper contents of this file! So, do I just go into the relevant salt .sls file and hard code it to enp0s5? Or do I try to make it smart and adjust depending on which template? Can I do that at run time (e.g., by altering the file from my .bashrc after running hostnamectl), or must I make my decision when running the salt state? The former would let me change kernels without reconfiguring, the latter would require re-creating the template (or starting it up and editing a file, which is inelegant) when I change the kernel.

But that’s a problem I know how to work. Hardware level glitches typically mystify me, and your questions helped me find the immediate cause of the problem.

Thank You!

8

If you use NetworkManager instead of /etc/network/interfaces then you won’t need to hardcorde the network interface name, but with /etc/network/interfaces I don’t know how to handle the case with different interface names.

9

Well the irony runs richly here. In sys-net-wifi I am actually using Network Manager. But I must be doing something wrong, because I have to go into /etc/NetworkMaanger/system-connections/<name of my wifi>.nmconnection and edit wls6f0 to wls5f0.

Having done that I’m able to use that device with the “provided by qube” kernel as well. In fact, I am doing so right now.

10

You can just remove the interface-name=X from your NetworkManager config file and it’ll work.

11

Confirmed that that works! Thanks again!

Next I figure out how to translate what I have over on the the ethernet side to use NetworkManager.