All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Khem Raj" <raj.khem@gmail.com>
To: "Monsees, Steven C (US)" <steven.monsees@baesystems.com>
Cc: "yocto@lists.yoctoproject.org" <yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto #sdk
Date: Tue, 9 Mar 2021 08:56:23 -0800	[thread overview]
Message-ID: <CAMKF1soNzS3dcesyn+F6NnSy5nqYz2FZreTApf34-dqCAU6Lkw@mail.gmail.com> (raw)
In-Reply-To: <60476cbb.1c69fb81.52948.d974SMTPIN_ADDED_MISSING@mx.google.com>

[-- Attachment #1: Type: text/plain, Size: 11006 bytes --]

it excludes the variables from checksums see
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#checksums

On Tue, Mar 9, 2021 at 4:40 AM Monsees, Steven C (US) <
steven.monsees@baesystems.com> wrote:

>
>
> What is the difference between using “SIGGEN_UNLOCKED_RECIPES +=” and
> “BB_HASHBASE_WHITELIST_append =” ?
>
>
>
>
>
> *From:* Khem Raj <raj.khem@gmail.com>
> *Sent:* Thursday, March 4, 2021 1:22 PM
> *To:* Monsees, Steven C (US) <steven.monsees@baesystems.com>
> *Cc:* yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] #yocto #sdk
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
> right, the change seems to be happening in task checksums and that happens
> if some of bitbake variables change when SDK is built built and when it is
> being installed ( when it will run parse again ) perhaps the workspace
> under the hood is still accessible and you can use bitbake-diffsigs to
> narrow it down the variable that is changing
>
>
>
> On Thu, Mar 4, 2021 at 9:38 AM Monsees, Steven C (US) via
> lists.yoctoproject.org <steven.monsees=
> baesystems.com@lists.yoctoproject.org> wrote:
>
>
>
> I am seeing similar issues on line  for my eSDK install issue, but no
> resolutions…
>
>
>
> Can someone advise on best course of action to debug this ?
>
>
>
> 11:10 smonsees@yix490016
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk>
> ./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh
>
> LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4
>
> ====================================================================
>
> Enter target directory for SDK (default: ~/limws_sdk):
> /disk0/scratch/smonsees/testSDK
>
> You are about to install the SDK to "/disk0/scratch/smonsees/testSDK".
> Proceed [Y/n]? Y
>
> Extracting
> SDK..............................................................................done
>
> Setting it up...
>
> Extracting buildtools...
>
> Preparing build system...
>
> Parsing recipes: 100%
> |##########################################################################################|
> Time: 0:01:36
>
> Initialising tasks: 100%
> |#######################################################################################|
> Time: 0:00:04
>
> Checking sstate mirror object availability: 100%
> |###############################################################| Time:
> 0:00:02
>
> WARNING: The efitools:do_compile sig is computed to be
> 5851605e22907038837428950427053e22ea655641a08b5dafa39d6d6e1c5e15, but the
> sig is locked to
> b81a26e3591c71acd3d22212bfdb70a15a0df49af72e7634e6a39851f16e18b5 in
> SIGGEN_LOCKEDSIGS_t-corei7-64
>
> The monkeysphere:do_install sig is computed to be
> 13a65b26dfff91f2432a8064d98003559eafffa214d81c3c6ea112c2dfba0391, but the
> sig is locked to
> 2058fc9032b0e7f5c1ea358de4fa8d25ccec7204b73ebc636e79222d8cc00469 in
> SIGGEN_LOCKEDSIGS_t-corei7-64
>
> The signature:do_compile sig is computed to be
> ac0c5c19cdbe7484046657ccb7b768c02fbbabb43166befa93b71a85d5fcf55b, but the
> sig is locked to
> cf5c3f72489f447b1199aafe4b4148988ff91cecd970422352f2238afb127683 in
> SIGGEN_LOCKEDSIGS_t-corei7-64
>
> The grub-efi-native:do_clean_grub sig is computed to be
> 4e16b100c32e9428126eb10864508038527cec795c5e4391208d96a55735c90a, but the
> sig is locked to
> a2bd26be0297624af53d6f8cf657d79740fb229db821c446d564c5ee9dc80ea3 in
> SIGGEN_LOCKEDSIGS_t-x86-64
>
> The grub-efi-native:do_compile sig is computed to be
> 630cc346f7ececf98c54f9134e8fee546e85c92f1e3c6ac3c258a1cdf24d4565, but the
> sig is locked to
> 802bba0874ce26169a9e16dcdb440795e8fa904977b036d637d6c4086ce72de8 in
> SIGGEN_LOCKEDSIGS_t-x86-64
>
> The grub-efi:do_clean_grub sig is computed to be
> faf0ae3c9159ef3ebb13d2521ecf51dfeeac0c2c47691cd0aaa80de91187af3c, but the
> sig is locked to
> 0075bbd34297bfbc62685ff5477feec11d0dd2bcda6787a151cfb7927a7f39c2 in
> SIGGEN_LOCKEDSIGS_t-corei7-64
>
> The grub-efi:do_compile sig is computed to be
> 30c09f3e8db4059b7e1ff23823f208be94d0e622904fc43eda497027be095a71, but the
> sig is locked to
> a9e8ddd9ecac11e67c66d9fccbabe23b6eb4a19c5996baef8ff960dfcdc898ed in
> SIGGEN_LOCKEDSIGS_t-corei7-64
>
> ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly
>
> Task
> /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/db/db_5.3.28.bb:do_populate_sysroot,
> unihash dcfb179ae99ac73583d33eec1357ff5d06fb58f160e5d7285061b6e1c9c3a9c0,
> taskhash dcfb179ae99ac73583d33eec1357ff5d06fb58f160e5d7285061b6e1c9c3a9c0
>
> Task
> /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-extended/sed/sed_4.2.2.bb:do_package_write_ipk,
> unihash a37dc1cc0064749d1f6de69d0a9b8eab9ff6ef4089eff28a76e1851f8f8f8fe3,
> taskhash a37dc1cc0064749d1f6de69d0a9b8eab9ff6ef4089eff28a76e1851f8f8f8fe3
>
> Task
> /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb:do_package_qa,
> unihash 2b17b70b3e1568840e3b39488b9e6470c89d5ffd502f02b2c129331d7609add8,
> taskhash 2b17b70b3e1568840e3b39488b9e6470c89d5ffd502f02b2c129331d7609add8
>
> Task
> /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-connectivity/openssh/openssh_8.0p1.bb:do_package_qa,
> unihash 87a24567344a646de9ab6fba50b398e41711ff4d1bca749ebe02d84359c2a155,
> taskhash 87a24567344a646de9ab6fba50b398e41711ff4d1bca749ebe02d84359c2a155
>
> .
>
> .
>
>
>
>
>
>
> https://www.mail-archive.com/search?l=yocto@yoctoproject.org&q=subject:%22Re%5C%3A+%5C%5Byocto%5C%5D+eSDK+install+script+failure%22&o=newest&f=1
>
>
>
> https://www.yoctoproject.org/pipermail/yocto/2017-August/037359.html
>
>
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12344
>
>
>
>
>
> *From:* yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> *On
> Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
> *Sent:* Thursday, March 4, 2021 8:13 AM
> *To:* Monsees, Steven C (US) <steven.monsees@baesystems.com>;
> yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] #yocto #sdk
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
>
>
>
>
> Is there a list of certain classes that might interfere with the ability of the eSDK to lock down the configuratiuon ?
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
> *From:* yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> *On
> Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
> *Sent:* Tuesday, March 2, 2021 3:26 PM
> *To:* yocto@lists.yoctoproject.org
> *Subject:* [yocto] #yocto #sdk
>
>
>
> *External Email Alert*
>
> *This email has been sent from an account outside of the BAE Systems
> network.*
>
> Please treat the email with caution, especially if you are requested to
> click on a link, decrypt/open an attachment, or enable macros.  For further
> information on how to spot phishing, access “Cybersecurity OneSpace Page”
> and report phishing by clicking the button “Report Phishing” on the Outlook
> toolbar.
>
>
>
>
>
> I still appear to be having an issue with the SXT SDK install…
>
>
>
> Building for zeus/x86_64 Intel based platform…
>
> I build my kernel image clean, fully functional…
>
> Standard SDK builds clean and appears functional…
>
>
>
> Ext SDK builds clean, but on install I am still seeing Error below…
>
>
>
> (1)    What is it comparing  between unhash/task hash ?, more sig issues ?
>
>
>
> (2)    What is meant by “This is usually due to missing setscene tasks” ?
>
>
>
> (3)    In the local.conf under the SDK they set :
>
>
>
> SSTATE_MIRRORS += " file://universal/(.*) file://universal-4.9/\1
> file://universal-4.9/(.*) file://universal-4.8/\1"
>
>
>
> Under sdk-extra.conf I set :
>
>
>
> SSTATE_MIRRORS += file://.* file:///ede/tms/yocto/zeus/sstate_cache/PATH
>
>
>
> My SSTATE_MIRRIOR is based off the clean builds I mentioned above, is this
> the correct procedure ?
>
>
>
> I am trying to figure out how best to debug this issue, it is occurring on
> the post install, and everything pretty much appears in place.
>
>
>
> Steve
>
>
>
> 14:43 smonsees@yix490038
> /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk>./
> limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh
>
> LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4
>
> ====================================================================
>
> Enter target directory for SDK (default: ~/limws_sdk):
> /disk0/scratch/smonsees/testSDK
>
> You are about to install the SDK to "/disk0/scratch/smonsees/testSDK".
> Proceed [Y/n]? Y
>
> Extracting
> SDK..............................................................................done
>
> Setting it up...
>
> Extracting buildtools...
>
> Preparing build system...
>
> Parsing recipes: 100%
> |###########################################################################################|
> Time: 0:01:32
>
> Initialising tasks: 100%
> |########################################################################################|
> Time: 0:00:04
>
> Checking sstate mirror object availability: 100%
> |################################################################| Time:
> 0:00:03
>
> ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly
>
> Task
> /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/liburcu/liburcu_0.11.1.bb:do_populate_sysroot,
> unihash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601,
> taskhash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601
>
> Task
> /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-devtools/python/python3_3.7.8.bb:do_packagedata,
> unihash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f,
> taskhash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f
>
> .
>
> .
>
> .
>
>
>
> This is usually due to missing setscene tasks. Those missing in this build
> were:
>
>
>
> <<appears to list every recipe under ./testSDK/layers directory here>>
>
>
> 
>
>

