4 ms·

Just a quick tip, if you are interested in Yocto, and especially Yocto on the Raspberry Pi: there's a layer called meta-updater[1], originally developed for Aut

by tkfu 8y ago

Just a quick tip, if you are interested in Yocto, and especially Yocto on the Raspberry Pi: there's a layer called meta-updater[1], originally developed for Automotive Grade Linux, that lets you add over-the-air updates to your Yocto-built systems, and it supports Raspberry Pi. It uses OSTree[2] to give you atomic updates and nice, small update sizes. (The whole filesystem is a content-addressed object store that's hard-linked into the actual directory structure at boot time.) There's also a guide[3] for doing this using HERE's servers for delivering your updates. It's free to use, but if you prefer a free-as-in-speech solution, you can either ignore the update client and run the updates yourself from a bare OSTree repo, or run the open-source community edition[4] of HERE's server software. (Full disclosure: I work for HERE, and wrote the quickstart guide[3] I'm linking.) [1] https://github.com/advancedtelematic/meta-updater/ https://github.com/advancedtelematic/meta-updater/ [2] https://ostree.readthedocs.io/en/latest/ https://ostree.readthedocs.io/en/latest/ [3] https://docs.atsgarage.com/quickstarts/raspberry-pi.html https://docs.atsgarage.com/quickstarts/raspberry-pi.html [4] https://github.com/advancedtelematic/ota-community-edition/ https://github.com/advancedtelematic/ota-community-edition/

codetrotter 8y ago
With regards to image update management, personally what I wish to do for my Yocto image is to have it be: - Small enough that it fits into RAM. - Fetched over the network on boot, PXE-style. - Configured to not write any files to the greatest extent possible, and where writing files can not be avoided one would use tmpfs. With the above three criteria satisfied, the following is achieved: a) We never write to an SD card so we avoid SD card corruption issues. b) Since the whole system image is sitting in RAM, we could do without NFS, Samba or similar either. We do need to persist some data, but that data is coming from our application and is going to be stored in a database on a server on the local network. I am currently working on developing the application that our image will run, but I have dug up some preliminary information relating to what I said above: - Read-only Raspberry Pi [1]. Applies to Raspbian but certainly provides a starting point for doing the same thing with Yocto. - Poky NFS Root [2]. Like I said, I don't need the NFS root part if the image can fit in RAM, but the portions that deal with gPXE might certainly be relevant. - The State of Netbooting Raspberry Pis (December 2017) [3]. "Net-booting works well on the Raspberry Pi B Model 3 without an SD Card." So actually we won't be needing gPXE. - Network Boot Your Raspberry Pi [4]. Referenced by [3] and provides the steps needed to configure Raspberry Pi 3 for network booting without an SD-card. I am not completely decided upon whether or not to avoid NFS yet though. Because we never persist any files on the root file system anyway, serving said fs over NFS can be done in read-only mode, and we would put each revision of the corresponding root file system in a uniquely named top-level directory so that a client running the current version image has one place that it gets the files it expects from and the next version of the image which might expect other files or differing layout would get its files from another directory. Old root file system directories which are no longer in use would be removed so this scheme doesn't require much in terms of storage space. It should be noted that NFS has some security issues [5], but our deployment is going to be running on an isolated network exclusive to the hardware that we are providing, so this concern is already resolved. Said isolated network will connect our embedded Raspberry Pis, a server (TFTP, database and NFS), and a tablet configured and provided by us. The tablet provides a graphical user interface that our customers will use to interact with the system. [1]: https://learn.adafruit.com/read-only-raspberry-pi/ https://learn.adafruit.com/read-only-raspberry-pi/ [2]: https://wiki.yoctoproject.org/wiki/Poky_NFS_Root https://wiki.yoctoproject.org/wiki/Poky_NFS_Root [3]: https://blog.alexellis.io/the-state-of-netbooting-raspberry-pi/ https://blog.alexellis.io/the-state-of-netbooting-raspberry-... [4]: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md https://www.raspberrypi.org/documentation/hardware/raspberry... [5]: https://www.tldp.org/HOWTO/NFS-HOWTO/security.html https://www.tldp.org/HOWTO/NFS-HOWTO/security.html
- zubairlk 8y ago
  Running an OS + application entirely from memory is an interesting approach indeed. I guess the fundamental big problem you are facing is SD card corruption. In our experience, we've found the SanDisk Extreme Pro cards to be most reliable. (coupled with a good power supply). Read-only rootfs is almost a must have for any production environment. resinOS does not satisfy all your requirements (nfs boot, state in memory etc).. But we do have stuff in place to reduce the problems you are facing. - There is an initramfs in the kernel. When the kernel loads in memory, it runs fsck on the root/data partitions before mounting the rootfs. - The rootfs is read-only with only a few configuration files in the state partition. - Applications run inside a container so you can basically run rasbian on top of resinOS. I wrote more about resinOS in another comment highlighting remote application container updates/vpn access etc. https://news.ycombinator.com/item?id=18093336 https://news.ycombinator.com/item?id=18093336 Disclaimer: I work at resin in the OS team. I've noted down your feedback about running purely in memory.
  - kingosticks 8y ago
    > Applications run inside a container so you can basically run rasbian on top of resinOS. How well does that work? Do you get full access to the underlying hardware? Can you still access the GPIOs, HDMI-CEC etc? Are there any other downsides to doing this?
    - zubairlk 8y ago
      Sorry for the delay. Yes they get full access. CEC might be an interesting one. "If you choose, your containers can be configured to run as privileged, access hardware directly, and even inject modules into the kernel." from https://docs.resin.io/learn/welcome/primer/ https://docs.resin.io/learn/welcome/primer/
