Re: [yocto] [meta-security][PATCH 2/2] sssd: fix libcrypto version used

[akuster808]

On 3/26/19 3:24 AM, Adrian Bunk wrote:
> On Mon, Mar 25, 2019 at 09:58:55AM -0700, Armin Kuster wrote:
>> Signed-off-by: Armin Kuster 
>> ---
>>  recipes-security/sssd/sssd_1.16.3.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/recipes-security/sssd/sssd_1.16.3.bb 
>> b/recipes-security/sssd/sssd_1.16.3.bb
>> index 8f7f805..d39fa23 100644
>> --- a/recipes-security/sssd/sssd_1.16.3.bb
>> +++ b/recipes-security/sssd/sssd_1.16.3.bb
>> @@ -33,7 +33,7 @@ PACKAGECONFIG[manpages] = "--with-manpages, 
>> --with-manpages=no"
>>  PACKAGECONFIG[python2] = "--with-python2-bindings, 
>> --without-python2-bindings"
>>  PACKAGECONFIG[python3] = "--with-python3-bindings, 
>> --without-python3-bindings"
>>  PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss,"
>> -PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto"
>> +PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto10"
>> ...
> This looks wrong for multiple reasons, and it still gave the same error 
> when I tried it.
That is troubling. I don't see any errors here. Thanks for the feed
back. I will have to dig at this a bit more.

Can you provide some build detail so that I can reproduce it?

>
> How has this change been tested?
Not for this change.

Which reminds me I should automate some testing for this package.

regards,
Armin
>
> cu
> Adrian
>


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

[yocto] Read-only filesystems: Move directory to RW directory and symlink back

[Timothy Froehlich]

Is there a recommended way of doing this? Right now I have a
ROOTFS_POSTPROCESS_CMD that moves the directories and symlinks them back,
but I'm not sure if I'm doing it exactly right or if there's something
built-in.

The function just does a bunch of this:
install -d ${D}/${persist_dir}

mv ${D}/${ORIG} ${D}/${persist_dir}/${LINKNAME}
ln -sr ${D}/${persist_dir}/${LINKNAME} ${D}/${ORIG}

-- 
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] [rauc] create a rescue image

[Mike Looijmans]

On 26-03-19 12:31, jairo wrote:
> 
> Thank you very much Mike.
> 
> 
> 
>> With NAND you'll probably have a filesystem (jffs2 or UBI) in place.
>> With that, you could just use a package manager like opkg to update
>> sofware. If the box has a network connection, just running "opkg
>> update && opkg upgrade" will install the current releases with the
>> minimum effort. We've been using this on a million boxes and it works
>> fine (until someone decides to patch libc and you get a 300+ package
>> upgrade).
> 
> 
> Is there a public repository with ipk packages, or do I have to create
> my own repository?

OpenEmbedded already created it, it's usually in build/tmp-glibc/deploy/ipk

To turn it into a "feed" just share this directory through http. On my 
development setup, I installed apache and created a symlink to that directory. 
You'll also need to add "distro-feed-configs" to your image (and maybe append 
it a bit to match your system).

> Can opkg solve dependencies well? Can it create problems?

Haven't seen any problems with it, and it installs dependencies along with 
packages.

>> Linux is also capable of upgrading a running system. Basically, copy
>> some
>> executables to a tmp filesystem, remount everything read-only, and
>> change root
>> to the tmp part. Then you can rewrite partitions and reboot.
>>
>> In any case, you should have a u-boot configuration that allows it to
>> be
>> debricked. Typically a USB stick or DFU will do nicely if your board
>> has USB.
>> Or even serial...
> 
> I'm using Barebox, I think there would be no problems out there, the
> bad part of using opkg is that the product should be used by clients
> without much knowledge of linux. In that part I think it would be
> easier for customers to use a update system such as Rauc or any similar

The system that's using ipkg is a TV settop box, and the average user has 
about the intellectual capabilities of a potato.

To actually upgrade, the user selects "settings" and "update software" from 
the main menu using the remote control, and doesn't even have to leave the 
couch.

(To recover a bricked box, or install from scratch, the procedure is much more 
complicated: Download a zip file, unpack on a USB stick, put it into the 
settop and switch it on. That'd require intellect slightly above your average 
vegetable but is still doable apparently.)

Being user-friendly is about providing a proper wrapper, it's not about 
technology.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW13'19

