[yocto] meta-openstack: bundler fails to build
Hi, I'm trying to build bundler ruby tool from meta-openstack (thud branch) but it fails with following: ERROR: bundler-1.6.2-r0 do_compile: Function failed: do_compile (log file is located at /home/builder/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/bundler/1.6.2-r0/temp/log.do_compile.2232) ERROR: Logfile of failure stored in: /home/builder/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/bundler/1.6.2-r0/temp/log.do_compile.2232 Log data follows: | DEBUG: Executing shell function do_compile | ERROR: Loading command: build (LoadError) | cannot load such file -- zlib | ERROR: While executing gem ... (NoMethodError) | undefined method `invoke_with_build_args' for nil:NilClass | WARNING: exit code 1 from a shell command. Any ideas what should be checked (I'm not familiar with ruby at all). I plan to also bump bundler to 2.0 version so can share then results and recipe. Thanks. BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ERROR: Actual rootfs size is larger than allowed
Dear all, I am new at Yocto Project and I have a simple question. I have cloned poky (rocko branch), sourced the environment and bitbaked the core-minimal-image-dev without problems. I can write the image in a SD Card and I am able to boot the system. However, when I add IMAGE_INSTALL_append to local.conf with some packages recipes (IMAGE_INSTALL_append = “nodejs” for example), I get the following error: * ERROR: Function failed: do_image_wic * ERROR: Actual rootfs size (284260 KB) is larger than allowed size 262144 KB. My question is: where could I find that 262144 KB default size value? I would like to change it and make it bigger. I have tried to add IMAGE_ROOTFS_SIZE = “500” to local.conf file but it still fails. I attach the log.do_image_wic file. Thanks you in advance, MM log.do_image_wic.4351 Description: log.do_image_wic.4351 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to specify a different kernel for an image
On Fri, Jul 19, 2019 at 1:58 AM Gabriele Zampieri
wrote:
>
> Hi,
>
> you could define two machines, where the manufacturing one is just an overlay
> of the production one. If the two kernels differs only for their config, you
> can specify different defconfig based on machine. If you need a completely
> different kernel, just specify PREFERRED_PROVIDER_virtual/kernel in
> manufacturing overlay
Hi Gabriele,
I wondered about that, but I get confused about the MACHINE concept in
Yocto/OE/bitbake...
1. If I define a new machine, but I have a lot of recipes conditioned
on the old machine, how do I say "This is the same as machine A, but
with these differences"? I have defined a machine now ("mymachine")
and have recipes and .bbappend files with things like this in them:
SRC_URI_mymachine += "file:/blah/blah/blah"
do_install_append_mymachine() {
do_stuff()
}
Do I have to replicate (and maintain) all of the references to
mymachine to also refer to my newly defined "installationmachine"? Or
can I tell Bitbake that "installationmachine" is the same as
"mymachine", and just add/change new stuff for "installationmachine"?
I hope my confusion here makes sense, but since it's confusion, it's
tough to tell :-)
2. My new image going to be used as an installation image for my
production image. So I need to include the production image (for
MACHINE="mymachine")) deploy products in the image for my installation
image. How can I do that if I define a new MACHINE for the production
image?
Thank you so much for the suggestion... it confirms that I am looking
in the right places and thinking about the right things... I just
don't know how to solve this problem.
I'm also surprised that it's not a more general problem... which leads
me to believe that I must be thinking about this the wrong way.
Thanks again.
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Setting home directory ownership
I am unable to set the home directory ownership. I am using poky@warrior
and my last attempt was the following recipe:
"""
inherit useradd
USERADD_PACKAGES = "${PN}"
USERADD_PARAM_${PN} = "-P someusername -u 1000 -d /home/someusername -r -s
/bin/bash foosomeusername"
LICENSE = "CLOSED"
do_install () {
install -d ${D}/home/someusername
# If I don't use the UID I get an error message saying "invalid user:
hubshuffle", although it seems to work for some usernames e.g. "user1" like
in the skeleton recipe for useradd.
chown -R 1000 ${D}/home/foosomeusername
}
pkg_postinst_${PN} () {
chown -R 1000 $D/home/someusername
}
FILES_${PN} = " \
/home/someusername \
"
"""
I don't know what I am doing wrong, any hint is very welcome thanks.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting home directory ownership
Sorry. I was using NFS boot and was copying over the rootfs with "cp -r"
instead of "cp -a", the permissions are fine. The only issue that remains
is that I have to use "chmod -R 1000" i.e. the UID instead of the username
otherwise I get the following error:
"""
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing shell function do_install
| install: invalid user ‘someusername’
"""
On Fri, 19 Jul 2019 at 14:17, Sergio Torres Soldado <
torres.sold...@gmail.com> wrote:
> I am unable to set the home directory ownership. I am using poky@warrior
> and my last attempt was the following recipe:
>
> """
> inherit useradd
> USERADD_PACKAGES = "${PN}"
>
> USERADD_PARAM_${PN} = "-P someusername -u 1000 -d /home/someusername -r -s
> /bin/bash foosomeusername"
>
> LICENSE = "CLOSED"
>
> do_install () {
> install -d ${D}/home/someusername
> # If I don't use the UID I get an error message saying "invalid user:
> hubshuffle", although it seems to work for some usernames e.g. "user1" like
> in the skeleton recipe for useradd.
> chown -R 1000 ${D}/home/foosomeusername
> }
>
> pkg_postinst_${PN} () {
> chown -R 1000 $D/home/someusername
> }
>
> FILES_${PN} = " \
> /home/someusername \
> "
> """
>
> I don't know what I am doing wrong, any hint is very welcome thanks.
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to specify a different kernel for an image
Hi Patrick,
Do I have to replicate (and maintain) all of the references to
> mymachine to also refer to my newly defined "installationmachine"? Or
> can I tell Bitbake that "installationmachine" is the same as
> "mymachine", and just add/change new stuff for "installationmachine"?
>
I would approach in this way: in my meta-something/conf/machine:
- machine_base.inc where I put all the standard machine configuration for
production
- mymachine.conf
require conf/machine/machine_base.inc
- myinstallationmachine.conf
require conf/machine/machine_base.inc
PREFERRED_PROVIDER_virtual/kernel = "some-linux-provider"
Then in something.bbappend:
- If the property is common to both machines:
SRC_URI_append = " file://modifications.patch"
- if the property is machine specific:
SRC_URI_append_ = " file://machinespec.patch"
In this way you have to maintain only the differences between your
machines, without redundancy.
2. My new image going to be used as an installation image for my
> production image. So I need to include the production image (for
> MACHINE="mymachine")) deploy products in the image for my installation
> image. How can I do that if I define a new MACHINE for the production
> image?
>
This is not clear to me. With 'installation image' do you mean a full image
(bootloader, kernel, rootfs etc)?
Can you give me some more details about this use case?
Best regards,
Gabriele
Il giorno ven 19 lug 2019 alle ore 14:49 Patrick Doyle
ha scritto:
> On Fri, Jul 19, 2019 at 1:58 AM Gabriele Zampieri
> wrote:
> >
> > Hi,
> >
> > you could define two machines, where the manufacturing one is just an
> overlay of the production one. If the two kernels differs only for their
> config, you can specify different defconfig based on machine. If you need a
> completely different kernel, just specify
> PREFERRED_PROVIDER_virtual/kernel in manufacturing overlay
>
> Hi Gabriele,
> I wondered about that, but I get confused about the MACHINE concept in
> Yocto/OE/bitbake...
>
> 1. If I define a new machine, but I have a lot of recipes conditioned
> on the old machine, how do I say "This is the same as machine A, but
> with these differences"? I have defined a machine now ("mymachine")
> and have recipes and .bbappend files with things like this in them:
>
> SRC_URI_mymachine += "file:/blah/blah/blah"
> do_install_append_mymachine() {
> do_stuff()
> }
>
> Do I have to replicate (and maintain) all of the references to
> mymachine to also refer to my newly defined "installationmachine"? Or
> can I tell Bitbake that "installationmachine" is the same as
> "mymachine", and just add/change new stuff for "installationmachine"?
>
> I hope my confusion here makes sense, but since it's confusion, it's
> tough to tell :-)
>
> 2. My new image going to be used as an installation image for my
> production image. So I need to include the production image (for
> MACHINE="mymachine")) deploy products in the image for my installation
> image. How can I do that if I define a new MACHINE for the production
> image?
>
> Thank you so much for the suggestion... it confirms that I am looking
> in the right places and thinking about the right things... I just
> don't know how to solve this problem.
>
> I'm also surprised that it's not a more general problem... which leads
> me to believe that I must be thinking about this the wrong way.
>
> Thanks again.
>
> --wpd
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: Actual rootfs size is larger than allowed
On 7/19/19 4:27 AM, María del Mar Velasco AERTEC Solutions – Aerospace & Aviation wrote: Dear all, I am new at Yocto Project and I have a simple question. I have cloned poky (rocko branch), sourced the environment and bitbaked the core-minimal-image-dev without problems. I can write the image in a SD Card and I am able to boot the system. However, when I add IMAGE_INSTALL_append to local.conf with some packages recipes (IMAGE_INSTALL_append = “nodejs” for example), I get the following error: * ERROR: Function failed: do_image_wic * ERROR: Actual rootfs size (284260 KB) is larger than allowed size 262144 KB. My question is: where could I find that 262144 KB default size value? I would like to change it and make it bigger. I have tried to add IMAGE_ROOTFS_SIZE = “500” to local.conf file but it still fails. you might want to check the kickstart ( .wks ) file and adjust the --fixed-size values for partition sizes I attach the log.do_image_wic file. Thanks you in advance, MM -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image not staring after upgrade from sumo to thud
Hi Pierluigi, is not clear what guide did you read and what is your issue. Distinti Saluti / Best Regards -- Marco Cavallini | KOAN sas | Bergamo - Italia embedded software engineering http://KoanSoftware.com Il giorno gio 11 lug 2019 alle ore 10:51 Pierluigi Greto ha scritto: > > Hi all, > > I have several platforms and I have upgrade Yocto from sumo to thud. > Most of them works fine after the upgrade, but some of them are not > starting. Basically after I install the image and I have chose my OS in > grub, the system reboot. But if I create the image using sumo, the image > is working fine. > My system is a x86 arch. I have read the guide for migrating from sumo > to thud and I was using COMPATIBLE_MACHINE for kernel multiconfig. I > have fix this because it's known issue. But other than that, I don't > know why it's not working (also because most of the other platforms are > working as with sumo). > Any suggestions? > Thank you. > > Best, > Pierluigi > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to specify a different kernel for an image
On Fri, Jul 19, 2019 at 10:03 AM Gabriele Zampieri wrote: >> 2. My new image going to be used as an installation image for my >> production image. So I need to include the production image (for >> MACHINE="mymachine")) deploy products in the image for my installation >> image. How can I do that if I define a new MACHINE for the production >> image? > > > This is not clear to me. With 'installation image' do you mean a full image > (bootloader, kernel, rootfs etc)? > Can you give me some more details about this use case? > Hi Gabriele, Thank you again so much for your help! My use case is as follows: I need to create an image that will go on a USB stick that we use when we manufacture our boards. That image will be used to flash the production image that we ship. The manufacturing image will have a different kernel configuration, possibly a different device tree, and certainly a different rootfs than our production image. I would like to: $ bitbake manufacturing-image and have the build system set up so that it builds production-image and includes production-image-ubi.img as a file in the rootfs for my manufacturing-image. It seems to me that production-image-ubi.img must be built with MACHINE=mymachine manufacturing-image would have to be built with MACHINE=my-manufacturing-machine ...and that's where I get confused/concerned about using a different MACHINE for my manufacturing image vs my production image. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [psplash][PATCH 1/3] add recovered bar.png
Ping.
We still carry patches locally I'd rather prefer to drop.
--
Stefan
On 2019-02-25 16:16, Stefan Agner wrote:
> From: Stefan Agner
>
> While the source files for the main splash image is present in
> the source folder base-image, the progress bar isn't. This
> patch adds the bar.png recovered from the RLE data in the bar
> header file. The tool make-image-header.sh allows to translate
> this png back the the header exactly.
>
> Signed-off-by: Stefan Agner
> ---
> base-images/bar.png | Bin 0 -> 1849 bytes
> 1 file changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 base-images/bar.png
>
> diff --git a/base-images/bar.png b/base-images/bar.png
> new file mode 100644
> index
> ..e2c1f1781cdcfa68c8a664a8b3072344d3aeaf1b
> GIT binary patch
> literal 1849
> zcmV-92gdk`P)
> zaB^>EX>4U6ba`-PAZ2)IW&i+q+O3ysmg6W4h5xgPSpt#}g5~f$r*|;Rp9^-9&coGR
> zb;drGU@Q>2pHL__{{1!GKe#C8 zF2T1Pk8zy#1^xOMVBzeq&;8EMi8!4ToiA<^%JR%;oObD)NciZd^V#KdTnWF0bN z`?c2N)$4OGh|v}E2|FG_;_;c57r_c7OOe$sXs2bg+g{S{$)B}z_vVXuG(T(S%V{Cc
> zQaFF35MMMp`$<1*w-tJ#c5CwUi)wcl@7m3t<{U?KB}6C{-5HcWr`RnRLe3z2Sj4?1
> zRkUs28Fxa64a7QVR@}`|CWhLR0(B}hY3%Pt4ND9>*znEVSax3$ z1xo`pK{wymLfdcN{u(8C?gUFFOh%jI%k4gO{^Y(-H0MfPq9rEK(*c-QPGcF1-1>x7
> zxTnV2B6Pdm9qZ#-U zNZy!@2s$S4DOfp6;0gky%AMQ<8<7Y&*bVTFF-F^#m5*+e7JyKRVnBlp1Xv*`^2b6#
> z4iyy*PF16tCe2!+#1J*cXmQo3Vq(G6qM0SjR+6NUG{s~orJPFUEGS``V>Xvl&bbsg
> zEttAsbb&=Fm8;ZHwZ>{S)m%$M`n1rr#bzzF+)C#z9oxUhZmy@Edl@v4N+S#%ao9*B
> zk1~;KQ)ZYt zFJ?Yb2)xKGW zQ0ry?qR0lccHz?0%S2)8DM#%=TFhm%94ECArAFm|P;4Odsm)B(P!>r`Z#FwhBQ`oX
> z&S0~};_7SyN7>i?-tZ7wNpbW7f^970m(k}~RNJHo8YLkRyHw|x9S?*VV3$pV@-TS!
> zrN<$2Bv!&Kv!E?&4u)))ruZCmIf4??&D0J1lL99A&I(=^;L^YW!g5~|++3|6ukCEP
> z!c$rUKCVwkf+4lmoS#y+@#$=pqlde7h>-btg|)-52#z!aCEPOplNj$Sd{G0Q+((${
> z>osms9-3@_?p6JH2;%=B$)U&vez{DyXE{C!@2)fBdx_z$Gvj-S;r=AU-zJ8;&W!IR
> zhP%#;&%3kMrf4d;hS_nB$-_}-D0^X`j*mXNjy!dQK8~ zJZ@D3Rc=)cca)7OzN>|?$`Wg7qBxXQUUn$S9EK(7DU~G=ML(*I9Q(nyExz7$R4x3X
> zl%k|#l`b5JOc6+pOS^dA_c+r+BdtrSx}~aFQ^V-OwH0?{$8S!yiyPPvlManfe*IzO
> z4yz?*{B4)LyEm?0x`OKD`eB8)%x=`<#4o~5le{+!7EYr8u4O%v^3~{;ODi7t7Emil
> z#WV1EAuT;Zx<%x!LjP;Y&zRjU=nG}$ML^GS!^pjBa}~~W%&)B7&tSi^c0Yst9<}=!
> z?044gXRu!*x9oVPkrGZ0inB^*NQeU(%`tGWsTcmWPv7y+`9K}CS~8Ac-Kocz5n3jc
> z6K#1+lz`4PmIfJcjKRO2?my>cBAz3|;LZR5010qNS#tmYE+YT{E+YYWr9XB6000Mc
> zNliru;{p;D2os84rL_P60n$lCK~#9!?cG638$lSx@n?7TQoMw<*=PwKJ>*!Sq)`y_
> zEriljK=1OAfhJLN%MX zGu~wKeXgI9WTIa0tFEqoC{3rD&!4sc{9~TyDGUqR*m$FA^{t}l^{>6hVxFJJIz9cO
> zEXzm?$eHi^+S_}tot<}!wIp@B7izUSloEI$S(d5Q>ZsejSQIl&r)sx5Bm*pgcDtiA
> zohpdqOId53&9$|n4h}w$67bB9k3Z|?X8g3a)+&xK ztIljVyp}&2jh$hovMFN>i2*q<#;8)+bY`Q`SpID0zQ(Ssydo_iN4vXKXFZ$Q#jmme
> zmJ7uMC?)`k2~bP`6ceDB04OFvF#%9a02C9Tm;fjy@ZT0Q2;9GT-QC@j3Xr3-v!1gK
> z0wcdvDmue{fAGhN1^}LiwO0N9z?qdwMfv6Ox-(3YTQ!>}BnIT5**sB_+&Z&zd0pOM
> z@NIr{^oge=ump@TIz0R+KMV`1*SARoSOWF>w!*NWK$2>;EoGVIz-QovJRbO5t8Gd8
> n?IiZa_e-uw0P^y;D-s?6yTzgg!=Gv;0NkvXXu0mjfd-8h+
>
> literal 0
> HcmV?d1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
