Error in getting dual image active image configuration

ASUS KRPA-U16 not working with EPYC 7D13 (100-000000322)

zedei

New Member

rootwyrm

Member

zedei

New Member

RolloZ170

Well-Known Member

RageBone

Active Member

rootwyrm

Member

You are correct (I can’t say exactly which, because it does vary by BIOS.) It will also indicate PSB fuse trip if you have the appropriate hookups (Asus board doesn’t though.) The 7D13 is, as I said, a low-power contract customer part with a unique SKU and unique microcode. Which is literally all the information I or anyone else has on it to date. This may in fact, be the first sample to be found in the wild at all.

And honestly, even I don’t know that I could get it working based on that. AGESA’s signed, and even attempting to run any variant microcode would require breaking seal. With the right board you could load some special pieces into the BIOS, but that’s no guarantee the CPUIDs even present. And retail boards literally can’t do it — it’s more than just using SPI to write the BIOS, even without PSB enable.

RageBone

Active Member

@rootwyrm i understand what you are saying but some things don’t make sense to from your choice of words.

What Hookups do you mean that the krpa is supposed to not have?

And what do you mean with «seal» and breaking it?

you are specifically mentioning signatures previously so i think you mean something else?

Are you talking about very specific pieces of «something» or are you just generalizing?
And what is «the right board» to you?
Do you mean the Reference Boards?

ExecutableFix

Active Member

I owned a 7D12 for a while and ran it in my home system. It does NOT require a custom microcode (in fact, none of the custom SKUs do because they share the same stepping as retail parts) and it was not vendor locked. A SKU is only vendor locked if it has previously been installed in a Dell or HP system. These SKUs are not meant for HP or Dell, so there’s no factory lock applied to them.

The 7D12 only has 4 memory channels which indicates it was made for a specific board. It will still work on normal boards, but the memory has to be in the right slots, which is why you need to try to boot it with one DIMM first. My guess would be that the same applies to the 7D13.

NablaSquaredG

Well-Known Member

ExecutableFix

Active Member

RageBone

Active Member

I was told HP does it their own undisclosed «proprietary» way.
Lenovo and Dell use PSB to lock CPUs.

Again in case of a PSB Lock, it is expected that Post gets stuck at a code from 78 to 7F.
78 was observed to be the code, as far as the crystal ball states, it should be code 7D, it isn’t, don’t ask me why.

At this point in time, we simply don’t know enough and i can only hope that the OP starts delivering, for example postcodes.

If it is a new stepping compared to retail Milan, i am certain that it needs additional microcode which likely isn’t included.

If one were to have a bios meant for those CPUs, we could look further into it.

zedei

New Member

rootwyrm

Member

Actually, every ODM and OEM has the capability to use PSB fusing. And HP actually does use PSB fusing. Hell, I use PSB fusing. The difference is that HP and everyone who isn’t the giant bag of dicks that is Dell uses a different PSB method which does not lock the CPU to a specific motherboard. There’s a general outline of some of the pieces involved in the AMD public SEV API Specification under the Platform Management section.

Quoth HP: «HPE does not use the same security technique that Dell is using for a BIOS hardware root of trust. HPE does not burn, fuse, or permanently store our public key into AMD processors which ship with our products. HPE uses a unique approach to authenticate our BIOS and BMC firmware: HPE fuses our hardware – or silicon – root of trust into our own BMC silicon to ensure only authenticated firmware is executed. Thus, while we implement a hardware root of trust for our BIOS and BMC firmware, the processors that ship with our servers are not locked to our platforms.«

Translation:
HPE places the fusing on their side of the equation — the BMC — instead of burning their key into the processor and turning it into a fancy paperweight. Since the processor isn’t generally an information sensitive component anyways, so resale carries minimal to zero security risk. (BMC compromise, however, is high risk as it contains passwords, authentication, and network information even when power is removed. And can intercept a hell of a lot on a running system to say the least.)
This is why an HPE sourced CPU works in anything. HPE’s BMC confirms the AMD public key against an HPE managed root of trust. As long as the processor is genuine and hasn’t been tampered with? HPE’s cool with it. CPU side keys aren’t kosher? Board may brick. Tamper with the BMC to alter, say, just the HPE logo on the login screen? Board will brick. Board went and bricked? Take your $16000 of CPUs, move them to a new $800 board, and you’re back in business.

