Hi,

just some info on the things I've experienced the last days playing with the example image for the iot 2050.

First, using Linux Mint, I have no problem building the example image as explained on github.com/siemens/meta-iot2050.

However once the image is copied to a sd card or usb stick, I'm only able to let it boot 1 time.  Once I press the reset button, powercycle or restart the system, the image doesn't boot anymore.

I've connected a monitor to the displayport and the only thing that I see is 2 Linux Tux's and a blinking cursor.  The first time I've boot the system, after a while a normal login prompt appears, but now after restarting this doesn't happen anymore.  Result an incomplete boot.

I realized that the kernel boot log, is not displayed on my monitor, so I've connected a ftdi TTL to usb adapter to the debug port.  Now i can see the complete bootlog. (see attachement)

As you can see the booting stops once the kernel tries to load the rootfs.  

Waiting for root device PARTUUID=20c5e49d-f8f5-4e3c-9427-7379c6a97962...

The quickest way to create a workaround for this is to create a new boot/boot.scr file.

howto:

copy the "boot.scr" content, minus the weird characters at the beginning of the file, to "boot.txt".

edit boot.txt with root=/dev/sda1

create a new boot.scr using the following command

mkimage -A arm -O linux -T script -C none -n "My Boot" -d boot.txt boot.scr

mkimage is part of the u-boot-tools package (Debian)

I hope this is helpful for people experiencing the same problem

regards,

Kris

It might be, if you did a hard reset by pressing the button at the wrong time, that you left the image in an inconsistent state.

The image is "individualized" on first boot, receiving among other things a new UUID for its rootfs. That is updated in two places, and if the reset left one place uncommited to SD card, you would see such an error. Following that theory, all should be fine if you use a fresh image again and trigger the first reboot via a regular "reboot" command on the device.

We may reduce the risk of such a corruption in the future by enforcing a "sync" after that individualization step - noted. But hard resets always bear the risk of unrecoverable corruptions.

Oh, and your workaround can be achieved even easier:

# update-u-boot-script
# sync