valiente

I am also in the process of doing this - Main reason for me is that I've now had to enlarge my Docker.img size for a 3rd time - No I do not have misconfigured paths, I just have nearly 80 containers and some are just very large, IPEX-LLM for instance. I also have some containers that are a little large and now I will easily be able to inspect it.

Just FYI, I started having loads of issues since 0.16 betas - Turns out I also made changes to my extra parameters, and I increased my shm sizing but that same time I somehow reduced my tmpfs-size=100000000 which equals to only 100MB - Maybe it was always set to that from a really old Template? But often I would just not get recordings anymore, I now gave it 25GB as I have plenty of RAM to spare and all my issues have disappeared. So just double check your Extra Params

I can confirm that this fix worked for me - @ZappyZap please update the Template to reflect the correct variables so that future downloads aren't affected.

Yes please lets try it!

Here is the result, ran it a couple of times before forcing spin-down, during and after: root@brute:~# sdparm -C sense /dev/sdj /dev/sdj: SEAGATE ST16000NM004J E004 root@brute:~# sdparm -C sense /dev/sdj /dev/sdj: SEAGATE ST16000NM004J E004 root@brute:~# sdparm -C sense /dev/sdj /dev/sdj: SEAGATE ST16000NM004J E004 root@brute:~# sdparm -C sense /dev/sdj /dev/sdj: SEAGATE ST16000NM004J E004 Decode response as sense data: Fixed format, current; Sense key: Not Ready Additional sense: Logical unit not ready, notify (enable spinup) required Field replaceable unit code: 2 root@brute:~# sdparm -C sense /dev/sdj /dev/sdj: SEAGATE ST16000NM004J E004 root@brute:~# sdparm -C sense /dev/sdj /dev/sdj: SEAGATE ST16000NM004J E004 root@brute:~# sdparm -C sense /dev/sdj /dev/sdj: SEAGATE ST16000NM004J E004 Drive is still not down: I was doing this with SDJ drive today as SDI was being used at the moment.

Yeah, I am aware that this is only for SAS - I just meant that this sent me down a rabbit hole to ensure all drives are actually spinning down. Here is the result: root@brute:~# sg_start -rp3 /dev/sdi && sleep 4s && sdparm -C sense /dev/sdi /dev/sdi: SEAGATE ST16000NM004J E004 Decode response as sense data: Fixed format, current; Sense key: Not Ready Additional sense: Logical unit not ready, notify (enable spinup) required Field replaceable unit code: 2 I had cleared my stats, waited 10 minutes then ran the above command - Stats still show 0 reads and 0 writes: But still no spin down:

I noticed a very nice power consumption reduction after installing this Plugin which helped my other drives to spin down. However, I have 3 SAS drives that just don't spin down, either manually or on a schedule - They are just ALWAYS spinning: ST16000NM004J /usr/local/emhttp/plugins/sas-spindown/sas-util: SAS Spindown Utility (v20240218.01) sdc | ST18000NM004J | 1000:005d:1028:1f49 | n/a | sdi | ST16000NM004J | 1000:005d:1028:1f49 | n/a | sdj | ST16000NM004J | 1000:005d:1028:1f49 | n/a | Run completed. The output is at /tmp/sas-util-out. The disk log: Oct 21 09:04:58 brute emhttpd: spinning down /dev/sdi Oct 21 09:04:58 brute SAS Assist v2024.02.18: Spinning down device /dev/sdi Oct 21 09:05:22 brute emhttpd: read SMART /dev/sdi Oct 21 09:51:47 brute emhttpd: spinning down /dev/sdi Oct 21 09:51:47 brute SAS Assist v2024.02.18: Spinning down device /dev/sdi Oct 21 09:52:11 brute emhttpd: read SMART /dev/sdi Oct 21 10:16:29 brute emhttpd: spinning down /dev/sdi Oct 21 10:16:29 brute SAS Assist v2024.02.18: Spinning down device /dev/sdi Oct 21 10:16:52 brute emhttpd: read SMART /dev/sdi Diagnostics also attached brute-diagnostics-20241021-1014.zip

Running into the same problem - My mover has now been running for over 18 hours, yet my drives are barely moving all while my cache drive is filling up... I also have Frigate and the last 3 days worth of footage hasn't been touched by mover...

Had the exact same issue twice now - Mine was with erikvl87/languagetool container. Filled up my /run folder and basically took down all other containers with it as well as making the server unresponsive with 100% CPU Usage Increased /run slighthly - Will keep an eye on it This container received the --no-healthcheck treatment