[sjolley.yp.pm]

Current Dev Position: YP 2.7 M4 (New feature Freeze has begun.)

Next Deadline: YP 2.7 M3 Release Target was Mar. 8, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Paul 
*   SWAT team rotation: Paul -> Ross on Mar. 30, 2019
*   SWAT team rotation: Ross -> Amanda on Apr. 5, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Key Status/Updates:

*   M3 has been built and is currently in QA
*   There are a small number of upgrades which merged after M3 as it was
felt better to be up to date in these cases along with various other fixes.
The project is now very much in feature freeze and bug fixing working toward
the final release though.
*   The OpenEmbedded election for its TSC members is now in the
nomination phase.
*   For the stable releases, the autobuilder-helper changes have now
merged and the resulttool patches are also backported on the relevant -next
branches. This means we're ready to build both 2.5.3 and 2.6.2.

 

Planned Releases for YP 2.7:

*   YP 2.7 M3 Cutoff was Feb. 25, 2019
*   YP 2.7 M3 Release Target was Mar. 8, 2019
*   YP 2.7 M4 Cutoff is Apr. 1, 2019
*   YP 2.7 M4 Release Target is Apr. 26, 2019

 

Planned upcoming dot releases:

*   YP 2.5.3 (Sumo) will be targeted for build as soon as it is ready..
*   YP 2.6.2 (Thud) will be targeted after YP 2.5.3 is done.

 

Tracking Metrics:

*   WDD 2418 (last week 2432) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1538 (last week 1526)
*   Patches in the Pending State: 656 (43%) [last week 656 (43%)]

 

Key Status Links for YP:

 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status

 
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule

 
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

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

Re: [yocto] [rauc] create a rescue image

[jairo]

Thank you very much Mike.



> With NAND you'll probably have a filesystem (jffs2 or UBI) in place.
> With that, you could just use a package manager like opkg to update
> sofware. If the box has a network connection, just running "opkg
> update && opkg upgrade" will install the current releases with the
> minimum effort. We've been using this on a million boxes and it works
> fine (until someone decides to patch libc and you get a 300+ package
> upgrade).


Is there a public repository with ipk packages, or do I have to create
my own repository?
Can opkg solve dependencies well? Can it create problems?


> Linux is also capable of upgrading a running system. Basically, copy
> some 
> executables to a tmp filesystem, remount everything read-only, and
> change root 
> to the tmp part. Then you can rewrite partitions and reboot.
> 
> In any case, you should have a u-boot configuration that allows it to
> be 
> debricked. Typically a USB stick or DFU will do nicely if your board
> has USB. 
> Or even serial...

I'm using Barebox, I think there would be no problems out there, the
bad part of using opkg is that the product should be used by clients
without much knowledge of linux. In that part I think it would be
easier for customers to use a update system such as Rauc or any similar
...

A greeting!


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

[yocto] [meta-anaconda][PATCH 1/1] packagegroup-anaconda-support: Add lvm2-udevrules

[Ovidiu Panait]

Installing an image without lvm2-udevrules using Anaconda would
produce an un-bootable system because "/dev/mapper/xxx" files are
not created.

Signed-off-by: Ovidiu Panait 
---
 .../packagegroups/packagegroup-anaconda-support.bb   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/recipes-installersupport/packagegroups/packagegroup-anaconda-support.bb 
b/recipes-installersupport/packagegroups/packagegroup-anaconda-support.bb
index 3f3f41e..21d69b6 100644
--- a/recipes-installersupport/packagegroups/packagegroup-anaconda-support.bb
+++ b/recipes-installersupport/packagegroups/packagegroup-anaconda-support.bb
@@ -12,6 +12,7 @@ RDEPENDS_${PN} = " \
 efibootmgr \
 kmod \
 lvm2 \
+lvm2-udevrules \
 util-linux-mount \
 util-linux-switch-root \
 init-ifupdown \
-- 
2.20.1

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

Re: [yocto] [meta-security][PATCH 2/2] sssd: fix libcrypto version used

[Adrian Bunk]

