ccrisan / thingos Goto Github PK

Hey Crissan,

Maybe I didn't looked deep enough, but I remember that the upgrade procedure changed over time? Can you tell me where I can find it?

Cédric

Is there any reason F2FS (could|should)n't be used for the root file system?

I have both Pi Zero W and Pi Zero.
I've tried 20190911 and 20200606 versions of moionEyeOS for raspberry-pi and they both fail at the wpa_supplicant.conf stage.

What's the issue?

It may also be useful to highlight the link from MotionEye wiki now goes to a different product's page for wpa_supplicant.conf and the example code snippet isn't the same as the one you can find (if you look hard enough) on motioneye wiki.
In brief, the example on "thingos" is missing both "country" and "scan_ssid" params.

For the avoidance of doubt, I followed the instructions to the letter changing the line endings to unix, (this isn't my first Pi rodeo)
I also installed Notepad++ as per recommendation to see if it made a difference - it didn't.
The same wpa_supplicant error was displayed for both versions, using fresh install each time.
None of the install attempts passed the wpa_supplicant step in the init process,
causing a kernel panic due to network and exit from boot process.

What am I doing wrong?
Suggestions gratefully received.

With a normal WebCam, only one image is needed at a time, the current one on the FTP server.
With a recording for example of every 5 minutes a picture.
This means that the older image is overwritten with the new one.
But what are the settings for this?
Every 5 minutes a picture, upload always with the same name on the FTP server.
...Chris

Current GZ disk images are around 70MB each for Raspberry Pis. When upgrading firmware, most of the time is spent downloading the disk image.

Using XZ compression, the same image can be compressed down to 45MB.
Example compression command:
XZ_OPT=-9 tar cJf motioneyeos-raspberrypi.tar.xz motioneyeos-raspberrypi.img

I don't know how much memory is required and how long it takes to extract an XZ file, but it may be a feasible option. If memory and CPU does become a concern, motionEye can always kill off motion software before starting the extract and upgrade process (not sure if it's already doing this).

After merging changes from dev branch, building Raspberry Pi 4 image fails:

2021-05-25T17:09:08.7893348Z make[1]: Leaving directory '/home/runner/work/photOS/photOS/output/raspberrypi4/build/linux-custom'
2021-05-25T17:09:08.7904897Z PATH="/home/runner/work/photOS/photOS/output/raspberrypi4/host/bin:/home/runner/work/photOS/photOS/output/raspberrypi4/host/sbin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/home/runner/.local/bin:/opt/pipx_bin:/usr/share/rust/.cargo/bin:/home/runner/.config/composer/vendor/bin:/usr/local/.ghcup/bin:/home/runner/.dotnet/tools:/snap/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" PKG_CONFIG="/home/runner/work/photOS/photOS/output/raspberrypi4/host/bin/pkg-config" PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_LIBDIR="/home/runner/work/photOS/photOS/output/raspberrypi4/host/lib/pkgconfig:/home/runner/work/photOS/photOS/output/raspberrypi4/host/share/pkgconfig" BR_BINARIES_DIR=/home/runner/work/photOS/photOS/output/raspberrypi4/images KCFLAGS=-Wno-attribute-alias DTC_FLAGS=-@ /usr/bin/make -j3 HOSTCC="/home/runner/work/photOS/photOS/output/raspberrypi4/host/bin/ccache /usr/bin/gcc -O2 -I/home/runner/work/photOS/photOS/output/raspberrypi4/host/include -L/home/runner/work/photOS/photOS/output/raspberrypi4/host/lib -Wl,-rpath,/home/runner/work/photOS/photOS/output/raspberrypi4/host/lib" ARCH=arm INSTALL_MOD_PATH=/home/runner/work/photOS/photOS/output/raspberrypi4/target CROSS_COMPILE="/home/runner/work/photOS/photOS/output/raspberrypi4/host/bin/arm-none-linux-gnueabihf-" DEPMOD=/home/runner/work/photOS/photOS/output/raspberrypi4/host/sbin/depmod INSTALL_MOD_STRIP=1 -C /home/runner/work/photOS/photOS/output/raspberrypi4/build/linux-custom bcm2711-rpi-4-b.dtb broadcom/bcm2711-rpi-cm4.dtb
2021-05-25T17:09:08.7930923Z make[1]: Entering directory '/home/runner/work/photOS/photOS/output/raspberrypi4/build/linux-custom'
2021-05-25T17:09:09.2954568Z make[2]: *** No rule to make target 'arch/arm/boot/dts/broadcom/bcm2711-rpi-cm4.dtb'.  Stop.
2021-05-25T17:09:09.2957930Z make[1]: *** [Makefile:1338: broadcom/bcm2711-rpi-cm4.dtb] Error 2

