[yocto] Busybox shell script misbehavior when it is launched by systemd service
Hi,
I have a shell script myscript_launch.sh launched by systemd service,
in the shell script, it call another shell script in background:
if [ -f ${CHECK_ACTIVE} ]; then
echo "script is already running" >> /tmp/debug.log
else
/usr/bin/myscript_check_resource.sh &
echo "launch script result: $?" >> /tmp/debug.log
fi
The script myscript_launch.sh had no problem to be launched by systemd
service, but it could not run another script in the background (no
problem if it launched another script not using "&". I could see
launch script result: 0 in the debug.log, there was no error, but I
could never see that that script myscript_check_resource.sh running.
If I run the script myscript_launch.sh from the debug terminal, I can
see the "/usr/bin/myscript_check_resource.sh &" was running fine.
That is weird busybox behavior, anyone knows how to fix it?
Thank you.
Kind regards,
- jh
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using GitLab for OE/Yocto layers
On Wed, Nov 06, 2019 at 04:01:03PM +, Paul Barker wrote: >... > At the risk of bikeshedding I'd like to get some feedback on these ideas at > this stage. Have I missed any advantages/disadvantages? >... Three comments from me: 1. Patch review Merge requests work well when there is one maintainer who reviews everything. For not regressing on the current level of review before something hits master, merging a merge request into master-next should then result in patch review emails sent to a list. Or a setup where creation of a merge request automatically generates review emails. This is similar to all patches for stable branches now being sent for review to the mailing list a few days before they get merged into the stable branch, which has caught problematic patches due to more people reviewing them. 2. Maintaining an own GitLab instance This was mentioned as an option. Expect upgrades to new GitLab releases once per month, which is work and as with all software never without regression risk. Not a dealbreaker, but has to be resourced. 3. Long-term suistainability Whatever the past track record of GitLab is, chances are the company behind it will sooner or later be bought by another company - and then anything can happen. The code behind SourceForge was also at some point made available under an open source licence, and forks being used in instances like Debian Alioth ended up being unmaintainable dead ends long-term. Berkeley DB would be an example where the company behind the software was bought by another company, and now there are plenty of CVEs that are unfixable due to changed licencing. Is there anyone capable and willing to continue open source maintainance of the GitLab open source sources if the company behind it would stop the open source releases tomorrow? With projects like GNOME using GitLab the answer might be "yes", but this should be evaluated before moving infrastructure to GitLab. > Paul Barker cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel modules packaged but not installed
On Wed, Nov 6, 2019 at 1:40 PM Dimitris Tassopoulos wrote:
>
> Hi Bruce,
>
> I've also tried adding the `kernel-modules` in the IMAGE_INSTALL,
> but that doesn't help either, because as I've mentioned this package
> is empty.
>
> The individual module packages are indeed populated and adding each
> one individually in the IMAGE_INSTALL makes them install in the final
> image.
>
> So the problem is that the `kernel-modules` doesn't add all the module
> packages in one package and it's empty. Therefore, when it's installed
> it installs nothing.
The kernel-modules package is a meta-package. It is supposed to be
empty. It has RDEPENDS on all of the other modules that were built. So
if you install it, it pulls in all of the build and packaged modules.
That works for rpm/ipk, or whatever package format you are using.
Bruce
>
> Regards,
> Dimitris
>
> Bruce Ashfield schrieb am Mi., 6. Nov. 2019, 17:20:
>>
>> On Wed, Nov 6, 2019 at 11:06 AM Dimitris Tassopoulos
>> wrote:
>> >
>> > Hi all. I have a weird issue with the kernel modules not being installed
>> > in the image and also not packaged.
>> > I see the packages for individual "kernel-module-*.ipk" modules but the
>> > "kernel-modules_*.ipk" is always
>> > empty.
>> >
>> > I'm also able to see the "modules-${MACHINE}.tgz" in DEPLOYDIR which has
>> > all the modules in there, just fine.
>> >
>> > In my image file I've also set this:
>> > MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
>>
>> Have you tried something stronger than the RRECOMMENDS ? i.e. either
>> adding one of the modules, or the kernel-modules meta package to
>> IMAGE_INSTALL ?
>>
>> Bruce
>>
>> >
>> > This is the kernel recipe:
>> > https://gitlab.com/dimtass/meta-allwinner-hx/blob/master/recipes-kernel/linux/linux-stable_4.19.bb
>> >
>> > And this is the conf folder
>> > https://gitlab.com/dimtass/meta-allwinner-hx/tree/master/conf
>> >
>> > For some reason I can't figure out why modules are not ending up in the
>> > image.
>> >
>> > If I do it manually in a do_install_append like this:
>> > do_install_append() {
>> > # Install kernel-modules
>> > install -d ${D}${nonarch_base_libdir}
>> > oe_runmake INSTALL_MOD_PATH=${D} modules_install
>> > }
>> >
>> > then it works, but I guess that shouldn't be the right way.
>> >
>> > Any suggestions or ideas?
>> >
>> > Thanks!
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding KVM kernel modules to Yocto Kernel
On Wed, Nov 6, 2019 at 11:56 AM Wayne Li wrote: > > The thing is I don't know how to pick specific kernel modules and add it to > the system. Me and my coworker were able to add missing TUN/TAP kernel > modules using the same process I described (i.e. pulling up the GUI, saving a > .config file for TUN/TAP device driver support, and copying the .config > file's content into the kernel configuration file). And that worked and the > TUN module was added. So I was just trying the same thing as that but for > KVM. I assumed that picking the right option in the GUI and using the right > .config file from there would build the right specific kernel modules into > the kernel. That will ensure the kernel is configured to build the modules, but that doesn't mean they are installed to the image. > > I mean is there another way to specify specific kernel modules I want built > into the system? What do you mean by the generic meta package > "kernel-modules". Just so you know, my coworker was the one who did most of > the work building the Yocto kernel. But he's left the company so now I'm > picking up the pieces. The "kernel-modules" package is a meta package that installs all built modules onto the system. So unless you are really size constrained on the device, use it, and you'll get everything that was configured and built as a module. Bruce > > -Thanks!, Wayne Li > > On Wed, Nov 6, 2019 at 10:40 AM Bruce Ashfield > wrote: >> >> On Wed, Nov 6, 2019 at 11:30 AM Wayne Li wrote: >> > >> > Dear Yocto Developers, >> > >> > I'm trying to get KVM added and working on a Yocto kernel I built up for a >> > T4240 RDB (has a PowerPC CPU). KVM isn't working and the reason why it >> > isn't working seems to be I'm missing the necessary kernel modules. More >> > specifically, I don't seem to have a kvm.ko file that I can load. Here's >> > how I attempted to add KVM to the kernel. >> > >> > I went to the SDK install folder and ran ". fsl-setup-env -m t4240rdb-64b" >> > and then "bitbake virtual/kernel -c menuconfig". After the GUI comes up, >> > I went to Virtualization -> KVM support for PowerPC E500MC/E5500/E6500 >> > processors and hit "Save" to save the configuration. I then went and >> > copied the content of the .config file created by this into the kernel >> > configuration file specified by the following path; >> > "build_t4240rdb-64b/virt1.config". This path was specified by the >> > variable KERNEL_DEFCONFIG in >> > sources/meta_freescale/conf/machine/t4240rdb-64b.conf. Here's what I >> > currently have in the kernel configuration file (i.e. the virt1.config >> > file I mentioned above): >> > >> > https://gist.github.com/WayneZhenLi/4172cd4a819b71a11b85fc5aaa57ebd1 >> > >> > After this, I built the kernel by running "bitbake -c compile -f >> > virtual/kernel" and rebuilt the full linux image. I re-added everything >> > to the SD card and booted up the T4240 RDB with the newly modified Yocto >> > kernel. At this point if I run lsmod, only the following two kernel >> > modules show up: >> > >> > Module Size Used by >> > nfsd 100940 11 >> > exportfs6723 1 nfsd >> > >> > But if I do a "find . -name "kvm"" I get the following: >> > >> > ./usr/src/kernel/Documentation/virtual/kvm >> > ./usr/src/kernel/arch/arm/kvm >> > ./usr/src/kernel/arch/arm64/kvm >> > ./usr/src/kernel/arch/mips/kvm >> > ./usr/src/kernel/arch/powerpc/kvm >> > ./usr/src/kernel/arch/s390/kvm >> > ./usr/src/kernel/arch/tile/kvm >> > ./usr/src/kernel/arch/x86/kvm >> > ./usr/src/kernel/drivers/s390/kvm >> > ./usr/src/kernel/include/config/kvm >> > ./usr/src/kernel/include/config/have/kvm >> > ./usr/src/kernel/include/kvm >> > ./usr/src/kernel/virt/kvm >> > ./dev/kvm >> > ./sys/devices/virtual/misc/kvm >> > ./sys/class/misc/kvm >> > ./sys/kernel/debug/kvm >> > ./sys/module/kvm >> > >> > So it does look like kvm-related files were added to the Yocto kernel >> > because of the changes I made to the kernel configuration file. But there >> > is no kvm.ko (or any .ko file related to kvm) anywhere in the file system. >> >> Is the image you are building installing the specific kernel modules >> you need, or the generic meta package "kernel-modules" ? Without >> something like that, you can build the support, but the modules won't >> be present on the image. >> >> Bruce >> >> > >> > Is there something I'm doing wrong here? Am I missing important lines in >> > my kernel configuration file? Let me know your thoughts. >> > >> > -Thanks!, Wayne Li >> > -- >> > ___ >> > yocto mailing list >> > yocto@yoctoproject.org >> > https://lists.yoctoproject.org/listinfo/yocto >> >> >> >> -- >> - Thou shalt not follow the NULL pointer, for chaos and madness await >> thee at its end >> - "Use the force Harry" - Gandalf, Star Trek II -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use
Re: [yocto] Running systemd service including boot time
On Wed, Nov 6, 2019 at 12:17 PM JH wrote: > > Hi, > > I built Yocto image to include a systemd service and it's timer, the > timer calls the service repeated every 30 minutes, it runs well, but I > need it also run it first time in the boot, not wait 30 minutes. I > tried to add OnBootSec=2, it does not run in boot, any tips how can I > force it run immediately in boot? > > OnBootSec=2 I wonder if 2s is too less of an elapsed time. Could you test setting it to say 30s > OnActiveSec=30min > > Thank you. > > Kind regards, > > - jh > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Running systemd service including boot time
Hi, I built Yocto image to include a systemd service and it's timer, the timer calls the service repeated every 30 minutes, it runs well, but I need it also run it first time in the boot, not wait 30 minutes. I tried to add OnBootSec=2, it does not run in boot, any tips how can I force it run immediately in boot? OnBootSec=2 OnActiveSec=30min Thank you. Kind regards, - jh -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding KVM kernel modules to Yocto Kernel
The thing is I don't know how to pick specific kernel modules and add it to the system. Me and my coworker were able to add missing TUN/TAP kernel modules using the same process I described (i.e. pulling up the GUI, saving a .config file for TUN/TAP device driver support, and copying the .config file's content into the kernel configuration file). And that worked and the TUN module was added. So I was just trying the same thing as that but for KVM. I assumed that picking the right option in the GUI and using the right .config file from there would build the right specific kernel modules into the kernel. I mean is there another way to specify specific kernel modules I want built into the system? What do you mean by the generic meta package "kernel-modules". Just so you know, my coworker was the one who did most of the work building the Yocto kernel. But he's left the company so now I'm picking up the pieces. -Thanks!, Wayne Li On Wed, Nov 6, 2019 at 10:40 AM Bruce Ashfield wrote: > On Wed, Nov 6, 2019 at 11:30 AM Wayne Li wrote: > > > > Dear Yocto Developers, > > > > I'm trying to get KVM added and working on a Yocto kernel I built up for > a T4240 RDB (has a PowerPC CPU). KVM isn't working and the reason why it > isn't working seems to be I'm missing the necessary kernel modules. More > specifically, I don't seem to have a kvm.ko file that I can load. Here's > how I attempted to add KVM to the kernel. > > > > I went to the SDK install folder and ran ". fsl-setup-env -m > t4240rdb-64b" and then "bitbake virtual/kernel -c menuconfig". After the > GUI comes up, I went to Virtualization -> KVM support for PowerPC > E500MC/E5500/E6500 processors and hit "Save" to save the configuration. I > then went and copied the content of the .config file created by this into > the kernel configuration file specified by the following path; > "build_t4240rdb-64b/virt1.config". This path was specified by the variable > KERNEL_DEFCONFIG in sources/meta_freescale/conf/machine/t4240rdb-64b.conf. > Here's what I currently have in the kernel configuration file (i.e. the > virt1.config file I mentioned above): > > > > https://gist.github.com/WayneZhenLi/4172cd4a819b71a11b85fc5aaa57ebd1 > > > > After this, I built the kernel by running "bitbake -c compile -f > virtual/kernel" and rebuilt the full linux image. I re-added everything to > the SD card and booted up the T4240 RDB with the newly modified Yocto > kernel. At this point if I run lsmod, only the following two kernel > modules show up: > > > > Module Size Used by > > nfsd 100940 11 > > exportfs6723 1 nfsd > > > > But if I do a "find . -name "kvm"" I get the following: > > > > ./usr/src/kernel/Documentation/virtual/kvm > > ./usr/src/kernel/arch/arm/kvm > > ./usr/src/kernel/arch/arm64/kvm > > ./usr/src/kernel/arch/mips/kvm > > ./usr/src/kernel/arch/powerpc/kvm > > ./usr/src/kernel/arch/s390/kvm > > ./usr/src/kernel/arch/tile/kvm > > ./usr/src/kernel/arch/x86/kvm > > ./usr/src/kernel/drivers/s390/kvm > > ./usr/src/kernel/include/config/kvm > > ./usr/src/kernel/include/config/have/kvm > > ./usr/src/kernel/include/kvm > > ./usr/src/kernel/virt/kvm > > ./dev/kvm > > ./sys/devices/virtual/misc/kvm > > ./sys/class/misc/kvm > > ./sys/kernel/debug/kvm > > ./sys/module/kvm > > > > So it does look like kvm-related files were added to the Yocto kernel > because of the changes I made to the kernel configuration file. But there > is no kvm.ko (or any .ko file related to kvm) anywhere in the file system. > > Is the image you are building installing the specific kernel modules > you need, or the generic meta package "kernel-modules" ? Without > something like that, you can build the support, but the modules won't > be present on the image. > > Bruce > > > > > Is there something I'm doing wrong here? Am I missing important lines > in my kernel configuration file? Let me know your thoughts. > > > > -Thanks!, Wayne Li > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding KVM kernel modules to Yocto Kernel
On Wed, Nov 6, 2019 at 11:30 AM Wayne Li wrote: > > Dear Yocto Developers, > > I'm trying to get KVM added and working on a Yocto kernel I built up for a > T4240 RDB (has a PowerPC CPU). KVM isn't working and the reason why it isn't > working seems to be I'm missing the necessary kernel modules. More > specifically, I don't seem to have a kvm.ko file that I can load. Here's how > I attempted to add KVM to the kernel. > > I went to the SDK install folder and ran ". fsl-setup-env -m t4240rdb-64b" > and then "bitbake virtual/kernel -c menuconfig". After the GUI comes up, I > went to Virtualization -> KVM support for PowerPC E500MC/E5500/E6500 > processors and hit "Save" to save the configuration. I then went and copied > the content of the .config file created by this into the kernel configuration > file specified by the following path; "build_t4240rdb-64b/virt1.config". > This path was specified by the variable KERNEL_DEFCONFIG in > sources/meta_freescale/conf/machine/t4240rdb-64b.conf. Here's what I > currently have in the kernel configuration file (i.e. the virt1.config file I > mentioned above): > > https://gist.github.com/WayneZhenLi/4172cd4a819b71a11b85fc5aaa57ebd1 > > After this, I built the kernel by running "bitbake -c compile -f > virtual/kernel" and rebuilt the full linux image. I re-added everything to > the SD card and booted up the T4240 RDB with the newly modified Yocto kernel. > At this point if I run lsmod, only the following two kernel modules show up: > > Module Size Used by > nfsd 100940 11 > exportfs6723 1 nfsd > > But if I do a "find . -name "kvm"" I get the following: > > ./usr/src/kernel/Documentation/virtual/kvm > ./usr/src/kernel/arch/arm/kvm > ./usr/src/kernel/arch/arm64/kvm > ./usr/src/kernel/arch/mips/kvm > ./usr/src/kernel/arch/powerpc/kvm > ./usr/src/kernel/arch/s390/kvm > ./usr/src/kernel/arch/tile/kvm > ./usr/src/kernel/arch/x86/kvm > ./usr/src/kernel/drivers/s390/kvm > ./usr/src/kernel/include/config/kvm > ./usr/src/kernel/include/config/have/kvm > ./usr/src/kernel/include/kvm > ./usr/src/kernel/virt/kvm > ./dev/kvm > ./sys/devices/virtual/misc/kvm > ./sys/class/misc/kvm > ./sys/kernel/debug/kvm > ./sys/module/kvm > > So it does look like kvm-related files were added to the Yocto kernel because > of the changes I made to the kernel configuration file. But there is no > kvm.ko (or any .ko file related to kvm) anywhere in the file system. Is the image you are building installing the specific kernel modules you need, or the generic meta package "kernel-modules" ? Without something like that, you can build the support, but the modules won't be present on the image. Bruce > > Is there something I'm doing wrong here? Am I missing important lines in my > kernel configuration file? Let me know your thoughts. > > -Thanks!, Wayne Li > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Adding KVM kernel modules to Yocto Kernel
Dear Yocto Developers, I'm trying to get KVM added and working on a Yocto kernel I built up for a T4240 RDB (has a PowerPC CPU). KVM isn't working and the reason why it isn't working seems to be I'm missing the necessary kernel modules. More specifically, I don't seem to have a kvm.ko file that I can load. Here's how I attempted to add KVM to the kernel. I went to the SDK install folder and ran ". fsl-setup-env -m t4240rdb-64b" and then "bitbake virtual/kernel -c menuconfig". After the GUI comes up, I went to Virtualization -> KVM support for PowerPC E500MC/E5500/E6500 processors and hit "Save" to save the configuration. I then went and copied the content of the .config file created by this into the kernel configuration file specified by the following path; "build_t4240rdb-64b/virt1.config". This path was specified by the variable KERNEL_DEFCONFIG in sources/meta_freescale/conf/machine/t4240rdb-64b.conf. Here's what I currently have in the kernel configuration file (i.e. the virt1.config file I mentioned above): https://gist.github.com/WayneZhenLi/4172cd4a819b71a11b85fc5aaa57ebd1 After this, I built the kernel by running "bitbake -c compile -f virtual/kernel" and rebuilt the full linux image. I re-added everything to the SD card and booted up the T4240 RDB with the newly modified Yocto kernel. At this point if I run lsmod, only the following two kernel modules show up: Module Size Used by nfsd 100940 11 exportfs6723 1 nfsd But if I do a "find . -name "kvm"" I get the following: ./usr/src/kernel/Documentation/virtual/kvm ./usr/src/kernel/arch/arm/kvm ./usr/src/kernel/arch/arm64/kvm ./usr/src/kernel/arch/mips/kvm ./usr/src/kernel/arch/powerpc/kvm ./usr/src/kernel/arch/s390/kvm ./usr/src/kernel/arch/tile/kvm ./usr/src/kernel/arch/x86/kvm ./usr/src/kernel/drivers/s390/kvm ./usr/src/kernel/include/config/kvm ./usr/src/kernel/include/config/have/kvm ./usr/src/kernel/include/kvm ./usr/src/kernel/virt/kvm ./dev/kvm ./sys/devices/virtual/misc/kvm ./sys/class/misc/kvm ./sys/kernel/debug/kvm ./sys/module/kvm So it does look like kvm-related files were added to the Yocto kernel because of the changes I made to the kernel configuration file. But there is no kvm.ko (or any .ko file related to kvm) anywhere in the file system. Is there something I'm doing wrong here? Am I missing important lines in my kernel configuration file? Let me know your thoughts. -Thanks!, Wayne Li -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel modules packaged but not installed
On Wed, Nov 6, 2019 at 11:06 AM Dimitris Tassopoulos wrote:
>
> Hi all. I have a weird issue with the kernel modules not being installed in
> the image and also not packaged.
> I see the packages for individual "kernel-module-*.ipk" modules but the
> "kernel-modules_*.ipk" is always
> empty.
>
> I'm also able to see the "modules-${MACHINE}.tgz" in DEPLOYDIR which has all
> the modules in there, just fine.
>
> In my image file I've also set this:
> MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
Have you tried something stronger than the RRECOMMENDS ? i.e. either
adding one of the modules, or the kernel-modules meta package to
IMAGE_INSTALL ?
Bruce
>
> This is the kernel recipe:
> https://gitlab.com/dimtass/meta-allwinner-hx/blob/master/recipes-kernel/linux/linux-stable_4.19.bb
>
> And this is the conf folder
> https://gitlab.com/dimtass/meta-allwinner-hx/tree/master/conf
>
> For some reason I can't figure out why modules are not ending up in the image.
>
> If I do it manually in a do_install_append like this:
> do_install_append() {
> # Install kernel-modules
> install -d ${D}${nonarch_base_libdir}
> oe_runmake INSTALL_MOD_PATH=${D} modules_install
> }
>
> then it works, but I guess that shouldn't be the right way.
>
> Any suggestions or ideas?
>
> Thanks!
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using GitLab for OE/Yocto layers
Hey folks, We had some initial discussion at OEDEM about the patch submission process and how repositories are hosted (see https://docs.google.com/document/d/1Qm1mJ6xLozWW9NgBnokue7TmhwgFP8b2HR8TUlaQwNs/edit#heading=h.o4qtddy8bh9i). Patch submission via mailing list still has some key features (such as ability to compose a patch response offline) and I don't expect that the core OE/Yocto repositories will be changing their workflow in the short term. However, lots of tools and non-core layers already use a pull request model for patch submission, typically via GitHub or GitLab. I'd like to propose that we set up a common place for OE/Yocto repositories which want to use this pull request model and start to collaborate on some of the tooling. As discussed in OEDEM, GitLab has a few major advantages over GitHub, BitBucket, etc here as they've got a track record of working well with open source projects and we can run the software on our own infrastructure if desired. We can use something like https://gitlab.com/openembedded at first to trial things and then maybe move to https://gitlab.openembedded.org (or gitlab.yoctoproject.org) if things look good. I see the following advantages to this approach: * Increased bus factor for repository administration - several layers currently have only one admin or live in someone's personal GitHub account, we risk losing access to these if the person in question disappears. * Integrated issue tracking - we can standardise on a few issue labels and use milestones in GitLab to correspond to Yocto release branches. As the repositories would be in the same group we would be able to make use of group-level issue lists and boards to show issues across several layers. * Integrated merge request tracking - Similar to issues, we would be able to see a combined group-level list of open merge requests. This is a good view to use to help out other layer maintainers as you can easily see new merge requests across all repositories and pick a few to review. * Separation of patches to different repositories/branches - Where one mailing list takes patches for many repositories it's often confusing which repository or branch is the target for a given patch. * Easier contribution from behind corporate firewalls or buggy email servers - contribution is via ssh/https. * Subgroups - GitLab supports more than one layer of grouping so we can organise repositories even within the top level "openembedded" group. * Ability to enable/disable merge requests per-repository - With GitHub you can't disable pull requests. If your repository takes patches by another method you have to manually watch out for pull requests and comment on each one to tell the contributor how to submit patches. With GitLab this isn't necessary as you can just turn off merge requests for that repository. * Ability to standardise on automated testing - we can integrate patchtest and yocto-check-layer with GitLab CI and run these scripts on each merge request. This requires a bit of work in both test scripts to allow configuration as not all tests will be appropriate for all layers. However it's much easier than integrating these scripts with several incompatible repository hosts and CI systems. * Ability to standardise on security - If we want to we can enforce two-factor authentication (2FA) for logins, make use of the merge request approvals feature in GitLab, etc. We don't need to do that initially but it may be useful in the future. At the risk of bikeshedding I'd like to get some feedback on these ideas at this stage. Have I missed any advantages/disadvantages? Is anyone interested in helping to guinea pig this with a couple of layers/repositories to see how it works in practice? -- Paul Barker -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel modules packaged but not installed
Hi all. I have a weird issue with the kernel modules not being installed in
the image and also not packaged.
I see the packages for individual "kernel-module-*.ipk" modules but the
"kernel-modules_*.ipk" is always
empty.
I'm also able to see the "modules-${MACHINE}.tgz" in DEPLOYDIR which has
all the modules in there, just fine.
In my image file I've also set this:
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
This is the kernel recipe:
https://gitlab.com/dimtass/meta-allwinner-hx/blob/master/recipes-kernel/linux/linux-stable_4.19.bb
And this is the conf folder
https://gitlab.com/dimtass/meta-allwinner-hx/tree/master/conf
For some reason I can't figure out why modules are not ending up in the
image.
If I do it manually in a do_install_append like this:
do_install_append() {
# Install kernel-modules
install -d ${D}${nonarch_base_libdir}
oe_runmake INSTALL_MOD_PATH=${D} modules_install
}
then it works, but I guess that shouldn't be the right way.
Any suggestions or ideas?
Thanks!
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] install kernel-modules in rootfs without kernel
Dear list, I want to deploy a kernel-module like poky/meta-skeleton/recipes-kernel/hello-mod. But, when I add IMAGE_INSTALL += "kernel-module-hello" to my image, the modules is as expected below /lib/modules/ , more then that the kernel is also installed below /boot/. My kernel should not be part of the rootfs, but "inherit module" forces the kernel to be populated below /boot/Image. How to correctly stop the kernel to be part of the rootfs? Best John -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] Error with Pyro and wic
Ok I solved.
The problem is the filesystem of destination folder.
The /deploy is a shared vboxsf shared folder.
If build the sdcard in local folder all works
M
Il 06/11/19 09:48, Mauro Ziliani ha scritto:
Hi all.
I'm trying to port udooneo to Pyro.
By now I build core-image-minimal
I try to make a udoo-sdcard with the command
wic create -e core-image-minimal udoo-sdard -o /deploy/udoo-scard
udoo-sdcard.wks is placed in meta-udoo/scripts/lib/wic/canned-wks
udoo-sdcard.wks ---
bootloader
part SPL --source rawcopy --sourceparams="file=SPL" --ondisk mmcblk
--no-table --align 1
part u-boot --source rawcopy --sourceparams="file=u-boot.img" --ondisk
mmcblk --no-table --align 69
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root
--align 4096
udoo-sdcard.wks ---
When tryo to build an sdcard with wic I get this errors
errors
INFO: Creating image(s)...
Traceback (most recent call last):
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py",
line 389, in _invoke_fiemap
fcntl.ioctl(self._f_image, _FIEMAP_IOCTL, self._buf, 1)
OSError: [Errno 95] Operation not supported
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py",
line 529, in filemap
return FilemapFiemap(image, log)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py",
line 363, in __init__
self.block_is_mapped(0)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py",
line 410, in block_is_mapped
struct_fiemap = self._invoke_fiemap(block, 1)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py",
line 397, in _invoke_fiemap
raise ErrorNotSupp(errstr)
wic.filemap.ErrorNotSupp: FilemapFiemap: the FIEMAP ioctl is not
supported by the file-system
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/mauro/pyro/sources/poky/scripts/wic", line 326, in
sys.exit(main(sys.argv[1:]))
File "/home/mauro/pyro/sources/poky/scripts/wic", line 321, in main
return hlp.invoke_subcommand(args, parser, hlp.wic_help_usage,
subcommands)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/help.py", line
97, in invoke_subcommand
subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
File "/home/mauro/pyro/sources/poky/scripts/wic", line 259, in
wic_create_subcommand
native_sysroot, options)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/engine.py", line
195, in wic_create
plugin.do_create()
File
"/home/mauro/pyro/sources/poky/scripts/lib/wic/plugins/imager/direct.py",
line 96, in do_create
self.assemble()
File
"/home/mauro/pyro/sources/poky/scripts/lib/wic/plugins/imager/direct.py",
line 187, in assemble
self._image.assemble()
File
"/home/mauro/pyro/sources/poky/scripts/lib/wic/plugins/imager/direct.py",
line 553, in assemble
sparse_copy(source, self.path, part.start * self.sector_size)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py",
line 537, in sparse_copy
fmap = api(src_fname)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py",
line 531, in filemap
return FilemapSeek(image, log)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py",
line 210, in __init__
self._probe_seek_hole()
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py",
line 245, in _probe_seek_hole
raise ErrorNotSupp("the file-system does not support "
wic.filemap.ErrorNotSupp: the file-system does not support "SEEK_HOLE"
and "SEEK_DATA" but only provides a stub implementation
It seems that wic doesn't have some function to handle a part defined
in wks.
Any suggestions?
Best regards,
Mauro
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-gplv2][PATCH] dosfstools: fix out of bound writes
Fix write issues where sprintf writes across both name and ext fields
and drops the final null terminator outside the struct
Signed-off-by: AJ Bagwell
---
.../fixing-out-of-bound-writes.patch | 54 +++
.../dosfstools/dosfstools_2.11.bb | 1 +
2 files changed, 55 insertions(+)
create mode 100644
recipes-devtools/dosfstools/dosfstools/fixing-out-of-bound-writes.patch
diff --git
a/recipes-devtools/dosfstools/dosfstools/fixing-out-of-bound-writes.patch
b/recipes-devtools/dosfstools/dosfstools/fixing-out-of-bound-writes.patch
new file mode 100644
index 000..f80f5ab
--- /dev/null
+++ b/recipes-devtools/dosfstools/dosfstools/fixing-out-of-bound-writes.patch
@@ -0,0 +1,54 @@
+Fix out of bound write issues where sprintf writes across both
+name and ext fields and drops the final null terminator outside the struct
+
+Upstream-Status: Inappropriate [licensing]
+We're tracking an old release of dosfstools due to licensing issues.
+
+diff --git a/dosfsck/check.c b/dosfsck/check.c
+index e8c13bb..91177d3 100644
+--- a/dosfsck/check.c
b/dosfsck/check.c
+@@ -58,6 +58,13 @@ static DOS_FILE *root;
+ }\
+ } while(0)
+
++static void de_printf(DIR_ENT *de, const char *pattern, int curr_num)
++{
++char buffer[12];
++sprintf(buffer, pattern, curr_num);
++memcpy(de->name, buffer, 8);
++memcpy(de->ext, buffer + 8, 3);
++}
+
+ loff_t alloc_rootdir_entry(DOS_FS *fs, DIR_ENT *de, const char *pattern)
+ {
+@@ -110,7 +117,8 @@ loff_t alloc_rootdir_entry(DOS_FS *fs, DIR_ENT *de, const
char *pattern)
+ }
+ memset(de,0,sizeof(DIR_ENT));
+ while (1) {
+-sprintf(de->name,pattern,curr_num);
++de_printf(de, pattern, curr_num);
++
+ clu_num = fs->root_cluster;
+ i = 0;
+ offset2 = cluster_start(fs,clu_num);
+@@ -150,7 +158,7 @@ loff_t alloc_rootdir_entry(DOS_FS *fs, DIR_ENT *de, const
char *pattern)
+ offset = fs->root_start+next_free*sizeof(DIR_ENT);
+ memset(de,0,sizeof(DIR_ENT));
+ while (1) {
+-sprintf(de->name,pattern,curr_num);
++de_printf(de, pattern, curr_num);
+ for (scan = 0; scan < fs->root_entries; scan++)
+ if (scan != next_free &&
+ !strncmp(root[scan].name,de->name,MSDOS_NAME))
+@@ -311,8 +319,8 @@ static void auto_rename(DOS_FILE *file)
+ first = file->parent ? file->parent->first : root;
+ number = 0;
+ while (1) {
+-sprintf(file->dir_ent.name,"FSCK%04d",number);
+-strncpy(file->dir_ent.ext,"REN",3);
++de_printf(>dir_ent, "FSCK%04dREN", number);
++
+ for (walk = first; walk; walk = walk->next)
+ if (walk != file && !strncmp(walk->dir_ent.name,file->dir_ent.
+ name,MSDOS_NAME)) break;
diff --git a/recipes-devtools/dosfstools/dosfstools_2.11.bb
b/recipes-devtools/dosfstools/dosfstools_2.11.bb
index dd543b1..37c2181 100644
--- a/recipes-devtools/dosfstools/dosfstools_2.11.bb
+++ b/recipes-devtools/dosfstools/dosfstools_2.11.bb
@@ -19,6 +19,7 @@ SRC_URI =
"http://pkgs.fedoraproject.org/repo/pkgs/${BPN}/${BP}.src.tar.gz/407d4
file://nofat32_autoselect.patch \
file://fix_populated_dosfs_creation.patch \
file://0001-Include-fcntl.h-for-getting-loff_t-definition.patch \
+ file://fixing-out-of-bound-writes.patch \
"
SRC_URI[md5sum] = "407d405ade410f7597d364ab5dc8c9f6"
--
2.17.1
The information contained in or attached to this email is intended only for the
use of the individual or entity to which it is addressed. If you are not the
intended recipient, or a person responsible for delivering it to the intended
recipient, you are not authorised to and must not disclose, copy, distribute,
or retain this message or any part of it. It may contain information which is
confidential and/or covered by legal professional or other privilege under
applicable law.
The views expressed in this email are not necessarily the views of Centrica plc
or its subsidiaries, and the company, its directors, officers or employees make
no representation or accept any liability for its accuracy or completeness
unless expressly stated to the contrary.
Additional regulatory disclosures may be found here:
https://www.centrica.com/privacy-cookies-and-legal-disclaimer#email
PH Jones is a trading name of British Gas Social Housing Limited. British Gas
Social Housing Limited (company no: 01026007), British Gas Trading Limited
(company no: 03078711), British Gas Services Limited (company no: 3141243),
British Gas Insurance Limited (company no: 06608316), British Gas New Heating
Limited (company no: 06723244), British Gas Services (Commercial) Limited
(company no: 07385984) and Centrica Energy (Trading) Limited (company no:
02877397) are all wholly owned subsidiaries of Centrica plc (company no:
3033654). Each company is registered in England and Wales with a registered
office at Millstream, Maidenhead Road, Windsor, Berkshire SL4 5GD.
British Gas Insurance Limited is authorised by the Prudential Regulation
Authority and regulated by the Financial Conduct Authority and
[yocto] Error with Pyro and wic
Hi all.
I'm trying to port udooneo to Pyro.
By now I build core-image-minimal
I try to make a udoo-sdcard with the command
wic create -e core-image-minimal udoo-sdard -o /deploy/udoo-scard
udoo-sdcard.wks is placed in meta-udoo/scripts/lib/wic/canned-wks
udoo-sdcard.wks ---
bootloader
part SPL --source rawcopy --sourceparams="file=SPL" --ondisk mmcblk
--no-table --align 1
part u-boot --source rawcopy --sourceparams="file=u-boot.img" --ondisk
mmcblk --no-table --align 69
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root
--align 4096
udoo-sdcard.wks ---
When tryo to build an sdcard with wic I get this errors
errors
INFO: Creating image(s)...
Traceback (most recent call last):
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py", line
389, in _invoke_fiemap
fcntl.ioctl(self._f_image, _FIEMAP_IOCTL, self._buf, 1)
OSError: [Errno 95] Operation not supported
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py", line
529, in filemap
return FilemapFiemap(image, log)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py", line
363, in __init__
self.block_is_mapped(0)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py", line
410, in block_is_mapped
struct_fiemap = self._invoke_fiemap(block, 1)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py", line
397, in _invoke_fiemap
raise ErrorNotSupp(errstr)
wic.filemap.ErrorNotSupp: FilemapFiemap: the FIEMAP ioctl is not
supported by the file-system
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/mauro/pyro/sources/poky/scripts/wic", line 326, in
sys.exit(main(sys.argv[1:]))
File "/home/mauro/pyro/sources/poky/scripts/wic", line 321, in main
return hlp.invoke_subcommand(args, parser, hlp.wic_help_usage,
subcommands)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/help.py", line
97, in invoke_subcommand
subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
File "/home/mauro/pyro/sources/poky/scripts/wic", line 259, in
wic_create_subcommand
native_sysroot, options)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/engine.py", line
195, in wic_create
plugin.do_create()
File
"/home/mauro/pyro/sources/poky/scripts/lib/wic/plugins/imager/direct.py",
line 96, in do_create
self.assemble()
File
"/home/mauro/pyro/sources/poky/scripts/lib/wic/plugins/imager/direct.py",
line 187, in assemble
self._image.assemble()
File
"/home/mauro/pyro/sources/poky/scripts/lib/wic/plugins/imager/direct.py",
line 553, in assemble
sparse_copy(source, self.path, part.start * self.sector_size)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py", line
537, in sparse_copy
fmap = api(src_fname)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py", line
531, in filemap
return FilemapSeek(image, log)
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py", line
210, in __init__
self._probe_seek_hole()
File "/home/mauro/pyro/sources/poky/scripts/lib/wic/filemap.py", line
245, in _probe_seek_hole
raise ErrorNotSupp("the file-system does not support "
wic.filemap.ErrorNotSupp: the file-system does not support "SEEK_HOLE"
and "SEEK_DATA" but only provides a stub implementation
It seems that wic doesn't have some function to handle a part defined in
wks.
Any suggestions?
Best regards,
Mauro
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
