Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yocto, RockPi and SBOMs: Building modern embedded Linux images

vpetersson.com

Post reply on HN
Print view View original

71–80 of 125 posts

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#71

Post by Coi-l »

fathermarz wrote: post #36

As someone in the Software Supply Chain business. Yocto SBOMs are considered low quality because they include things that do and do not exist in the final compiled artifact. When you compare what exists inside, physically from a binary perspective, what is included in the manifest, and what is generated in the build root, you will find they will never align unless you get creative and map artifacts together. Today th…

May I ask what you recommend?

Since it is easy for me I prefer the Yocto SBOM, but the security side forces blackduck binary scanning on us which while finding most things on the binary constantly misidentifies a lot of versions, resulting in a lot of manual work.

It also does not know which patches Yocto has applied for fixing CVEs.

And none of these can figure out what is in the kernel and therefor triggers an ungodly amount of CVEs in parts of the kernel we don't have compiled in.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#72

Post by thebruce87m »

maufl wrote: post #62

What I would really like is something like Docker to build images for my raspberry pis. Just a single file, shell commands, that's it. I feel that Yocto is already too complicated if you want a reproducable setup for you raspberry pi at home.

That’s what Balena does. Base immutable OS and docker images.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#73

Post by fake-name »

jcalvinowens wrote: post #54

Yocto can be incredibly simple, this is my favorite example: https://github.com/bootlin/simplest-yocto-setup/ Only the kernel and bootloader usually need to be specialized for most modern arm boards: the userland can be generic. Most of the problems people have with yocto are due to layers from hardware vendors which contain a lot of unnecessary cruft.

Yocto can appear incredibly simple.

Until something somewhere deep inside the build process breaks, or you need to enable a peripheral the default device-tree for your board doesn't enable, or a gnat farts on the other side of the world, and it completely stops working.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#74

Post by mort96 »

chocobor wrote: post #60

Q: How do you guys centrally update field devices? I am working on professionalizing our IOT setup that currently consists of a few dozen raspberries which run docker containers. They are individually updated by sshing into them and running apt update manually. Docker containers are deployed with a commercial solution. I want to have a centralized way to update the OSes, but it does not really make sense for our smal…

I've used RAUC (https://rauc.io/) professionally for a couple of projects and am happy with it. There's a RAUC meta layer which provides bbclasses for generating rauc bundles from an image recipe. It's not that complicated to set up boot partition selection in u-boot.

For embedded systems, I strongly prefer the "full immutable system image update" approach over the "update individual packages with a package manager" approach. Plus you get rollbacks "for free": if the system doesn't boot into the new image, it automatically falls back to booting into the previous image.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#75

Post by mort96 »

codetrotter wrote: post #21

Last time I tried Yocto, some people here on HN suggested that I try Buildroot instead. I don’t see so many mentions of Buildroot in this thread yet. If you are interested in Yocto it might be worth having a look at Buildroot as well. I liked it a lot when I tried it. My thread from years ago, where people told me about Buildroot: https://news.ycombinator.com/item?id=18083506 The website of Buildroot: https://buildro…

My experience with buildroot is that it's really slow to compile because it doesn't compile packages in parallel (so you'll only get the parallelism of an individual package's build system, with sequential stuff inbetween), and you end up recompiling from source a whole lot because it doesn't do dependency tracking between packages so if you change a library, you either have to manually remember to recompile the whole chain of dependents, or do a clean build. Yocto, on the other hand, compiles packages in parallel and tracks which packages need to be recompiled due to a changed recipe or config file.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#76

Post by mort96 »

RobotToaster wrote: post #61
elcritch wrote: post #58

Earlier quoted context omitted.

