[yocto] devtmpfs failing to mount
Hi all - I'm using Yocto version rocko with a custom layer to run on the Zynq+ SoC on a custom board. When trying to boot I'm getting the following error in the boot output: [4.205861] devtmpfs: error mounting -2 dmesg | tail shows a similar result: [4.127997] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities [4.183737] EXT4-fs (mmcblk0p2): recovery complete [4.190840] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) [4.198870] VFS: Mounted root (ext4 filesystem) on device 179:2. [4.205861] devtmpfs: error mounting -2 Are there common reasons for this happening I should check? I'm having trouble isolating a cause. The only change I made was including an additional python library in one of my recipes, which I will try rolling back next. Any ideas are greatly appreciated! Thanks, Emily -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] devtmpfs failing to mount
Hello! Yes those are both useful things to know. I am booting by flashing an SD card with a wic image (made using sdimage-bootpart.wks), so the flashing process takes care of creating the partitions. So the partition should be of type EXT4. The mounting process is actually what I'm a little fuzzy on in the first place. In October I had no issues with a mounting error for devtmpfs, and I've made few changes since, however I can't seem to shake this error, even when checking out older versions of the yocto repositories. The mounting process should be mostly taken from the meta-xilinx repository. Thanks, Emily On Mon, Mar 11, 2019 at 3:16 PM Loïc Domaigné wrote: > Bonsoir Emily, > > > I'm using Yocto version rocko with a custom layer to run on the Zynq+ SoC > > on a custom board. When trying to boot I'm getting the following error in > > the boot output: > > ... > > [4.127997] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature > > incompatibilities > > [4.183737] EXT4-fs (mmcblk0p2): recovery complete > > [4.190840] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data > > mode. Opts: (null) > > [4.198870] VFS: Mounted root (ext4 filesystem) on device 179:2. > > [4.205861] devtmpfs: error mounting -2 > > > > Are there common reasons for this happening I should check? > > Not sure if that helps, but I'd check: > a) What's the type of the mmcblk0p2 (=rootfs?) partition? and > b) How is this partition mounted? > > Cheers! > Loïc > -- > ___ > 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] /usr/bin/env requires coreutils?
Hi all - It seems like now you need to depend on coreutils to get /usr/bin/env working, why is that? Coreutils is a bit big and takes awhile to compile. This wasn't the previous behavior, and I'm wondering why it was changed. Thanks! Emily -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] /usr/bin/env requires coreutils?
Hi Leon - The full error is below, but essentially: nothing provides /usr/bin/env needed by init-clock-1.0.0-r0.aarch64 Thanks! Emily ERROR: core-image-gfex-1.0-r0 do_rootfs: Could not invoke dnf. Command '/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/gfex_prototype4-poky-linux/core-image-gfex/1.0-r0/recipe-sysroot-native/usr/bin/dnf -y -c /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/gfex_prototype4-poky-linux/core-image-gfex/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/gfex_prototype4-poky-linux/core-image-gfex/1.0-r0/rootfs/etc/yum.repos.d --repofrompath=oe-repo,/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/gfex_prototype4-poky-linux/core-image-gfex/1.0-r0/oe-rootfs-repo --installroot=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/gfex_prototype4-poky-linux/core-image-gfex/1.0-r0/rootfs --setopt=logdir=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/gfex_prototype4-poky-linux/core-image-gfex/1.0-r0/temp --nogpgcheck install init-clock run-postinsts locale-base-en-us locale-base-en-gb' returned 1: Added oe-repo repo from /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/gfex_prototype4-poky-linux/core-image-gfex/1.0-r0/oe-rootfs-repo Last metadata expiration check: 0:00:00 ago on Tue 12 Mar 2019 09:57:18 PM UTC. Error: Problem: conflicting requests - nothing provides /usr/bin/env needed by init-clock-1.0.0-r0.aarch64 ERROR: core-image-gfex-1.0-r0 do_rootfs: Function failed: do_rootfs ERROR: Logfile of failure stored in: /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/gfex_prototype4-poky-linux/core-image-gfex/1.0-r0/temp/log.do_rootfs.16222 ERROR: Task (/local/d6/easmith5/rocko_bitbake/meta-l1calo/recipes-core/images/core-image-gfex.bb:do_rootfs) failed with exit code '1' On Tue, Mar 12, 2019 at 3:02 PM Leon Woestenberg wrote: > Hi Emily, > > On Tue, Mar 12, 2019 at 7:45 PM Emily S wrote: > > > > It seems like now you need to depend on coreutils to get /usr/bin/env > working, why is that? Coreutils is a bit big and takes awhile to compile. > > This wasn't the previous behavior, and I'm wondering why it was changed. > > > What issue do you see without core-utils? > > Regards, Leon. > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] /usr/bin/env requires coreutils?
Hi Leon -
When you ask if there is anything in /usr/bin at all I'm not sure what you
mean, could you elaborate?
Ahh so you're saying something in the init-clock recipe itself is incorrect
in the way it uses ${bindir}? I did not actually write this recipe so I may
be not understanding it fully, but I don't actually see ${bindir} in it
anywhere.
Yes that link is the correct recipe!
Thanks!
Emily
On Tue, Mar 12, 2019 at 5:27 PM Leon Woestenberg
wrote:
> Hi Emily,
>
> I guess the problem is more in your init-clock recipe, and I am
> assuming this one:
>
>
> https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/init/init-clock_1.0.0.bb
>
> This probably was always incorrect, but the problem now shows with
> newer Yocto releases.
>
> Regards,
>
> Leon
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] /usr/bin/env requires coreutils?
Hi Leon -
Ahh okay you meant just literally if there was anything else in it. An
additional complication of my setup is that our custom board is in Europe,
so right now there's no one to load the OS for me and boot, but I will
check as soon as I can.
In regards to your second point, do you mean that the init-clock recipe
might be trying to install the script in a slightly incorrect location? For
example it's trying to install in /usr/bin/env when my OS is setup to use
/bin/env instead?
Thanks,
Emily
On Tue, Mar 12, 2019 at 6:24 PM Leon Woestenberg
wrote:
> Hi Emily,
>
> On Tue, Mar 12, 2019 at 11:53 PM Emily S wrote:
> >
> > When you ask if there is anything in /usr/bin at all I'm not sure what
> you mean, could you elaborate?
> >
> On the root filesystem, do you see other executables in the /usr/bin/
> directory?
>
> > Ahh so you're saying something in the init-clock recipe itself is
> incorrect in the way it uses ${bindir}? I did not actually write this
> recipe so I may be not understanding it fully, but I don't actually see
> ${bindir} in it anywhere.
> >
> That last part of the sentence might be the actual problem, in case
> you do not have /usr/bin/env (but /bin/env for example).
>
> > Yes that link is the correct recipe!
> >
> Google power.
>
> Regards,
>
> Leon.
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] /usr/bin/env requires coreutils?
Hi Leon - Thanks again for your help. In /usr/bin right now there seems to be mostly coreutils generated things, but some python as well. I'll have to double check the hard-coded header in init-clock, didn't realize anything was hard coded. I have an additional question for perhaps you or anyone on the list: With this same OS (yocto rocko & our custom layer meta-l1calo: https://github.com/kratsg/meta-l1calo) I was previously having issues with devtmpfs not mounting at boot, but after updating to the most recent rocko commits in openembedded-core and poky, that issue seemed to go away, however my boot stops after devtmpfs is mounted (before udev can start). Additionally I'm not given a login and instead directed immediately to a shell. I don't think I have changed anything to do with udev or devtmpfs, does anyone have ideas on why that might be happening? I've attached the entire boot log. Thanks, Emily On Tue, Mar 12, 2019 at 7:05 PM Leon Woestenberg wrote: > Hi Emily, > > On Wed, Mar 13, 2019 at 12:50 AM Emily S wrote: > > > > Ahh okay you meant just literally if there was anything else in it. An > additional complication of my setup is that our custom board is in Europe, > so right now there's no one to load the OS for me and boot, but I will > check as soon as I can. > > > You could check the locally generated filesystem image also, you > typically do not need access to the board to verify this. > > Something like tar tvf or "wic ls" - depending on your image type(s) > -- see the Yocto docs for WIC inspection, I don't know from heart. > > (But I would travel to Europe Alps and have the trip paid -- much > better than remote board access). > > > In regards to your second point, do you mean that the init-clock recipe > might be trying to install the script in a slightly incorrect location? For > example it's trying to install in /usr/bin/env when my OS is setup to use > /bin/env instead? > > > I mean "env" could be installed to /bin/env, whereas the "shebang" in > the header is hard-coded to use /usr/bin/env. > Solution: remove the hard-coding in init-clock. > > With this, you should be able to inspect further. > > Regards, > > Leon. > boot.log Description: Binary data -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Incorporating Xilinx DNNDK into Yocto
Hi all - Xilinx has the Deep Neural Network Development Kit (DNNDK) that they just released the source code for in the last month or so. They have the code written nicely in the form of yocto recipes but it doesn't appear to be an actual layer: https://github.com/Xilinx/Edge-AI-Platform-Tutorials/tree/master/docs/DPU-Integration/reference-files/files . Is there a possibility of creating a layer for it? Or should I look into other options, like adding it as a submodule to my custom layer meta-l1calo: https://github.com/kratsg/meta-l1calo? Or if anyone has additional options, suggestions are appreciated! Thanks for the help! Emily -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
