I have compiled C code running as a binary on an ARM. The ARM boots Linux from an SD Card using an old Image that was generated using buildroot. Within the C code I call a shell script that moves the new Image I want to boot with from a sub-directory on the SD Card onto the top level of the SD Card (overwriting the old Image), and then use the backup Image.bak to restore the Image in the sub-directory again, in case I run the script again:

mv /sd/newImage/Image /sd/
mv /sd/newImage/Image.bak /sd/newImage/Image

The reboot works properly in this case (Putty disconnects -> the LED on the board I'm using goes Red then Green -> I can reconnect through Putty), although the second mv command does not - it removes the Image.bak but does not create an Image - but that is not the purpose of this post, really.

When I try to modify the script so that the Image.bak does actually restore the Image by using the cp command, then the reboot does not work properly.

mv /sd/newImage/Image /sd/
cp /sd/newImage/Image.bak /sd/newImage/Image

What happens is the Putty terminal I was using disconnects, but the LED on the board that goes red when signaling it is rebooting just stays green and the only way to re-establish a connection through Putty is to manually power cycle the board via the power switch. So it seems that there is something weird happening when I call the cp command in the shell script. I have tried umount /sd and using sync before the reboot thinking that maybe there was syncing issues, but that didn't work either.

I am logged in as root, and the permissions should not be an issue with any of this.

  • Does this depend on the cumulative size of Image + Image.bak? – kubanczyk May 8 '18 at 18:34
  • Both Image and Image.bak are approximately 16MB – sdepot May 8 '18 at 18:43
  • If you manually run the commands, or the script, under the same user context that the compiled binary runs under, does everything work properly? – RobbieCrash May 8 '18 at 20:22
  • Could the writes have not flushed to storage before the reboot? Try sync. – Michael Hampton May 8 '18 at 20:35
  • @RobbieCrash If I run (individually) the commands from the script above that does NOT contain the cp then yes I believe it was working fine, including the mv command actually working. When I manually/individually run the commands from the script above that contains the cp then no it doesn't work and behaves the same way as if I had the compiled binary run the script. @MichaelHampton yes I tried the sync command after the cp command and before the reboot and that did not work. – sdepot May 9 '18 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.