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

91–100 of 125 posts

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

#91

Post by jcalvinowens »

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.

The more your hardware vendors work upstream, the more Yocto will simplify your life.

If you buy hardware from a vendor who hands you a "meta-bigco" layer with their own fork of u-boot and the kernel, you're gonna have a bad time...

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

#92

Post by eschneider »

cushychicken wrote: post #18
palata wrote: post #9

Yocto is pretty great! Unfortunately I feel like it gets a lot of criticism, but usually from people who haven't gotten to learn it. Like "I had to spend 2h on Yocto and this thing suuuuucks , I threw a docker image there and called it a day". Which is a pity, because when used correctly it's really powerful! From the article, I can't help but mention that one third of the "key terminology" is about codenames. What d…

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.…

This is truth. I've done a lot of work bringing up custom boards with both Yocto and Buildroot and I rather like Yocto. But yeah, first project with Yocto was painful. It's rather well documented, but one really needs a good idea of what's going on to really know what you're even looking for.

That said, once you get it figured out, it's very flexible and largely logical. :)

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

#94

Post by unitexe »

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…

One has to implement the rollbacks in the bootloader after they have implemented an A/B update pattern.

In u-boot this is done with its boot count limit config and altbootcmd.

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

#95

Post by unitexe »

finnthehuman wrote: post #29
msarnoff wrote: post #22

The one thing I still don't like about Yocto is the setup process. You need to check out multiple layer repositories, make sure you check out the right commit from each repository (need reproducibility!), put everything in the correct directory structure, and then set up `bblayers.conf` and `local.conf`. I've got a script that does all this, but it's still a pain. I've been thinking about putting everything in a mono…

I recently found out about the 'kas' tool that tries to be a better version of the hacky scripts we all write for this. Here's a link to an example YAML config to give you a taste: https://kas.readthedocs.io/en/1.0/userguide.html#project-con...

+1 for kas I won't build yocto images any other way. Using their kas-container script makes building with their container a breeze.

Other kas features I love: - Patching 3rd party layers with quilt - Configuration fragments - Chaining together configuration fragments

As another example, here is my kas setup for building rootfs images and container images for various different boards:

https://github.com/unitexe/meta-unit-kas

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

#96

Post by klysm »

jvanderbot wrote: post #50
klysm wrote: post #46

I think long term yocto and build root are going to be replaced by container tooling. Theres not that big of a difference between compiling an OS image and building a container image.

Well one difference is that docker lives well above the metal and in a nice cozy environment on mostly standard operating systems and yocto builds that nice cozy environment for all kinds of nonstandard hardware.

Yeah agreed they are targeting different environments, but at the end of the day it's tools for building root file systems. I expect that to converge to better tooling.

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

#97

Post by Joel_Mckay »

mort96 wrote: post #87
Joel_Mckay wrote: post #32

Earlier quoted context omitted.

"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…

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

In time you may, but perhaps you were confused about the primary use-case context bringing up small linux SBM. The mess Yocto can leave behind was not something manufacturers prioritized, and there are countless half-baked solutions simply abandoned within a single release cycle. Out of date package versions, and storage space-optimized stripped/kludged binaries are the consequences. Historically, the things people did to get the minimal OS on flash also meant builds that are not repeatable/serviceable, buggy/unreliable (hence custom patches), and ultimately in mountains of e-waste.

My point was Yocto has always created liabilities/costs no one including its proponents wanted to address over the long-term. Best of luck =3

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

#98

Post by whiatp »

rcxdude wrote: post #41
palata wrote: post #9

Yocto is pretty great! Unfortunately I feel like it gets a lot of criticism, but usually from people who haven't gotten to learn it. Like "I had to spend 2h on Yocto and this thing suuuuucks , I threw a docker image there and called it a day". Which is a pity, because when used correctly it's really powerful! From the article, I can't help but mention that one third of the "key terminology" is about codenames. What d…

It's powerful but bitbake wasn't so much designed as emerged from a primordial soup, it's easy to go completely insane trying to debug it due to the amount of action-at-distance recipes and layers can create. (try playing the "where did this compile flag come from?" game)

bitbake -e is super useful for that game. It dumps out a complete history of where all variables were set/changed, and their values along the way. I also use it to do what I call "variable shopping," where I roughly know what path/name content I need, but not what the variable it is in is called.

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

#99

Post by mort96 »

Joel_Mckay wrote: post #97
mort96 wrote: post #87

Earlier quoted context omitted.

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…

"I don't understand where you're coming from at all." In time you may, but perhaps you were confused about the primary use-case context bringing up small linux SBM. The mess Yocto can leave behind was not something manufacturers prioritized, and there are countless half-baked solutions simply abandoned within a single release cycle. Out of date package versions, and storage space-optimized stripped/kludged binaries a…

I might have been unclear. What I don't understand is how binary stripping and custom patches is associated with SoCs with low RAM, or why you claimed that it does static linking when it doesn't by default.

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

#100

Post by not_the_fda »

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.

Take a look at buildroot its a much better system.
Post reply on HN