[-- Attachment #2: Type: text/html, Size: 24438 bytes --]

  parent reply	other threads:[~2021-03-09 16:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02 20:25 #yocto #sdk Monsees, Steven C (US)
2021-03-04 13:13 ` Monsees, Steven C (US)
2021-03-04 17:18   ` [yocto] " Khem Raj
2021-03-04 17:51     ` Monsees, Steven C (US)
2021-03-04 17:38   ` Monsees, Steven C (US)
2021-03-04 18:22     ` Khem Raj
2021-03-09 12:39       ` Monsees, Steven C (US)
     [not found]       ` <60476cbb.1c69fb81.52948.d974SMTPIN_ADDED_MISSING@mx.google.com>
2021-03-09 16:56         ` Khem Raj [this message]
2021-03-24 16:18       ` Monsees, Steven C (US)
2021-03-24 18:35         ` Khem Raj
2021-03-24 18:42           ` Monsees, Steven C (US)
  -- strict thread matches above, loose matches on Subject: below --
2021-04-06 10:57 Monsees, Steven C (US)
2021-04-01 13:36 Monsees, Steven C (US)
2021-03-25 19:59 Monsees, Steven C (US)
2021-03-25 21:15 ` Khem Raj
2021-04-01 10:51   ` Monsees, Steven C (US)
2021-02-23 18:02 Monsees, Steven C (US)
2021-02-23 19:29 ` [yocto] " Khem Raj
2021-02-23 20:41   ` Monsees, Steven C (US)
2021-02-24 13:08     ` Monsees, Steven C (US)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMKF1soNzS3dcesyn+F6NnSy5nqYz2FZreTApf34-dqCAU6Lkw@mail.gmail.com \
    --to=raj.khem@gmail.com \
    --cc=steven.monsees@baesystems.com \
    --cc=yocto@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.