On Mon, Mar 25, 2019 at 09:58:55AM -0700, Armin Kuster wrote:
> Signed-off-by: Armin Kuster 
> ---
>  recipes-security/sssd/sssd_1.16.3.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/recipes-security/sssd/sssd_1.16.3.bb 
> b/recipes-security/sssd/sssd_1.16.3.bb
> index 8f7f805..d39fa23 100644
> --- a/recipes-security/sssd/sssd_1.16.3.bb
> +++ b/recipes-security/sssd/sssd_1.16.3.bb
> @@ -33,7 +33,7 @@ PACKAGECONFIG[manpages] = "--with-manpages, 
> --with-manpages=no"
>  PACKAGECONFIG[python2] = "--with-python2-bindings, 
> --without-python2-bindings"
>  PACKAGECONFIG[python3] = "--with-python3-bindings, 
> --without-python3-bindings"
>  PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss,"
> -PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto"
> +PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto10"
>...

This looks wrong for multiple reasons, and it still gave the same error 
when I tried it.

How has this change been tested?

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] [rauc] create a rescue image

[jairo]

El mar, 26-03-2019 a las 09:14 +0100, Patrick Boettcher escribió:
> On Tue, 26 Mar 2019 09:05:47 +0100
> jairo  wrote:
> 
> > Thanks Patrick:
> > 
> > 
> > The idea is that when an update is going to be done, the system
> > will
> > restart in the rescue partition so that it updates the main
> > partition
> > and when it is updated it will restart the main partition again.
> 
> This is a good idea when you want to keep a maximum of rootfs-space
> for
> one system and can be done with RAUC, bootchooser and barebox.
> 
> However, there is a risk of when a system update (from the
> rescue-partition) installs a non-working image. Then you will stuck
> on
> your rescue system without a possibility to get back a working
> system.
> 
> This is why "usually" there is system0 and a system1 which are
> switching over after an update and the system marks itself OK if it
> is
> - otherwise it is switching back to the previous system.

Yes, I know, it is somewhat risky, but I have only 512MB of nand
memory, and we are getting a lot of software. I think we have to
evaluate the move to a hardware with more memory, at the moment is what
we have. I think it is practically impossible to put 2 systems in so
little memory.

> 
> Also check the latest phytec recipes in their distro, they integrated
> RAUC and barebox-state (in eeprom) and bootchooser. Though this is
> not
> yet releases for IMX6 - afaik.

Sure, they are going to release a new version this Friday. I'll have to
take a good look. :D

--
Jairo



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

Re: [yocto] [OE-core] Information about non-traditional uses of the Yocto Project and OpenEmbedded

[Dimitris Tassopoulos]

Hi Gus, very interesting stuff you have there.
Thanks for the heads up.
Dimitris

On Mon, Mar 25, 2019 at 4:10 PM Angus Lees  wrote:

> Oh I lie, some of my Android-SDK stuff survives:
> https://github.com/anguslees/openembedded-android/wiki
>
> Here's a relevant scummvm forum post to put it in historical context:
> https://forums.scummvm.org/viewtopic.php?p=57260=bcf54148cb83752212a19262b76551c8#p57260
> ... And my announce to the android-ndk list, that promptly resulted in the
> Android powers-that-be shutting it down with prejudice.  I believe the
> quote was "this threatens the future of Android" ;)
> https://groups.google.com/d/topic/android-ndk/Ps1RWb21zRw/discussion
>
>  - Gus
>
> On Thu, 21 Mar 2019 at 15:36, Angus Lees  wrote:
>
>> I use yocto to build an immutable disk image for several architectures of
>> Kubernetes servers (currently armv7, aarch64, x86-64).  It's basically a
>> CoreOS Container Linux clone, except smaller and more portable.  I like
>> yocto/OE's powerful cross-compilation, minimalism, read-only rootfs, A/B
>> image upgrades (I'm using rauc), etc.
>> https://gitlab.com/containos/containos
>>
>> Previously I've used yocto/openembedded to build:
>> - minimal x86-64 docker images, and pre-built package repository (
>> https://github.com/anguslees/boxfactory - no longer maintained now that
>> alpine is a thing).
>> - an early Android C/C++ sdk development environment (ie: nativesdk) -
>> before the official "Android NDK" became useful.  I added support for
>> `repo` tool, bionic, etc - I was even doing canadian-cross to build the SDK
>> on Linux/glibc, to run on win32/mingw, and compile for armv7/bionic :P
>> Unfortunately this got killed by politics and never saw the light of day,
>> but it was used to build the early releases of the "ScummVM" Android app
>> (possibly the first native app on the Android marketplace).
>>
>> Indeed, I don't think I've ever used it for an actual embedded platform :P
>>
>>  - Gus
>>
>> On Thu, 28 Feb 2019 at 07:01, Philip Balister 
>> wrote:
>>
>>> During the last OpenEmbedded developer meeting, it became clear that
>>> people are using the Yocto project/OpenEmbedded in spaces outside what
>>> we think of as traditional embedded. Lieu Ta is working on a
>>> presentation for the Linux Foundation Leadership Summit and we would
>>> like to collect as many "unusual" applications are possible from
>>> companies we can publicly acknowledge. Unusual is edge, containers,
>>> desktop, etc. Or even really interesting embedded applications :)
>>>
>>> Please drop me an email (off list is fine) with enough info for us to
>>> add you to a slide and acknowledge your work.
>>>
>>> Thanks,
>>>
>>> Philip
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> openembedded-c...@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>
>>
>> --
>>  - Gus
>>
>
>
> --
>  - Gus
> --
> ___
> 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] [rauc] create a rescue image