On the OEM/SI side, it’s about the same. Because seriously, bricking a CPU just to screw over customers is nothing but a dick move and par for the course with Dell EMC. And you can hypothetically set the CPU side PSB eFuse without locking it to a specific vendor’s specific model with a specific serial number. But it makes a LOT more sense from not only a cost but a serviceability perspective to brick the much more failure prone system planar when the ARKs don’t line up than it does to brick a CPU because of a BMC firmware flash failure. And it’s a hell of a lot cheaper too.

«Wait, what? Then why doesn’t Dell do that?»
Because Dell’s ethical standards are basically ‘anything that makes Mikey a few extra bucks might get you not fired.’ There’s a reason Intel has consistently called them the best friend money can buy. That’s exactly the kind of company they are. If they can use deliberate bricking to ‘justify’ charging you three times as much on disservice contracts because «well we have to replace the CPUs every time too»? They’ll try and find some way to make the bricked CPUs your fault at the same time.

Decode should be:

• Reset of external IDE/SATA (though I wonder if it may be inverted 0x1A which is DXE boot service)
• Begin CPU transition to normal mode
• Application processor pre-microcode
• Memory initialization failure (retry possible)
• Unrecoverable DXE failure in microcode/firmware load — should be specifically unable to load from the board ROM side
• Aaaaaaand the board tries to boot with the CPU still in real mode after an unrecoverable DXE failure. Are you serious with this Asus? Sigh.

Note that this assumes Asus didn’t completely mangle Aptio and just decide to make up all their own UEFI->80h status codes with no relation to reality. But the likelihood of that is basically nil. I presume that the system has zero display output, so that puts it into needing a BIOS with debugging PEIMs (probably don’t have space anyway, looks to be a 64Mbit) and a JTAG (no headers present) or AMI Debug.

edit: should clarify, because it’s a 2-digit and not full UEFI code, DE can only be interpreted as a ‘generalized DXE microcode/firmware load failure.’ There isn’t enough information to identify if it is IOD, CCX, or peripheral.

zedei

New Member

zedei

New Member

zedei

New Member

Since this is an endless loop, I didn’t note the starting code. Here are some codes that come before the loop:
15
C2
C8
63
21
dE
Ad
A1
34
02
50
dE etc. etc.

So it seems the last code of the cycle is 50: Memory initialization error and then it begins again with dE (whatever that means).
I have tried with different memory sticks (that work fine when the 7742 CPU is installed).

RageBone

Active Member

As far as i can see, the codes asus provides are bonkers.

Experience for instance shows that without any ram installed, you get stuck at postcode 10 and nothing else.
Expected would be something in the 50s for memory issues, likely 53 or 55 from what i remember from AMI on x99.

Additionally, postcodes on Epyc seem to not be ordered «deterministic», i’d say.
On my H11ssl, code 55 returns multiple times.
According to my crystal ball, it stands for an SMBus Transaction collision.
The crystal ball also seems to mainly contain error codes, which seems weird to me but i have not found anything better yet.

Postcode 15 seems to appear instead of code 10 when you have any memory installed.
till and including code 50, everything looks familiar to me.
I will take a closes look at my board tomorrow.
Crystal Ball interprets 50 as a failure to claim ownership of SMB.
Additionally, the previous 02 can be interpreted as a generic memory error.

What i can say so far is that you don’t appear to have the usual CPU incompatibility issues that we have experienced with for instance ES CPUs of A0 steppings.
Such issues would likely manifest in D0 or D1
Your system also does not quickly jump and stay at 02 which could be serious PSP-BL failure.
So i’m sorry that this isn’t more then a guessing game at this point.