There’s also SkiffOS ( https://github.com/skiffos/SkiffOS ). It’s a project that uses buildroot to create a small Linux for a specific device that’s only used to start a container. I’ve wanted to try it sometime after getting headaches with both Buildroot and Yocto. Particular adding more libraries tends to break things.

That doesn't sound very performant.

Why not? The only overhead I can see is some storage and memory overhead due to duplicate libraries, and some possible small startup time penalty? Containers are just normal Linux processes after all, it's not like there's a VM involved

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#77

Post by mvip »

mort96 wrote: post #74
chocobor wrote: post #60

Q: How do you guys centrally update field devices? I am working on professionalizing our IOT setup that currently consists of a few dozen raspberries which run docker containers. They are individually updated by sshing into them and running apt update manually. Docker containers are deployed with a commercial solution. I want to have a centralized way to update the OSes, but it does not really make sense for our smal…

I've used RAUC ( https://rauc.io/ ) professionally for a couple of projects and am happy with it. There's a RAUC meta layer which provides bbclasses for generating rauc bundles from an image recipe. It's not that complicated to set up boot partition selection in u-boot. For embedded systems, I strongly prefer the "full immutable system image update" approach over the "update individual packages with a package manager…

+1 for "full immutable system image update"

People who suggest updating individual packages (or even worse, individual deb packages for instance) have never deployed any large scale IoT/Embedded projects. These devices are very different than servers/desktops and will break in ways you can't imagine. We started out using deb packages at Screenly before moving to Ubuntu Core, and the amount of error/recovery logic we had written to recover from broken deb package state was insane at that point.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#78

Post by mort96 »

msarnoff wrote: post #24
codetrotter wrote: post #21

Last time I tried Yocto, some people here on HN suggested that I try Buildroot instead. I don’t see so many mentions of Buildroot in this thread yet. If you are interested in Yocto it might be worth having a look at Buildroot as well. I liked it a lot when I tried it. My thread from years ago, where people told me about Buildroot: https://news.ycombinator.com/item?id=18083506 The website of Buildroot: https://buildro…

I think, in a lot of cases, the choice between Buildroot and Yocto comes down to "which one does the SoC vendor support."

I think that's fair, but it does depend on what you want the relationship with your SoC vendor and the Yocto community to be. A lot of SoCs have pretty good community support in Yocto (and probably Buildroot), and using a community-maintained BSP meta layer will make things easier for you in some ways. SoC vendors aren't always great at following Yocto best practices. Plus, unless you have excellent support contracts with your vendor and are prepared to use it, you'll probably go to the Yocto community for support with weird Yocto issues you run into; and Yocto developers are (understandably) much more helpful if you say you use mainline Linux with a BSP maintained by the Yocto project than if you use a vendor's kernel fork with a BSP maintained by the SoC vendor.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#79

Post by mvip »

josteink wrote: post #70

> One limitation of the current disk image for Rock Pi is that you don’t have a functional TTY. I believe on systemd-based systems these are service-units you need to enable, and with yocto, possibly install? systemctl enable -now getty@tty0 (etc) Or something like that. I’ve experienced similar issues while working on a x86 based NAS and also on the RPi when enabling serial-consoles.

Oh nice! Thanks. Will give that a try.

Re: Yocto, RockPi and SBOMs: Building modern embedded Linux images

#80

Post by nullify88 »

chocobor wrote: post #60

Q: How do you guys centrally update field devices? I am working on professionalizing our IOT setup that currently consists of a few dozen raspberries which run docker containers. They are individually updated by sshing into them and running apt update manually. Docker containers are deployed with a commercial solution. I want to have a centralized way to update the OSes, but it does not really make sense for our smal…

I would suggest taking a look at bootc https://github.com/containers/bootc which enables you to use OCI / Docker containers as a transport and delivery system for OS updates. That makes available much of the tooling used to build and deliver container images for the purposes of delivering os updates.

Such possibilities include the various registeries available for storing OS updates and branches. Tooling for security scanning, sbom generation, signing Docker or podman for building the image.

It's important to note that the container image itself is not executed upon boot, but rather unpacked before hand.

Post reply on HN