- kingosticks 8y ago
  Be wary of some packages that expect their log folder to exist at /var/log/some_package else they won't start, I can't remember which of nginix or apache has that issue. That adafruit script is very simple and there are more robust setups out there, albeit not as well documented. Netbooting isn't 100% reliable and last time I checked there were certain network switches/hubs that caused issues. Maybe that's a non-issue if you are also providing the network infrastructure. Lastly, remember that the more RAM you consume for your filesystem/logs etc, the less available for our actual application. That becomes more of a problem when you start also assigning a large chunk of that RAM to the GPU.

by tkfu 8y ago

codetrotter 8y ago

With regards to image update management, personally what I wish to do for my Yocto image is to have it be: - Small enough that it fits into RAM. - Fetched over the network on boot, PXE-style. - Configured to not write any files to the greatest extent possible, and where writing files can not be avoided one would use tmpfs. With the above three criteria satisfied, the following is achieved: a) We never write to an SD card so we avoid SD card corruption issues. b) Since the whole system image is sitting in RAM, we could do without NFS, Samba or similar either. We do need to persist some data, but that data is coming from our application and is going to be stored in a database on a server on the local network. I am currently working on developing the application that our image will run, but I have dug up some preliminary information relating to what I said above: - Read-only Raspberry Pi [1]. Applies to Raspbian but certainly provides a starting point for doing the same thing with Yocto. - Poky NFS Root [2]. Like I said, I don't need the NFS root part if the image can fit in RAM, but the portions that deal with gPXE might certainly be relevant. - The State of Netbooting Raspberry Pis (December 2017) [3]. "Net-booting works well on the Raspberry Pi B Model 3 without an SD Card." So actually we won't be needing gPXE. - Network Boot Your Raspberry Pi [4]. Referenced by [3] and provides the steps needed to configure Raspberry Pi 3 for network booting without an SD-card. I am not completely decided upon whether or not to avoid NFS yet though. Because we never persist any files on the root file system anyway, serving said fs over NFS can be done in read-only mode, and we would put each revision of the corresponding root file system in a uniquely named top-level directory so that a client running the current version image has one place that it gets the files it expects from and the next version of the image which might expect other files or differing layout would get its files from another directory. Old root file system directories which are no longer in use would be removed so this scheme doesn't require much in terms of storage space. It should be noted that NFS has some security issues [5], but our deployment is going to be running on an isolated network exclusive to the hardware that we are providing, so this concern is already resolved. Said isolated network will connect our embedded Raspberry Pis, a server (TFTP, database and NFS), and a tablet configured and provided by us. The tablet provides a graphical user interface that our customers will use to interact with the system. [1]: https://learn.adafruit.com/read-only-raspberry-pi/ https://learn.adafruit.com/read-only-raspberry-pi/ [2]: https://wiki.yoctoproject.org/wiki/Poky_NFS_Root https://wiki.yoctoproject.org/wiki/Poky_NFS_Root [3]: https://blog.alexellis.io/the-state-of-netbooting-raspberry-pi/ https://blog.alexellis.io/the-state-of-netbooting-raspberry-... [4]: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md https://www.raspberrypi.org/documentation/hardware/raspberry... [5]: https://www.tldp.org/HOWTO/NFS-HOWTO/security.html https://www.tldp.org/HOWTO/NFS-HOWTO/security.html

zubairlk 8y ago
Running an OS + application entirely from memory is an interesting approach indeed. I guess the fundamental big problem you are facing is SD card corruption. In our experience, we've found the SanDisk Extreme Pro cards to be most reliable. (coupled with a good power supply). Read-only rootfs is almost a must have for any production environment. resinOS does not satisfy all your requirements (nfs boot, state in memory etc).. But we do have stuff in place to reduce the problems you are facing. - There is an initramfs in the kernel. When the kernel loads in memory, it runs fsck on the root/data partitions before mounting the rootfs. - The rootfs is read-only with only a few configuration files in the state partition. - Applications run inside a container so you can basically run rasbian on top of resinOS. I wrote more about resinOS in another comment highlighting remote application container updates/vpn access etc. https://news.ycombinator.com/item?id=18093336 https://news.ycombinator.com/item?id=18093336 Disclaimer: I work at resin in the OS team. I've noted down your feedback about running purely in memory.
- kingosticks 8y ago
  > Applications run inside a container so you can basically run rasbian on top of resinOS. How well does that work? Do you get full access to the underlying hardware? Can you still access the GPIOs, HDMI-CEC etc? Are there any other downsides to doing this?
  - zubairlk 8y ago
    Sorry for the delay. Yes they get full access. CEC might be an interesting one. "If you choose, your containers can be configured to run as privileged, access hardware directly, and even inject modules into the kernel." from https://docs.resin.io/learn/welcome/primer/ https://docs.resin.io/learn/welcome/primer/
kingosticks 8y ago
Be wary of some packages that expect their log folder to exist at /var/log/some_package else they won't start, I can't remember which of nginix or apache has that issue. That adafruit script is very simple and there are more robust setups out there, albeit not as well documented. Netbooting isn't 100% reliable and last time I checked there were certain network switches/hubs that caused issues. Maybe that's a non-issue if you are also providing the network infrastructure. Lastly, remember that the more RAM you consume for your filesystem/logs etc, the less available for our actual application. That becomes more of a problem when you start also assigning a large chunk of that RAM to the GPU.