It seems to be related to this commit: 1b69695

Any hint what I'm missing here?

Hey @ccrisan

A long time ago, hope you are still doing great. I'm trying out your latest version of thingos, but noticed it will install GCC 8.2.1 when BR2_TOOLCHAIN_EXTERNAL=y

Any idea how I can force the system to install a 5.x compiler?

Many thanks!

Current Raspberry Pi builds are using buildroot's toolchain, which is causing Raspberry Pi vcdbg to fail, because vcdbg is closed-source and provided as a binary. Other precompiled /opt/vc binaries including libraries in RPi firmware have the same problem.

In order to get the precompiled binaries to work, we need to use the official RPi toolchain.

It is probably worth providing all the /opt/vc binaries, similar to Raspbian.

I created this issue to keep track of the current status of supporting the new Raspberry Pi Zero 2 W.

I exists already a patch for buildroot. However, it is not integrated into buildroot yet.

Sometimes the fwupdate fails on Rpi 0w. Here is output where it failed for the first time, so I tried it again and it succeeded:

[root@thing-115d74d5 ~]# uname -a
Linux thing-115d74d5 5.15.32 #1 Tue Sep 27 11:06:53 UTC 2022 armv6l GNU/Linux
z oot@thing-115d74d5 ~]# fwupdate upgrade /tmp/thingos-raspberrypi-unknown.img.xz
upgrading to /tmp/thingos-raspberrypi-unknown.img.xz
downloading...
downloaded [custom]
extracting...
running pre-upgrade script postgresql.sh
extracted [custom]
flashing boot...
boot flashed [custom]
preparing for reboot...
losetup: /data/.fwupdate/firmware.img: Resource temporarily unavailable
z oot@thing-115d74d5 ~]# fwupdate upgrade /tmp/thingos-raspberrypi-unknown.img.xz
upgrading to /tmp/thingos-raspberrypi-unknown.img.xz
downloading...
downloaded [custom]
extracting...
running pre-upgrade script postgresql.sh
extracted [custom]
flashing boot...
boot flashed [custom]
preparing for reboot...
rebooting...

---- shutting down thingOS unknown ----
 * Stopping sshd: done
 * Stopping crond: done
 * Stopping ntpd: done
 * Stopping netwatch: done
 * Stopping network: done
 * Stopping wpa_supplicant on wlan0: done
 * Stopping rngd: done
 * Stopping eudev: done
 * Stopping throttle watcher: done
 * Stopping syslogd: done
umount: overlay busy - remounted read-only
umount: can't remount tmpfs read-only
umount: devtmpfs busy - remounted read-only
The system is going down NOW!
Sent SIGTERM to all processes
rm: can't remove '/sbin/reboot': Read-only file system
Sent SIGKILL to all processes 
Re[  648.263369] reboot: Restarting system

My guess is that it is related to my comment here for Pinecube, i.e. kernel/busybox bug:
#79 (comment)

I know the thing is rather minor, but it would be comfortable to provide an estimation of the disk space usage for a complete build which could become quite large with the firmware downloads.

Noticeably, I found that building a simple Raspberry Pi (v1) dedicated install is requiring around 9.3 Gb, with 6.3 Gb for the target system build and created image themselves.

