Re: [yocto] Naming images
Thanks Quentin! That's just what I needed.
Do you know if there's a variable to control the content of /etc/version?
Cheers,
-Damien
On Mon, Mar 29, 2021 at 4:14 PM Quentin Schulz <
quentin.sch...@streamunlimited.com> wrote:
> Hi Damien,
>
> On Mon, Mar 29, 2021 at 03:33:09PM +0300, Damien LEFEVRE wrote:
> > Hi,
> >
> > In my build system the generated images are in this format:
> >
> > imagename-machine-timestamp.img
> >
> > For release builds, I'd like to replace the time stamp with the image
> > version. I could rename the image after the build but is there a better
> way?
> >
>
> IMAGE_NAME variable is the one specifying the name which should be used
> for the final image. c.f.
> https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_NAME
>
> By default, its value is
> "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
>
> IMAGE_VERSION_SUFFIX is by default set to "-${DATETIME}" as documented
> here:
> https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_VERSION_SUFFIX
>
> Therefore to put the image version, you just need to change
> IMAGE_VERSION_SUFFIX to what you want it to contain.
>
> Cheers,
> Quentin
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52964): https://lists.yoctoproject.org/g/yocto/message/52964
Mute This Topic: https://lists.yoctoproject.org/mt/81694699/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] Naming images
Hi, In my build system the generated images are in this format: imagename-machine-timestamp.img For release builds, I'd like to replace the time stamp with the image version. I could rename the image after the build but is there a better way? I found a BUILDNAME variable but it has no effect. Also should the timestamp written in /etc/version match the one from the image name? For some reason for me it doesn't. /etc/version is 20180309123456 while the one from the image name is 20210329064542. -Damien -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52952): https://lists.yoctoproject.org/g/yocto/message/52952 Mute This Topic: https://lists.yoctoproject.org/mt/81694699/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] cpio issues
Hi, I am working with Tegra Xavier and meta-tegra. During the build process, 2 images get generated: - initramfs (cpio archive) - the actual roofs image initramfs is archived with cpio and since the cpio image type is enabled, bitbake tries to cpio the rootfs. The roofts is more than 2GB (not difficult with CUDA libraries) and cpio fails due to some 2GB size limitation. How can I keep the initramfs with cpio, but disable cpio archiving for the rootfs which I don't need or use for anything? Thanks, -Damien -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52013): https://lists.yoctoproject.org/g/yocto/message/52013 Mute This Topic: https://lists.yoctoproject.org/mt/79702974/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Disable systemd-timesyncd.service in image
Yes SYSTEMD_AUTO_ENABLE_${PN} doesn't apply to systemd recipe core services
as they are not installed as separate packages.
But I got it working now.
The default enable/disable service are defined in
https://github.com/systemd/systemd/blob/master/presets/90-systemd.preset
So
do_configure_append() {
sed -i -e "s/enable systemd-timesyncd.service/disable
systemd-timesyncd.service/g" ${S}/presets/90-systemd.preset
}
does the trick
Cheers,
-Damien
On Mon, Nov 23, 2020 at 10:42 PM Konrad Weihmann
wrote:
> The service is deployed with standard systemd package, which doesn't
> have that set as far as I see it (no SYSTEMD_AUTO_ENABLE_${PN} in the
> latest recipe revision)
>
> I think, after browsing through the code of systemd - this "autostart"
> behavior comes from [1].
> So I would say you can disable it with a drop-in file at
> /etc/systemd/system/systemd-timesyncd.service.d/disable.conf
> [Install]
> WantedBy=
>
> which also would be charming in a way that it isn't that invasive in the
> build system
>
> [1]
>
> https://github.com/systemd/systemd/blob/5b639090d0b4a49d77ba58bebe180b2a6f8da322/units/systemd-timesyncd.service.in#L55
>
> haven't tested it though, but you might wanna give that a shot, if
> Aaron's approach doesn't work.
>
> On 23.11.20 21:21, Joel A Cohen wrote:
> > I think you need to set SYSTEMD_AUTO_ENABLE = “disable” (actually any
> > value other than “enable”) in your bbappend.
> >
> > (It looks like SYSTEMD_AUTO_ENABLE_${PN} is intended to work too, but I
> > can’t verify it at the moment and reading over systemd.bbclass I’m not
> > sure if it works or not)
> >
> > —Aaron
> >
> > On Mon, Nov 23, 2020 at 11:51 AM Damien LEFEVRE > <mailto:lefevre...@gmail.com>> wrote:
> >
> > Hi,
> >
> > I would like to have systemd-timesyncd.service as part of an image
> > but have it disabled by default.
> >
> > Right now it is enabled by default which causes some issues.
> >
> > I've tried systemd_%.bbappend
> >
> > do_install_append() {
> > rm
> "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
> > rm
> >
> "$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
> > }
> >
> > but those symlinks are not part of the package.
> >
> > I've tried this to remove the link during the package deployment
> > during do_rootfs
> > pkg_postinst_${PN}_append() {
> > #!/bin/sh -e
> > rm
> "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
> > rm
> >
> "$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
> > }
> >
> > But at this stage the links still don't exist.
> >
> > Which package is actually responsible for enabling the default
> > services / creating the symlinks? How can we turn some of them off
> > while keeping them in the image?
> >
> > Thanks,
> > -Damien
> >
> >
> >
> >
> >
> >
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51539): https://lists.yoctoproject.org/g/yocto/message/51539
Mute This Topic: https://lists.yoctoproject.org/mt/78461756/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] Disable systemd-timesyncd.service in image
Hi,
I would like to have systemd-timesyncd.service as part of an image but have
it disabled by default.
Right now it is enabled by default which causes some issues.
I've tried systemd_%.bbappend
do_install_append() {
rm "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
rm
"$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
}
but those symlinks are not part of the package.
I've tried this to remove the link during the package deployment during
do_rootfs
pkg_postinst_${PN}_append() {
#!/bin/sh -e
rm "$D/etc/systemd/system/dbus-org.freedesktop.timesync1.service"
rm
"$D/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service"
}
But at this stage the links still don't exist.
Which package is actually responsible for enabling the default services /
creating the symlinks? How can we turn some of them off while keeping them
in the image?
Thanks,
-Damien
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51532): https://lists.yoctoproject.org/g/yocto/message/51532
Mute This Topic: https://lists.yoctoproject.org/mt/78461756/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] How to generate opensource licenses credits web page
Hi, I have a distro which is not using any package manager in the image. Images are deployed atomically. I'd like to make a script to generate the credits / acknowledgement web page for all the open source components to ease the task and make sure I don't forget anyone. In the actual image I have the list of the licenses in /usr/share/licenses/ which is good, but I'm missing the SUMMARY, DESCRIPTION, and HOMEPAGE fields we declare in the recipes which would be nice to display Is there any built-in way to bring that information in the image? I noticed that in the image's build directory there is /image-name/1.0-r0/oe-rootfs-repo/aarch64/Packages which if I understand correctly has the ipk package list with the missing information. Is there a way to copy that file in the image after do_rootfs completes? Thanks, -Damien -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50397): https://lists.yoctoproject.org/g/yocto/message/50397 Mute This Topic: https://lists.yoctoproject.org/mt/76469697/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Changing SDKPATH
Hi,
I would need that to change the default location for the SDK install script
to avoid mistakes with multiple SDKs and ease installations. How can I
change the SDKPATH?
My distro includes conf/distro/poky.conf and I overwrite
SDKPATH =
"/opt/${IMAGE_BASENAME}-${SDK_VERSION}-${DISTRO_CODENAME}-${MACHINE}"
If I set SDKPATH to something other than /opt/${DISTRO}/${SDK_VERSION} ,
nativesdk-libgcc-initial fails some sanity test:
...
checking how to run the C preprocessor... x86_64-pokysdk-linux-gcc -E
--sysroot=/data/yocto/zeus/build-jetson-xavier/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/7.3.0-r0/recipe-sysroot
configure: error: in
`/data/yocto/zeus/build-jetson-xavier/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/7.3.0-r0/gcc-7.3.0/build.x86_64-pokysdk-linux.x86_64-pokysdk-linux/libgcc':
configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E
--sysroot=/data/yocto/zeus/build-jetson-xavier/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/7.3.0-r0/recipe-sysroot
" fails sanity check
See `config.log' for more details.
WARNING: exit code 1 from a shell command.
...
Thanks,
-Damien
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50313): https://lists.yoctoproject.org/g/yocto/message/50313
Mute This Topic: https://lists.yoctoproject.org/mt/76328600/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] llvm native
Hi,
I added meta-clang layer and it solved my problem.
Cheers,
-Damien
On Fri, Jun 26, 2020, 11:20 Yann Dirson wrote:
> Oh, and beware of master and dunfell with llvm-config, if your target is
> multilib.
> You may need the patch referenced in
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13937
>
> Le ven. 26 juin 2020 à 10:17, Yann Dirson a
> écrit :
>
>> Did you check that llvm-native is listed in the sysroot-providers folder,
>> and that tmp/sysroots-components/x86_64/llvm-native/ contains the expected
>> files ?
>>
>> Le jeu. 25 juin 2020 à 19:17, Randy MacLeod
>> a écrit :
>>
>>> On 2020-06-10 9:10 a.m., Damien LEFEVRE wrote:
>>> > Hi,
>>> >
>>> > I'm trying to build a native package which uses llvm. I never used
>>> llvm
>>> > before, so time to learn
>>> >
>>> > I've added
>>> > DEPENDS += "llvm-native"
>>> >
>>> > to my recipe but I still get errors
>>> >
>>> > LLVM_CONFIG:
>>> > | CMake Error at data/shiboken_helpers.cmake:146 (message):
>>> > | Unable to detect CLANG location by checking LLVM_INSTALL_DIR,
>>> > | CLANG_INSTALL_DIR or running llvm-config.
>>> > | Call Stack (most recent call first):
>>> > | CMakeLists.txt:37 (setup_clang)
>>> >
>>> > I looked at the llvm_git.bb <http://llvm_git.bb> file
>>> > do_install_class-native() {
>>> > install -D -m 0755 ${B}/bin/llvm-tblgen ${D}${bindir}/llvm-tblgen${PV}
>>> > install -D -m 0755 ${B}/bin/llvm-config ${D}${bindir}/llvm-config${PV}
>>> > install -D -m 0755 ${B}/lib/libLLVM-${MAJOR_VERSION}.so
>>> > ${D}${libdir}/libLLVM-${MAJOR_VERSION}.so
>>> > }
>>> >
>>> > so I would expect to see llvm-config8.0.0 in
>>> > the recipe-sysroot-native/usr/bin/ inside my package folder but
>>> nothing
>>> > llvm related.
>>> >
>>> > What am I missing?
>>>
>>> That's odd, I can build:
>>>llvm-native-9.0.1
>>> using just oe-core from about a week ago. I don't have clang installed
>>> on that builder. Check the git history between your version and master.
>>> I don't see anything below from a quick look.
>>>
>>> Can you try building master?
>>>
>>> ../Randy
>>>
>>> oe-core.git $ git log --oneline meta/recipes-devtools/llvm
>>> 80cc6e60b9 llvm: Remove -fcommon
>>> 312e9fe3f0 recipes: Use -fcommon explicitly
>>> 8413dede13 llvm: Upgrade to 9.0.1 release
>>> 2fa183c59c llvm: fix upstream version check
>>> c1efb1772c llvm: rv32/rv64 target builds are not supported yet
>>> 85d9348272 llvm: add missing Upstream-Status tags
>>> 7f4870132e llvm: Update to 9.0.0
>>> 487eb18928 llvm: remove -mlongcall from CXXFLAGS for powerpc
>>> 13f9182e72 llvm: use python 3 during builds
>>> 3c08b63834 mesa,llvm,meson: Update llvm to 8.0.1 plus define and use
>>> LLVM version globally
>>> 5302047be6 llvm: fix link error for powerpc
>>> 3b4049157a llvm: fix more places where '8.0' version of llvm was
>>> hardcoded
>>> 0e7d761b13 llvm: support older toolchains
>>> 4405a1793a llvm: update from 8.0.0rc2 to 8.0.0 final release
>>> d8269db061 llvm: don't inherit perlnative
>>> 1587475e45 llvm: doesn't actually need pythonnative
>>> 8e24164606 llvm: Enable RTTI support in preparation for new mesa
>>> 18f565f3ca llvm: switch to the official git repository
>>> 96631d53be llvm,mesa: Upgrade to upcoming 8.0.0 release
>>> 4b1c0c7d55 meta: Fix Deprecated warnings from regexs
>>> 0053740c01 llvm: Enable AMDGPU backend for native/native-sdk builds too
>>> 5e6e08512e llvm: Use HOST_ARCH in LLVM_TARGETS_TO_BUILD for builds
>>> 865eb1c140 llvm: Use YOCTO_ALTERNATE_MULTILIB_NAME environment variable
>>> in llvm-config
>>> 7153a17166 llvm: Point llvm-config to one built with llvm-native
>>> b0783b713e llvm: Update to 6.0.1
>>>
>>>
>>> > Thanks,
>>> >
>>> >
>>> >
>>>
>>>
>>> --
>>> # Randy MacLeod
>>> # Wind River Linux
>>>
>>>
>>
>>
>> --
>> Yann Dirson
>> Blade / Shadow -- http://shadow.tech
>>
>>
>
> --
> Yann Dirson
> Blade / Shadow -- http://shadow.tech
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49763): https://lists.yoctoproject.org/g/yocto/message/49763
Mute This Topic: https://lists.yoctoproject.org/mt/74795953/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] llvm native
Hi,
I'm trying to build a native package which uses llvm. I never used llvm
before, so time to learn
I've added
DEPENDS += "llvm-native"
to my recipe but I still get errors
LLVM_CONFIG:
| CMake Error at data/shiboken_helpers.cmake:146 (message):
| Unable to detect CLANG location by checking LLVM_INSTALL_DIR,
| CLANG_INSTALL_DIR or running llvm-config.
| Call Stack (most recent call first):
| CMakeLists.txt:37 (setup_clang)
I looked at the llvm_git.bb file
do_install_class-native() {
install -D -m 0755 ${B}/bin/llvm-tblgen ${D}${bindir}/llvm-tblgen${PV}
install -D -m 0755 ${B}/bin/llvm-config ${D}${bindir}/llvm-config${PV}
install -D -m 0755 ${B}/lib/libLLVM-${MAJOR_VERSION}.so
${D}${libdir}/libLLVM-${MAJOR_VERSION}.so
}
so I would expect to see llvm-config8.0.0 in
the recipe-sysroot-native/usr/bin/ inside my package folder but nothing
llvm related.
What am I missing?
Thanks,
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49615): https://lists.yoctoproject.org/g/yocto/message/49615
Mute This Topic: https://lists.yoctoproject.org/mt/74795953/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] find utility alternative
Hi, I need to run a script using the find ... -empty option which isn't supported with busybox. ``` find: unrecognized: -empty BusyBox v1.30.1 (2020-05-25 15:54:17 UTC) multi-call binary. ``` Do any other package provide an alternative for then "find" utility? Thanks, -Damien -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49557): https://lists.yoctoproject.org/g/yocto/message/49557 Mute This Topic: https://lists.yoctoproject.org/mt/74628150/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] gpg: can't connect to the agent: File name too long
I think my problem is that the do_image_* are running as fakeroot/pseudo. Is there a way to run this task as a normal local user. I read that I should create the socket when not running under local user with gpgconf --create-socketdir But this fails too although I set permissions for all on the gpg files and directories: ''' | gpgconf: socketdir is '/test-warrior/build-jetson-xavier/tmp/work/jetson_xavier-poky-linux/test-image/1.0-r0/my_img/home' | gpgconf: no /run/user dir | gpgconf: using homedir as fallback | gpgconf: error creating socket directory | gpgconf: fatal error (exit status 1) ''' Basically I need to, as a normal user, run gpg after do_image_tegra. Any hint? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49484): https://lists.yoctoproject.org/g/yocto/message/49484 Mute This Topic: https://lists.yoctoproject.org/mt/74456223/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] gpg: can't connect to the agent: File name too long
Hi,
I'm using this command from a new image type
'''
gpg --homedir home --encrypt --sign --default-key "ser...@test.ltd"
--pinentry-mode loopback --passphrase-file server.passphrase --recipient
"dev...@test.ltd" --output ${IMAGE_LINK_NAME}.fw
${IMGDEPLOYDIR}/${IMAGE_NAME}.img
'''
>From yocto build I get this error
'''
| gpg: can't connect to the agent: File name too long
| gpg: Warning: not using 'ser...@test.ltd' as default key: No secret key
| gpg: all values passed to '--default-key' ignored
'''
I added this img_ota.bbclass
'''
inherit image_types image_types_tegra pythonnative
create_img_ota_pkg() {
rm -rf "${WORKDIR}/my_img"
mkdir -p "${WORKDIR}/my_img"
oldwd=`pwd`
cd "${WORKDIR}/my_img"
ln -sf "${STAGING_DATADIR_NATIVE}/gpg-keys/" home
ln -sf "${STAGING_DATADIR_NATIVE}/gpg-keys/update.passphrase"
update.passphrase
ln -sf "${STAGING_DATADIR_NATIVE}/gpg-keys/encrypt.py" encrypt.py
ln -sf "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.img" "${IMAGE_LINK_NAME}.img"
#gpg --homedir home --encrypt --sign --default-key "ser...@test.ltd"
--pinentry-mode loopback --passphrase-file server.passphrase --recipient
"dev...@test.ltd" --output ${IMAGE_LINK_NAME}.fw
${IMGDEPLOYDIR}/${IMAGE_NAME}.img
echo $(which python3)
python3 encrypt.py blabla.fw ${IMAGE_LINK_NAME}.img
cd oldwd
}
create_my_pkg[vardepsexclude] += "DATETIME"
IMAGE_CMD_img_ota = "create_img_ota_pkg"
do_image_img_ota[depends] += " \
gpg-keys-native:do_populate_sysroot \
"
IMAGE_TYPEDEP_img_ota += "tegraflash"
IMAGE_TYPES += "img_ota"
'''
I have a native recipe creating the gpg db and install the keys.
I did check the gpg and gpg-agent binaries used come from
/test-warrior/build-jetson-xavier/tmp/work/jetson_xavier-poky-linux/test-image/1.0-r0/recipe-sysroot-native/usr/bin
I tried to wrap the command in a python script but it had no effect.
If I open a terminal, add
/test-warrior/build-jetson-xavier/tmp/work/jetson_xavier-poky-linux/test-image/1.0-r0/recipe-sysroot-native/usr/bin
to PATH and run the commands, they go through successfully and I don't
manage to reproduce the error.
What is different with bitbake which could make this fail?
Thanks
-Damien
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49469): https://lists.yoctoproject.org/g/yocto/message/49469
Mute This Topic: https://lists.yoctoproject.org/mt/74456223/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] deploy GPG keys into images
Thanks for the tip Rudolf!
I found out that gpg has a --homedir flag to do the obvious. Since gpg
builds a database, I cannot simply copy the key.
Knowing that now, I can just create the gpg database via a standard recipe
using the native utility package and install the files.
-Damien
On Tue, May 19, 2020 at 7:01 PM Rudolf J Streif
wrote:
> Hi Damien,
> On 5/19/20 7:05 AM, Damien LEFEVRE wrote:
>
> Hi,
>
> I've put GnuPG in my image, and I'd like to deploy a set to public and
> private keys into the system images.
>
> How can I do that from recipes?
>
> You do this with a shell function that is added to
> ROOTFS_POSTPROCESS_COMMAND. Here is a script that I use to create SSH keys:
>
> # Image post-processing to configure sshd
>
> # Setup ssh key login for these users
> SSH_USERS ??= ""
> SSH_DISALLOW_PWAUTH ??= "1"
>
> configure_sshd() {
># disallow password authentication
>if [ "${SSH_DIALLOW_PWAUTH}" == "1" ]; then
> echo "PasswordAuthentication no" >>
> ${IMAGE_ROOTFS}/etc/ssh/sshd_config
>fi
>
># keys will be stored tmp/deploy/keys
>mkdir -p ${DEPLOY_DIR}/keys
>
># create the keys for the users
>for user in ${SSH_USERS}; do
> if [ ! -f ${DEPLOY_DIR}/keys/${user}-sshkey ]; then
> /usr/bin/ssh-keygen -t rsa -N '' \
> -f ${DEPLOY_DIR}/keys/${user}-sshkey
> fi
>
> # add public key to authorized_keys for the user
> mkdir -p ${IMAGE_ROOTFS}/home/${user}/.ssh
> cat ${DEPLOY_DIR}/keys/${user}-sshkey.pub \
> >> ${IMAGE_ROOTFS}/home/${user}/.ssh/authorized_keys
>done
> }
> ROOTFS_POSTPROCESS_COMMAND += "configure_sshd;"
>
> I have this script as an include file that I included into my image
> recipes.
>
> :rjs
>
>
> Thanks,
> -Damien
>
>
>
> --
> -
> Rudolf J Streif
> CEO/CTO ibeeto
> +1.855.442.3386 x700
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49451): https://lists.yoctoproject.org/g/yocto/message/49451
Mute This Topic: https://lists.yoctoproject.org/mt/74325514/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] deploy GPG keys into images
Hi, I've put GnuPG in my image, and I'd like to deploy a set to public and private keys into the system images. How can I do that from recipes? Thanks, -Damien -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49442): https://lists.yoctoproject.org/g/yocto/message/49442 Mute This Topic: https://lists.yoctoproject.org/mt/74325514/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] PREFERRED_VERSION
OK thanks guys, that's what I though.
I did hack 1 since I could, but good to know the hack 2. in case this ever
happens for packages I'm not in control of.
Cheers,
-Damien
On Thu, May 14, 2020 at 11:20 AM Quentin Schulz <
quentin.sch...@streamunlimited.com> wrote:
> Hi Damienm
>
> On Thu, May 14, 2020 at 11:05:56AM +0300, Damien LEFEVRE wrote:
> > Hi,
> >
> > Should it be possible to set PREFERRED_VERSION in the image definition
> > files?
> >
>
> Conceptually, no. An image recipe is a recipe. Global data is global and
> local data is local. A recipe (image or package) set local data only.
>
> > I have 2 image files:
> > - image1.bb
> > - image2.bb : PREFERRED_VERSION_package_1.0.0
> >
> > I have a package with 2 versions:
> > - package_1.0.0.bb
> > - package_1.1.0.bb
> >
>
> Correct way is different distro or machine. Obviously the build impact
> is high for such as small difference in images.
>
> Two possible hacks to me:
> 1. package10_1.0.0.bb and package11_1.1.0.bb but then you need to manage
> the dependencies inside recipes (those (r)depending on package10 or
> package11). If it's a "final" package which isn't a dependency of
> anything else except the image, that's actually not too bad. Then in the
> image you add package10 or package11.
>
> 2. Have an intermediate recipe which RDEPENDS_${PN} += "package
> (=1.1.0)" and the other on "package (=1.0.0)" and install this
> intermediate recipe in the appropriate image.
>
> There are shortcomings in both hacks (otherwise they wouldn't be called
> that way :) ).
>
> Quentin
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49411): https://lists.yoctoproject.org/g/yocto/message/49411
Mute This Topic: https://lists.yoctoproject.org/mt/74200563/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] PREFERRED_VERSION
Hi, Should it be possible to set PREFERRED_VERSION in the image definition files? I have 2 image files: - image1.bb - image2.bb : PREFERRED_VERSION_package_1.0.0 I have a package with 2 versions: - package_1.0.0.bb - package_1.1.0.bb I'm using the same HW setup, MACHINE, distro and local.conf. Thanks, -Damien -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49407): https://lists.yoctoproject.org/g/yocto/message/49407 Mute This Topic: https://lists.yoctoproject.org/mt/74200563/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] pkg_postinst_ontarget not executed
OK I found.
Yes "opkg configure" will call /var/lib/opkg/info/*.postinst for packages
marked as "unpacked" in /var/lib/opkg/status ex:
Package: test-deployment-lic
Version: 1.0-r0
Status: install ok unpacked
Architecture: aarch64
Installed-Time: 1589349316
Auto-Installed: yes
After update
Package: test-deployment-lic
Version: 1.0-r0
Status: install ok unpacked
Architecture: aarch64
Installed-Time: 1589349316
Auto-Installed: yes
Should be easy to merge.
Thanks!
-Damien
On Wed, May 13, 2020 at 12:04 PM Alexander Kanavin
wrote:
> Reading recipes-devtools/run-postinsts/run-postinsts/run-postinsts
> and_save_postinsts_common (in rootfs.py) once more, it seems
> /etc/ipk-postinsts is only used if there is no package manager on the
> target.
>
> If there is, then 'opkg configure' is run directly, and so postinsts come
> from some internal database. There is some additional magic in rootfs.py to
> mark packages with first-boot postinsts as unpacked, so they'll get picked
> up by opkg.
>
> Alex
>
> On Wed, 13 May 2020 at 09:33, Damien LEFEVRE wrote:
>
>> Thanks Alex,
>>
>> When I do a factory reset, the system detects as a first boot and the
>> script is executed.
>>
>> > cat /var/log/postinstall.log
>> Configuring test-deployment.
>>
>> One thing which puzzles me: the /etc/ipk-postinsts directory do not
>> exist. Not in the image recipe folder, not in the image file which I mount
>> to check the content before flashing and of course it's deleted at the end
>> of run-postinsts
>>
>> rootfs.py:
>> def _save_postinsts_common(self, dst_postinst_dir, src_postinst_dir):
>> if bb.utils.contains("IMAGE_FEATURES", "package-management",
>> True, False, self.d):
>> return
>> num = 0
>> for p in self._get_delayed_postinsts():
>> bb.utils.mkdirhier(dst_postinst_dir)
>>
>> if os.path.exists(os.path.join(src_postinst_dir, p +
>> ".postinst")):
>> shutil.copy(os.path.join(src_postinst_dir, p +
>> ".postinst"),
>> os.path.join(dst_postinst_dir, "%03d-%s" %
>> (num, p)))
>>
>> num += 1
>>
>>
>> package-management is in my image features so I understand nothing get
>> written.
>>
>> So who temporarily creates that /etc/ipk-postinsts?
>>
>> Thanks,
>> -Damien
>>
>> On Fri, May 8, 2020 at 6:15 PM Alexander Kanavin
>> wrote:
>>
>>> On Fri, 8 May 2020 at 11:32, Damien LEFEVRE
>>> wrote:
>>>
>>>>
>>>> If can find the postinst script in
>>>> /var/lib/opkg/info/test-deployment.postinst and execute it.
>>>>
>>>> Since test-deployment is a new package, I would have expected
>>>> pkg_postinst_ontarget to be executed
>>>>
>>>> How is the first boot detected on a poky image? Is there a way to
>>>> detect if .postinst scripts haven't been executed?
>>>>
>>>
>>> The scripts to be executed are written into /etc/rpm|deb|ipk-postinsts/
>>> and executed by
>>> meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts script
>>> (which is started on first boot as a service).
>>> Then they get deleted.
>>>
>>> Alex
>>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49389): https://lists.yoctoproject.org/g/yocto/message/49389
Mute This Topic: https://lists.yoctoproject.org/mt/74069263/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] pkg_postinst_ontarget not executed
Thanks Alex,
When I do a factory reset, the system detects as a first boot and the
script is executed.
> cat /var/log/postinstall.log
Configuring test-deployment.
One thing which puzzles me: the /etc/ipk-postinsts directory do not exist.
Not in the image recipe folder, not in the image file which I mount to
check the content before flashing and of course it's deleted at the end of
run-postinsts
rootfs.py:
def _save_postinsts_common(self, dst_postinst_dir, src_postinst_dir):
if bb.utils.contains("IMAGE_FEATURES", "package-management",
True, False, self.d):
return
num = 0
for p in self._get_delayed_postinsts():
bb.utils.mkdirhier(dst_postinst_dir)
if os.path.exists(os.path.join(src_postinst_dir, p +
".postinst")):
shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
os.path.join(dst_postinst_dir, "%03d-%s" %
(num, p)))
num += 1
package-management is in my image features so I understand nothing get
written.
So who temporarily creates that /etc/ipk-postinsts?
Thanks,
-Damien
On Fri, May 8, 2020 at 6:15 PM Alexander Kanavin
wrote:
> On Fri, 8 May 2020 at 11:32, Damien LEFEVRE wrote:
>
>>
>> If can find the postinst script in
>> /var/lib/opkg/info/test-deployment.postinst and execute it.
>>
>> Since test-deployment is a new package, I would have expected
>> pkg_postinst_ontarget to be executed
>>
>> How is the first boot detected on a poky image? Is there a way to detect
>> if .postinst scripts haven't been executed?
>>
>
> The scripts to be executed are written into /etc/rpm|deb|ipk-postinsts/
> and executed by
> meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts script
> (which is started on first boot as a service).
> Then they get deleted.
>
> Alex
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49385): https://lists.yoctoproject.org/g/yocto/message/49385
Mute This Topic: https://lists.yoctoproject.org/mt/74069263/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] pkg_postinst_ontarget not executed
Hi,
I have a device with rootfs mounted readonly and with an overlay on top of
it to do the factory reset.
There's A/B partitioning. So there is a duplicate set of partitions.
There's an OTA engine to deploy atomics images.
I have the following usecase:
1. I flash a minimal image
2. I write the device type into a file (mutiple variant but same HW setup)
to a persistent data partition.
3. I deploy the common product image via OTA engine. The whole rootfs is
deployed atomically
4. I copy the current overlay partition content to the next overlay
partition
5. Reboot
6. System boots to the next slot to the common product image
Currently, the common product image is the minimal image with the addition
of this test-deployment package:
DISCRIPTION = "Test product specific deployment"
LICENSE = "CLOSED"
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI = " \
file://config.type1 \
file://config.type2 \
file://config.type3 \
"
do_configure[noexec] = "1"
do_compile[noexec] = "1"
do_install() {
install -d ${D}/opt/test
install -m 0644 ${WORKDIR}/config.type1 ${D}/opt/test
install -m 0644 ${WORKDIR}/config.type2 ${D}/opt/test
install -m 0644 ${WORKDIR}/config.type3 ${D}/opt/test
}
pkg_postinst_ontarget_${PN}() {
systemid=$(cat /persistent/systemid)
cd /opt/test
mv config.$systemid config
rm config.*
}
FILES_${PN} += " \
/opt/test/* \
"
The /opt/test folder is now present but it still contains config.type1,
config.type2 and config.type3.
If can find the postinst script in
/var/lib/opkg/info/test-deployment.postinst and execute it.
Since test-deployment is a new package, I would have expected
pkg_postinst_ontarget to be executed
How is the first boot detected on a poky image? Is there a way to detect if
.postinst scripts haven't been executed?
Thanks,
-Damien
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49356): https://lists.yoctoproject.org/g/yocto/message/49356
Mute This Topic: https://lists.yoctoproject.org/mt/74069263/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] Yocto img file deployment
Hi, I have a yocto image: image.img. On my build PC I have > file image.img image.img: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 802815 sectors, extended partition table (last) > fdisk -l image.img Disk image.img: 392 MiB, 411041792 bytes, 802816 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 45C0DFD4-267E-4C4A-820F-B94F180165E7 Device StartEnd Sectors Size Type image.img1 2048 800767 798720 390M Linux filesystem And I can calculate the offset (512 * 2048 = 1048576) to mount image.img1 to let say /tmp/update mount -t ext4 -o loop,offset=1048576 image.img /tmp/update Now on the target device (Tegra), I'd like to write the content of image.img1 to /dev/mmcblk0p38. But the output of busybox's fdisk is different > fdisk -l image.img Disk image.img: 392 MB, 411041792 bytes, 802816 sectors 49 cylinders, 255 heads, 63 sectors/track Units: sectors of 1 * 512 = 512 bytes Device Boot StartCHSEndCHSStartLBA EndLBASectors Size Id Type image.img10,0,1 1023,254,63 1 802815 802815 391M ee EFI GPT Partition 1 has different physical/logical start (non-Linux?): phys=(0,0,1) logical=(0,0,2) Partition 1 has different physical/logical end: phys=(1023,254,63) logical=(49,248,7) How can I deduce the offset from this output? Better even, is there a way to dd image.img1 directly to /dev/mmcblk0p38? Thanks, -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49319): https://lists.yoctoproject.org/g/yocto/message/49319 Mute This Topic: https://lists.yoctoproject.org/mt/73973198/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] zeus KCFLAGS
Hi, I'm trying to build the core-image-minimal on zeus branch, device Tegra Xavier. The compiler has to be GCC 7.* due to some NVidia pre-built binaries. So I back ported it from Thud if I recall. The kernel compilation fails with this error: | cc1: error: -Werror=address-of-packed-member: no option -Waddress-of-packed-member | cc1: error: -Werror=missing-attributes: no option -Wmissing-attributes How to I make the compiler treat these error as warnings? I've tried adding all these to the kernel recipe: export KCFLAGS = " -Wno-error=address-of-packed-member -Wno-error=missing-attributes " export KCPPFLAGS = " -Wno-error=address-of-packed-member -Wno-error=missing-attributes " TARGET_CFLAGS += " -Wno-error=address-of-packed-member -Wno-error=missing-attributes " TARGET_CPPFLAGS += " -Wno-error=address-of-packed-member -Wno-error=missing-attributes " KBUILD_CFLAGS += " -Wno-error=address-of-packed-member -Wno-error=missing-attributes " None of them seems to be applied. Anything special changed on Zeus? Note I didn't have any issue building the kernel on Warrior. Thanks -Damien -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49248): https://lists.yoctoproject.org/g/yocto/message/49248 Mute This Topic: https://lists.yoctoproject.org/mt/73300050/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] u-boot factory reset
Hi,
First time customizing u-boot, forgive my basic question.
To implement a factory reset, my initramfs expects a ‘factoryreset’ kernel
parameter to format an overlay FS partition before mounting it.
The target machine is a Tegra TX2.
I’m able to use the Volume Up button for factory reset, which is gpio-313 .
When starting the board if I press the button say 5s, I’d like to add the
‘factoryreset’ parameter to the boot parameters
I think I could use this syntax @uboot_var('factoryreset') in the
KERNEL_ROOTSPEC variable and have the variable set either to '' or
'factoryreset'
Maybe, I should append distro_bootcmd to add the gpio pin reading to
set factoryreset variable before proceeding with the boot sequence.
But how can I add the variable and have it set if the if the gpio pin is at
a certain state?
Thanks,
-Damien
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49066): https://lists.yoctoproject.org/g/yocto/message/49066
Mute This Topic: https://lists.yoctoproject.org/mt/72809180/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