Источник

Docker error pulling image configuration #2167

Expected behavior

The image should be successfully pulled.

Actual behavior

mac_mini4:abcd mac-mini-4$ docker pull node
Using default tag: latest
latest: Pulling from library/node
85b1f47fba49: Pulling fs layer
5409e9a7fa9e: Pulling fs layer
661393707836: Pulling fs layer
1bb98c08d57e: Waiting
f957ac1b6e47: Waiting
166b7c18b759: Waiting
02cb65a8d0f6: Waiting
9052b6207e12: Waiting
error pulling image configuration: Get https://dseasb33srnrn.cloudfront.net/registry-v2/docker/registry/v2/blobs/sha256/ba/badd967af535567f92c04665ccbf4ccf63f58960e38a43f611b1b19ca3a713e7/data?Expires=1508747774&Signature=itXcTt8IGLoxsACN4OJMgmRgUfrEOE3i9J6g8ooOV9AANUAQgXnJb6Rme48DxjzCLTWnKKLQqASNNa2fNuxCCy9X6qVSBZGazxNktOwWe70fjIqR5ojTQG5GtaZUsoL0k6we

gPQXKMIBdZfGu33YeMPD7CymCow4Ww4dwwvPgo_&Key-Pair-Id=APKAJECH5M7VWIS5YZ6Q: dial tcp 192.168.65.1:443: getsockopt: connection refused
mac_mini4:abcd mac-mini-4$

Occurs with other images too..

Information

• OS : MacOS Seirra 10.12.6
• Docker Version 17.09.0-ce-mac35 (19611) Channel: stable a98b7c1b7c
• When I try to pull any images I get the above Behaviour
• What I have tried?
  a) Added dns under daemon tab of docker . «dns» : [ «8.8.8.8», «8.8.4.4» ]
  b) Added DNS Servers «8.8.8.8» and «8.8.4.4» under Network Preferences -> Advanced -> DNS tab
• Images: https://ibb.co/n2zCVm and https://ibb.co/g6HcwR

I checked some other posts and saw some users facing this similar issue. But they could resolve it just by setting up the DNS servers to 8.8.8.8, which unfortunately not working for me.
Can anyone please help?

What could be possibly wrong here in my steps? PS*: new to Docker here.
If you think I have not provided enough information, please let me know. I will update accordingly.

The text was updated successfully, but these errors were encountered:

Источник

docker pull failed with error pulling image configuration and X.509 cert #23356

Steps to reproduce the issue:
docker pull cirros

docker pull busybox

The text was updated successfully, but these errors were encountered:

I have a hint for you: possibly you are working under proxy(enterprise environment).
I hit your problem when I worked in corp, but no problem in home.

This is resolved. Steps taken are

• Obtain a crt from the https://dseasb33srnrn.cloudfront.net with openssl
• Copy the crt to /etc/share/ca-certificates (Ubuntu)
• Restart docker

I am facing the same issue, can u please let us know what exactly you have done to solve it .

thanks @jianghaitao fixed for me! Debian 8 Docker 1.12, Docker-compose 1.8.0

@jianghaitao
Could you help to provide the command for how to get the crt from the https://dseasb33srnrn.cloudfront.net with openssl?

@davesliu openssl s_client -connect dseasb33srnrn.cloudfront.net:443

Hello, thanks a lot, I was facing the same issue with docker and finally solved it with your help.
Full command list used is here (note this is for Ubuntu 16.04)

$ proxytunnel -p proxyhost:8080 -P proxyuser:proxypwd -d dseasb33srnrn.cloudfront.net:443 -a 7000 —verbose & echo -n | openssl s_client -connect localhost:7000 | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > ./cloudfront.crt

proxyhost = IP for your corporation proxy server
proxyuser = user used to connect thru proxy
proxypwd = proxyuser password

This command creates a proxytunnel with clean credentials and creates a daemon on port 7000 in your localhost.
After that you run the openssl s_client command to connect on localhost:7000 and finally extract certificate data to a .crt file in your