Hi:
Thanks for motioneyeos, I love it. I want to try out thingosnow too.
How do you set your environment variables , which ? seems to be my problem ?
I am a newbie and love to understand more about buildroot
I am trying to build thingos on Ubuntu 20.04,
I also get same error building motioneyos .
What am I doing wrong ?
Thanks I used your instructions from your github README.md and got this message at build time:

jf@jf-All-Series:~/mythingos$ ./build.sh raspberrypi3
You seem to have the current working directory in your
LD_LIBRARY_PATH environment variable. This doesn't work.
make[1]: *** [support/dependencies/dependencies.mk:27: dependencies] Error 1
make: *** [Makefile:84: _all] Error 2

jf@jf-All-Series:~/mythingos$ env | grep "LD_LIBRARY_PATH"
LD_LIBRARY_PATH=:/usr/lib/x86_64-linux-gnu/gazebo-11/plugins

no content is available under the wiki page: Building OS Images

Would it be possible to add support for Orange PI ZERO and ONE?

Upon boot on ThingOS with the Raspberry Pi 3 I had the following message:

* Setting current date using http date: invalid option -- 'D'
Try 'date --help' for more information.

I bundled the which utility to check which date binary is being installed:

# which date
/bin/date

I realized later on that I was including the gnu coreutils package which overwrites the symlink for the date binary to Busybox.

Perhaps a solution would be to use the explicit file path in the /etc/init.d/S50date file such that /bin/busybox date is called perhaps even setting a variable DATEBIN=/bin/busybox\ date and using that instead such that users can use the coreutils without having to create a separate overlay for the S50date file.

https://github.com/ccrisan/thingos/wiki/wpa_supplicant.conf
Need to add country code as:
country=US # Use appropriate country code

A couple of packages such as PHP, Nginx, are trying to create following directory /root/motioneyeos/output/raspberrypi3/target/var/log.

However this has been declared as a symbol link to /data/log. Due this the installation step stops the build. Any ideas or best practices how to overcome (without updating the packages)?

This is actually not a bug report, but more a question to understand design decisions.

Why is the system rebooted if network connection (in my case wifi) is lost? Is it due to the main use case of thingOS (motioneyeos), where missing connectivity would significantly reduce the main purpose? Or is it not that easy to reconnect on a Raspberry Pi?

Background

I'm using thingOS for a digital photoframe. thingOS helped a lot to get a working prototype quickly up and running. In that use-case it is not that fatal if network is done, as the images are stored locally.
Thus, I'm investigating the best way to just restart networking instead of rebooting the whole system and I want to make sure there are not already known pitfalls.

I have build a bananapim1 image

git clone <repo> --branch master --depth 1
cd thingos
./build.sh bananapim1
./build.sh bananapim1 mkrelease 
sudo ./writeimage.sh -d /dev/sdb -i output/bananapim1/images/thingos-bananapim1.img

SSH starts to work soon after first boot, but stops to work after reboot and next boots.

log.zip

Hello,

no wlan connection, detaching the ethernet cable from the router makes the RPi to boot in a loop.

I have read the CONTRIBUTING and the FAQ before opening this issue.
I have verified all the suggestions in Troubleshooting/Wireless Connection Problems have been verified OK.
RPi3B+ connects to wlan when booting SD-Raspbian.
The motionEyeOS was burned on SD, the file was motioneyeos-raspberrypi3-20200606.img.
wpa_supplicant.conf was added before the first boot.
Setting the motionEyeOS up was done succesfully via ethernet cable connected to my router.
The same router has the wlan.

also:
-verified that the data/etc/wpa_supplicant.conf is read in reboot by changing the SSID.
-verified with hex-editor that the wpa_supplicant.conf does not include CR LF (0x0D 0x0A) but ONLY LF (0x0A)
-have tried all kind of entries in the wpa_supplicant.conf.

my laptop and smartphone connect to the wlan OK, as does openplotter/RPi3+.

