we’re trying to use yocto dunfell and mender on a STM32MP157C-DK2
Our ( probably bad ) idea is to replicate the STM32MP157C mender-community layer for yocto thud, creating the u-boot patches using devtool.
Now, we can build (obtaining the .mender and the .gptimg files) and start the board. The Mender server recognize the board as a pending device and it’s possible to accept it. But we have some problems with partitions.
If we use the mender client we get this error:
Failed to read the current active partition: No match between boot and root partitions.: exit status 243
Moreover, if we use fw_printenv command we get:
fw_printenv cannot read environment using default
cannot read default environment from file
U-boot version is 2020.01
Any advice how to solve this issue?
Related
After Changing to version 1.19, but using Omnipath implementation, I'm randomly receiving the following error: ERROR calling: gasnet_barrier_try(id, 0).
I know that the Omnipath implementation of GASNet is no longer supported by the current version of Chapel. However, I would like to use some features available only in version 1.19, and the cluster I use runs over an Omnipath network.
In order to use the PSM substrate (OmniPath), I proceed as suggested by Chapel's Gitter community:
export CHPL_GASNET_ALLOW_BAD_SUBSTRATE=true
wget https://gasnet.lbl.gov/download/GASNet-1.32.0.tar.gz
tar xzf GASNet-1.32.0.tar.gz
rm -rf $CHPL_HOME/third-party/gasnet/gasnet-src
mv GASNet-1.32.0 $CHPL_HOME/third-party/gasnet/gasnet-src
Then, I setup other variables:
export CHPL_COMM='gasnet'
export CHPL_LAUNCHER='gasnetrun_psm'
export CHPL_COMM_SUBSTRATE='psm'
export CHPL_GASNET_SEGMENT='everything'
export CHPL_TARGET_CPU='native'
export GASNET_PSM_SPAWNER='ssh'
export HFI_NO_CPUAFFINITY=1
Next, I build the runtime, etc.
However, when I run experiments, I randomly receive the following error:
ERROR calling: gasnet_barrier_try(id, 0)
at: comm-gasnet.c:1020
error: GASNET_ERR_BARRIER_MISMATCH (Barrier id's mismatched)
Which finishes the execution of the program.
I cannot find in GASNet documentation the reason for this error. I could only find a bit of information on GASNet's code.
Do you know what's the cause of this problem?
Thank you all.
I realize this is an old question, but for the record the current version of Chapel (1.28.0) now embeds a version of GASNet (GASNet-EX 2022.3.0 as of this writing) that provides CHPL_COMM=gasnet CHPL_COMM_SUBSTRATE=ofi (aka GASNet ofi-conduit) that provides high-quality support for Intel Omni-Path.
In particular, there should no longer be any reason to clobber Chapel's embedded version of GASNet-EX with an ancient/outdated GASNet-1 to get Omni-Path support, as suggested in the original question.
For more details see Chapel's detailed Omni-Path instructions.
After sleeping (in lite account type) node-red, created by node-red starter kit, crashes while starting. It is possible to login in editor for a few seconds and then it crashes with error code "an instance of the app crashed: APP/PROC/WEB: Exite with status 1 (out of memory)". Dashboard (node-red-dashboard) was installed before sleeping and worked correctly.
I tried to restart Node-RED, Stop and Start.
I solved this problem. The problem may be due to the memory overflow in the container Garden. Taking into account that the content is stored in the cache, the application cannot start after the restart process, it issues an Exit status 1 (out of memory) error.
The cache is updated only by pushing the application into the cloud.
An option that was checked for application recovery:
View the name of the database for NodeRED (which stores all information about the Node-RED) in Cloudant, for example, "nodered."
Install to PC Cloud Foundry Command Line Interface - CLI https://docs.cloudfoundry.org/cf-cli/install-go-cli.html
Download from github and unarchive the application's code bluemix-starter https://github.com/knolleary/node-red-bluemix-starter (clone or download -> download zip)
In the downloaded folder add a record to a manifest file (manifest.yml) in the env section, in which set the database name (for example, nodered) in Cloudant to environment variable NODE_RED_STORAGE_DB_NAME. Four spaces must be made before NODE_RED_STORAGE_DB_NAME. It is better to make changes using the Notepad ++ editor.
---
applications:
- memory: 256M
env:
OPTIMIZE_MEMORY: true
NODE_RED_STORAGE_DB_NAME: nodered
command: node index.js --settings ./bluemix-settings.js –v
Save the file after changing.
Run the command line (cmd) and then:
a. go to a folder with a downloaded project, such as Windows
cd c:/node-red-bluemix-starter
b. specify the api endpoint where the application is located, in our case:
cf api https://api.eu-gb.bluemix.net
c. send a registration command in the cloud
cf login
d. specify the mail and password (password is entered without explicit character display)
e. pushing the project by specifying the name of your instance Node-RED, for example NameApp
cf push NameApp
I have created Azure Batch pool with Linux Machine and specified Application Package for the Pool.
My command line is
command='python $AZ_BATCH_APP_PACKAGE_scriptv1_1/tasks/XXX/get_XXXXX_data.py',
python3: can't open file '$AZ_BATCH_APP_PACKAGE_scriptv1_1/tasks/XXX/get_XXXXX_data.py':
[Errno 2] No such file or directory
when i connect to node and look at working directory non of the Application Package files are present there.
How do i make sure that files from Application Package are available in working directory or I can invoke/execute files under Application Package from command line ?
Make sure that your async operation have proper await in place before you start using the package in your code.
Also please share your design \ pseudo-code scenario and how you are approaching it as a design?
Further to add:
Seems like this one is pool level package.
The error seems like that the application env variable is either incorrectly used or there is some other user level issue. Please checkout linmk below and specially the section where use of env variable is mentioned.
This seems like user level issue because In case of downloading the package resource, if there will be an error it will be visible to you via exception handler or at the tool level is you are using batch explorer \ Batch-labs or code level exception handling.
https://learn.microsoft.com/en-us/azure/batch/batch-application-packages
Reason \ Rationale:
If the pool level or the task application has error, an error-list will come back if there was an error in the application package then it will be returned as the UserError or and AppPackageError which will be visible in the exception handle of the code.
Key you can always RDP into your node and checkout the package availability: information here: https://learn.microsoft.com/en-us/azure/batch/batch-api-basics#connecting-to-compute-nodes
I once created a small sample to help peeps around so this resource might help you to checkeout the use here.
Hope rest helps.
On Linux, the application package with version string is formatted as:
AZ_BATCH_APP_PACKAGE_{0}_{1}
On Windows it is formatted as:
AZ_BATCH_APP_PACKAGE_APPLICATIONID#version
Where 0 is the application name and 1 is the version.
$AZ_BATCH_APP_PACKAGE_scriptv1_1 will take you to the root folder where the application was unzipped.
Does this "exact" path exist in that location?
tasks/XXX/get_XXXXX_data.py
You can see more information here:
https://learn.microsoft.com/en-us/azure/batch/batch-application-packages
Edit: Just saw this question: "or can I invoke/execute files under Application Package from command line"
Yes you can invoke and execute files from the application package directory with the environment variable above.
If you type env on the node you will see the environment variables that have been set.
New to streamsets. Following the documentation tutorial, was getting
FileNotFound: ... HADOOPFS_14 ... (permission denied)
error when trying to set the destination location as a local FS directory and preview the pipeline (basically saying either the file can't be accessed or does not exist), yet the permissions for the directory in question are drwxrwxr-x. 2 mapr mapr. Eventually found workaround by setting the destination folder permissions to be publicly writable ($chmod o+w /path/to/dir). Yet, the user that started the sdc service (while I was following the installation instructions) should have had write permissions on that directory (was root).
I set the sdc user env. vars. to use the name "mapr" (the owner of the directories I'm trying to access), so why did I get rejected? What is happening here when I set the env. vars. for sdc (because it does not seem to be doing anything)?
This is a snippet of what my /opt/streamsets-datacollector/libexec/sdcd-env.sh file looks like:
# user that will run the data collector, it must exist in the system
#
export SDC_USER=mapr
# group of the user that will run the data collector, it must exist in the system
#
export SDC_GROUP=mapr
So my question is, what determines the permissions for the sdc service (which I assume is what is being used to access FS locations by the streamsets web UI)? Any explaination or links to specific documentation would be appreciated. Thanks.
Looking at the command ps -ef | grep sdc to examine who the system thinks the owner of the sdc process really is, found that it was listed as:
sdc 36438 36216 2 09:04 ? 00:01:28 /usr/bin/java -classpath /opt/streamsets-datacollector
So it seems that editing sdcd-env.sh did not have any effect. What did work was editing the /usr/lib/systemd/system/sdc.service file to look like (notice that have set user and group to be the user that owns the directories to be used in the streamsets pipeline):
[Unit]
Description=StreamSets Data Collector (SDC)
[Service]
User=mapr
Group=mapr
LimitNOFILE=32768
Environment=SDC_CONF=/etc/sdc
Environment=SDC_HOME=/opt/streamsets-datacollector
Environment=SDC_LOG=/var/log/sdc
Environment=SDC_DATA=/var/lib/sdc
ExecStart=/opt/streamsets-datacollector/bin/streamsets dc -verbose
TimeoutSec=60
Then restarting the sdc service (with systemctl start sdc, on centos 7) showed:
mapr 157013 156955 83 10:38 ? 00:01:08 /usr/bin/java -classpath /opt/streamsets-datacollector...
and was able to validate and run pipelines with origins and destinations on local FS that are owned by the user and group set in the sdc.service file.
* NOTE: the specific directories used in the initial post are hadoop-mapr directories mounted via NFS (mapr 6.0) (though the fact that they are NFS should mean that this solution should apply generally) hosted on nodes running centos 7.
Following are are two sample codes that I tried
Code1:
import boto3
session = boto3.session.Session()
ec2_us_east = session.resource('ec2')
snap = ec2_us_east.Snapshot('snap-<id>')
snap.copy(DryRun=False,SourceRegion='us-east-1',SourceSnapshotId=snap.id,Description="testB3Copy",DestinationRegion="us-west-1")
Code2:
import boto3
ec2_us_east_client = boto3.client('ec2')
ec2_us_east_client.copy_snapshot(DryRun=False,SourceRegion='us-east-1',SourceSnapshotId=<snap-id>,Description="testB3Copy",DestinationRegion="us-west-1")
Both generates same error message as shown below:
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-65-464cba179f87> in <module>()
----> 1 ec2_us_east_client.copy_snapshot(DryRun=True,SourceRegion='us-east-1',SourceSnapshotId=snap.id,Description="testB3Copy",DestinationRegion="us-west-1")
/usr/lib/python2.7/site-packages/botocore/client.pyc in _api_call(self, **kwargs)
239 endpoint_prefix=service_model.endpoint_prefix,
240 operation_name=operation_name),
--> 241 model=operation_model, params=request_dict
242 )
243
/usr/lib/python2.7/site-packages/botocore/hooks.pyc in emit(self, event_name, **kwargs)
150 for handler in handlers_to_call:
151 logger.debug('Event %s: calling handler %s', event_name, handler)
--> 152 response = handler(**kwargs)
153 responses.append((handler, response))
154 return responses
TypeError: copy_snapshot_encrypted() takes exactly 3 arguments (1 given)
I'm not sure what is going wrong here. As per the documentation copy_snapshot takes 5 arguments.
Also not sure about whether it is possible to transfer Encrypted snapshot using boto2+
When you transfer Windows AMI from one region to another (by copying snapshots and registering an AMI manually or via scripts), final AMI's platform property will be set as "Other Linux" instead of "Windows"
NOTE: platform windows to other Linux change can be ignored since when the virtualization_type is hvm, it doesn't matter. VM will bootup normally since Fully virtualized VMs boot by executing mbr.
At the moment, Boto (v2+,3+), AWS CLI or Amazon console doesn't support AMI with encrypted volume transfer between regions.
Also Boto (v2+,3+) doesn't transparently support transfer of AMIs with encrypted snapshots
NOTE: There is a hard limit of 5 active snapshot transfer, which probably creates a challenge for AMI Transfer feature (Not sure). But AWSCLI (latest version as of today) supports Encrypted blockdevice transfer.
So here is what I did. I have used AWS CLI to transfer snapshot and Python-boto to manage the transfer
1. Shellscript
INPUT(CommandlineArgs) takes snapshotID, source region and destination region as input
Output snapshotID or <predeterminedstring, eg: TfrFailed>(incase transfer failed due to 5ActiveSnapshotTransferAcrossRegionLimit)
2. Python (boto)
Input(CommandlineArgs) takes AMI_ID(s)
Logic:
for each ami
collect information about snapshots
try
initiates transfer of each snapshot (by calling shell script which uses AWS CLI)
catch exception (output of shell script == <predeterminedstring>
retry after sometime (you would be here if you had hit the hard limit of 5 active snapshots
finally (once all snapshots are transfered)
register a new ami (optionally transfer all tags from source AMI to target AMI)
print SRC_AMI_ID "-->" DST_AMI_ID
done
Output: <SourceLocation_AMI-ID> --> <TargetLocation_AMI-ID
NOTE: you might see that the target AMI looses information about "platform" since when we transfer AMIs this way we are not refering to a manifest file and I couldn't figure out a way to forcefully set platform -> "Windows". But you can ignore that, and it should work just fine if you set "Virtualization_type" as "hvm".
NOTE: If you do this and want to use "Get password feature", you probably are out of luck since this would need platform to be set as "Windows"
Incase of paravirtual, most likely your target AMI won't bootup unless your new ami has sufficient properties configured for PVGRUB
Update: Boto 3 release 0.0.7 should now include support for copying encrypted snapshots in the Botocore client interface.
Right now there is a customization to help with this method in Botocore, and it is used by the AWS CLI. It is not yet available in Boto 3. Botocore provides two public interfaces, the newer one being the low-level clients exposed in Boto 3. These do not yet support the customization that is set up here:
https://github.com/boto/botocore/blob/develop/botocore/handlers.py#L398
We are working to get this plumbed through so that this and a few other calls just work in Boto 3, like they do in the AWS CLI today. The change will require a Botocore code change and release, and then it should just work in Boto 3.