bookworm ignores blacklisting of hid_logitech_dj about linux

[XECDesign]

I think that is the solution. If you looks up how to blacklist modules, the instructions should tell you that that's a necessary step.

Like here - https://wiki.debian.org/KernelModuleBlacklisting

[lurch]

@pelwell / @popcornmix Should this issue be moved to our Linux repo?

[pelwell]

It's working for me:

$ modprobe --show-config  | grep black
blacklist 8192cu
blacklist arkfb
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist cirrusfb
blacklist cyber2000fb
blacklist kyrofb
blacklist matroxfb_base
blacklist mb862xxfb
blacklist neofb
blacklist pm2fb
blacklist pm3fb
blacklist s3fb
blacklist savagefb
blacklist sisfb
blacklist tdfxfb
blacklist tridentfb
blacklist vt8623fb
blacklist hid_logitech_dj

$ sudo dmesg -W &
# < plug in dongle >
[   38.569368] usb 1-2: new full-speed USB device number 2 using xhci-hcd
[   38.720430] usb 1-2: New USB device found, idVendor=046d, idProduct=c539, bcdDevice=39.06
[   38.720441] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   38.720445] usb 1-2: Product: USB Receiver
[   38.720449] usb 1-2: Manufacturer: Logitech
[   38.745291] input: Logitech USB Receiver as /devices/platform/axi/1000120000.pcie/1f00200000.usb/xhci-hcd.0/usb1/1-2/1-2:1.0/0003:046D:C539.0001/input/input3
[   38.801782] hid-generic 0003:046D:C539.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-xhci-hcd.0-2/input0
[   38.824030] input: Logitech USB Receiver Mouse as /devices/platform/axi/1000120000.pcie/1f00200000.usb/xhci-hcd.0/usb1/1-2/1-2:1.1/0003:046D:C539.0002/input/input4
[   38.824198] input: Logitech USB Receiver Consumer Control as /devices/platform/axi/1000120000.pcie/1f00200000.usb/xhci-hcd.0/usb1/1-2/1-2:1.1/0003:046D:C539.0002/input/input5
[   38.881479] input: Logitech USB Receiver System Control as /devices/platform/axi/1000120000.pcie/1f00200000.usb/xhci-hcd.0/usb1/1-2/1-2:1.1/0003:046D:C539.0002/input/input6
[   38.881630] hid-generic 0003:046D:C539.0002: input,hiddev96,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-xhci-hcd.0-2/input1
[   38.885711] hid-generic 0003:046D:C539.0003: hiddev97,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-xhci-hcd.0-2/input2
$ lsmod | grep log
$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 046d:c539 Logitech, Inc. Lightspeed Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Try this:

1. Reboot without the dongle plugged in.
2. Remove raspi-blacklist.conf, or comment out the line with a #.
3. Run sudo udevadm monitor -k -p | tee no_blacklist.txt, and leave it running.
4. Plug in the dongle.
5. When the output stops, hit Ctrl-C.
6. Remove the dongle and reboot again.
7. Restore raspi-blacklist.conf, or uncomment the line.
8. Run sudo udevadm monitor -k -p | tee blacklist.txt, and leave it running.
9. Plug in the dongle.
10. When the output stops, hit Ctrl-C.

Upload no_blacklist.txt and blacklist.txt.

[steinhelten]

OK. Two things - First, by "dongle" I assume you meant the cable to the KVM switch. If that's not right, I'll have to do this over. Second, I did this precisely in the order given above, though it seemed a bit odd to me. I would have thought you'd have wanted me to restore the blacklist file before rebooting, but I did it as you requested, and rebooted before restoring the blacklist file.
no_blacklist.txt
blacklist.txt

[steinhelten]

If I'm interpretting the contents of those files correctly, it would appear that the blacklist "worked" in that it prevented the driver from being loaded when the KVM switch is connected after booting, and my concerns about rebooting before restoring the file were unfounded. So, what's the difference between it being connected at boot time, or after boot time?

[XECDesign]

I can't verify right now, but I have a suspicion it might be initramfs shenanigans.

Does running sudo update-initramfs -u fix it?

[steinhelten]

OK! That worked! I booted with the KVM switch attached, and it came up with the keyboard and mouse (trackpad) working, and the driver not loaded. So... what's the long-term solution?

[pelwell]

Thanks, @XECDesign.

[steinhelten]

Interesting. I don't remember having to do that under buster. Can you help walk me though the steps for preparing a new system, then? This is unclear to me, because if I just copy an image onto a new SD card, and boot it, I'm stuck - I can't use the keyboad and mouse, and I can't ssh in because that's off by default. To get around that this time, I physically disconnected the keyboard from the KVM switch and plugged it in directly to the RPi. Obviously, I'd prefer to not have to do that each time I create a new system image.

1. image a new SD card
2. mount the SD card (I use an RPI to copy the image, so this should be easy), say, on /mnt
3. echo "blacklist hid_logitech_dj" > /mnt/etc/modprobe.d/raspi-blacklist.conf
4. then... how do I do a "non-native" initramfs? OR what's next?

[XECDesign]

It wasn't a thing under buster or bullseye because we didn't use initramfs then. It's something we just added with bookworm.

Modules can also be blacklisted in cmdline.txt with module_blacklist=whatever. I haven't tried it, so I don't know if it works. If it does, does that solve your problem?

[steinhelten]

It just might! I did the following:

1. commented out the blacklist line in /etc/modprobe.d/raspi-blacklist.conf
2. rebooted
3. confirmed that a) the module was loaded and b) the keyboard and mouse did not work
4. Executed the following:

#!/bin/sh
ed /boot/cmdline.txt <<EOF
s/$/ module_blacklist=hid_logitech_dj/
wq
EOF

5. rebooted
6. Verified that the module was NOT loaded, and that the keyboard and mouse worked, which they did

Now, curiously, hid_logitech_dj does NOT appear in the blacklist using "modprobe --showconfig", which might be confusing under some circumstances. But, by including a version of the above shell script (including /mnt in the path to cmdline.txt) in my "standup" script, I think I can successfully create viable images.

Thanks!

[XECDesign]

Heads up that it should be /boot/firmware/cmdline.txt (another bookworm change).

/boot/cmdline.txt is a symlink, so it may work, but some tools (like sed) will overwrite the symlink with an actual file. I'm guessing in this case it worked because ed doesn't do that, or you mounted /boot manually.

[steinhelten]

Yikes! It appears that ed was well-behaved in this respect, because I checked and the symlink was preserved.
Since the symlink is a relative and not an absolute reference, it would probably work in the non-native case (having it mounted on /mnt), but I'll change my script to use /mnt/boot/firmware/cmdline.txt just to be on the safe side.

Again, thank you.

[XECDesign]

No worries, glad it's sorted now.

[lurch]

and I can't ssh in because that's off by default.

It's easy to enable SSH using Raspberry Pi Imager.

[steinhelten]

Well, while that's a great suggestion in general, I happen to be running FreeBSD on the Pi that I currently use to make the Raspberry Pi OS SD images.

[lurch]

Ah! In that case, see https://www.raspberrypi.com/documentation/computers/configuration.html#remote-access