Otherwise the camera works, and mass storage works, wlan does not, and I can not get rid of the ethernet-cable.

Any ideas?
Is there a position in the log files which tells what really went wrong, for example: net not found, authentication, .conf parameter error, timeout...??

I can access/download the log files via motionEyeOS/Expert Settings if needed.
I am not able to decode the entries with sufficient knowledge.

view wpa_supplicant.txt

The attached files include the statement: scan_ssid=1, deleting that entry does not help. My wlan is not hidden.

Due to an incompatibility between glibc 2.33 and fakeroot, the system cannot be build on e.g. Arch Linux. There is a patch for fakeroot in buildroot: https://git.busybox.net/buildroot/commit/?id=f45925a951318e9e53bead80b363e004301adc6f

As I want to avoid doing cherry-picking and going out of sync with thingOS, it would be great if you can upgrade the underlying buildroot.

Hi, I´ve already included the dnsmasq.conf and the hostapd.conf files in the boot partition. I also modified the os_networkless configuration and set it to true. But after initializing my raspberry it won´t create the network.

Hey I was wondering if you could bring the package versions up to date with the ones provided by buildroot some of them such as automake are a couple of versions behind

The Wiki mentions the boot partition as FAT32, but it was never FAT32, instead, it´s FAT16.

With current settings, AP on Rpi 0w is not working. Here is log:

---- booting thingOS unknown ----
 * Detecting disk device: /dev/mmcblk0
 * Creating data partition: done
 * Formatting data partition: done
 * Mounting data partition: done
 * Copying data skeleton: done
 * Mounting filesystems: done
 * Mounting overlay filesystems: done
 * Setting empty root password: done
 * Copying version file: done
 * Setting UTC timezone: done
 * Loading kernel modules: done
 * Setting hostname: done
 * Starting syslogd: done
 * Loading device-tree overlays: done
 * Starting throttle watcher: done
 * Starting eudev: done
 * Starting watchdog: done
 * Starting rngd: done
 * Renaming network interfaces: done
 * Preparing AP interfaces: no device
 * Starting dnsmasq: SIOCSIFADDR: No such device
ap0: ERROR while getting interface flags: No such device
done
 * Starting crond: done
 * Generating ssh host keys: done
 * Starting sshd: done