Uninstall, reboot and reinstall worked! Thanks

Also getting a strange response when trying to upgrade from 545.29.06 to 550.40.07: +============================================================================== | WARNING - WARNING - WARNING - WARNING - WARNING - WARNING - WARNING - WARNING | | Don't close this window with the red 'X' in the top right corner until the 'DONE' button is displayed! | | WARNING - WARNING - WARNING - WARNING - WARNING - WARNING - WARNING - WARNING +============================================================================== ----------------Downloading Nvidia Driver Package v470.199.02----------------- ---------This could take some time, please don't close this window!------------ ---------------Can't download Nvidia Driver Package v470.199.02---------------- For some reason it tries to download the earliest available version...

I just got this same issue for the first time this morning: Also, on 6.12.4 but only thing that is different is last night I had an unsafe shutdown, which corrupted my docker.img - I rebuilt this around midnight and got all containers up and running. About 6 hours later I see the server is dead with this same error. Obviously all docker settings reset to default, and mine is set to macvlan now. Will also be trying ipvlan - Can't remember if that is what I used to have it on.

Any updates on this? Just checked my HA logs and found this: Logger: homeassistant Source: helpers/entity_platform.py:712 First occurred: 20 August 2023 at 19:45:06 (40192 occurrences) Last logged: 19:16:42 Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 510, in async_add_entities await asyncio.gather(*tasks) File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 712, in _async_add_entity raise HomeAssistantError(f"Invalid entity ID: {entity.entity_id}") homeassistant.exceptions.HomeAssistantError: Invalid entity ID: binary_sensor.brute_vm_home_assistant_usb_nbsp_nbsp_nbsp_nbsp_nbsp_nbsp_nbsp_input_type_checkbox_name_usbopt_0463_ffff_id_usbopt0_value_0463_ffff_nbsp_nbsp_nbsp_nbsp_nbsp_input_type_number_size_5_maxlength_5_id_usbboot0_class_narrow_bootorder_style_width_

I just updated and still seeing my HA logs spiking: Logger: homeassistant Source: helpers/entity_platform.py:750 First occurred: 12:51:59 (781 occurrences) Last logged: 13:05:25 Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 504, in async_add_entities await asyncio.gather(*tasks) File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 750, in _async_add_entity raise HomeAssistantError(f"Invalid entity ID: {entity.entity_id}") homeassistant.exceptions.HomeAssistantError: Invalid entity ID: binary_sensor.brute_vm_home_assistant_usb_nbsp_nbsp_nbsp_nbsp_nbsp_nbsp_nbsp_input_type_checkbox_name_usbopt_0463_ffff_id_usbopt0_value_0463_ffff_nbsp_nbsp_nbsp_nbsp_nbsp_input_type_number_size_5_maxlength_5_id_usbboot0_class_narrow_bootorder_style_width_ Logger: homeassistant.components.binary_sensor Source: helpers/entity_platform.py:750 Integration: Binary Sensor (documentation, issues) First occurred: 12:51:59 (461 occurrences) Last logged: 13:07:22 Error adding entities for domain binary_sensor with platform mqtt Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 504, in async_add_entities await asyncio.gather(*tasks) File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 750, in _async_add_entity raise HomeAssistantError(f"Invalid entity ID: {entity.entity_id}") homeassistant.exceptions.HomeAssistantError: Invalid entity ID: binary_sensor.brute_vm_home_assistant_usb_nbsp_nbsp_nbsp_nbsp_nbsp_nbsp_nbsp_input_type_checkbox_name_usbopt_0463_ffff_id_usbopt0_value_0463_ffff_nbsp_nbsp_nbsp_nbsp_nbsp_input_type_number_size_5_maxlength_5_id_usbboot0_class_narrow_bootorder_style_width_ 781 entries in 15 minutes...

Good day, this seems to work great. One thing I noticed today, one of the entity names coming through to MQTT is extremely long: brute_VM_home_assistant_USB_nbsp&nbsp&nbsp&nbsp&nbsp_ <input_type="number"_size="5"_maxlength="5"_id="usbboot0"_class="narrow_bootorder"___style="width__50px;"_name="usbboot[1a86_7523]"___title="boot_order"__value=""_> qinheng_electronics_ch340_serial_converter turned off I am running a Home Assistant VM, which has a USB Serial Adapter passed through. Seems like every time this serial USB has a reading, I get the MQTT entry of the device turning ON and OFF.