I've set successfully my Yocto build to patch one of the standard kernel modules, and I'd like to make it possible to update that (and possibly some others in the future) module only on the target system using kernel modules RPM file. The only problem is that the patched module is marked with the exact same revision as the original one, so the only way to update would be to force reinstall of all kernel modules.
Is there any way to manually change PR or a similar version-related parameter for a specific kernel module, or maybe tweak the Yocto project in some other way, so the RPM file built upon it would recognize that module as the only one in need of update?
Related
I have a Yocto system where I'm running some Chef InSpec scans. Chef InSpec offers a command to check if a package is installed, however, that doesn't work with Yocto (I imagine it would if you'd install a package manager, but I don't want to do that). What would be the best way to check if a certain package is installed on the system?
I know that bitbake can show every package that would be in the built image, but I need to check on the target system. Is there a way I can get this information from bitbake from within a recipe that would just route the output into a file on the rootfs? Or is there a better approach without installing a package manager on the target system?
Inside the folder tmp/deploy/images/$MACHINE/${IMAGE}/
You should see a file named with manifest extension. It is often named like this : [image-name]-[image-version].manifest"
In this file you will find all packages that are present in your linux image built with Yocto, so packages that will be deployed in your target.
I'm in the process of upgrading from Yocto Sumo to Yocto Dunfell. In this process there's quite a few packages getting added to the rootfs that wasn't there before and which I don't have use for. I would like to know why they are added? Which dependency triggers them to get added?
In previous versions of Yocto there was a pn-depends.dot file which provided this information. This has now been removed. All that is left is a task-depends.dot which I guess I should use, however it is harder to read as it lists dependencies between individual tasks and doesn't show why a certain package is added to the rootfs. The command bitbake -g <image-name> -u taskexp makes it slightly easier to read the file but it is still hard to understand as package names are not always the same as task names.
What is the preferred solution to get an answer to "why is included in my rootfs?"
I'm attempting to build an image with the phytec bsp 18.2 from here: https://wiki.phytec.com/productinfo/phycore-i-mx7/bsp-yocto-fsl-imx7/
I require a newer version of systemd (> 234) and so am substituting the systemd recipe for version 234 from rocko, found here: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd?h=rocko by putting this in a custom layer. However, during the do_rootfs step, I receive an error that "No package provides libsystemd.so.0(LIBSYSTEMD_219). I've tried a work-around recommended here: Smart can't install...no package provides shared object file and it didn't solve the issue. I've tried echoing libsystemd.so.0, LIBSYSTEMD_219, and libsystemd.so.0(LIBSYSTEMD_219) to both ${rootfs}/etc/rpm/sysinfo/Providename and ${rootfs}/var/lib/rpm/Providename and had no luck. Does anyone have an idea on how to fix this? I'd appreciate any help that could be offered, and please let me know if I can offer any more information.
I don't know about the yocto wrapper, etc, but in standard RPM-land, this error:
Computing transaction...error: Can't install python3-systemd-234-r0.0#cortexa7hf_neon: no package provides libsystemd.so.0(LIBSYSTEMD_219)
means that there is a .so or executable in the RPM named python3-systemd-234-r0.0 that was compiled with a specific version of libsystemd.so.0 that had the flag LIBSYSTEMD_219. That flag is the "ELF Symbol Versioning" and it's seen most with GLIBC_XX when you try to install an RPM that's too new for a target system (e.g. CentOS 7 RPM on CentOS 6).
The systemd on your target machine is too old, so it only defines the versions it is compatible with, e.g. libsystemd.so.0(LIBSYSTEMD_210) or similar.
What you need to do is build your python3-systemd-234-r0.0 on a machine with the same version of systemd as the target (or cross-compile appropriately), or create a systemd RPM that includes the functionality you're attempting.
So you need to figure out how to apply one of these solutions to your build system; sorry I don't know enough about yocto to help there.
Is there a way to install multiple versions of the same package in CentOS/RHEL (7/8) if the package installs separate files in each version?
We have an application we've recently converted to using RPM instead of a home-built package manager based on tar. In order to make atomic-like switches between versions, each version installed in separate directories with the version number in the name, and a symlink with the unversioned name pointed to the current, or previous, version at any given moment in time. The application, of course, used the unversioned name to get init script, configuration files, interpreter version and code. I'm thinking that the alternatives package would be the basis for this, although we wouldn't use the alternatives command to manage symlinks (although there's no technical reason not to).
Not exactly as you describe.
Some packages allow this (Kernel and Kernel-devel being two of them) but i beilieve this is an exception added within the package manager.
Certain Applications like PHP and Python which is perfectly acceptable to have multiple version (Python2.X and 3.X) do this by changing the base name of the application/rpm.
Take a look at: https://rpm.org/user_doc/multiple_versions.html
It gives a good insight on how to achieve what you want
A project I've inherited uses a very old version of buildroot, but I'd like to change it to use a feature that was added only in a later buildroot release.
Is there a straightforward way of updating a buildroot setup to use a later release?
e.g. if I save out a defconfig file and import that in a later buildroot release, would that just work, or are there practical reasons why not? Are there additional configuration files I'd need to carry across (e.g. kernel, busybox, etc)? Thanks!
No.
In fact, it's worse that that.
You can start by using a newer Buildroot version with your old default configuration file, but you will need to check the resulting configuration carefully for deprecated packages and packages whose versions are not compatible with whatever application software you might be adding to the Buildroot filesystem. The names of some packages (e.g. opencv) change over time, so you need to eyeball the resulting .config file to make sure that all of the packages that you need are there.
If you build a toolchain or Linux kernel in Buildroot (commonly done but not generally good practice), then you need to make sure that the new configuration is set to build the old version of the kernel and compiler. These might be too old to build some of the packages in the newer version of Buildroot.
If you upgrade your kernel at the same time that you upgrade Buildroot, then you need to port your old kernel config file to the new kernel version. Since the kernel configuration options change frequently, you will probably need to start from defconfig for your board and then use make menuconfig to manually add the configs that you need.
Busybox is a bit less volatile, so there is a chance that your old config will work.
If your old Buildroot configuration uses postbuild or postimage scripts, you will need to review them, but my guess is that they will not need any changes.
You should allocate at least a week for this work, maybe more, depending on the complexity of the configuration. Remember that if you are forced to use an older vendor kernel due to patches for a specific SoC, for example, the Freescale 2.6.33.9 kernel for the BSC9131, then the upgrade that you want to do might not be possible without doing six to twelve months of work to port the vendor's kernel patches to a newer kernel version.
Cheers.