Welcome to thing-115d74d5!
thing-115d74d5 login: root
Password: 
[root@thing-115d74d5 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether b8:27:eb:08:21:80 brd ff:ff:ff:ff:ff:ff

I think problem is with commit 4a4c9e2
There is common variable OS_WLAN1="wlan1" for all boards in os.conf, but if the variable is set, /etc/init.d/S44hostapd will check if this interface is working. Since Rpi 0w does not have wlan1, it will fail. /etc/init.d/S44hostapd should be either changed, or OS_WLAN1 should be set only for boards which actually supports it, not globally. If I remove OS_WLAN1 variable, it works again:

---- booting thingOS unknown ----
 * Detecting disk device: /dev/mmcblk0
 * Creating data partition: done
 * Formatting data partition: done
 * Mounting data partition: done
 * Copying data skeleton: done
 * Mounting filesystems: done
 * Mounting overlay filesystems: done
 * Setting empty root password: done
 * Copying version file: done
 * Setting UTC timezone: done
 * Loading kernel modules: done
 * Setting hostname: done
 * Starting syslogd: done
 * Loading device-tree overlays: done
 * Starting throttle watcher: done
 * Starting eudev: done
 * Starting watchdog: done
 * Starting rngd: done
 * Renaming network interfaces: done
 * Preparing AP interfaces: ap0
 * Starting hostapd on ap0: done (brcmfmac)
 * Starting dnsmasq: done
 * Starting crond: done
 * Generating ssh host keys: done
 * Starting sshd: done

Welcome to thing-115d74d5!
thing-115d74d5 login: root
Password: 
[root@thing-115d74d5 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether b8:27:eb:08:21:80 brd ff:ff:ff:ff:ff:ff
3: ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether b8:27:eb:08:21:80 brd ff:ff:ff:ff:ff:ff
    inet 192.168.27.1/24 brd 192.168.27.255 scope global ap0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe08:2180/64 scope link 
       valid_lft forever preferred_lft forever

I find myself in need to do a x86_64 board (well actually a PC) and find that it is currently possible. How to approach adding a new board.

BR

I changed board/common/overlay/etc/version and did
./build.sh raspberrypi
./build.sh raspberrypi mkrelease

A corresponding image file is created. However, the rootfs is not updated (/etc/version still has the old content).

This lead to some confusion.

Marked in red in Right column:
Batteries Included, Network Connections
Core Features
Reliability, Other Goodies
Internals
Boot Process
Source Code
Board Configurations
Building OS Images
Add New Packages
FAQ
Troubleshooting
Various
Add a RTC Module

All Red Links point back to Home Wiki page.

brcmfmac43455-sdio.clm_blob file from https://github.com/RPi-Distro/firmware-nonfree/raw/master/ must be in thingos/tree/dev/board/raspberrypi3/overlay/lib/firmware/brcm

see motioneye-project/motioneyeos#2090

I'm trying to create a wpa_supplicant but am having problems. I tried creating one and putting it in the /boot directory and that wouldn't work - said read-only file system; next I tried putting it in /etc directory - same error; lastly I tried putting it in the /data/etc directory and that worked, but it wasn't accepted. I followed the instructions on: https://github.com/ccrisan/motioneyeos/wiki/Wifi-Preconfiguration but it's really not clear where to put the file and after I booted by reconnecting my ethernet connection, the wpa_supplicant I put in /data/etc has been reset back to the default one. So, I need some guidance here.

Directory structure in /data is only copied from dataskel if it has just created the data partition. If doing firmware upgrade, new contents in dataskel are not copied to existing data partition.
Example:
varlib was added recently, so upgrading from old firmware will cause /var/lib symlink to break.

Hello,

I see you are using modified Buildroot for your purposes and you are merging upstream back to your project from time to time. When I look at this project, I can not see easily what are you changes and what files are kept upstream. So let me put the question: have you considered using Buildroot external for this project? In my opinion, using externals is much simpler to keep project clean and as close as possible upstream Buildroot. You can use all Buildroot architectures, packages and toolchain, but you can put all your custom configs, boards, scripts and packages on top of it. Switching to newer Buildroot is therefore very easy without the need to resolve many merge conflicts (or user of thingos could even use its own version of Buildroot). Or maybe I am just not skilled enough using git to easily navigate in the project.

Since you are (or was?) maintainer of motionieyeos, please let me discuss about this project as well. Since you are merging changes from Buildroot -> thingOS and then from thingOS -> motionEyeOS, things gets even more complicated and maybe using external would make even more sense at least for motionEyeOs. I myself have small project https://gitlab.com/sonicpp/gnss-pi (nothing big as thingos), but using br2-externals helped me a lot to keep the project small and easy to migrate to newer versions of Buildroot. Now I am thinking about to switch from Buildroot to thingos, but keeping using externals. Maybe it would make sense to motioneyeos, too (I imagine motioneyeos is not much different from base project, thingos, only few packages/overlays on top of it)?

Regards,
Jan

Would it be possible to add support for Cubie Board?

Hi,

from what I understand, in a normal linux system, initrd.gz files are created with the initramfs-tools and are dependent on the kernel version.

Yet, I see that in thingos, every board comes with a specific initrd.gz file (directly in the boards directory) that seems to be pre-built somewhere externally. I see that the update mechanism is built around this.

Can you shed a light on how these initrd files are created and why they don't depend on the specific kernel version that is built with thingos?

Any chance that the source code will be provided as a buildroot package?

Is it possible to format /data partition as FAT32 instead of Ext4?

I miss an option to find (fwupdate versions) and install (fwupdate upgrade) pre-releases from github. Can this be configured?