Open asdfghjkai opened 3 years ago
The modprobe
binary used in HAOS is not from the busybox package but from the kmod package (BR2_PACKAGE_KMOD
). Afaict this gets selected implicitly somehow. This is the tool which comes from kernel.org and I think blacklist is a feature enabled by default.
Are you sure you blacklist the module correctly? From what I can tell the module filename is dvb-usb-rtl28xxu.ko
, so I'd guess you need to use blacklist dvb-usb-rtl28xxu
to blacklist that module. Although, I read on the Arch Linux Wiki that -
and _
can be used interchangeably, so I guess its not that.
Maybe another module is depending on it, which causes it to get loaded? There is a work around using a install
instruction documented on the Arch Linux wiki: https://wiki.archlinux.org/title/Kernel_module#Blacklisting
Thanks for letting me know I was going down the rabbit hole! I think the blacklist 'should' have worked, given it looks for the name of the loaded module (Which uses underscores versus the filename (Which likely uses hyphens to stand out) - also to stick with convention.
Let me take a look. I think I found the module it that depends on it (And blocked that also) but looks like no others. I'll try the arch work around and report back
`
blacklist dvb_usb_rtl28xxu blacklist dvb_usb_v2#
dvb_usb_rtl28xxu 32768 1 dvb_usb_v2 32768 1 dvb_usb_rtl28xxu
`
Cheers @agners
Apologes, still no good. Still loading?!? Restarted betweenb
cat /etc/modprobe.d/blacklist-dvb-2.conf
install dvb_usb_rtl28xxu /bin/true
lsmod | grep dvb
dvb_usb_rtl28xxu 32768 1
dvb_usb_v2 32768 1 dvb_usb_rtl28xxu
ls /dev | grep dvb
dvb
@asdfghjkai how do you access the OS shell?
@agners One of two methods
In this case, not using the SSH addon because I wanted to access the underlying OS before it passes anything through to the HA container.
@asdfghjkai this Reddit post lists multiple blacklist
lines, maybe that helps?
blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830
Maybe journalctl
is saying something?
journalctl -b 1 | grep modprobe
Can you also try the following: Have the blacklist setup the way you think it should work. Plug out the DVB tuner. Boot Home Assistant completely, make sure the modules are not loaded, plug-in the DVB tuner, check if the modules are loaded now (it might be that the blacklist directory gets mounted too late, bascially modprobe loading the modules too early).
@agners Just have that ago, same symptoms
cat /etc/modprobe.d/blacklist-dvb-2.conf blacklist dvb_usb_rtl28xxu blacklist rtl2832 blacklist rtl2830
dvb_usb_rtl28xxu 32768 1 dvb_usb_v2 32768 1 dvb_usb_rtl28xxu
Also nothing from journalctl :(
Just tried the second method Restarted not connected, lsmod | grep dvb returns nothing, good, no sign of it in /dev also. Good so far
Plug in the device and it doesn't load any drivers. This I think will suffice for now, the integration is able to sense the raw device and work with it. Still not quite right, but I think it will have to do
Plug in the device and it doesn't load any drivers. This I think will suffice for now, the integration is able to sense the raw device and work with it. Still not quite right, but I think it will have to do
So it did not load the drivers correct?
Hm, that means that our mount is too late for blacklist to work. I'll have a closer look at that, but it will take me some time to debug.
Correct. Didn’t load anything so instead the integration is just using the raw usb device (not even mapped to a serial device, but hey it works)
Let me know if I can help out at all, test builds or so on and I’ll let you know
Indeed it seems that blacklist module is currently not working. The reason is that the /etc/modprobe.d
mount point is loaded after systemd-udevd
, hence the module is loaded before systemd-udevd
has a chance to read the config files from /etc/modprobe.d
. I tried to reverse the start order (start systemd-udevd
after /etc/modprobe.d
is mounted), but that seems not to work. From what I can tell systemd-udevd
is really essential to get anything going in terms of mounting etc. so basically we cannot mount before systemd-udevd
is running, a chicken-egg problem.
From this comment it seems that mount /etc
as part of the regular system boot seems not officially supported by systemd. I'd guess bind mount parts of /etc
is somewhat an edge case.
I think the only proper way to fix this would be to mount /etc
in full (bind mount all sub directories) in a initramfs is probably the proper solution for this. But this would mean a major change for HAOS...
However, there is good news also: There is a work around: You can add module_blacklist=dvb_usb_rtl28xxu
to /mnt/boot/cmdline.txt
, which tells the kernel on a low level to ignore loading a module with that name.
@asdfghjkai can you try this approach?
There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
However, there is good news also: There is a work around: You can add
module_blacklist=dvb_usb_rtl28xxu
to/mnt/boot/cmdline.txt
, which tells the kernel on a low level to ignore loading a module with that name.
That doesn't seem to work. Do you know of any other workarounds?
It does work, see official Linux kernel documentation of module_blacklist
at https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html.
Did you reboot after setting that parameter? Do you have that driver/card in question? Can you share your host logs (dmesg)?
Hardware Environment
Home Assistant OS release:
System Health
Home Assistant Community Store
GitHub API | ok -- | -- Github API Calls Remaining | 4923 Installed Version | 1.14.1 Stage | running Available Repositories | 953 Installed Repositories | 11Home Assistant Cloud
logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | okHome Assistant Supervisor
host_os | Home Assistant OS 6.3 -- | -- update_channel | stable supervisor_version | supervisor-2021.09.0 docker_version | 20.10.7 disk_total | 219.4 GB disk_used | 27.2 GB healthy | true supported | true board | rpi4-64 supervisor_api | ok version_api | ok installed_addons | File editor (5.3.3), Check Home Assistant configuration (3.8.0), AirCast (3.1.1), Samba share (9.5.1), Mosquitto broker (6.0.1), Nextcloud Backup (0.16.2), SSH & Web Terminal (9.0.1), Home Panel (2.2.0), Portainer (2.0.0), zigbee2mqttassistant (0.3.157), Zigbee2mqtt (1.21.1-1), Git pull (7.13.1), MariaDB (2.4.0), Grafana (7.0.2), InfluxDB (4.1.1), Wmbusmeters (W-MBus to MQTT) (0.2.19)Lovelace
dashboards | 3 -- | -- resources | 4 views | 17 mode | storageSupervisor logs:
Journal logs:
Lots of these. I think one of my thermostat's is not playing too well with z2m
Kernel logs:
Description of problem: I'm trying to use a dvb tuner as an SDR to communicate (or listen) to responses from my home water meter. The details do not matter too much, the main issue is that the tuner is (correctly) identified by the OS as a DVB tuner and as such loads the appropriate module. Because I do not want it to do this, I followed the instructions here to add an entry to modprobe.d, to blacklist the kernel module in question. For what it's worth, it's dvb_usb_rtl28xxu.
This upon restart had no effect, and I started digging down towards the os build, and busybox, which has a number of configurations around modprobe here including toggles to enable blacklisting. I confirmed I would need to enable CONFIG_MODPROBE as well as CONFIG_FEATURE_MODPROBE_BLACKLIST which I found within the source here
I built a 6.3 image (at the time) from source using the instructions provided, and with this subtle tweak, and then tested on my RPi - the same symptoms.
Question is, what else needs to be changed, is there anyway to integrate this as part of the standard build, or is the idea bust and I should just purchase a proper radio dongle.
I was hoping the above would provide a solution and I could raise a PR, but unfortunately not. Happy to try alternative options and build from source to confirm/deny if any proposed fixes work.