Re: [yocto] Make one directory writeable

[Ulf Samuelsson]

You can use overlayfs for this. You mount the overlayfs on top of your rootfs 
and then it appear like you have a writeable file system.
In reality all the new  stuff is written to another (writeable) file system.
If you dismount the overlayfs, the rootfs reverts back to its original state.
If you again  mount the overlayfs, you get your modifications back.

Best Regards,
Ulf Samuelsson
+46 722 427 437

> 13 feb. 2019 kl. 08:21 skrev Bhupendra Singh 
> :
> 
> Hello
> I have built core-image-minimal  with read only rootfs  then now  I want to 
> make one directory (like /mnt) writable.
> Is it possible to make one directory writeable in read only rootfs if yes 
> ,please tell me how can I do same.   
>  
> Bhupendra Singh
>  
> -- 
> ___
> 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] Make one directory writeable

[Josef Holzmayr]

Hi Bhupendra,

On Wed, Feb 13, 2019 at 12:51:17PM +0530, Bhupendra Singh wrote:
> Hello 
> 
> I have built core-image-minimal  with read only rootfs  then now  I want to
> make one directory (like /mnt) writable. 
> 
> Is it possible to make one directory writeable in read only rootfs if yes
> ,please tell me how can I do same.   

This is not exactly yocto specific, general linux concepts apply. You
can use a secondary, tertiary, ... partition or starage device and then
mount that as read-write. But it always has to be a seperate filesystem.
There is no way to make only one path of a given filesystem RW, it
always means that the whole filesystem is writeable.

Greetz
-- 
———
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Toolchain , kernel-dev and xenomai

[Johann Obermayr]

Hello,

At this time we work with 1.3.2 (yes, it's very old, but we are working to 
change to v2.5.x)

We have some trouble with your toolchain.

  1.  Kernel/scripts/basic/fixdep   is missing.

If I will compile in the toolchain kernel source directory "make scripts" I get 
some other errors (see b) )


   b) Xenomai integrates its files as linked. And this links are installed 
with the toolchain. So the files are not really available.


Thanks & Regards
  Johann

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEVTOOL doesn't upgrade glibc as expected

[Randy MacLeod]

Adding the list back.

On 1/31/19 12:56 PM, Dhanush K.S wrote:

Hi Randy,

(back from vacation).


No. Not actually, as we upgraded to Sumo recently and would probably 
jump straight to Warrior if need be.


Warrior is still in development so keep that in mind.

Wanted to get the time_t functionality for 32 bit arch due to the 
current Y2038 bug. But it seems like GNU has postponed it to future release.


As you can see be reading the Jan 2019 article:
   https://lwn.net/Articles/776435/
the Linux Y2038 work is ongoing. Even once it's 'finished', it's
unlikely that you won't have to upgrade your deployed systems to
fix one or two defects so I'm confused about why you seem need/want
this right now rather than in months or a year or more.



Yeah! Would agree with having a combo that no one probably would be 
having. But what I don't get is why the incompatibility with of v2.28 
with Yocto 2.5? Is it inherent with all  yocto releases or something to 
do just with sumo?


I don't work on the glibc upgrades so I'm not sure.
There's nothing unique going on in Yocto but rather
changing glibc versions is often lots of work that requires
both broad and deep OS knowledge.

../Randy



Look forward to your views on this.
Thanks!


On Wed, 30 Jan 2019 at 21:10, Randy MacLeod > wrote:


On 1/30/19 8:42 AM, Burton, Ross wrote:
 > No doubt devtool should handle this better, but upgrading glibc is
 > *not easy*.  If you can't do it manually then I wouldn't recommend
 > doing it at all.
 >
 > A better start would be to copy the recipes from git for the version
 > you want, and then you'll be able to pick up all of the patches to
 > other recipes that you'll also need.

Have you seriously considered upgrading to Thud/2.6.x?

What feature(s) do you want that makes you feel that an
upgrade it to v2.28 is worth the effort? If you put the
work in to do the update, you'll have a YP-based combo that
no one else is using. While that may get you exactly what you want,
there will be costs involved in maintaining it so I'm curious
about your motivation and thoughts about maintenance.

../Randy

 >
 > Ross
 >
 > On Wed, 30 Jan 2019 at 13:35, Dhanush K.S mailto:dhanush...@gmail.com>> wrote:
 >>
 >> Hi,
 >>
 >> I'm currently using Yocto Sumo 2.5 release with the glibc
version 2.27 and would like to upgrade it to v2.28.
 >> Using the devtool upgrade glibc -V 2.28 -S
044c96f0d5595aeb0bb4e79355081c5a7f4faca5 doesn't work as expected.
 >> In turn it creates the workspace/recipes/glibc_2.28.bb
 recipe with the contents and SRC_URI of v2.27.
 >>
 >> devtool upgrade glibc -S 044c96f0d5595aeb0bb4e79355081c5a7f4faca5
 >> NOTE: Starting bitbake server...
 >> NOTE: Creating workspace layer in