Finally copy .crt file to certificates store
$ sudo cp cloudfront.crt /usr/local/share/ca-certificates/

And update certificates
$ sudo update-ca-certificates

Источник

error pulling image configuration #27911

I have a fresh new win2K16 with containers enabled as well as hyper-v is turned on. Whenever I tru to issue the tes cmmand as indicated to test (firewal disabled, no proxy. )
docker pull microsoft/windowsservercore:10.0.14393.321
I get
error pulling image configuration: Get https://dseasb33srnrn.cloudfront.net/registry-v2/docker/registry/v2/blobs/sha256/
93/93a9c37b36d03323f7b8fdd7f0302f7e487a0e8b31ccd8e689c40a404d2f1ea9/data?Expires=1477932342&Signature=N2NdygkaXM6YfVCvXm
TpzD1vDn6k-P50sruyKW21-iVgVdMNwwLUGS0vN2E2ocHrBXowghRgtWX214AcQ5TWo7AqfufXTfsMU9s3TLQV8ed9-dFAXjC5QMImgTmC8Ef0NsQ26s6E
tgiWxvm6XJqV8txihfUO46BOuN-n3Lyfs_&Key-Pair-Id=APKAJECH5M7VWIS5YZ6Q: dial tcp 52.85.221.56:443: i/o timeout
Thanks

error pulling image configuration

Steps to reproduce the issue:

1. docker pull microsoft/windowsservercore:10.0.14393.321

error pulling image configuration: Get https://dseasb33srnrn.cloudfront.net/registry-v2/docker/registry/v2/blobs/sha256/
93/93a9c37b36d03323f7b8fdd7f0302f7e487a0e8b31ccd8e689c40a404d2f1ea9/data?Expires=1477932342&Signature=N2NdygkaXM6YfVCvXm
TpzD1vDn6k-P50sruyKW21-iVgVdMNwwLUGS0vN2E2ocHrBXowghRgtWX214AcQ5TWo7AqfufXTfsMU9s3TLQV8ed9-dFAXjC5QMImgTmC8Ef0NsQ26s6E
tgiWxvm6XJqV8txihfUO46BOuN-n3Lyfs_&Key-Pair-Id=APKAJECH5M7VWIS5YZ6Q: dial tcp 52.85.221.56:443: i/o timeout

I expexted a container to ve created

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version :

Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 1.12.2-cs2-ws-beta
Storage Driver: windowsfilter
Windows:
Logging Driver: json-file
Plugins:
Volume: local
Network: nat null overlay
Swarm: inactive
Default Isolation: process
Kernel Version: 10.0 14393 (14393.351.amd64fre.rs1_release_inmarket.161014-1755)
Operating System: Windows Server 2016 Standard
OSType: windows
Architecture: x86_64
CPUs: 1
Total Memory: 2 GiB
Name: ProdWebServer
ID: EAFQ:W3YV:HIXM:GWRN:WFJK:6TCQ:HEKP:AX6O:CESU:BQ2G:QLEP:OL3O
Docker Root Dir: C:ProgramDatadocker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false«`

Additional environment details (AWS, VirtualBox, physical, etc.):

The text was updated successfully, but these errors were encountered:

Источник

Figure 48 Password Manager Page

NOTE:

There is no default password. Passwords must be at least 8 characters but no more than

64 characters long. Passwords are case sensitive. There is no default password. Passwords are

up to 64 alpha-numeric and special characters

(~,`,!,@,#,$,%,^,&,*,(,),-,_,+,=,{,[,},],|,,<,,,>,.,?,/»,’ and space) in length, and are case sensitive.

The password needs to be entered again to confirm new password. In case of a forgotten password,

manually reset the switch to its factory defaults.

Enter the old password and the new password twice, and click Apply. At the next log on, use the

new password.

Use the Dual Image Configuration page to name and change the next bootup image. The Dual

Image Configuration allows activating either of the stored images: Image1 or Image2. When one

image is activated, the other image serves as a backup; if Image1 either fails or does not boot,

then the other image can be activated.

To display the Dual Image Configuration page, click Maintenance > Dual Image Configuration.

Figure 49 Dual Image Configuration Page

Table 37 Dual Image Configuration Fields

Field

Image Name

Active Image

Image Description

Image Version

Click Activate to activate the selected image selected in the Image Name field. Be sure to

configure the Image Description field to the version of the image loaded so that users can

easily distinguish between the images.

Click Apply to apply a description to the image selected in the Image Name field.

Click Delete to delete the image selected in the Image Name field.

Description

Select the image you want to perform an action on. You can activate the selected image,

delete it, or configure a description of it. Options are Image1 and Image2.

The currently active image.

Specify a description of the image selected in the Image Name field.

The software version associated with the active image.

Dual Image Configuration

65

Expected behavior

The image should be successfully pulled.

Actual behavior

mac_mini4:abcd mac-mini-4$ docker pull node
Using default tag: latest
latest: Pulling from library/node
85b1f47fba49: Pulling fs layer
5409e9a7fa9e: Pulling fs layer
661393707836: Pulling fs layer
1bb98c08d57e: Waiting
f957ac1b6e47: Waiting
166b7c18b759: Waiting
02cb65a8d0f6: Waiting
9052b6207e12: Waiting
error pulling image configuration: Get https://dseasb33srnrn.cloudfront.net/registry-v2/docker/registry/v2/blobs/sha256/ba/badd967af535567f92c04665ccbf4ccf63f58960e38a43f611b1b19ca3a713e7/data?Expires=1508747774&Signature=itXcTt8IGLoxsACN4OJMgmRgUfrEOE3i9J6g8ooOV9AANUAQgXnJb6Rme48DxjzCLTWnKKLQqASNNa2fNuxCCy9X6qVSBZGazxNktOwWe70fjIqR5ojTQG5GtaZUsoL0k6we~gPQXKMIBdZfGu33YeMPD7CymCow4Ww4dwwvPgo_&Key-Pair-Id=APKAJECH5M7VWIS5YZ6Q: dial tcp 192.168.65.1:443: getsockopt: connection refused
mac_mini4:abcd mac-mini-4$

Occurs with other images too..

Information

• OS : MacOS Seirra 10.12.6
• Docker Version 17.09.0-ce-mac35 (19611) Channel: stable a98b7c1b7c
• When I try to pull any images I get the above Behaviour
• What I have tried?
  a) Added dns under daemon tab of docker . "dns" : [ "8.8.8.8", "8.8.4.4" ]
  b) Added DNS Servers "8.8.8.8" and "8.8.4.4" under Network Preferences -> Advanced -> DNS tab
• Images: https://ibb.co/n2zCVm and https://ibb.co/g6HcwR

I checked some other posts and saw some users facing this similar issue. But they could resolve it just by setting up the DNS servers to 8.8.8.8, which unfortunately not working for me.
Can anyone please help?

What could be possibly wrong here in my steps? PS*: new to Docker here.
If you think I have not provided enough information, please let me know. I will update accordingly.

Hi, I am pretty new to using OpenWRT, and on my current project I am needing to modify the included packages/drivers so that I can enable WiFi (I am building openWRT images which run on our Onion Omega2+’s). On this current configuration, wireless support was originally excluded from the build so there are none of the wireless tools, drivers etc.

First, what would be the best approach for modifying the original config? When I try to include my WiFi drivers / other packages and build, I get the following error:

«WARNING: your configuration is out of sync. Please run make menuconfig, oldconfig or defconfig!»

I’m not quite too sure what this means, as I can only find a couple of posts online regarding this error. I even tried to start a new config, and simply add everything that was added in the original, I still get the same error. We have tried running oldconfig/defconfig but nothing seems to be working, maybe I am overlooking something here, or making a mistake?

If anyone has seen / resolved this issue before, I’d really appreciate your help! We’re getting held back by this at the moment. Thanks in advance!