[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