[Patrick Boettcher]

On Tue, 26 Mar 2019 09:05:47 +0100
jairo  wrote:

> Thanks Patrick:
> 
> 
> The idea is that when an update is going to be done, the system will
> restart in the rescue partition so that it updates the main partition
> and when it is updated it will restart the main partition again.

This is a good idea when you want to keep a maximum of rootfs-space for
one system and can be done with RAUC, bootchooser and barebox.

However, there is a risk of when a system update (from the
rescue-partition) installs a non-working image. Then you will stuck on
your rescue system without a possibility to get back a working system.

This is why "usually" there is system0 and a system1 which are
switching over after an update and the system marks itself OK if it is
- otherwise it is switching back to the previous system.

> I think the problem (among others) was having it because I was not
> applying any patch to the device-tree. It's a somewhat complicated
> issue, anyway, thank you very much for the help, I think it's a good
> clue to keep going.

Also check the latest phytec recipes in their distro, they integrated
RAUC and barebox-state (in eeprom) and bootchooser. Though this is not
yet releases for IMX6 - afaik.

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

Re: [yocto] [rauc] create a rescue image

[jairo]

Thanks Patrick:


The idea is that when an update is going to be done, the system will
restart in the rescue partition so that it updates the main partition
and when it is updated it will restart the main partition again.


I think the problem (among others) was having it because I was not
applying any patch to the device-tree. It's a somewhat complicated
issue, anyway, thank you very much for the help, I think it's a good
clue to keep going.

A greeting!


El lun, 25-03-2019 a las 17:21 +0100, Patrick Boettcher escribió:
> Hi,
> 
> On Mon, 25 Mar 2019 16:01:37 +0100
> jairo  wrote:
> 
> > Hi all,
> > 
> > I want to make a system with a rescue partition.
> > 
> > What is the minimum to make a rescue image? Or how can it be done?
> > 
> > I use a board with a imx6 micro from phytec, and in the meta-yogurt
> > layer there is a recipe called phytec-initramfs-image.bb that
> > creates
> > an image or partition with cpio.gz format of 11MB containing
> > rootfs,
> > can it be used That image as a rescue? If so, how do you copy a
> > cpio
> > partition in an UBI MTD system?
> 
> To create an initramfs rescue image (assuming that's what you would
> want to do?) You need to tell yocto that there is a initramfs to be
> built:
> 
> To your local.conf you can add
> 
>   # for initramfs-usage
>   INITRAMFS_IMAGE = "rescue-image-initramfs"
>   INITRAMFS_IMAGE_BUNDLE = "1"
> 
> and you'll to craete a corresponding .bb-file. There are example over
> the internet if you search for it. I needed the following packages:
> 
>   PACKAGE_INSTALL = "packagegroup-core-boot \
>  ppp  \
>  bash \
>  sshd \
>  rauc \
>  mtd-utils\
>   "
> 
> This gave me a initramfs of 25-30 MB and barebox wasnot able to
> jump to the kernel so I had to patch.
> 
> After that you just need to add a partition for the initramfs and its
> device-tree-blob (dtb) to the UBIFS and flash it and boot it.
> 
> You should, if you haven't already, come up with a complete strategy
> of
> how to do your updates and upgrades using RAUC or another update-
> system.
> 
> best regards,
> --
> Patrick.
> 
> 
> 


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