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

81–90 of 125 posts

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

#81

Post by thebruce87m »

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…

Yocto + Mender is one option, but you don’t the yocto pain. We are trying Balena at the moment and liking it. It manages both the OS and the docker bit.

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

#82

Post by samuelbrian »

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.

I've been working on something recently that you might find interesting: https://github.com/makrocosm/makrocosm

It's not a shell script, but it has makefile rules that make it relatively simple to build a Docker image for your architecture, export it and turn into a filesystem image, build a kernel, u-boot, etc The referenced "example project" repo builds a basic Alpine image for the Raspberry Pi (https://github.com/makrocosm/example-project/tree/main/platf...) and others

It was motivated by frustrations with Yocto at a new job after 8 or so years working on firmware for network equipment using an offshoot of uClinux. Hoping to convince new job to use Makrocosm before we settle on Yocto.

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

#83

Post by written-beyond »

fake-name wrote: post #73
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.

I spent at least a week to understand Yocto, started reading a book. I couldn't wrap my head around it. Just went back to the RPI OS image builder scripts.

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

#84

Post by palata »

thebruce87m wrote: post #81
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…

Yocto + Mender is one option, but you don’t the yocto pain. We are trying Balena at the moment and liking it. It manages both the OS and the docker bit.

With Balena you are shipping entire Linux distros that you did not build, right? How do you deal with licences?

E.g. if you ship an Ubuntu container, you have to honour the licences of all the packages that you are shipping inside that Ubuntu container. Do you?

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

#85

Post by ab71e5 »

written-beyond wrote: post #83
fake-name wrote: post #73

Earlier quoted context omitted.

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.

I spent at least a week to understand Yocto, started reading a book. I couldn't wrap my head around it. Just went back to the RPI OS image builder scripts.

Which book was that? The bootlin course slides are pretty good

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

#86

Post by cushychicken »

PhilipRoman wrote: post #64
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…

Not what you're looking for, but https://sbabic.github.io/swupdate/swupdate.html It's meant (I think?) for immutable style distros like Yocto. You basically create a cpio archive and a manifest of what file goes in which partition (plus bells and whistles like cryptography). It's a good idea to have double buffering, so that if boot fails to come to a reasonable state, the device will revert after a few tries. IMO th…

+1 for swupdate. Implemented it three or so different times at this point and really like it.

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

#87

Post by mort96 »

Joel_Mckay wrote: post #32
cushychicken wrote: post #18

Earlier quoted context omitted.

Part of why it gets so much criticism is that Yocto’s learning curve is pure brutality . Out of the box configurations for Yocto images and recipes are fabulous. Trying to modify those configurations below the application layer… you’re gonna have a bad time. Opaque error messages, the whole layers vs recipes vs meta issues, etc. I also can’t shake the feeling that yocto was made to solve a chip company’s problems (I.…

"Part of why it gets so much criticism is that Yocto’s learning curve is pure brutality." At one time when SoCs were RAM lean... and build specific patching, stripping and static linking was considered an acceptable tradeoff in the yocto build systems for IoT etc. The use-cases are extremely difficult to justify these days with 256MB of ram on a $5 SoC... However, the approach was commercially unsustainable from main…

From experience, none of the difficulty of Yocto comes from the fact that it strips binaries; it builds stripped packages and puts debug info in separate -dbg packages, which is super standard in the Linux world.

Yocto doesn't do static linking unless you specifically ask for it, libraries end up as .so files in /usr/lib like on all other Linux systems.

When Yocto carries patches, it's typically because those patches are necessary to fix bad assumptions upstreams make which Yocto breaks, or to fix bugs, not to reduce RAM usage.

I don't understand where you're coming from at all.

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

#88

Post by ahlCVA »

mort96 wrote: post #75
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 whol…

Buildroot has package-parallel builds when using BR2_PER_PACKAGE_DIRECTORIES (see https://buildroot.org/downloads/manual/manual.html#top-level...). It's for some reason still marked as experimental in the docs but it has been solid for me for many years.

The lack of dependency tracking isn't great but other than working around it like you described just using ccache has worked pretty well for me. My Buildroot images at work do full recompiles in under 10 minutes that way.

Meanwhile the Yocto projects I've worked on used to have a ton of chaff that causes partial rebuilds with trivial changes to take longer than that. This probably isn't an inherent Yocto/BitBake thing but the majority of Yocto projects out there seems to take a very kitchen-sink approach so it's what you'll end up having to deal with in practice.

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

#89

Post by leonheld »

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…

> have not yet found a hardware independent Linux distro that can be reliably updated in an IOT context

I'm part of the team that builds an immutable distro based on OSTree (https://www.torizon.io) that does exactly that.

Docker/Podman support is first-class as the distro is just a binary, Yocto-based one that we maintain so users don't have to. You can try our cloud for free with the "maker" tier. To update a device you just drop a compose file with the web ui and massively update a fleet. You can even use hardware acceleration from the containers using our reference OCI images.

The layer is open (https://github.com/torizon/meta-toradex-torizon) and will get Raspberry Pi support soon but you can integrate already easily with meta-raspberrypi (we can also do this for you very quickly ;-)).

Happy to answer any questions.

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

#90

Post by fathermarz »

Coi-l wrote: post #71
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 ungo…

There is no tool at the moment that solves this, but it is being worked on amongst some players in the industry by those that fundamentally understand the problem. It is a very niche skill set that the greater compliance world doesn’t understand the need for yet. I would say we are 1-3 years away from solving the noise problem of SCA/BCA.
Post reply on HN