Some applications try to increase the buffers for performance reason. The
QUIC Go implementation for instance tries to request a 2048 kiB buffer
size.
The kernel default depends on skubuf size (which is architecture
dependent), but it is memory size independet and typically around 200 kiB
(see [1]).
Other network tuning guides suggest 16MiB for 1GB ethernet, as well as
changing the default as well as maximum bufffer size (see [2]). This
conservatively increases the maximum buffer size to 4MiB.
[1]: https://elixir.bootlin.com/linux/v5.15.45/source/include/net/sock.h#L2742
[2]: https://nateware.com/2013/04/06/linux-network-tuning-for-2013/
* Add open-vm-tools to AArch64 for better VMware support (#1050)
* Bump buildroot
* buildroot 666868435d...de7aa15c65 (1):
> package/openvmtools: bump version to 11.3.5
For phyiscal hardware the default Power Button action has been disabled
to avoid accidentally power down the machine.
However, for virtual machine this method is often used to shutdown the
virtual machine gracefully. Use the regular power settings for virtual
machines.
* Use upstream Linux driver for Bluetooth on ASUS Tinker
* Drop unnecessary Bluetooth initialization systemd service
Bluetooth is now entirely handled by the kernel.
* Recreate defconfigs using savedefconfig target
Buildroot allows to generate minimal defconfigs using the savedefconfig
target. Regenerate all our configurations so they all look alive and are
minimalistc.
* Fix generic_aarch64_defconfig
* Enable additional LED triggers
* Improve Yellow device tree
Fix soundcard name and use BTN_1 as key code.
* Add input-event-daemon configuration
Add minimal input-event-daemon configuration to avoid the default
configuration taking effect. This minimal configuration triggers
the USB configuration import on button press.
* Support firewall matching by pkttype
Matching by pkttype is required by the reference OTBR firewall script.
* Add additional Kernel configurations required for OpenThread.
It seems that the GitHub container registry sometimes returns 503
service unavailable temporarily ("Error fetching tags list: invalid status
code from registry 503"). Use skopeo's retry mechanism to try up to 5
times before failing.
Add VID/PID of some known problematic USB SSD controllers to USB storage
quirk list. This should make most USB SSD's work with Home Assistant OS
out-of-the box.
The Google Gasket driver has been removed from the main kernels staging
tree between 5.10 and 5.15 development window. Readd Google's
out-of-tree driver to continiue support Google Coral devices.
* Replace bluetooth-bcm43xx with pi-bluetooth Buildroot package
The new pi-bluetooth packages the scripts and systemd service from
the Raspberry distribution package directly:
https://github.com/RPi-Distro/pi-bluetooth
* Update to latest pi-bluetooth service files
* Update busybox configuration to 1.35.0
The new/deleted configurations are generated automatically, no actual
change in this patch.
* Enable busybox xxd command
The xxd tool is useful for conversion in scripts.
* Prevent start erros on Compute Module 4 without WiFi/Bluetooth
Enable IPv6 forwarding by default which is useful to run IPv6 based
OpenThread Border Router.
Currently Docker enables IPv4 forwarding by default. Enabling IPv6
support will enable IPv6 routing as well, but we are not ready yet to
enable IPv6 support for Docker at this point.
Enabling IPv6 forwarding should be harmless as there are no IPv6
addresses configured internally and Home Assistant OS is not typically
dual-homed. In cases where it is dual-homed (e.g. VPN), routing is
often used and firewalling is setup as part of that add-on.
* Enable wext and nl80211 drivers for wpa_supplicant for all devices
* Enable r8188eu module globally and add related firmware to all devices config
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Use anonymous Docker volume as build output
Use anonymous Docker volumes as build output. This makes sure
every build is using a clean output directory.
This aligns with what we used to have in Barebox. Most of the time the
user is not expected to make a choice, so keeping the timeout short is
sensible.
* Drop default NetworkManager configuration
NetworkManager will automatically connect using the global defaults.
Also Supervisor today will create a profiles once the user configures
the network explicitly.
* Create system-connection directory
* Add tempio host package
tempio is a template helper using Go's template engine and sprig
functions.
* Use tempio to generate rauc manifest
* Use tempio to generate rauc system.conf
This reverts commit ff07728fa3.
Removing the .git file from the git submodule is problematic when
updating buildroot: Files deleted stay present in the buildroot
directory (since their origin is no longer known).
The workaround has been introduced to allow building non-git submodule
releases (rel-6) on the same runners. Since rel-7 uses git submodule and
we stay with git submodule for the forseeable future, remove this work
around.
* Drop unnecessary device tree utilities
They have been used for Barebox which uses device tree to configure the
state storage and its location. With the change to GRUB the tools are no
longer required.
* Determine manual GRUB update depending on installed tools
Manually update the GRUB environment if no grub environment tools are
installed. This makes a upgrade work even after a previous downgrade (in
that case a grubenv file might still be present in the UEFI ESP).
* Add generic-aarch64 to the list of Kernels
* Bump buildroot
* buildroot 8bbb32c16a...962ff8c0d4 (1):
> package/rtl8812au-aircrack-ng: bump version to 3a6402e
* Fix kernel version for Raspberry Pi kernel based boards
* Linux: Update kernel 5.15.25
Use highest available kernel version in Buildroot 2021.08 (5.13)
* Update Hardkernel patches to Linux 5.15
* Update generic-x86-64/ova kernel config/patches for 5.15
* Drop Intel e1000e Sourceforge driver
The driver has been discontinued sometime last year. The main reason the
out-of-tree kernel has been enabled was for support for the i219-V
network chips which meanwhile are supported in mainline.
* Use shell functions for install hooks
* Use post-install hook to initialize GRUB2 bootloader env
Unfortunately the boot name to be updated (RAUC_SLOT_BOOTNAME) is not
available when updating the "boot" slot. Instead, initialize the boot
slot in a kernel post-install slot.
* Fix migration from Barebox GRUB
Create GRUB env which defaults to the boot slot we are updating to. This
makes sure that the newly installed OS version will be booted on next
reboot even if installed on boot slot B.
* Add AArch64/ARM64 EFI boot support (for QEMU and some boards)
* Allow GRUB to load cmdline.txt-like
* Enable qcow2/vmdk disk images
Co-authored-by: Stefan Agner <stefan@agner.ch>
* updated generic_raw_uart to latest version which comes with dualcopro
support for the HmIP-RFUSB usb rf-sticks by eQ3/ELV.
* remove 99-hmip-rfusb.rules to keep a HmIP-RFUSB device free from being
occupied by the cp210x driver but use the new generic_raw_uart support
instead allowing for advanced dualcopro support for HomeMatic/BidCos-RF
and homematicIP support in parallel.
To make HDMI CEC work, we have to compile MESON_DRM as a module
(see #1717). However, this essentially reverts #1347, which fixed the
reboot problem by compiling the driver into the kernel.
Hence we need to reintroduce the earlier fix from #1345, which reverts
the offending commit causing the reboot problem.
* Fix enable USB host mode kernel patch
Update to a new patch which applies the device tree change such that the
USB controller actually gets enabled.
* Update Home Assistant Yellow board config
Update config to match changes which have been made to other baords as
well.
* Rename Home Assistant Amber to Yellow
Rename the board from "amber" to "yellow" as Home Assistant Yellow is
the official name now.
* Add Home Assistant Yellow to the build matrix
* ODROID XU4: Update U-Boot on eMMC boot partition
Update the U-Boot on the eMMC boot partition if present. Only write the
first megabyte as the eMMC boot partition might be smaller than the SPL
image and only the first megabyte is occupied by FW/BL1/BL2/TZSW (see
https://wiki.odroid.com/odroid-xu4/software/partition_table#tab__odroid-xu341).
* Bump buildroot
* buildroot 907739ed48...4c6c8fb767 (1):
> package/rpi-firmware: bump version to 71bd3109
* RaspberryPi: Update kernel 5.10.63 - oldstable_20211201
* Add Raspberry Pi Zero 2 W device tree
* Use LSI Logic SCSI controller in vmdk descriptor as well
For some reason, the vmdk disk format's descriptor contains the
controller type as well. By default, qemu-img sets it to "ide", which
seems not optimal especially for VMware's ESXi. Set adapter type to
commonly supported "lsilogic".
* Move ova image generation to hdd-image.sh
* Check if Busybox supports oflag
It seems that Busybox' dd shipped with OS release 5 and earlier does not
support oflag. Check if the flag is supported before making use of it.
* Exit if a command in the update scripts returns an error
This makes sure that the update isn't marked as successful in case there
is an error in the update script.
* Devices description update
Updating the list of supported devices according to https://www.home-assistant.io/installation/
* Intel NUC -> Generic x86-64 (e.g. Intel NUC)
* Remove unsupported Raspberry Pi and Raspberry Pi Zero
* Use OpenSSL to generate OVA manifest file (#826)
It seems that sha256sum adds a space after the hash algorithm which
causes "Invalid OVF checksum algorithm" on certain VMware virtualization
products.
Using OpenSSL avoids the space and makes the manifest file compatible
wiht VMware products.
* Use Buildroot provided OpenSSL binary
* Use SCSI controller by default
Make sure to overwrite existing files on upload. This allows to trigger
rebuilds and have the latest builds on the os-builds server.
Note: When using GitHub Actions, the release/ directory is cleared at
the beginning (by the checkout action, which has the clean option set
by default which also causes files in .gitignore to be deleted).
* Avoid race condition when fetching containers during build
So far only a single builder was active for each architecture. This
toghether with the naming scheme to include architecture/machine name
made sure that an image could only be fetched or used by a single
builder.
However, since most systems are now aarch64, multiple runners are now
active for a single architecture. This makes it necessary to lock
fetching/coping of container images to avoid race conditions.
Use rtl8812au driver provided by buildroot. This uses a newer verison of
the v5.6.4.2 branch which works with newer kernel and seems to be the
recommended branch.
Note: It seems that our buildroot package currently fails to properly
deploy the 88XXau.ko kernel module. Instead of fixing our version, just
move to the buildroot version.
* Update Linux kernel patches for Home Assistant Amber
Fix user LED polarity. Also rebase the patchset ontop of the Raspberry Pi
kernel 1.20211029.
* Add RTC as well
These boards support the rather ancient ARMv6 architecture only. We
officially stopped supporting them already two releases ago, its time to
say goodbye.
* Add systemd-journal-remote to the image
This allows to access journald's log from within Supervisor and expose
more system logs to users.
* Allow to access systemd-journal-gatewayd from Supervisor
Create a systemd-journal-gatewayd.socket service using a Unix socket and
bind mount it into the Supervisor container. This allows to query
systemd-journald from Supervisor directly.
* Bump buildroot
* buildroot 73991f0fee...5b5dff3136 (1):
> package/linux-firmware: Add RTL8152/8153/8156 firmware
* Enable Realtek 8152/8153/8156 USB Ethernet adapter support
Enable kernel driver and install firmware for Realtek USB Ethernet
adapter. While at it, also enable some other common USB Ethernet
adapters which don't require firmwares.
If a git submodule is converted to a regular git directory (e.g. when
moving from dev -> rel-6 branch), the directory is not properly cleaned
by the checkout action.
Remove the git submodule .git files which makes sure that git properly
reinitialize subdirectories, even if they have been a submodule before.
See also: https://github.com/actions/checkout/issues/624
* Add Amber machine
Introduce a new machine for Amber. Store it under Raspberry Pi boards
since Amber is based on the Raspberry Pi Compute Module 4. This way we
can reuse existing scripts.
* Add kernel patches for Amber
Add kernel patches which add a custom device tree for Amber.
* Add device wipe support via GPIO button
Allow to wipe the device by pressing and holding the red button.
* Enable serial console by default
Enable serial console on the on-board USB-to-UART adapter as well as on
the GPIO header.
* Use 64-bit mode by default
Support only 64-bit for Amber, it is mature enough.
Currently the hassos-apparmor.service wants the
hassos-supervisor.service and vice-versa. This is unnecessary and leads
to activation of hassos-supervisor.service when reload/restart
hassos-apparmor.service (Supervisor is doing that on startup).
Make hassos-apparmor.service independent and add dependency as well as
ordering from hassos-supervisor.service side.
* Avoid duplicate log entries
So far the hassos-supervisor.service starts the hassos-supervisor script
which in turn attaches to the Supervisor container. This causes stdout
and stderr to be forwarded to the service unit, which in turn logs it in
the journal.
However, Docker too logs all stdout/stderr to the journal through the
systemd-journald log driver.
Do not attach to the Supervisor container to avoid logging the
Supervisor twice.
Note that this no longer forwards signals to the container. However, the
hassos-supervisor.service uses the ExecStop= setting to make sure the
container gets gracefully stopped.
* Use image and container name as syslog identifier
By default Docker users the container id as syslog identifier. This
leads to log messages which cannot easily be attributed to a particular
container (since the container id is a random hex string).
Use the image and container name as syslog identifier.
Note that the Docker journald log driver still stores the container id
as a separate field (CONTAINER_ID), in case the particular instance need
to be tracked.
* Bump buildroot
* buildroot 3c5f87185d...5ffdf6ccc5 (1):
> package/e2fsprogs: Create y2038 capable file systems by default
* Use inode size of 256 bytes for overlayfs
By default older versions of mkfs.ext4 create file systems with inode
size of 128 bytes. This does not allow for 64-bit timestamps, which
leads to y2038 compatibility warnings. Use 256 bytes inodes.
* Remove dt-utils patches applied upstream
All patches are now applied upstream. With 2021.03.0 release no more
downstream patches are required.
* Bump buildroot to fix linux-firmware build issues
* buildroot f10577b836...3c5f87185d (3):
> package/linux-firmware: add rtl8761b/rtl8761bu firmware
> package/linux-firmware: bump version to 20210919
> Revert "package/linux-firmware: add rtl8761b/rtl8761bu firmware"
* Bump to Buildroot 2021.08.1
Move to Buildroot 2021.08.1 using the 2021.08.x-haos branch. Some
patches on the previous branch 2021.02.x-haos have been applied upstream
meanwhile. Others required rather trivial rebasing.
This latest Buildroot release brings new versions of the following
components:
- glibc 2.33
- systemd 249.3
- Networkmanager 1.32.2
- BlueZ 5.60
- Docker 20.10.8
The patch "Fix dhcp client" seems not to be necessary anymore. The
directory /var/lib/dhcp seems not in use when NetworkManager invokes
dhclient. It seems the leases which are typically stored in that
directory are managed inside NetworkManager.
* buildroot 2021.08.1..2021.08.x-haos (6)
> package/rpi-firmware: bump version to 1.20210805
> package/rpi-wifi-firmware: bump version to 883b726
> package/linux-firmware: add rtl8761b/rtl8761bu firmware
> package/docker-proxy: bump version to 64b7a4574d14
> package/rpi-firmware: Allow to deploy multiple firmware files
> network-manager: wpa_supplicant
* Bump Raspberry Pi Bluetooth helper scripts
With the update to Buildroot 2021.08.1, the bthelper fails with an error
org.bluez.Error.Busy when trying to power off the device. Presumably this
is a race condition which surfaced due to a change in Bluez 5.60:
348feb005a
Oct 11 14:32:21 homeassistant systemd[1]: Reached target Bluetooth Support.
...
Oct 11 14:32:21 homeassistant bluetoothd[412]: Bluetooth management interface 1.18 initialized
Oct 11 14:32:21 homeassistant systemd[1]: Started Raspberry Pi bluetooth helper.
Oct 11 14:32:21 homeassistant bthelper[417]: Raspberry Pi BDADDR already set
Oct 11 14:32:21 homeassistant bthelper[426]: [58B blob data]
Oct 11 14:32:21 homeassistant bthelper[426]: [59B blob data]
Oct 11 14:32:21 homeassistant bthelper[426]: Failed to set power off: org.bluez.Error.Busy
Oct 11 14:32:21 homeassistant systemd[1]: bthelper@hci0.service: Main process exited, code=exited, status=1/FAILURE
Oct 11 14:32:21 homeassistant systemd[1]: bthelper@hci0.service: Failed with result 'exit-code'.
The latest version of the pi-bluetooth package introduced a sleep before
powering off the device, however, presumably for a different reason:
ae2efdeee8 (diff-609c8a23261988c47afd40be9b012feb1d167de8761c1301e44e1864635c19e3)
Anyways, this latest version seems to also fix the above mentioned race
condition.
Sometimes the first command after starting the Docker daemon container
fails, presumably because the container did not start yet. Wait until
the Docker daemon is ready.
The BCM2711 has two USB 2.0 IPs: A Broadcom XHCI USB 2.0 controller and
a Synopsys DWC2 USB 2.0 Host/Device controller. When USB boot is used
the former is active. Make sure the driver has the correct device tree
compatible.
We only have a single U-Boot version currently, so there is no value in
storing the patch file in a version specific directory. This makes sure
U-Boot 2021.10 final release also has fileenv support.
* Add NVMe and XHCI USB driver fix for Raspberry Pi
Add patch which fixes NVMe read reliability and allows to compile the
XHCI USB driver (for Compute Module 4).
* Enable Broadcom XHCI driver for Compute Module 4
The BCM2711 has two USB 2.0 IPs: A Broadcom XHCI USB 2.0 controller and
a Synopsys DWC2 USB 2.0 Host/Device controller. When USB boot is used
the former is active. Make sure U-Boot has the driver built-in for that
IP.
* Remove duplicate config.txt copy statement
* Use static cmdline.txt file
Instead of dynamically creating cmdline.txt use a static version of it.
This aligns with other boot loader/firmware configuration files and makes
it easier to customize the file per board.
Support optional board specific default RPi firmware configuration file
(config.txt). Also rename from boot-env.txt to config.txt since this
file is not read by the U-Boot boot loader but the Raspberry Pi specific
boot firmware.
* Use skopeo to download container images
Separate container download from image build. This will allow to share
the downloaded images between multiple builds.
We won't store the Supervisor container with the version tag, just with
the latest tag. This allows to simplify the procedure a bit. It seems
there is no downside to this approach.
* Use official Docker in Docker images to build data partition
Instead of building our own Debian based image let's use the official
Docker in Docker image. This avoids building an image for the hassio
data partition and speeds up build as well.
This calls mount commands using sudo to mount the data partition as part
of the buildroot build now. This is not much different from before as
mount has been called as root inside the container, essentially equates
to the same "isolation" level.
* Use image digest as part of the file name
The landing page has no version information in the tag. To avoid
potentially source caching issues, use the digest as part of the file
name.
CONFIG_BT_HCIBTUSB selects CONFIG_BT_INTEL. That causes CONFIG_BT_INTEL
to be built-in instead of being built as a kernel module.
When the driver is built-in, loading firmware fails during early boot
with the following error message:
[ 1.058941] bluetooth hci0: Direct firmware load for intel/ibt-17-16-1.sfi failed with error -2
Make sure the driver is built as a module which should fix firmware
loading.
* Add U-Boot patches for NVMe boot support
Add NVMe to boot order. Fix NVMe support on 64-bit Raspberry Pi devices.
This is useful for Raspberry Pi Compute Module 4 IO Board where a native
NVMe can be plugged in.
* Enable NVMe support for Raspberry Pi 4
Our machine configuration rpi4 and rpi4_64 work on the Compute Module IO
Board. In this configuration a NVMe SSD can be used. Therefor, enable
support for NVMe in the Raspberry Pi 4 configurations.
Note: Regular Raspberry Pi devices will not notice a difference as the
"nvme scan" command will return very quickly and not find a NVMe on the
PCIe bus.
* Use built-in NVMe support in Kernel for NVMe boot support
The bump to U-Boot 2021.10-rc5 also makes quite some patches obsolete
since they are already part of U-Boot.
This also removes a patch which disables framebuffer support on
Raspberry Pi: Framebuffer support seems to work fine in todays
U-Boot/Linux combination. It can help debug boot problems on Raspberry
Pi devices. Without the patch framebuffer support will be enabled by
default.
Some USB devices cause the USB stack to get stuck with a stall error.
This adds a patch which recovers from this situation.
This avoids an U-Boot crash when Arduino Mega R3 devices are connected,
which cause an USB stall when trying to read the product string.
When a USB keyboard is connected to Raspberry Pi 32-bit versions of
U-Boot crashed in certain situations just before booting Linux. This
seems to be cause by a buffer overflow when removing the USB keyboard
before hand-over to Linux.
Add buildroot utils/check-package check to the pr-checks.yml workflow.
It checks for common errors/mistakes when creating own buildroot
packages. Also fixed all warnings this utility output for our existing packages.
* Linux: Update kernel 5.10.61 for ODROID-N2 (#1512)
Update the kernel to 5.10.61 for ODROID-N2 and fix the update script
to update kernel for ODROID-N2 next time too.
* Move ODROID kernel patches to non-kernel version specific directory
The minimal memory reserved parameter vm.min_free_kbytes should be
between 1-3% according to RedHat.
However, the kernel by default reserves around 3MB (e.g. only 3285 on a
32-bit Raspberry Pi 4 2GB installation). This seems to be too low for
network intensive applications such as ours: Under memory pressure
"page allocation failure" on various orders have been observed.
Raspberry Pi OS uses a fixed value of 16MB. Follow this setting for now.
Note: We cannot set this globally for Home Assistant: x86-64 machines
can have quite a bit more memory, which also requires increased
min_free_kbytes parameter. ODROID-N2 on the other hand uses transparent
huge pages: If enabled, the kernel requires higher min_free_kbytes
values, and sets those also by default (e.g. on ODROID-N2+ with 4GB
memory its set to 22528 by default).
Don't fail adding reserved memory when a memory region already has been
reserved (e.g. via memreserve). This avoids conflicting no-map setting
and makes sure memory is properly reserved.
* Enable some useful kernel configurations
* Add xe-guest-utilities for better Xen support
Add guest utilities and make sure the Xen guest daemon gets started
when running under Xen virtualization.
* Avoid using tar when uploading dev builds
The GitHub action to upload the images to the os-builds server uses
tar before uploading. This creates unnecessary copies and takes a while.
Switch to a GitHub action which uploads the images using rsync instead.
Other compression methods remove the original image file at compression.
Add the -m (move) command to zip to do the same when compressing with
zip. This saves some space in the builds image/release directory.
The CRDA (Central Regulatory Domain Agent) utility has been used as a
user space helper to load regulatory information for WiFi drivers.
However, since Linux 4.15 the kernel can load the regulatory information
directly from a signed firmware file "regulatory.db".
The regulatory.db file is provided by the WIRELESS_REGDB package, which
has been already installed since its a dependency of CRDA.
Drop CRDA and select WIRELESS_REGDB package explicitly to make sure the
regulatory.db file is present.
LVM2 is not really required in the embedded use case. Opt out of
installing the standard installation which will install only dmsetup.
This requires a backported fix for the lvm2 package to not install
unnecessary systemd services.
Fixes: #1448
* Drop buildroot from git repository
Manage buildroot in a separate git repository and use a git submodule
to include it into the HAOS source tree.
This makes it easier to manage changes to buildroot since it can be
managed by git. A buildroot fork repository is being maintained with
the changes we currently have. It makes the buildroot-patches unnecessary
and should make it easier to rebase and upstream changes to buildroot.
* Remove buildroot-patches
Now that buildroot changes are managed in the buildroot fork repository
there is no need to manage patches in a separate directory.
* Initialize git submodule if necessary
* Move build directory to root
This avoids conflict/local modification issues with the buildroot
git submodule.
* Improve kernel update scripts
Use separate script for ODROID-N2 for now. Also warn if there are kernel
patches with a specific kernel version number in the source tree: They
typically can be just moved to the new kernel version, but one should
compile check them before committing.
* Add squashfs with LZ4 and LZO compression to Barebox
* Add squashfs with LZO compression to U-Boot
* Use squashfs for Linux kernel partition
Generate a squashfs image with LZO compression for the Linux kernel
partition. Adjust the boot scripts to be file system independent commands
to boot from squashfs.
The patches for ODROID-C2/C4 don't apply to Linux 5.12 used in
ODROID-N2. Move ODROID-C2/C4 patches to kernel version specific
directory so they don't get applied for ODROID-N2.
Use the latest Linux stable release 5.12 for ODROID-N2. This allows to
test if we see the random kernel crashes observed with 5.10 in latest
stable 5.12 as well.
The rauc hook for the spl slotclass writes to the disk directly. Make
sure the changes do not end up in cache in case the device looses power
or is otherwise not properly rebooted.
Also use the same partition label detection we are using in
hassos-expand.
In the past file system extents have been deactivated to get better
performance in U-Boot. However, the performance issue has been addressed
with commit d5aee659f217 ("fs: ext4: cache extent data") in U-Boot. The
performance should be equal to regular files using no extents.
Enabling extents has an advantage however: Files are stored more
efficently, especially relatively large files like a kernel image. The
impact is not all that big (~100KiB), but worthwhile nonetheless.
The Wireless Extension framework is deprecated, but it seems that the
Wireless Extensions proc API is still popular (/proc/net/wireless).
Enable the minimal set of Wireless Extension to get the proc API.
Since we start the HomeAssistant shell directly on tty the service
responsible for starting did not restart the shell on exit. Remove the
RemainAfterExit flag to make sure that the shell restarts on exit.
It seems that the TPU (thermal monitoring) sometimes reports
unreasonable high temperatures, leading the kernel to trigger a thermal
shutdown. Add a patch which filters out such spurious temperature
readings.
* Remove CONFIG_CLOCKSOURCE_EFI configuration
It seems to cause messages like this on some machines:
EFI Event timer too slow freq = 100 Hz
The Barebox efi_defconfig configurationd doesn't enable it either.
Disable it by default as well.
* Enable CONFIG_CMD_ECHO_E to fix menutree
It seems that menutree needs CONFIG_CMD_ECHO_E to properly display the
boot menu.
Also enable other useful commands such as edit or reset.
* Bump Barebox to 2021.05.0
Since the move to 5.10 multiple users experience stability issues
leading to random crashes. All reboots follow a SError Interrupt:
[48112.247242] SError Interrupt on CPU5, code 0xbf000000 -- SError
...
Revert back to Linux 5.9.16 for now.
Using console focused virtualization environments such as virsh having
a serial console is the easiest way to interact with a virtual machine.
It also saves resources since no video memory needs to be allocated.
Enable serial console besides tty1 by default.
Note: The bootloader as well as the kernel shows its boot messages on
all consoles. However, only the last console is mapped to /dev/console,
which systemd is using to show service startup messages. Putting tty1 as
last console makes sure that systemd messages are still shown on the
console screen.
When using quotes currently, they are not passed to HA due to $*. This
doesn't allow to use some commands properly, e.g. snapshot restore with
a passwort with spaces:
```
ha snapshot restore c31f3c93 --password "test test"
...
time="2021-05-26T11:24:19+02:00" level=fatal msg="Error while executing rootCmd: accepts 1 arg(s), received 2"
```
Properly pass all arguments using $@ in quotes.
Add a minimal motd so users know what kind of system they just logged
in. Also add the hint that the Home Assistant CLI is still available
using the command ha.
* Recreate Supervisor container on OS upgrade/downgrade
When the operating system gets upgraded or downgraded the Supervisor
start script might start the Supervisor slightly differently (e.g. with
RT scheduling support). If the container has already been created, a OS
upgrade or downgrade won't recreate the Supervisor container.
* Move startup script version file to /mnt/data
* Start ha-cli on tty1 instead of a getty
Instead of starting a getty start the ha-cli directly. This will show
the banner right on startup with the important information such as IP
address of the instance or the URL to reach it.
* Use default shell as root shell instead of HA CLI
Instead of using the ha-cli.sh script as login shell use the regular
shell. Amongst other things, this allows to run VS Code devcontainers
remotely via SSH or using scp. The HA CLI is still available using the
`ha` command.
* Enable systemd-time-wait-sync.service by default
Enable the systemd-time-wait-sync.service by default. This allows to use
the time-sync.target which allows to make sure services only get started
once the time is synchronized.
* Make sure time is synchronized when starting hassos-supervisor.service
Use the time-sync.target to make sure that the Supervisor gets stsarted
after the time has been synchronized.
* Set timeout for systemd-time-wait-sync.service
Don't delay startup forever in case time synchronization doesn't work.
This allows to boot the system even without Internet connection.
Support OS releases (tags) with custom dev part (3rd group of the
release number). This allows to create tagged release candidates with
the form 6.0.rc1.
It seems that the crash of the Meson DRM driver on shutdown can also be
fixed by compiling it in. The driver is also built-in in LibreELEC,
hence this is better tested by the upstream community.
Note the underlying issue seems to be a disabled clock: Since the
introduction of meson_drv_shutdown some registers are touched at a very
late stage. Those clock get disabled in meson_ee_pwrc_shutdown. It seems
that when the driver is built-in, meson_drv_shutdown gets called before
meson_ee_pwrc_shutdown and hence sidesteps the problem.
Note: This increases the kernel by a bit since DRM needs to be built-in
as well. Configure some less common used file systems as modules
(ext3/NFS).
Since 0001-CMD-read-string-from-fileinto-env.patch is in the global
directory to be applied for U-Boot, drop it from the Raspberry Pi
specific patch directory.
In Linux 5.10.24 a regression has been introduced which broke reboot on
ODROID-N2(+). Interestingly the patch should improve reboot stability
for VIM3, which uses the same SoC. However, it seems that in the
ODROID-N2 case, this causes more problems then it fixes. Revert the
offending patch.
* Fix issue with latest shellcheck version
The latest shellcheck versions use a new error number for non-POSIX
string replacement. Change to ignore this new error number.
* Ignore shellcheck issue about not following sourced files
Newer shellcheck versions also warn when shellcheck does not follow
sourcing of files with known path:
Not following: ./meta was not specified as input (see shellcheck -x).
We check those files separately so ignore this error for the two scripts
affected.
Virtual Disk images are often used on Windows and/or Mac platforms where
xz is not a widely known file ending and also not supported by dafault.
Use zip which is much better known.
Keep using xz for boards since those are not meant to be extracted by
users but directly used in Etcher. Also keep using xz for qcow2, since
qcow2 is mostly used on Linux platforms where xz is available by default
and zip usually needs an extra package.
Use sparse files instead of files written full of zeros. This speeds up
the image generation process significantly. It also makes sure that
virtual disk image formats are minimal in size.
Note: qemu-img automatically generates sparse files when detecting a
block full of zeros. But this is applied on the write side, after image
convertion: The disk image format itself still thinks the whole image
is allocated, leading to larger image than necessary. Also some output
format seem to regonize chunks of zero and create sparse files themself.
With this change, the raw source image file is a sparse file. This is
regocnized by qemu-img at read time (see block/file-posix.c), and leads
to "native" sparse files in the output format.
Some numbers
- qcow2 1.8G -> 862M (same on-disk size)
- vdi 15G -> 888M (same on-disk size)
- vhdx 30G -> 1.1G (918M -> 861M on-disk size)
- vmdk 1.8G -> 866M (about the same on-disk size)
Obviously this also affects the compressed size. But because there are
still lots of zeros, the difference in compressed size is not that big.
* Use interface-name to exclude veth
The type veth is not a valid type (see [1] for how to obtain a list of
valid device types. Use `driver` to filter veth.
Note: It seems that NetworkManager did not manage veth so far, so this
change seems not to be relevant in practice.
Co-authored-by: Pascal Vizeli <pascal.vizeli@syshack.ch>
* add eq3_char_loop package (eQ-3 char loopback kernel module)
* add generic_raw_uart package (low-latency raw UART kernel driver)
* add rpi-rf-mod package
* add device tree overlay support for RPI-RF-MOD/HM-MOD-RPI-PCB on Raspberry Pi
* enable GPIOLIB and GPIO_SYSFS required for RPI-RF-MOD/HM-MOD-RPI-PCB support.
* add basic RPI-RF-MOD/HM-MOD-RPI-PCB support for ASUS Tinker Board
* add device tree overlay support for ASUS Tinker Board and add
haos-config.txt loading support to U-Boot boot script
* Re-add patches missed with U-Boot 2021.04-rc4 upgrade
Also add patches for Raspberry Pi again.
* Regenerate patches for U-Boot 2021.04
* Update to U-Boot 2021.04
The latest version of OS Agent sets haos.wipe=1 as kernel argument to
trigger a device wipe. Let systemd pickup this kernel command line
argument and start haos-wipe.service.
This rather complex architecture allows to add other triggers in the
future, e.g. a button read in the boot loader.
* Disable systemd-logind support for udisks2
Currently udisks2 uses systemd-logind to prevent the system from
rebooting or similar operations while udisks operations are ongoing.
Unfortunately this stops us from using udisks2 during early boot since
systemd-logind is not ready at this point. Make the dependency
configureable so we can opt-out of using systemd-logind.
* Make dbus.service/socket and udisks2.service/socket available early
Disable default dependencies. This avoids those services to be ordered
after sysinit.target, and makes them available before local-fs.target
is reached. All mounts like mnt-data.mount are ordered before
local-fs.target, so breaking this dependency allows to use D-Bus before
mounting local file systems.
This seems fine when using the system bus directly from /run (instead of
/var/run, which is anyway a symlink to /run normally). It seems that
udisks misses /var/lib/udisks2 but it seems not to be required for the
features used so far.
So far the exit code has been evaluated, which seems to be non-zero even
with a regular term signal. With that systemd assumed the service is in
a failed state, when in fact this seems the regular behavior of dropbear
when shutting it down.
* Add udisks2 package
Add latest release of udisks2 as a package. Also disable polkit to avoid
excessive dependencies.
* Add udisks2 and os-agent to Home Assistant OS
* Bump OS Agent to latest version with udisks support
* Add RTL87xx/RTL88xx Bluetooth firmware
Enable Realtek Bluetooth dongles by adding firmware for RTL87xx and
RTL8xx devices.
* Enable Wireless firmwares for OVA and Generic x86-64 machines
Virtual machines might use hardware pass through functionality to get
direct access to wireless hardware. Add all firmwares we use in Generic
x86-64 image also to the OVA image. Also enable Ralink devices for the
two machines.
* Add RTL87xx/RTL88xx Bluetooth firmwares (#1273)
Add RTL87xx/RTL88xx Bluetooth to all devices without on-board Bluetooth.
* 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.
* Use systemd-growfs instead of resize2fs (#1106)
Since systemd 236 systemd has a built-in file system growing mechanism.
The mechanism relies on the kernels online file system resize
capabilities instead of the external resize2fs utility. Online resizing
is supposedly much faster since the kernel takes care of things.
This also makes sure that external file systems get resized which
previously have not been taken care of.
* Drop HA OS specific file system resizing
Since we have systemd-growfs in place now we can drop our file system
resizing code.
* Make sure /dev/disk/by-label/hassos-data is present after resizing
Note: systemd will retry mnt-data.mount later, so at least in theory
this shouldn't really matter. However, the journal has a lot of churn
due to that reordering.
It seems that page table mappings for compressed tables cause issues in
certain situation leading to "zram: Decompression failed!" errors.
Upstream Linux seems to have recognized the problem and a patch to drop
the functionality entirly has been proposed:
https://lore.kernel.org/linux-mm/20201117135632.GA27763@infradead.org/
* Enable hidraw driver (#1120)
The hidraw driver is required by some IoT devices such as Wyze sense or
Jablotron JA-100. Enable the driver on all platforms by default.
It seems that on certain setups the default DNS over TLS mode
"opportunistic" causes delays of ~10s when trying to resolve names. This
is probably caused by providers and/or firewall setups not properly rejecting
connections on port 853.
It seems that also other distributions (such as Arch Linux) still
disable DNS over TLS currently. Side step issues with DNS over TLS by
disabling it for now.
Directing people from discord to this page but there wasn't any mention they will likely be needing quirks enabled for usb boot on Rpi4. Also some minor layout adjustments on that section.
The EEPROM upgrade 2020-10-28 causes issues with JMS583 or JMS580
controller from Jmicron. Others reported that the same update fixes
reboot issues. Currently there is no Raspberry Pi 4 firmware which works
for all cases. Therefor don't ship an EEPROM upgrade so users can flash
and continue using what works for their setup.
Old Laptops are a popular choice to run Home Assistant: They have low
power consumption, are relatively fast and cheap to come by. However,
closing their lid by default puts a Linux system into suspend. This is
not what the typical user of Home Assistant OS wants. Ignore lid
activity in any state by default.
* Add Realtek RTL8812AU out-of-tree driver
This adds support for Realtek RTL8812AU devices such as the Hardkernel
WiFi Module 5A (with the RTL8811AU chipset, supported by this driver as
well). This patch uses Realtek driver 5.9.3.2 which has been made to
compile up to Linux 5.10.
Note: This driver does not seem to support 5GHz networks! But it seems
the only driver which supports the RTL8811AU chipset and also works with
recent mainline drivers...
* Enable RTL8812AU driver for Hardkernel modules
The WiFi Module 5A comes with a RTL8811AU chipset. Enable the driver for
all Hardkernel modules.
When we write the update to the boot partiton, there is nothing which
makes sure that data is written to disk. This leaves a rather large
window (probably around 30s) where a machine reset/poweroff can lead
to a corrupted boot partition. Use the sync mount option to minimize the
corruption window.
Note that sync is not ideal for flash drives normally. But since we
write very little and typically only on OS update to the boot partition,
this shouldn't be a problem.
After increasing the actual disk image size the capacity field in the
OVF description file still was mentioning 6GB. This seems to be
problematic for VMware hypervisor. Increase the size to 32GB as well.
* Revert "Fix boot from 128GB Micron eMMC on ODROID-N2(+) (#1064)"
This reverts commit 162084082e.
This patches seem to cause issue on a ODROID-N2 with 32GB eMMC.
* Cap eMMC frequency to 24MHz in U-Boot for ODROID-N2(+)
Also remove the ODROID-C4 specific patch.
* Avoid waiting for external drive unnecessarily
Even though the condition to start hassos-data.service is not met (the
file /mnt/overlay/data-move is not there by default), it seems that
systemd waits for the dependencies for hassos-data.service. Don't
Require or Wants any dependencies which might not be present by
default.
* Use systemd to wait for partition using partlabel device
* Use sfdisk which allows to wipe filesystem signatures
Even though we zap the partition table using sgdisk, the file system
superblock (which contains the file system label) does survive. This
can cause problems when trying to reuse a disk previously already
labeled using hassos-data: It might take precendence on next boot
over the existing data partition on the eMMC.
Make sure to clean all file system signatures using sfdisk.
VMware as well as Qemu emulate LSI53C1030 SCSI controller when choosing
a SCSI controller has host interface for disks. For VMware this seems
to be the default choice. Enable the driver by default.
* Make the datactl command more robust
Validate target disk (partition) size to avoid a copy attempt which will
fail. If e2image operation fails, make sure the leftover copy is not
regonized as data partition.
* Fix hassos-data service device unit dependencies
In case the data partition is missing avoid using the Docker command.
The Docker command triggers a socket activation, which in turn makes
systemd wait for the data partition. This blocks entry into the shell
forever.
Just enter the shell in case data partition is not mounted.
* Rewrite datactl command
Prepare the target partition as part of the datactl command. Rely on
partlabel for the target disk since we are always using GPT on the
target disk. Use systemd and partlabel mechanism to wait and find
the target data disk. Keep using the file system label to identify
the source disk.
Also use e2image instead of raw dd to move data. This should
speed up the processes significantly.
* Fix corner case when reusing same disk again
* Add find utility helpful to find things
* Add hwclock utility useful to debug RTC issues
* Remove several utilities which are provided by util-linux (such as
dmesg, mount, blkid etc.)
* Drop unused utilities e.g. for raw nand (nandread/write/ubi)
Fix ethernet PHY reset timing to make sure the link comes up when
reconfiguring the link.
Also drop 0006-clk-meson-g12a-mark-fclk_div2-as-critical.patch which has
been applied in v5.9.2 stable release.
The version banner was showing "Amlogic Meson G12A (Unknown) Revision
28:0 (0:0)" in all cases instead of the correct SoC name and revision.
Make sure the SoC revision is properly read also for the banner.
* Add sound card by default using the hdaudio driver (#925)
* Use virtio-net for VirtualBox
The virtio-net driver is a paravirtualization driver which means less
overhead than virtualizing a full network card. The driver is supported
by VirtualBox since several releases by now.
* Use full OS name in product name.
The change "Avoid trying to boot non-existing kernel image in failover
case" introduced a broken boot script on Raspberry Pi (when booting from
partition B) and ODROID-XU4.
* Bump dev channel after build
Bump version on dev channel automatically when building a dev branch
pre-release.
Co-authored-by: Joakim Sørensen <hi@ludeeus.dev>
HAOS builds add a lot of files and things get quickly messy. Use a
directory per build.
Also don't abort the complete build if a single board failed, we still
might be interested in the rest.
* Add 2020-10-28 beta EEPROM
This improves boot from USB and speeds up boot times.
also includes sd card v1 boot reliability.
see https://github.com/raspberrypi/rpi-eeprom/pull/246
Also add HDMI_DELAY=0 so HDMI display is always visible
for easier debugging.
* Add development build version part to version number
Add third part in the version number to indicate development builds.
Generate a default version number based on the date, e.g.
"5.6.dev20201124".
* Add GitHub Action workflow for development builds
Add another GitHub workflow for development builds. Make it triggered
only for now. The version number is generated by the workflow and
passed to all builds to make sure all builds have the same development
build version.
* Add documentation
* Avoid trying to boot non-existing kernel image in fail-over case
The A/B update system automatically switches to the other boot slot when
booting fails. However, in a fresh installation, only boot slot A
exists. If booting fails three times (e.g. if somebody plugs out power
before the slot can be marked as good), then the system switches to boot
slot B which does not contain a kernel image yet. Avoid trying to boot
the non-existing kernel image.
With this change, if slot B is empty U-Boot will restore both slots to 3
attempts and retry booting from slot A on next reboot:
```
Trying to boot slot B, 2 attempts remaining. Loading kernel ...
** Unrecognized filesystem type **
No valid slot found, resetting tries to 3
storing env...
```
Co-authored-by: Pascal Vizeli <pascal.vizeli@syshack.ch>
* Fix N2+ boot by disabling USB enumeration
On some devices USB enumeration in U-Boot seems to freeze:
starting USB...
Bus usb@ff500000: Register 3000140 NbrPorts 3
Starting the controller
USB XHCI 1.10
scanning bus usb@ff500000 for devices... <freeze>
We don't use USB currenty in the U-Boot script, disable it for now.
* Disable USB enumeration on all ODROID devices
The current default size of 6GB can fill up pretty quickly. Since most
disk images we offer resize dynamically its not really problem to ship
with a bigger default size. It avoids support cases when people forget
to increase the disk image size.
* Remove busybox Linux module support
Since systemd relies on the upstream Linux kernel module handling
utility "kmod" the busybox implementations are not required. Already
today the official "kmod" utility takes precedence:
haos # ls -la /usr/sbin/*mod*
lrwxrwxrwx 1 root root 11 Nov 11 11:32 /usr/sbin/depmod -> ../bin/kmod
lrwxrwxrwx 1 root root 11 Nov 11 11:32 /usr/sbin/insmod -> ../bin/kmod
lrwxrwxrwx 1 root root 11 Nov 11 11:32 /usr/sbin/lsmod -> ../bin/kmod
lrwxrwxrwx 1 root root 11 Nov 11 11:32 /usr/sbin/modinfo -> ../bin/kmod
lrwxrwxrwx 1 root root 11 Nov 11 11:32 /usr/sbin/modprobe -> ../bin/kmod
lrwxrwxrwx 1 root root 11 Nov 11 11:32 /usr/sbin/rmmod -> ../bin/kmod
* Move modprobe configuration alsa-base.conf to correct location
The official modprobe package from kmod checks three locations:
/etc/modprobe.d/, /lib/modprobe.d/ and /run/modprobe.d/. Since usr-move
/lib is a symlink to /usr/lib, the correct location for distribution
provided modprobe files is /usr/lib/modprobe.d.
* Initial version of release workflow using GitHub Actions
Add release workflow using GitHub Actions to replace the current Azure
DevOps pipeline. Currently the same functionality is implemented. This
uses multiple builds in parallel to make better use of CPU resources.
Remove Azure DevOps pipeline.
* Add GitHub Actions workflow for pull-request checks
Lint Dockerfile and shell scripts when PRs are opened.
* Use multiple runners in parallel
Buildroot has stretches where CPU resources are not fully utilized.
Spawn multiple builds accross builders to increase load. Also sort them
by architecture to maximize ccache hit rate.
* Checkout before validate version
* Add resolved.conf to disable stub resolver and DNSSEC
There are Add-Ons which try to bind port 53 on all interfaces including
127.0.0.53. Disable the stub resolver to make them continue working. We
don't need the resolver currently anyway.
Also disable DNSSEC to make sure the baords can access a NTP time server
even when their time is incorrect (since DNSSEC validation may fail).
This is a known chicken-egg problem with systemd-resolved/systemd-timesyncd
and might be addressed in a future version, with what we can reenable
DNSSEC:
https://github.com/systemd/systemd/issues/5873
* Make sure resolve gets added only once to nsswitch.conf
Only add resolve to nsswitch.conf if not already present.
* Use double quote to prevent globbing and exit with error in case
directory doesn't exit in hassos-hook.sh
* echo flags are undefined in POSIX, use bash instead in
bluetooth-rtl8723
* Use /run as default location for lock files for U-Boot tools
While there is a command line parameter to set the lock file explicitly,
there are other tools invoking fw_setenv (in particular rauc) which do
not set the lock file. Using /run by default makes fw_setenv use the
correct lock file in all situations.
* Don't explicitly set lock file location
Since we patch U-Boot tools to use /run by default setting it explicitly
is unnecessary.
* Change titels to reflect official/new naming
* Use GitHub Actions to trigger Release Drafter
The Add-On is no longer developed and GitHub Actions is the recommended
way to use the Release Drafter
* Update buildroot-patches for 2020.11-rc1 buildroot
* Update buildroot to 2020.11-rc1
Signed-off-by: Stefan Agner <stefan@agner.ch>
* Don't rely on sfdisk --list-free output
The --list-free (-F) argument does not allow machine readable mode. And
it seems that the output format changes over time (different spacing,
using size postfixes instead of raw blocks).
Use sfdisk json output and calculate free partition space ourselfs. This
works for 2.35 and 2.36 and is more robust since we rely on output which
is meant for scripts to parse.
* Migrate defconfigs for Buildroot 2020.11-rc1
In particular, rename BR2_TARGET_UBOOT_BOOT_SCRIPT(_SOURCE) to
BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT(_SOURCE).
* Rebase/remove systemd patches for systemd 246
* Drop apparmor/libapparmor from buildroot-external
* hassos-persists: use /run as directory for lockfiles
The U-Boot tools use /var/lock by default which is not created any more
by systemd by default (it is under tmpfiles legacy.conf, which we no
longer install).
* Disable systemd-update-done.service
The service is not suited for pure read-only systems. In particular the
service needs to be able to write a file in /etc and /var. Remove the
service. Note: This is a static service and cannot be removed using
systemd-preset.
* Disable apparmor.service for now
The service loads all default profiles. Some might actually cause
problems. E.g. the profile for ping seems not to match our setup for
/etc/resolv.conf:
[85503.634653] audit: type=1400 audit(1605286002.684:236): apparmor="DENIED" operation="open" profile="ping" name="/run/resolv.conf" pid=27585 comm="ping" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Drop AVAHI and use systemd-resolved to announce hostname via mDNS
and LLMNR. Also continue to offer the _workstation._tcp.local service
since it is used by the CoreDNS mDNS plug-in.
* Bump Raspberry Pi kernel to 5.4
Bump kernel to the downstream Raspberry Pi 5.4 kernel. Drop patches
already merged upstream and use rebased patches for USB reset
controller (required for U-Boot 2020.10 for USB SSD boot).
* Add compatible node for upstream U-Boot
Add brcm,bcm2835-pl011 to make upstream U-Boot bind with the
bcm283x_pl011 driver. This allows to boot with the device tree provided
by the Raspberry Pi Linux kernel 5.4 even without enable_uart=1.
After running HAOS on my ODROID N2+ several hours I see freezes and
sometimes stack traces which point to a problem in CPU frequency
scaling. This crash seems not to appear on Hardkernel's 18.04 Ubuntu
stable release. However, Hardkernel's Ubuntu uses the performance
governor. Use the performance governor as well to avoid crashes on N2+.
In case a container image is corrupted `docker inspect` might fail:
# docker inspect --format='{{.Id}}' "${SUPERVISOR_IMAGE}"
Error response from daemon: readlink /mnt/data/docker/overlay2: invalid argument
In that same state the `docker images` command still shows the images.
Since `docker inspect` returns an error SUPERVISOR_IMAGE_ID will be empty
and a simple `docker pull` will be attempted. That does not suffice to
recover from a corrupted container image.
Use `docker images` to get the image ids and make sure to delete all
image ids found by that command.
Also don't use RuntimeDirectory since it deletes the runtime directory
between the service start attempts which defeats the purpose.
This reverts commit c92b4b54be.
Pure GPT would be nice, but older EEPROM/firmware version seem not to
handle it properly (before EEPROM 2020-09-03/firmware 2020-10-22). Since
devices still get shipped with older EEPROM we currently moving to pure
GPT would make those devices not booting.
Stick with hybrid mode for now to make sure HAOS boots on all devices no
matter if a new or old EEPROM is in use.
* Simplify self healing capabilities of Supervisor service
Instead of relying on time based information on how long the container
has been running use a startup marker file to infer if the last startup
has been successful.
* Update buildroot-external/rootfs-overlay/usr/sbin/hassos-supervisor
Co-authored-by: Pascal Vizeli <pascal.vizeli@syshack.ch>
Co-authored-by: Pascal Vizeli <pascal.vizeli@syshack.ch>
The landingpage container is a minimal webserver with built-in zeroconf
annoucement. Preinstall the machine specific landingpage container to
make sure it will show up right after startup.
* automatically fsck to repair partitions
* add fsck.fat so rpi boot partition can be repaired
* Use Wants= instead of Requires=
Co-authored-by: Pascal Vizeli <pascal.vizeli@syshack.ch>
* add dosfstools to all images
* run hassos-data and hassos-expand after fsck
Co-authored-by: Pascal Vizeli <pascal.vizeli@syshack.ch>
* Make sure to set board_rev for N2+ correctly
For some reason the code to set the environment did not make it into the
ODROID N2 board code. Fix the patch to correctly set board_rev for N2(+).
Also remove the w400 patch as it is no longer required.
* Use latest ODROID-N2+ patches
Use the queued patches (and fixes) for upstream ODROID-N2+ support.
This uses the clock settings from meson-g12b-a311d.dtsi running the
CPUs at the following clocks:
- 4xA73@2.2GHz
- 2xA53@1.8GHz
Instead of reverting the CDC ACM cool-down patch fix the intention of
that change. This should fix the error recovery paths in the CDC ACM
driver and allow CDC ACM devices to continue working even in the event
of USB issues.
Revert CDC ACM cool-down patch. This should fix the error recovery paths
in the CDC ACM driver and allow CDC ACM devices to continue working even
in the event of USB issues.
* Bump ODROID boards to Linux 5.9.1
This makes quite some patches obsolete which since have been upstreamed.
* Drop Linux 5.7 header symbols
Since we do not introduce new packages which actually require a newer
kernel headers, there is no value in having config symbols for the new
kernel version. Buildroot is still using the headers from our kernel,
and hence gets the latest version of the headers.
The Docker socket path is /run/docker.sock. Also only one path can be
used per property. This fixes the supervisor service, which currently
refuses to start due to missing Docker socket.
The patch causes U-Boot freezes in some configurations. The root cause
is that U-Boot does not allow to use the bss section in pre-relocation
code (which is where the UART is used). Drop the patch as it is not
required currently.
See also:
http://u-boot.10912.n7.nabble.com/RPi4-U-Boot-freeze-td424432.html#a427198
The to symlink serial0/1 currently might apply to the first or second
ttyAMAX instance. In downstream, a patch makes sure that the first
PL011 is always ttyAMA0. However, upstream the numbering depends on the
UART alias, which leads to the first PL011 being ttyAMA1.
Check the actual iobase too to make sure we are dealing with the first
PL011 instance.
See also:
05cfe136f7 (diff-2678c183f503319c8d8c09c818af789a)
The new readline utilty used by the CLI add-on requires the size of the
terminal to be set. Use the resize command to initialize terminal size
on login if we are running on a serial terminal.
The U-Boot build system creates a ready to use idbloader.img. A earlier
commit dropped the HAOS code to create the same. However, the commit
missed copying the one built by U-Boot. Make sure idbloader.img gets
copied to the image output directory.
Currently the Microsoft Reserved Partition GUID is used for this FAT32
formatted partition. This GUID is a rather Microsoft Windows specific
GUID and not commonly used on Linux.
On Linux systems partitions of this type do not get automatically
mounted (see /usr/lib/udev/rules.d/80-udisks2.rules). However, since
this partition contains some files user commonly need to adjust
(config.txt, cmdline.txt) it would be good if the partition does get
mounted.
Use Microsoft Basic Data instead, which is used by default for FAT32
partition (even by Linux partitioning tools such as gparted). Tested
on ASUS Tinker Board and RPi4.
The hassos-expand script calls sfdisk to find free disk space. It seems
that today it considers the space before the first partition as free:
$ sudo sfdisk -Fq /dev/sdi
Start End Sectors Size
2048 16383 14336 7M
This causes the script to always resize. It seems not to cause harm to
the partition table (it does not resize really). However, the call to
partx seems to confuse systemd and kill the mnt-data.mount process
(presumably because udev causes remove/add events for the by-label
device units).
Consider everything below 8MiB to not be worthy of a size change. This
avoids missdetection and resize attempts where there is no need.
* Remove rk3288-xt-q8l-v10.dts related patches
We only support ASUS Tinker Board, so no need for those patches.
* Remove unnecessary patches and rebase some for Tinker Board S
Some patches only apply to the Tinker Board device tree. Rebase them to
apply to the dtsi file so they apply for both boards, the Tinker Board
and the Tinker Board S board.
Support custom output directories akin to how buildroot supports O=.
This allows to use separate output directory per board, e.g. using
make O=output_odroid-n2.
* Fix Tinker Board S (eMMC) boot (#650)
Use Tinker Board S U-Boot configuration which is capable to boot from
eMMC as well as from SD card.
Note that this makes U-Boot always claiming to run on Tinker Board S:
..
Model: Rockchip RK3288 Asus Tinker Board S
..
It seems that there is no generic Tinker Board configuration. However,
Tinker Board S configuration really seems to work well with Tinker Board
as well, so just use it.
Also today the U-Boot Makefile seems to generate a working idbloader.img
already. Drop our special handling.
* Use Tinker Board S device tree if booting from eMMC for Linux
Instead of patching the Tinker Board device tree, select the device tree
based on what device we are booting from.
Note: This boots the non-S device tree when booting a Tinker Board S
from SD card! But there is no reliable detection otherwise, so let's
just live with that fact.
* Document how to use our U-Boot to flash eMMC
Aligning partitions (and hence file system structures) to higher level
then 512 byte sectors is common practise and highly recommended for flash
backed block devices. It makes sure that the underlaying flash translation
layer (FTL) does not amplify writes due to missalignment of its erase
block size. Use a 1MiB boundary which is what a modern fdisk is doing.
Before this change:
# fdisk /dev/mmcblk0
Welcome to fdisk (util-linux 2.35.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/mmcblk0: 14.57 GiB, 15634268160 bytes, 30535680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x48617373
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 16384 65537 49154 24M c W95 FAT32 (LBA)
/dev/mmcblk0p2 65539 1228814 1163276 568M 5 Extended
/dev/mmcblk0p3 1228816 1425425 196610 96M 83 Linux
/dev/mmcblk0p4 1425427 30535679 29110253 13.9G 83 Linux
/dev/mmcblk0p5 65540 114693 49154 24M 83 Linux
/dev/mmcblk0p6 114695 638984 524290 256M 83 Linux
/dev/mmcblk0p7 638986 688139 49154 24M 83 Linux
/dev/mmcblk0p8 688141 1212430 524290 256M 83 Linux
/dev/mmcblk0p9 1212432 1228814 16383 8M 83 Linux
After this change:
# fdisk /dev/mmcblk0
Welcome to fdisk (util-linux 2.35.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/mmcblk0: 14.57 GiB, 15634268160 bytes, 30535680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x48617373
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 16384 65535 49152 24M c W95 FAT32 (LBA)
/dev/mmcblk0p2 65536 1239039 1173504 573M 5 Extended
/dev/mmcblk0p3 1241088 1437695 196608 96M 83 Linux
/dev/mmcblk0p4 1439744 30535679 29095936 13.9G 83 Linux
/dev/mmcblk0p5 67584 116735 49152 24M 83 Linux
/dev/mmcblk0p6 118784 643071 524288 256M 83 Linux
/dev/mmcblk0p7 645120 694271 49152 24M 83 Linux
/dev/mmcblk0p8 696320 1220607 524288 256M 83 Linux
/dev/mmcblk0p9 1222656 1239039 16384 8M 83 Linux
See also:
https://unix.stackexchange.com/questions/248939/how-to-achieve-optimal-alignment-for-emmc-partitionhttp://3gfp.com/wp/2014/07/formatting-sd-cards-for-speed-and-lifetime/
Remove code duplication and make sure to load socinfo only once. Also
set board_rev before MAC address to make sure board_rev is set even if
loading MAC address from efuses fails.
This makes sure that the kernel module loop is loaded, the loop devices
under /dev have been created before the container starts. Docker uses
the current /dev as template for the container /dev. If the loop entries
are missing, loop devices can't be used inside the container. Use
losetup which does not make assumption weather loop support is built-in.
This fixes issues seen on my machine when entering the build environment
the first time after build:
mount: /mnt/data: failed to setup loop device for /export/data.ext4.
make[2]: *** [package/pkg-generic.mk:364: /build/buildroot/output_rpi4/build/hassio-1.0.0/.stamp_target_installed] Error 32
* Add ODROID-N2+ support
Add ODROID-N2+ support with the new SoC revision c. Extend the U-Boot
script: Assume ODROID-N2 if the SoC revision is "a" (there are only "a"
revision SoCs on ODROID N2) and assume N2+ otherwise.
Currently using overclock mode as proposed in the upstream kernel patches.
* Update hassos-hook.sh
Co-authored-by: Pascal Vizeli <pascal.vizeli@syshack.ch>
* Backport USB PCIe/XHCI patches to U-Boot 2020.07
Backport relevant patches required to make PCIe/USB XHCI work.
* Backport/integrate PCIe device tree changes from upstream Linux
U-Boot uses the device tree provided by upstream Linux. Make sure the
device tree has the relevant chanages to make VL805 USB controller
reset work.
* Document RPi 4 USB mass storage support (#746)
Unfortunately builds for 32-bit seem to lead to freezes. Conservatively
only update to 2020.07 for 64-bit builds.
Co-authored-by: Malcolm Lashley <mlashley@gmail.com>
Co-authored-by: Malcolm Lashley <mlashley@gmail.com>
The proposed changed is to run the qemu guest agent for QEMU hypervisor. QEMU hypervisor and KVM hypervisor are using the same guest agent.
systemd allow detecting the difference between the two hypervisors. The change is using OR trigger, meaning it will trigger if one of the "ConditionVirtualization" rules is true.
Brutally added patch command after download.
> I'm not a buildroot expert but the best way seemed to move the
> upstream btuart download in a PRE_PATCH_HOOK so that standard
> buildroot way of patching can be applied.
I've been finally able to test it and the PRE_PATCH_HOOK does not work
seems it's never triggered.
I tried also th POST_RSYNC_HOOK that works but still patch is not
applied.
I think that patch is not detected (odd, patch naming seems complient)
or since source code is not downloaded buildroot thinks that patch is
not needed, couldn't sort it out.
This problem is referenced in many different issues, some of them:
Bluetooth: hci0: Frame reassembly failed (-84)
https://github.com/raspberrypi/firmware/issues/1150
Error communicating with local bluetooth adapter (RPi3)
https://github.com/home-assistant/core/issues/30147
Xiaomi BLE Temperature and Humidity sensor no longer working after update from 0.95.4 to .096.5
https://github.com/home-assistant/core/issues/25704
Xiaomi BLE Temperature and Humidity sensor
https://github.com/home-assistant/core/issues/24313#issuecomment-578554315
Solution seemed to reeduce the boud rate of the serial connection to BT
on rpi3b where flow control is missing.
The patch to the original btuart file is to reduce the baudrate only for
rpi3b models where flow control is missing:
- $HCIATTACH /dev/serial1 bcm43xx 921600 noflow - $BDADDR
+ $HCIATTACH /dev/serial1 bcm43xx 460800 noflow - $BDADDR
I'm not a buildroot expert but the best way seemed to move the
upstream btuart download in a PRE_PATCH_HOOK so that standard
buildroot way of patching can be applied.
Can be found in the [Configuration panel -> Settings -> Info](https://my.home-assistant.io/redirect/info/). It is listed as the `Board` value.
[](https://my.home-assistant.io/redirect/info/)
- type:input
validations:
required:true
attributes:
label:What version of Home Assistant Operating System is installed?
placeholder:"6.6"
description:>
Can be found in the [Configuration panel -> Settings -> Info](https://my.home-assistant.io/redirect/info/). It is listed as the `Host Operating System` value.
- type:dropdown
validations:
required:true
attributes:
label:Did you upgrade the Operating System.
options:
- "Yes"
- "No"
- type:textarea
validations:
required:true
attributes:
label:Steps to reproduce the issue
description:|
Please tell us exactly how to reproduce your issue.
Provide clear and concise step by step instructions and add code snippets if needed.
value:|
1.
2.
3.
...
- type:textarea
validations:
required:true
attributes:
label:Anything in the Supervisor logs that might be useful for us?
description:>
Supervisor Logs can be found under [Configuration panel -> Add-ons, Backup & Supervisor -> System](https://my.home-assistant.io/redirect/supervisor_logs/), then choose Log Provider `Supervisor`.
[](https://my.home-assistant.io/redirect/supervisor_logs/)
render:txt
- type:textarea
validations:
required:true
attributes:
label:Anything in the Host logs that might be useful for us?
description:>
Supervisor Logs can be found under [Configuration panel -> Add-ons, Backup & Supervisor -> System](https://my.home-assistant.io/redirect/supervisor_logs/), then choose Log Provider `Host`.
render:txt
- type:textarea
attributes:
label:System Health information
description:>
**Optional** Copy the full System Health in this text area.
Can be found in the [Configuration panel -> Settings -> Info](https://my.home-assistant.io/redirect/info/).
Use the copy icon on top right and choose `For GitHub`.
- type:textarea
attributes:
label:Additional information
description:>
**Optional** If you have any additional information for us, use the field below.
Please note, you can attach screenshots or screen recordings here, by
| Tinker S RK3288| January 2018 | yes | [tinker](../../../buildroot-external/configs/tinker_defconfig) |
| Tinker Edge T | November 2019 | no? | |
| Tinker Edge R | November 2019 | no? | |
## eMMC
eMMC support is provided with the same image. Just flash the image to the eMMC by connecting your Tinker Board S to your PC via Micro-USB. Refer to the Tinkerboard documentation how-to flash using Micro-USB and UMS.
The Home Assistant OS provided U-Boot does support UMS as well,
however manual intervention is necessary:
1. Set the jumper between Micro-USB and HDMI the maskrom mode
2. Insert SD card and connect the board via Micro-USB to your PC
3. Continusly press Ctrl+C to interrupt boot
4. Set the jumper back to the park position
5. Start UMS using:
```
ums 0 mmc 0
```
6. A mass storage device should appear. Flash Home Assistant OS to it.
## Serial console
To access the terminal over serial console, add `console=ttyS2,115200` to `cmdline.txt`. GPIO pins are: 34 = GND / 32 = UART TXD / 33 = UART RXD.
Odroid-C4 support is based heavily on the Odroid-C2 and N2 configurations. Given the similarity of the SoCs, as well as the comparable level of support in the Linux kernel, the C4 should hopefully present few surprises. However, Home Assistant support should be regarded as experimental.
Please also refer to the documentation pages for the [Odroid-C2](./odroid-c2.md) and [Odroid-N2](./odroid-n2.md), as some of that information may apply to the C4 as well.
Common C4 issues that have been specifically tested and appear to be working:
- boot from SD
- boot from eMMC
- MAC address obtained from eFuse
## GPIO
Refer to [the odroid wiki](https://wiki.odroid.com/odroid-c4/hardware/expansion_connectors).
The Odroid XU4 has a hidden boot sector that is only visible on the Odroid itself (can't be written by a card reader). There are a couple possibilities:
1) If the eMMC already had a working image before flashing HassOS:
* It will be booting to uBoot (but no further).
* If you have the serial adapter, you should be able to enter `distro_bootcmd` at the uboot prompt to continue booting.
* If not, flash the HassOS image to an SD card and boot off that temporarily (while the eMMC is also plugged in).
* Once booted, login at the prompts and then enter `dd if=/dev/mmcblk0 of=/dev/mmcblk0boot0 bs=512 skip=63 seek=62 count=1440` at the linux prompt.
* Reboot with eMMC (don't forget to flip the boot switch to eMMC)
2) Clean/wiped/corruped boot sector:
* You'll need to follow [Hardkernel's instructions](https://forum.odroid.com/viewtopic.php?f=53&t=6173) to get a working boot sector. Then flash HassOS and follow instructions above.
* Alternatively, you can try flash HassOS to both an SD and eMMC, then boot off the SD with the eMMC also plugged in, then run `dd if=/dev/mmcblk1 of=/dev/mmcblk0boot0 bs=512 skip=1 seek=0 count=16381` at the Linux prompt. Note that this is untested, but in theory should work..
The ODROID XU4 uses the eMMC boot partition to boot from. Typically eMMC readers can't write to this eMMC boot partition. There are a couple of possibilities:
1.**Working** e.g. the eMMC already had a working image before flashing HassOS:
- It will be booting to U-Boot (but no further).
- If you have the serial adapter, you should be able to enter `distro_bootcmd` at the uboot prompt to continue booting.
- If not, flash the HassOS image to an SD card and boot off that temporarily (while the eMMC is also plugged in).
- Once booted, login at the prompts and then enter `dd if=/dev/mmcblk0 of=/dev/mmcblk0boot0 bs=512 skip=63 seek=62 count=1440` at the linux prompt.
- Reboot with eMMC (don't forget to flip the boot switch to eMMC)
2.**Not Working** e.g. a clean/wiped/corruped eMMC boot partition:
- You'll need to follow [Hardkernel's instructions](https://forum.odroid.com/viewtopic.php?f=53&t=6173) to get a working boot sector. Then flash HassOS and follow instructions above.
- Alternatively, you can try flash HassOS to both an SD and eMMC, then boot off the SD with the eMMC also plugged in, then run `dd if=/dev/mmcblk1 of=/dev/mmcblk0boot0 bs=512 skip=1 seek=0 count=16381` at the Linux prompt. Note that this is untested, but in theory should work..
If you are getting permissions issues when using the dd command, try disabling RO:
`echo 0 > /sys/block/mmcblk0boot0/force_ro`
to re-enable after running dd:
`echo 1 > /sys/block/mmcblk0boot0/force_ro`
## Console
By default, console access is granted over the serial header and over HDMI. Certain startup messages will only appear on the serial console by default. To show the messages on the HDMI console instead, swap the order of the two consoles in the `cmdline.txt` file on the boot partition. You can also delete the SAC2 console if you don't plan on using the serial adapter.
Using this VMDK in a virtual machine requires the following:
- Operating system: Other 4.x or later Linux (64-bit)
- Enabled support for UEFI boot
- SATA disk controller
- Minimal of 1GB RAM
- At least 2x vCPU
- An assigned network
# OVA (Open Virtual Appliance)
Currently, we only publish a VMDK virtual disk, due to issues with our previous OVA distribution. We are currently investigating our options to bring back the OVA distribution. However, the VMDK works on the following hypervisors:
Currently we only publish a VMDK virtual disk due to issues with our previous OVA distribution. We are investigating our options to bring back the OVA distribution, however, the VMDK works for the hypervisors listed above.
## Requirements
Using this VMDK in a virtual machine requires the following:
- Operating system: Other 4.x or later Linux (64-bit)
The 64bit version is under development by RPi-Team. It work very nice but it could have some impacts. Actual we see that the SDcard access with ext4 are a bit slower than on 32bit.
## Serial console
For access to terminal over serial console, add `console=ttyAMA0,115200` to `cmdline.txt` and `enable_uart=1`, `dtoverlay=pi3-disable-bt` into `config.txt`. GPIO pins are: 6 = GND / 8 = UART TXD / 10 = UART RXD.
## I2C
Add `dtparam=i2c1=on` and `dtparam=i2c_arm=on` to `config.txt`. After that we create a module file on host with [config usb stick][config] or direct into `/etc/modules-load.d`.
rpi-i2c.conf:
```
i2c-dev
i2c-bcm2708
```
## USB Boot
USB mass storage boot is available on Raspberry Pi 3B, 3B+, 3A+, and 2B v1.2.
To enable USB boot, add `program_usb_boot_mode=1` into `config.txt`. Note that this **permanently** alters the one-time programmable memory of the device.
For more information see [RaspberryPi](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md).
### Caveats
* All bootable SD cards must be removed.
* Boot time can be significantly longer with USB. This is due to the boot process first attempting to boot from SD card, failing, and resorting to USB.
* Many USB drives simply do not work for boot. This is likely due to minimal driver support in uboot and will not be fixed. If you can't get it to boot on one drive, try a different brand/model. SanDisk Cruzer drives seem to have a higher rate of issues.
## Tweaks
If you don't need bluetooth, disabled it with add `dtoverlay=pi3-disable-bt` into `config.txt`.
| Raspberry Pi 4 B |2019 | yes | [rpi4](../../../buildroot-external/configs/rpi4_defconfig) / [rpi4_64](../../../buildroot-external/configs/rpi4_64_defconfig) |
## Serial console
For access to terminal over serial console, add `console=ttyAMA0,115200` to `cmdline.txt` and `enable_uart=1`, `dtoverlay=pi3-disable-bt` into `config.txt`. GPIO pins are: 6 = GND / 8 = UART TXD / 10 = UART RXD.
## I2C
Add `dtparam=i2c1=on` and `dtparam=i2c_arm=on` to `config.txt`. After that we create a module file on host with [config usb stick][config] or direct into `/etc/modules-load.d`.
rpi-i2c.conf:
```
i2c-dev
i2c-bcm2708
```
## USB Boot
USB mass storage boot is available on Raspberry Pi 4 (64-bit only), 3B, 3B+, 3A+, and 2B v1.2.
For Raspberry 3B, 3A+ and 2B v1.2, to enable USB boot, add `program_usb_boot_mode=1` into `config.txt`. Note that this **permanently** alters the one-time programmable memory of the device.
For Raspberry 4
* Make sure to update the bootloader to a stable release supporting USB mass storage boot (see [bcm2711_bootloader_config.md](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md#usbmassstorageboot)).
* If no SD card is used add `sd_poll_once=on` to `dtparam` in `config.txt` (comma separated). This gets rid of `mmc0: timeout waiting for hardware interrupt` kernel errors.
* If install still fails, then your SSD likely needs quirks enabled to work correctly (see [Finding the VID and PID of your USB SSD](https://www.raspberrypi.org/forums/viewtopic.php?t=245931)). Once you find your adapter's ID, add the quirks parameter in `cmdline.txt`.
For more information see [RaspberryPi](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md).
### Caveats
* All bootable SD cards must be removed.
* Boot time can be significantly longer with USB. This is due to the boot process first attempting to boot from SD card, failing, and resorting to USB.
* Many USB drives simply do not work for boot. This is likely due to minimal driver support in uboot and will not be fixed. If you can't get it to boot on one drive, try a different brand/model. SanDisk Cruzer drives seem to have a higher rate of issues.
## Tweaks
If you don't need bluetooth, disabled it with add `dtoverlay=pi3-disable-bt` into `config.txt`.
You can use an USB drive with HassOS to configure network options, SSH access to the host and to install updates.
Format a USB stick with FAT32/EXT4/NTFS and name it `CONFIG` (in all capitals). Alternative you can create a `CONFIG` folder inside boot partition. Use the following directory structure within the USB drive:
Format a USB stick with FAT32/EXT4/NTFS and name it `CONFIG` (in all capitals). Alternative you can create a `CONFIG` folder inside the `boot` partition. Use the following directory structure within the USB drive:
```text
network/
@@ -19,12 +19,14 @@ hassos-xy.raucb
- The `modules` folder is for modules-load configuration files.
- The `modprobe` folder is for modules configuration files (/etc/modprobe.d)
- The `udev` folder is for udev rules files.
- The `authorized_keys` file activates debug SSH access on port `22222`. See [Debugging Hassio][debug-hassio].
- The `authorized_keys` file activates debug SSH access on port `22222`. See [Debugging Home Assistant][debug-homeassistant].
- The `timesyncd.conf` file allow you to set different NTP servers. HassOS won't boot without correct working time servers!
- The `hassos-*.raucb` file is a firmware OTA update which will be installed. These can be found on on the [release][hassos-release] page.
Text files that are on USB stick must have Unix (LF) end of line characters. If you create USB stick on Windows machine, be sure to use Notepad++, Visual Studio Code or any other editor, that supports different line endings. In Notepad++ LF EOL can be enabled with setting `Edit -> EOL Conversion -> Unix (LF)`.
You can put this USB stick into the device and it will be read on startup and files written to the correct places. You can also trigger this process later over the
API/UI or by calling `systemctl restart hassos-config` on the host. *The USB Stick just needs to be insterted to the device during this setup process and can be disconnected afterwards.*
API/UI or by calling `systemctl restart hassos-config` on the host. *The USB Stick just needs to be inserted to the device during this setup process and can be disconnected afterwards.*
## Local
@@ -47,7 +49,9 @@ You can manual add, edit or remove connections configurations from `/etc/Network
### NTP
You can manual edit the systemd timesync file on `/etc/systemd/timesyncd.conf`.
The format of version is *MAJOR.BUILD*. Everytime we create a new release with same userland, we bump the build number.
The development number they will be bump for the stable release version and the development version go to next major number.
## Git branch/Tag
The branch `dev` ist the actual development branch and from there we never make a release. The `master` branch contains the development version and from there we build a beta release.
If we create a new staging/productive release, we create a new branch `rel-{MAJOR}`. They will be used for the whole cycle of this release.
## Upload release files
We use [ghr](https://github.com/tcnksm/ghr) to upload files to our repository. A binary version is available inside `scripts`.
First, install **docker** for your distribution - I'd advise to use your distro's provided packages, since that will make sure permissions et al. are sanely set up for what you are about to run. You're also expected to have your current user properly set up in in your sudoers policy, so that this account may elevate to root and execute arbitrary commands as UID 0 (this is required, since at some point during the build process, a new loopback device-backed filesystem image will be mounted inside a docker container - which requires a "privileged" container to run, which can only be done as root).
Now, change your working directory to your hassos repo checkout (please adapt pathnames as needed), make sure your intended changes to the source tree are applied (and committed, ideally :)), and execute the `enter.sh` helper script:
```
$ cd ~/codebase/hassos/
$ sudo scripts/enter.sh
Sending build context to Docker daemon 30.48MB
Step 1/6 : FROM ubuntu:18.04
[...]
---> 4dc25a21556b
Successfully built 4dc25a21556b
Successfully tagged hassbuildroot:latest
```
Note that the current iteration of `enter.sh` will try to load the **overlayfs** kernel module, which is not strictly required for docker's operation, as far as I can tell. It's OK if loading that module fails; the shell script will continue executing. If everything works out, you will find yourself in an interactive login shell inside your docker container/build environment, where you can peek around:
```
root@somehashinhex:/build#
root@somehashinhex:/build# make help
[...]
```
The _hassos_ developers provide a Makefile that will build hassos images for a (rather long!) list of targets. For example run the command below to start building the _ova_ variant, and go make a cup of tea. Or fifteen.
```
root@0db6f7079872:/build# make ova
[...]
```
That will result in a single VMDK image file at the very end of the build process. This image file is a compressed block device dump with a proper GPT partition table, prepared to ship into any OVA-compatible hypervisor's innards. For me, the end of the **ova** build steps looks like this:
The artifacts you just built are placed in the `target/` subdirectory:
```
root@fd292c061896:/build# ls -lh release/
total 141M
-rw-r--r-- 1 root root 141M Oct 10 20:22 hassos_ova-2.2.vmdk.gz
```
In order to be able to use this image file with the **qemu** hypervisor, you'll need to unpack it, and convert it to an image format that qemu can work with. Conveniently, the _hassos_ buildenv already provides all the tools we need for this conversion:
-rw-r--r-- 1 root root 337M Oct 10 20:25 hassos_ova-2.2.qcow2
-rw-r--r-- 1 root root 337M Oct 10 20:22 hassos_ova-2.2.vmdk
```
Now, exit the docker container's environment, and find the build artifacts in the `releases/` directory beneath your repository checkout dir. (The generated files will be owned by _root_; make sure to `chown` them to your user account, if needed.)
From there, qemu can try to boot it. Since the generated image assumes UEFI support in the host/hypervisor, this is slightly more tricky than with "classic"(/legacy) MBR-based images. On the *Debian* host I use to run my qemu virtual machine on, you'll need to install the **ovmf** package, which is described as providing "UEFI firmware for 64-bit x86 virtual machines". That package will install a _TianoCore_-derived qemu UEFI image build at `/usr/share/OVMF/OVMF_CODE.fd`, which we'll use with qemu to boot the generated qcow2 image. (Please adapt pathnames as necessary, for example if you have installed the ovmf firmware image at another location.)
This should pop up qemu's SDL frontend, displaying _hassos_' VT/CLI environment. Specifying addtional options and flags to qemu for network access, keyboard layout et al. are left as an exercise for the reader.
After the boot process has finished, you can log in to _hassos_ without a password, providing *root* as the username. From there, executing `login` on the *hassio>* shell prompt will yield a root shell in the host OS.
HassOS uses NetworkManager to control the host network. In future releases, you will be able to set up the configuration using the API/UI. Currently only a manual configuration using NetworkManager connection files is supported. Without a configuration file, the device will use DHCP by default. These network connection files can be placed on a USB drive and imported to the host as described in [Configuration][configuration-usb].
Home Assistant Operating System uses NetworkManager to control the host network.
## Configuration Examples
## Configure network
You can read the [Official Manual][keyfile] or find many configuration examples across the internet. The system is read-only, if you don't want the IP address to change on every boot, you should set the UUID property with a generic [UUID4][uuid]. Inside `\CONFIG\network\` on the USB or SD, create a file called `my-network` and add the appropriate contents below:
By default the device will be in DHCP state.
Basic network settings can be set through the Supervisor frontend in the System
tab. Advanced configurations such as VLAN are also available through the
`ha network` CLI command.
To restore the default configuration the `ha network` CLI command can be used as
well:
```
ha network update default --ipv4-method auto
```
If more advanced network settings are required network connection files can be
placed on a USB drive and imported to the host as described in
[Configuration][configuration-usb].
## Manual Network Configuration
If the frontend or `ha network` CLI cannot meet your use case, it is still
possible to configure the underlying NetworkManager manually.
You can read the [NetworkManager manual][nm-manual] or find many configuration
examples across the internet. Note that changes to `NetworkManager.conf` are
not supported currently, only connection keyfiles are supported. Keep in mind
that the system is read-only. If you don't want the IP address to change on
every boot, you should modify the UUID property to a generic [UUID4][uuid].
Inside the `\CONFIG\network\` directory on the USB drive or SD card, create a
file called `my-network` and add the appropriate contents below:
**NOTE: Please make sure to save this file with UNIX line endings (LF, and not Windows' default CRLF endings). You can do this using Notepad these days!**
### Default
We have a preinstalled connection profile:
A preinstalled connection profile for wired network is active by default:
```ini
[connection]
id=my-network
id=Home Assistant OS default
uuid=f62bf7c2-e565-49ff-bbfc-a4cf791e6add
type=802-3-ethernet
llmnr=2
mdns=2
[ipv4]
method=auto
@@ -25,13 +56,15 @@ addr-gen-mode=stable-privacy
method=auto
```
### LAN
### Wired connection to the LAN
```ini
[connection]
id=my-network
uuid=d55162b4-6152-4310-9312-8f4c54d86afa
type=802-3-ethernet
llmnr=2
mdns=2
[ipv4]
method=auto
@@ -41,7 +74,7 @@ addr-gen-mode=stable-privacy
method=auto
```
### Wireless WPA/PSK
### Wireless LAN WPA/PSK
```ini
[connection]
@@ -78,68 +111,83 @@ method=manual
address=192.168.1.111/24;192.168.1.1
dns=8.8.8.8;8.8.4.4;
```
For address, the value before the semicolon is the IP address and subnet prefix bitlength; the second value is the IP address of the gateway.
For `address`, the value before the semicolon is the IP address and subnet prefix bitlength. The second value (after the semicolon) is the IP address of the local gateway.
## Tips
### Reset network
If you want to reset the network configuration back to the default DHCP settings, use the following commands on the host:
If you want to reset the network configuration back to the default connection
profile using DHCP, use the following commands on the host console:
Home Assistant OS will recreate the default connection profile during boot.
### Enabling WiFi
WiFi is discouraged for reliability reasons. However if you're still like to use WiFi, you can us the `ha network` command to set up WiFi (example for a Raspberry Pi 4, check `ha network info` to check if your board supports WiFi and the name of the WiFi device):
```bash
ha network update wlan0 --enabled --ipv4-method auto --wifi-auth wpa-psk --wifi-mode infrastructure --wifi-ssid MY-SSID --wifi-psk MY_PASS
````
### Powersave
If you have trouble with powersave you can do following:
If you have trouble with powersave then apply the following changes:
```ini
[wifi]
# Values are 0 (use default), 1 (ignore/don't touch), 2 (disable) or 3 (enable).
powersave=0
```
## Using nmcli to set a static IPV4 address
Log into the HASSOS base system via a console:
## Using `nmcli` to set a static IPv4 address
Log into the the Home Assistant OS base system via a console:
```bash
Welcome to Home Assistant
homeassistant login:
```
Welcome to HassOS
Hassio login:
- Login as `root` (no password needed). At the `ha >` prompt, type `login` (as instructed).
From there you use the `nmcli` configuration tool.
-`# nmcli con show` will list the "Home Assistant OS default" connection in use.
-`# nmcli con show "Home Assistant OS default"` will list all the properties of the connection.
To start editing the configuration setting for "Home Assistant OS default":
```bash
# nmcli con edit "Home Assistant OS default"
```
Login as `root` (no password needed)
At the `hassio >` prompt, type `login` (as instructed).
From here you will use the `nmcli` configuration tool.
`# nmcli connection show` will list the “HassOS default” connection in use.
`# nmcli con show "HassOS default"` will list all the properties of the connection.
`# nmcli con edit "HassOS default"` will put you in a position to edit the connection.
`nmcli> print ipv4` will show you the ipv4 properties of this connection.
To add your static IP address (select 'yes' for manual method);
```
```bash
nmcli> set ipv4.addresses 192.168.100.10/24
Do you also want to set'ipv4.method' to 'manual'? [yes]:
```
In addition I have found it is wise to set the dns server and the local gateway. For most home routers these will be the same address. If you are using Pi-Hole you can set the dns to that.
```
In addition, it's recommended to set the DNS server and the local gateway. For most home routers the DNS server will have the same IP address as the router itself. If you are using Pi-Hole or a third-party DNS system then you can set the DNS server to that.
```bash
nmcli> set ipv4.dns 192.168.100.1
nmcli> set ipv4.gateway 192.168.100.1
nmcli> save
nmcli> quit
```
`nmcli> print ipv4` will show you the IPv4 properties of this connection. With `nmcli> save` you will save the changes afterwards.
If you now view the default connection `cat /etc/NetworkManager/system-connections/default` you should see the method is manual and the address is set.
Doing a `nmcli con reload` does not always work so restart the VM.
Doing a `nmcli con reload` does not always work, so restart the virtual machine or the physical system.
Hass.io OS based on [buildroot](https://buildroot.org/). It's a hypervisor for Docker and supports various kind of IoT hardware. It is also available as virtual appliance. The whole system is optimized for embedded system and security. You can update the system simple with OTA updates or offline updates.
Home Assistant Operating System (formerly HassOS) is a Linux based operating system optimized to host [Home Assistant](https://www.home-assistant.io) and its [Add-ons](https://www.home-assistant.io/addons/).
## Focus
Home Assistant Operating System uses Docker as Container engine. It by default deploys the Home Assistant Supervisor as a container. Home Assistant Supervisor in turn uses the Docker container engine to control Home Assistant Core and Add-Ons in separate containers. Home Assistant Operating System is **not** based on a regular Linux distribution like Ubuntu. It is built using [Buildroot](https://buildroot.org/) and it is optimized to run Home Assistant. It targets single board compute (SBC) devices like the Raspberry Pi or ODROID but also supports x86-64 systems with UEFI.
- Barebox as bootloader on EFI
- U-Boot as bootloader on IoT
- Linux/Buildroot LTS
-RAUC for OTA updates
-SquashFS LZ4 as filesystem
-Docker-CE
-AppArmor protected
- ZRAM LZ4 for /tmp, /var, swap
## Features
- Lightweight and memory-efficient
-Minimized I/O
-Over The Air (OTA) updates
-Offline updates
-Modular using Docker container engine
## Supported hardware
- Raspberry Pi
- Hardkernel ODROID
- Asus Tinker Board
- Generic x86-64 (e.g. Intel NUC)
- Virtual appliances
See the full list and specific models [here](./Documentation/boards/README.md)
## Getting Started
If you just want to use Home Assistant the official [getting started guide](https://www.home-assistant.io/getting-started/) and [installation instructions](https://www.home-assistant.io/hassio/installation/) take you through how to download Home Assistant Operating System and get it running on your machine.
If you're interested in finding out more about Home Assistant Operating System and how it works read on...
## Development
If you don't have experience with embedded systems, Buildroot or the build process for Linux distributions it is recommended to read up on these topics first (e.g. [Bootlin](https://bootlin.com/docs/) has excellent resources).
The Home Assistant Operating System documentation can be found on the [Home Assistant Developer Docs website](https://developers.home-assistant.io/docs/operating-system).
### Components
- **Bootloader:**
- [Barebox](https://barebox.org/) for devices that support UEFI
- [U-Boot](https://www.denx.de/wiki/U-Boot) for devices that don't support UEFI
- **Operating System:**
- [Buildroot](https://buildroot.org/) LTS Linux
- **File Systems:**
- [SquashFS](https://www.kernel.org/doc/Documentation/filesystems/squashfs.txt) for read-only file systems (using LZ4 compression)
- [ZRAM](https://www.kernel.org/doc/Documentation/blockdev/zram.txt) for `/tmp`, `/var` and swap (using LZ4 compression)
- **Container Platform:**
- [Docker Engine](https://docs.docker.com/engine/) for running Home Assistant components in containers
- **Updates:**
- [RAUC](https://rauc.io/) for Over The Air (OTA) and USB updates
- **Security:**
- [AppArmor](https://apparmor.net/) Linux kernel security module
### Development builds
The Development build GitHub Action Workflow is a manually triggered workflow
which creates Home Assistant OS development builds. The development builds are
available at [os-builds.home-assistant.io](https://os-builds.home-assistant.io/).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.