There should not be anything needed. However if it happens again you may want to pick up a micro-HDMI to HDMI cable so you can plug it into a TV and see where its getting stuck. That will help me fix it and make sure it doesn't happen.
I'm uploading a new DVR v2020.10.24.0043 now. It has a new Add Share UI, which will help you make sure the settings are correct.
Takes all information as correct each step then i hit save. Still get orange triangle and when I add the share under local content nothing imports.
Thanks for the shots. Did you trash the old share before adding the new one?
I'm guessing maybe there is some character in your password which is causing problems. I will try to reproduce it.
Yes trashed all old shares and rebooted before trying with the new update. The only odd character in password is @ if this is the problem I can setup a new user on the share folder with a simpler password.
I am getting the same orange triangle on my share. I am using a local Windows account with no special characters.
I get the same result with a simple password. It brings up a list of all the shares on the DS218 so it is seeing it correctly.
Could you update to DVR 2020.10.24.1720 then submit diagnostics
Ok just submitted.
I submitted mine also.
Maybe I'm missing something again.
It looks like the image doesn't contain fsck.fat On a power fail, the fat32 boot partition is marked dirty and there is no way to repair it without taking the drive to another system?
1 Like
Looks like you're right. I'll add fsck and make sure it gets run.
Were you seeing something get stuck or break with the dirty partition?
I know that you're following the Home Assistant model for a purpose-built distro. But, have you looked into or considered using portable services as a basis instead. Coupled with mkosi, you can have a single image that can be used as a container for Docker, Podman, or systemd-nspawn, or used a self-contained SystemD unit for a portable service, or used as an image for booting/bootstrapping a bare metal installation.
Plus, the added flexibility of properly tagged GPT partitions means that the same image could be used for multiple architectures across various deployments ...
Sounds like a cool set of tools, but I'm not sure it helps with the goal of running on RPI. It doesn't look like mkosi images can be booted on RPI, and honestly there's not much in our "container" to begin with. As you know the dvr server software has almost no dependencies and already runs in any Linux environment.
The primary goal here is to run seamlessly on RPI4, which means most of the work is in a customized EEPROM, VideoCore firmware updater, patched bootloader, customized device tree blob, and patched RPI4 kernel. All of that seems out of scope for mkosi.
We're currently using buildroot.org and I am very happy with it. In the past I have relied on tools like debootstrap and pacstrap for custom x64 OVAs and VMs, but for embedded systems buildroot is the way to go (because of its explicit support for a huge variety of embedded boards).
Sorry, not trying to hijack the thread. Just positing a scenario where Channels can be a single distributable for most Linux-based situations. (Native packages for NAS and some embedded devices are obviously excluded, but many embedded devices can be served, including the Pi4.)
Mkosi images are GPT envelopes containing myriad partitions. A single image can contain:
- ESP containing both x86_64 and aarch64 EFI bootloaders
- A x86_64 root partition
- A aarch64 root partition
- A shared home partition
- A shared srv data partition
The different types can all have different GPT partition types set, so that the bootloaders can all find and properly mount each different partition.
As far as not supporting the Pi4, there is support for using UEFI as the bootloader on the board.
A unified approach such as this could mean that all Linux platforms could feasibly be served by a single distributable image, from bare metal on x86_64, aarch64, and any other EFI-based platform, to allowing that same image to be used as a portable service for an existing distro based on systemd, as well as being used as an OCI-compliant container that could be used with Docker, Podman, LXC, and systemd-nspawn.
Didn't see anything broke with the dirty partition. Just found it in dmesg as I was testing a couple types of USB3 enclosures.
I had left it it a dirty state and your 2020.1025.0608 build did indeed clean it up.
1 Like
This UEFI bootloader is highly experimental and does not support networking at all: https://github.com/pftf/RPi4#initial-notice
I agree a unified approach that can run anywhere sounds very appealing. But I've done this enough times to know that most of the time "run anywhere" practically means "runs well nowhere".
A pipe dream, I suppose. But, it should be noted that recent kernels do feature support/drivers for networking and full RAM access. I guess it's true that the only thing unified standards give us is one more standard to support in addition to add the others.
(I was unaware that networking was an issue with EFI on the Pi4, as it's working fine with OpenBSD.)
You can use nmcli to scan and connect to Wi-Fi. See https://core.docs.ubuntu.com/en/stacks/network/network-manager/docs/configure-wifi-connections
The system is setup such that modifications to NetworkManager's connection list are persisted across upgrades.