I know how awkward that title is and I apologize.
OS: Home Assistant 11.2
Core: 2023.12.3
Computer: Raspberry Pi 4 Model B Rev 1.5
Explanation: I run a set of data collection scripts on my home network and one of the pieces of data is getting the computer model. In all my other SBCs, the below symlink gets that data.
Symlink: /proc/device-tree/model
File Location: /sys/firmware/devicetree/base/model
The symlink is broken and when I went to check the firmware directory, it is completely empty. The last update date for /sys/firmware according to ls -la is December 10 at 2:40 which when I checked my backups, is when core_2023.12.0 installed.
Attached is what should be in the firmware folder on my other Raspberry Pi 4 Model B Rev 1.5 right now.
I did a find from root for either the model file or anything vaguely resembling it and I can’t find it. Anyone else have this problem or is it just happening to me? Or am I missing something?
Full disclosure: I just–and I mean just–got my head wrapped around docker and containers due to installing Proxmox on my server. Right now, my Proxmox server runs a LXC container for docker, and in docker I run Handbrake and MakeMKV images that run the GUIs in a browser or run with command line. They connect to each other through mounting the LXC’s /home/user into both., then added a connection to the remote shares on my other server so I can send them to my media server. Yes, I did have to map all the mountings out first before I started but hey, that’s how I learn.
Long way of saying: I am just now able to start understanding how Home Assistant works–someone said Home Assistant OS was basically really a hypervisor overseeing a lot of containers and now that I use Proxmox, that really helped–but I’m still really unfamiliar with the details.
I installed the full Home Assistant on a dedicated Pi4, so it’s the only thing it does. Until yesterday, the only part I actually interacted with was the data portion, which is where all my files are, where I configure my GUI and script, store addons, etc. The container for this portion runs on Alpine Linux; I can and have and do install/update/change/build packages I need or like to use. in there It’s ephemeral; anything I do outside the data directory (it holds /config, /addons, etc) gets wiped clean on update, so I reinstall them whenever HA does an update .
When I run my data collection scripts on my Home Assistant SBC, they take their information from the container aka Alpine Linux., including saying my OS was Alpine. All of this worked correctly up until–according to the directory dates, December 10th at 2:40 AM when the /sys/firmware was last updated and everything in it vanished, breaking the symlink to /proc/device-tree/model. This also updated the container OS to Alpine 3.19.0. Data collection runs hourly; one of my Pis ssh’s into each computer to run four data collection scripts and updates a browser page I run off apache, so I can check current presence and network status and also check the OS/hardware/running services of all my computers from the browser (the services script doesn’t work on Alpine yet; different structure). I didn’t notice until recently because work got super busy, so I only verified availability and network status regularly.
These are the packages I install or switch to an updated/different version the Alpine container to help with this or just have fun: -figlet (it’s just cute ASCII art for an ssh banner), -iproute2 (network info, when updated has option to store network info in a variable as a json),
These are the ones I use for data collection that are already installed:
These are the files I access for data collection:
Until this month, all of those files were accessible both before I do the package updates and after. The only one affected was maybe /proc/uptime by the uptime update to get more options. Again: I’ve been running these scripts or versions of them for well over a year and I test individually on each SBC before adding them to my data collection scripts to run remotely; all of these worked on every computer, including whatever SBC was running Home Assistant. (Odroid N2+ until it died a few months ago) And all of them work right now–except /proc/device-tree/model on my Home Assistant SBC. The only way I can get model info is to add an extra ssh to Home Assistant itself as root and grab the data off that file (and while I"m there, get the OS data for Home Assistant instead of Alpine), save it to my shell script directory in my data container, and have the my script process that file for my data after it gets the rest from the container.
That’s why I’m weirded out; this is one of the things that is the same on every single Linux OS I’ve used and on Alpine, so why on earth would this one thing change?
This could conceivably be an Alpine issue; I downloaded Alpine 3.19.0 to run in Proxmox when I get a chance, and I kind of hope that it’s a deliberate change in Alpine, because otherwise, I can’t imagine why on earth the HA team would alter Alpine to break that symlink. Or they could be templating Alpine for the container each time and this time it accidentally broke. The entire thing is just so weird. Or maybe–though not likely–a bug in Alpine 3.19.0, but I doubt it; I can’t possibly be the first to notice, it was released at least three weeks ago and I googled a lot.
I’m honestly not sure it affects anything at all, but it bothers me so here we are. Though granted, it did make me finally get off my ass and figure out how to login as root into HA as well as do a badly needed refactor of my main data collection script (the one that does the ssh’ing) as well as clean and refactor my computer information scripts, so maybe it was destiny.
I run HASS on an amd64 virtual machine, so it’s possible there are difference between our devices. However, because both seem to be based on maintaining a set of Docker containers, I don’t think there’s much difference (other than the ARM specific virtual devicetree directory not existing on my machine).
If you run an up-to-date version of Docker, you should not have access to /sys/firmware by default. That’s a decision the Docker folks made because that directory contains things like bootloader configuration/information and Windows license keys.
On the Linux OS itself, there shouldn’t be any such restriction. If you can’t access these files outside of Docker, there’s something wrong, probably with your kernel. You said ssh’ing into the machine works as a workaround, so I don’t think this is the case.
What seems more likely to me, is that your current host OS comes with a recent version of Docker that shields the /sys/firmware directory from Docker containers by default. If the Docker version didn’t change, then I think what you’re seeing is what you should’ve been seeing all along.
The only way I can think of that Home Assistant could have changed this behaviour, is that it could’ve changed the configuration of the default containers. As you can read in the github issue I linked, there’s a way to tell Docker to basically disable security features (run in privileged more and allow access to all of sysfs). It’s possible that Home Assistant used to configure Docker in this manner, but no longer does.
Running a full application in privileged mode is normally a hack to work around other problems (i.e. not exposing the proper device paths with proper access controls and just allowing the container to do whatever and probably break out of isolation), so it could be that they enabled these workarounds to work around some unrelated issue. If the unrelated issue was fixed, and the containers no longer needed to run privileged, they could’ve disabled the workaround and broken your access to sysfs in the process.
The small Home Assistant supervisor daemon that acts as a sort of “”“hypervisor”“” (which handles updates of the other containers) does need to run in privileged mode; it needs to control Docker, so of course Docker can’t be configured to stop it from doing that. It’s a rather small service, though. However, I have noticed that on some installs, the supervisor daemon seems to lose its privileged mode due to a bug. It’s possible that this is bug also affected your seemingly privileged main container. If that’s the case, running the installation script again should fix the issue.
I googled all the terms I could think of that could affect your problem with “home assistant” but when it comes to devicetree access, only your Lemmy post seems to come up. I think your data collection setup may be rather unique among HASS users, so perhaps you really are the only one affected by this, or at least the only one who’s written a post about it.
In my tests, none of the normal (unprivileged) Docker containers I’m running on my servers could access /sys/firmware. I tested this under Ubuntu, Debian, Manjaro, and Arch hosts. Accessing various firmware related virtual files worked fine outside Docker, of course, but inside Docker, /sys/firmware is empty. I don’t have an Alpine install but I’d be surprised if that’d handle this directory any different.
Normally, you could work around the limitations here by just marking your home assistant container as privileged and ignoring the potential security implications, as you may have unknowingly been doing. I think that’s not exactly an unacceptable risk for a dedicated Raspberry Pi (though it would be bad to default to this configuration). Unfortunately, Home Assistant’s supervisor recreates containers for you during updates, so marking the containers as privileged can be more of a pain than you’d expect. You can try looking into ways to customise the Home Assistant Docker configuration to grant these permissions, perhaps there’s a config file I’m not aware of that you can use to make sure the supervisor recreates the containers with the appropriate configuration. As stupid as it may be, I would personally look towards alternative solutions, like your SSH workaround; perhaps your script can check for an empty /sys/firmware directory and apply the workaround from there?
tl;dr: it’s a kernel bug if you’re not running your data collecting script inside Docker, otherwise it could be a home assistant bug/update that caused the change, but as of a year or two ago you’re not supposed to be able to read these files from within a Docker container anyway.
For what it’s worth, I disagree with Docker’s blanket block of /sys/firmware and I hope the issue that’s open about this change will be resolved. You don’t want to leak Windows keys, but there should be an obvious way to expose the board info without disabling basic container security…
You know, I didn’t think of that. I’ve never run an OS in docker; all I tested my data collection scripts on were my regular VM’s a few times just for fun. And for that matter, most LXC containers I run in Proxmox are privileged to get around restrictions (still haven’t found a way for LXC’s to let me compile different architectures, though. HA may have updated their docker to current, which would explain why it happened so suddenly.
And yes, for now, I’ll just do root login to grab the information; it’s technically more accurate, I am just knee-jerk distrustful of using root to the point until Proxmox and this last year, I almost forgot it existed unless there’s a very weird linux problem I need it for. Thanks for this information, though; I’ve only just started seriously working with LXC and docker containers, so that’s not an approach I woudl have considered.