/source/yocto/build_arm-cortex-a8/workspace
 >>
 >> NOTE: Extracting current version source...
 >> NOTE: Resolving any missing task queue dependencies
 >>
 >> Build Configuration:
 >> BB_VERSION           = "1.37.0"
 >> BUILD_SYS            = "x86_64-linux"
 >> NATIVELSBSTRING      = "universal-4.8"
 >> TARGET_SYS           = "arm-poky-linux-gnueabi"
 >> MACHINE              = "arm-cortex-a8"
 >> DISTRO               = "poky"
 >> DISTRO_VERSION       = "2.5"
 >> TUNE_FEATURES        = "arm armv7a vfp neon callconvention-hard
cortexa8"
 >> TARGET_FPU           = "hard"
 >> meta
 >> meta-poky
 >> meta-yocto-bsp
 >> meta-oe              =
"master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
 >> workspace            = ":"
 >>
 >> NOTE: Executing RunQueue Tasks
 >> NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to
be rerun and all succeeded.
 >> NOTE: Writing buildhistory
 >> NOTE: Adding local source files to srctree...
 >> NOTE: Extracting upgraded version source...
 >> WARNING: Command 'git rebase
044c96f0d5595aeb0bb4e79355081c5a7f4faca5' failed:
 >> First, rewinding head to replay your work on top of it...
 >> Applying: sparc: Check PIC instead of SHARED in start.S [BZ #22638]
 >> error: Failed to merge in the changes.
 >> Using index info to reconstruct a base tree...
 >> M ChangeLog
 >> M sysdeps/sparc/sparc32/start.S
 >> M sysdeps/sparc/sparc64/start.S
 >> Falling back to patching base and 3-way merge...
 >> Auto-merging ChangeLog
 >> CONFLICT (content): Merge conflict in ChangeLog
 >> Patch failed at 0001 sparc: Check PIC instead of SHARED in
start.S [BZ #22638]
 >> The copy of the patch that failed is found in:
.git/rebase-apply/patch
 >>
 >> Resolve all conflicts manually, mark them as resolved with
 >> "git add/rm ", then run "git rebase --continue".
 >> You can instead skip this commit: run "git rebase --skip".
 >> To abort and get back to the state before

Re: [yocto] Using SDK/ESDK to build images

[Randy MacLeod]

On 2/12/19 6:55 AM, Kristupas Savickas wrote:

Hi,

we're looking into providing our customers with SDK/ESDK packages to 
develop custom solutions on our boards. We don't want to provide the 
whole project itself as it would leak our intellectual property, so 
precompiled packages are a must. Looking around, it seems like both SDK 
and ESDK are suited to build single packages, rather than complete 
images. Am I correct about this? 

Yes.
Is there some kind of method to allow 
images be built using SDK packages?


No, or none that I'm aware of at least.

My assumption has been that you either:
 1. enable package management in the image and
then add the app developed with the eSDK
using dnf/rpm or other pkgs mgmt tools or
 2. you develop the app using the eSDK then bring
it into the build system as a released/tagged entity (tarball/git)
and build your image.

I suppose you could create another mechanism where you apply
the app on top of the image or in another partition.
Maybe someone here has done that or has more experience with
your situation.

Oh, an obvious mechanism would be as an app container using for
example OverC:
   https://github.com/OverC/meta-overc

https://github.com/OverC/meta-overc/blob/master/docs/README.c3_app_container
--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Managing multiple builds

[Timothy Froehlich]

Hi, I've been struggling a bit with this question. I want to use Yocto to
build two+ products with separate dev/prod images for each (dev including
debug-tweaks, etc.). I've ruled out separate image recipes because my dev
builds need ENABLE_UART on my RaspberryPi and that needs to be set at the
conf level (I've got it set conditionally in my base dist conf).
Multiconfig looked promising, but I'm not happy about how long the parsing
takes to start a build. "--postread" looked nice, but I've barely seen it
mentioned so I'm worried that it's not well supported.

Basically, what do most people do for controlling their builds?
Tim Froehlich
Embedded Linux Engineer
tfroehl...@archsys.io
215-218-8955
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Make one directory writeable

[Mike Looijmans]

As for the particular case of /mnt, on most images, /mnt is a symlink to 
/media, and /media is (on) a filesystem in RAM, so it's already writeable.

If the write does not need to persist across reboots, use a tmpfs mount.

If your real problem is that you cannot create anything in /mnt (or /media for 
modern users), the issue is that someone broke something in your image, 
because that should work out of the box.


On 13-02-19 09:27, Josef Holzmayr wrote:
> Hi Bhupendra,
> 
> On Wed, Feb 13, 2019 at 12:51:17PM +0530, Bhupendra Singh wrote:
>> Hello
>>
>> I have built core-image-minimal  with read only rootfs  then now  I want to
>> make one directory (like /mnt) writable.
>>
>> Is it possible to make one directory writeable in read only rootfs if yes
>> ,please tell me how can I do same.
> 
> This is not exactly yocto specific, general linux concepts apply. You
> can use a secondary, tertiary, ... partition or starage device and then
> mount that as read-write. But it always has to be a seperate filesystem.
> There is no way to make only one path of a given filesystem RW, it
> always means that the whole filesystem is writeable.
> 
> Greetz
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto