Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Example Image not Bootable #169

Open
cybran01 opened this issue May 16, 2021 · 8 comments
Open

Example Image not Bootable #169

cybran01 opened this issue May 16, 2021 · 8 comments

Comments

@cybran01
Copy link

cybran01 commented May 16, 2021

Hello,

the image file iot2000-example-image-iot2000.wic does not seem to boot for me.
I built the image using kas build meta-iot2000/kas-example.yml in Ubuntu 20.04.1 LTS. There were a few warnings like
uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libdl.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libubacktrace.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libresolv.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libc.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination uclibc: /opt/uclibc/lib/ld-uClibc.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination uclibc: /opt/uclibc/lib/ld-uClibc.so.0 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libpthread.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libuargp.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libthread_db.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libcrypt.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libutil.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/librt.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libnsl.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] uclibc-1.0.12+gitAUTOINC+003b266cbe: uclibc: /opt/uclibc/lib/libm.so.1 is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]
however the build passed and the image was generated.

My build config was

Build Configuration:

BB_VERSION = "1.46.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "i586-poky-linux"
MACHINE = "iot2000"
DISTRO = "poky-iot2000"
DISTRO_VERSION = "V3.1.1"
TUNE_FEATURES = "m32 i586-nlp"
TARGET_FPU = ""
meta-efibootguard = "HEAD:e13f038bb362a6c086be50359f1bf31cf770e151"
meta-iot2000-bsp
meta-iot2000-example = "master:59db9e97451661920365d771605cec9bda8b9179"
meta-networking
meta-oe
meta-python = "HEAD:cc6fc6b1641ab23089c1e3bba11e0c6394f0867c"
meta-swupdate = "HEAD:1886350dacb63d931b3d1a3809b27795b0a5c306"
meta
meta-poky
meta-yocto-bsp = "HEAD:febbe2944c0c4a04b85fa98fdc261186115954d8"

No matter how i flashed the image onto the sd 16GB SD card, when slotting it into my IOT2040, the PWR and USER LED's would flicker and nothing else. The SD LED would not turn on. This leads me to believe it did not recognize the card as being bootable.

I have also tried flashing the image to USB stick and booting from bios, however the stick is also not detected as bootable.
Any help is appreciated.

@jan-kiszka
Copy link
Collaborator

Does the very same card work when flashing the pre-built V2.6.1 image onto it? If yes, you could also try building inside the reference environment using kas-container (thus docker) instead.

Those warnings are harmless - though I thought we suppressed them.

@cybran01
Copy link
Author

I do not have access to the pre-built V2.6.1 image. I have now set up the reference environment and built with ./kas-docker build meta-iot2000/kas-example.yml.
Then i flashed the image again (oddly though, the image file was in build/tmp/deploy/images/iot2000/ and not located directly in the meta-iot2000 directory as specified in the Readme), with the same results.

@jan-kiszka
Copy link
Collaborator

See https://support.industry.siemens.com/cs/document/109741799/simatic-iot2020-iot2040-sd-card-example-image?dti=0&pnid=24431&lc=en-WW for the released image (the new one is on its way there as well).

The README states that the image is under build/tmp/deploy/images/iot2000/iot2000-example-image-iot2000.wic (https://github.com/siemens/meta-iot2000#booting-the-image-from-sd-card).

@cybran01
Copy link
Author

cybran01 commented May 16, 2021

I am referring to

If you built the image in Docker, the .wic file will be located directly in the meta-iot2000 directory.

in the section "Booting the Image from SD card".
As for the example image, it seems that i need an account that still needs to be verified.

@jan-kiszka
Copy link
Collaborator

Ah, indeed - that statement is legacy and should be dropped.

@cybran01
Copy link
Author

I now have the provided example. I used Win32DiskImager to flash it to the sd card. This gave the same results as previously, as did flashing using disk dump in linux.
I think this means that my IOT is broken, particularly because the SD Led did not once light up during all attempts.

@jan-kiszka
Copy link
Collaborator

Did it work before? Did anything change to cause the current situation? Maybe you can get your hands on a second box to cross-check this.

@cybran01
Copy link
Author

cybran01 commented May 18, 2021

It worked until a power outage. This corrupted the previous SD card, i managed to recover the most important files though. Unfortunately, i won't be able to get my hands on a second box any time soon :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants