* Rename NetworkManager default profile
Rename the NetworkManager default profile to "Home Assistant OS
default". Improve documentation on how to reset to default
configuration.
Bump to the latest U-Boot release 2021.04-rc4. This alows to drop quite
some patches which have been sent to the mailing list or picked from the
mailing list and have been merged upstream now.
* Accept installation with intel-nuc in compatible string
For the OS release 6 intel-nuc gets renamed to generic-x86-64. Since
the machine name is in the OS compatible string we need to make sure
OS release 5 installation can update to release 6 despite the new
machine name.
* Change HASSOS_ID from hassos to haos
Use a rauc install-check hook to make this update compatible with OS
releases using hassos in the compatible string.
* Use home-assistant as organization in CPE_NAME
Align with Home Assistant core which uses home-assistant with a dash as
organization in CPE_NAME.
* Rename Intel NUC machine to Generic x86-64
The Intel NUC machine has evolved and supports various x86-64 machines
today. Rename the board.
Note that this does not address the migration issue. This will be
handled separately.
* Update Scripts/Documentation
* Rebase patches to Buildroot 2021.02-rc3
* Update Buildroot to 2021.02-rc3
* Declare Kernel headers to be Linux version 5.10 (since they are, and new Buildroot knows about 5.10)
Move to the new Linux 5.10 based kernel for all Raspberry Pi boards.
This uses the version of the last OS version used in Raspberry Pi OS
raspberrypi-kernel_1.20210201-1.
* Add Ralink rt27xx/rt28xx/rt30xx firmware (#1242)
Add Ralink firmware for devices which have the driver enabled. The
firmware's are rather small at 20KiB in total.
* Remove Ralink and other WiFi drivers from Tinker Board
The board has on-board WiFi, no need for Ralink drivers to be enabled.
* Add Ralink WiFi drivers and firmware to ODROID boards
This matches the 1.2-4+rpt8 release of Raspberry Pi OS' bluez-firmware
package. It addresses mainly addresses Spectra fix for CYW43455
(CVE-2020-10370).
Also update the Bluetooth start scripts with CM4 support and some
minor improvements.
* Add --cpu-rt-runtime to allow Docker allocate real-time CPU time (#1235)
* Enable Supervisor's CPU bandwith allocation feature (#1235)
Since we have CONFIG_RT_GROUP_SCHED enabled in the Home Assistant OS
kernel the Supervisor needs to enable CPU bandwith allocation for
Add-Ons which need real-time scheduling. Set the appropriate environment
variable.
It seems that the release drafter filters commits which have been made
before the last release has been made. If the last release is a
unrelated stable release, this clears the full changelog for the next
major release. It seems `filter-by-commitish` should prevent that.
While at it, also set `commitish` to be dev (which is the default, but
being explicit certainly doesn't hurt).
* Improve ASUS Tinker Board support for 5.10
Remove patches which are unnecessary. Revert DMA for UART as it seems to
cause more problems (its also what Armbian is doing). With that
Bluetooth firmware seems to load without errors when loaded before the
bluetooth daemon is running!
Note: It seems that the board overheats quite quickly. With Armbian,
without load, that seems not to be a big deal, but HAOS does quite a
bunch at startup, leading the CPU to reach the 90°C trip point. Maybe it
was related to the rather closed shelf I have the ASUS Tinker board
running, but only after using a fan the board behaved for me.
* Use hardware flow control explicitly
The rtk_hciattach program uses hardware flow control by default (judging
from tty settings after starting the program). Just to be sure,
explicitly request 115200 and hardware flow control.
* Add SocketCAN support
A Controller Area Network (CAN bus) is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other's applications without a host computer. It is a message-based protocol, designed originally for multiplex electrical wiring within automobiles to save on copper, but it can also be used in many other contexts. For each device, the data in a frame is transmitted sequentially but in such a way that if more than one device transmits at the same time, the highest priority device can continue while the others back off. Frames are received by all devices, including by the transmitting device.
* Update also for GS_USB support
There is a port of the candleLight USB to CAN firmware for CANable. The port works very well under Linux using the gs_usb driver. This firmware does not use slcan, so it is not interchangeable with the stock firmware. However, the CANable appears as a CAN interface natively in Linux
With the candlelight firmware, simply plug in the CANable and the device will enumerate as can0. Set the baud rate and bring the interface up with the following command, and you're good to go!
ip link set can0 up type can bitrate 500000
* Update for Peak PCAN-USB Support
Currently Linux has a limit of IGMP memberships of 20. When trying to
add membership to more than that, Linux fails with:
OSError: [Errno 105] No buffer space available
Allowing more memberships should not really be problematic as memory is
allocated dynamically when membership is actually added.
However, there is a protocol limit of how many memberships a host can be
in. The number of memberships needs to fit in a single group report
datagram of 64kB. In total 5459 group records fit in a datagram, but due
to IP header options this might be slightly smaller in practise.
(see https://github.com/home-assistant/core/issues/45957).
Use a limit of 1024, which should be plenty of headroom in both
directions.
Related to: https://github.com/home-assistant/core/issues/45957
* Drop ODROID specific kernel update script
With the jump to Linux 5.10 LTS we can use the same upstream kernel for
Hardkernel ODROID boards as well. Extend the update-kernel-upstream.sh
to support the ODROID boards.
* Linux: Update kernel 5.10.13
It seems that Busybox shell (ash) cannot calculate the disk size
properly probably due to integer overflow. Use jq to calculate the last
usable LBA which seems to be able to handle large integers.
There are incident reports on the internet where poeple report that
fsck.(v)fat actually leads to problems rather file system fixes. Around
the time when Home Assistant OS added fsck.fat for the boot partition,
reports of empty boot partitions or file with weired filenames started
to appear. This could be caused by fsck.fat.
Disable fsck on the boot partition.
Use udev rules to set the CPU online. For memory, we let the kernel
bring memory online automatically. This is preferred as udev rule
processing might be delayed in a low memory situation, see:
https://lwn.net/Articles/668944/
Partition handling for disks with 4k sectors broke partition resizing
when using MBR disk label. It seems that sfdisk doesn't calculate the
last LBA for diks with MBR label. Calculate the last usable LBA ourselfs
in the MBR case.
The calculation whether to resize the partition only works with disks
with 512 byte sector size. Use values provided by sfdisk exclusively to
make sure comparing the same sector size.
Furthermore, it seems that sgdisk does not like sfdisk's backup GPT
placement:
$ sgdisk -e /dev/zram1
Warning! Secondary partition table overlaps the last partition by 250 blocks!
Today it seems sfdisk can handle GPT quite well. Use sfdisk for all
operations in hassos-expand.
The e2scrub utilities only make sense on system which use LVM. They
come with e2fsprogs and can't be disabled currently. Drop them manually
in our post-build script.
systemd-udevd substitutes variables starting with $ in the PROGRAM
argument. If a shell variable is to be used, two $ need to be used to
escape properly. This fixes three instances of the following warning:
Invalid value "..." for PROGRAM (char 58: invalid substitution type), ignoring, but please fix it.
The supervisor container requires the "hassio-supervisor" AppArmor
profile. Make sure our AppArmor service hassos-apparmor is a dependency
of the hassos-supervisor.service.
