2

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:

#!/bin/sh
mv /sd/newImage/Image /sd/
mv /sd/newImage/Image.bak /sd/newImage/Image
reboot

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.

#!/bin/sh
mv /sd/newImage/Image /sd/
cp /sd/newImage/Image.bak /sd/newImage/Image
reboot

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.

sdepot
  • 21
  • 1
  • Does this depend on the cumulative size of `Image` + `Image.bak`? – kubanczyk May 08 '18 at 18:34
  • Both `Image` and `Image.bak` are approximately 16MB – sdepot May 08 '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 08 '18 at 20:22
  • Could the writes have not flushed to storage before the reboot? Try `sync`. – Michael Hampton May 08 '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 09 '18 at 12:46
  • But running cp seems to complete successfully? Can you use the file after cp returns? Can you check its hash to make sure it's actually copied properly? How are you for free space on the sdcard? – RobbieCrash May 09 '18 at 14:12
  • @RobbieCrash yeah the cp command takes a moment when I do it manually, but appears to complete fully. When you say checking the hash do you just mean `ls -l` and make sure they are the same size? And I have plenty of room on the SD Card that should be no issue – sdepot May 09 '18 at 14:26
  • Check with md5sum or sha256sum to make sure the contents are correct, not just the file size. https://linux.die.net/man/1/md5sum https://linux.die.net/man/1/sha256sum – RobbieCrash May 09 '18 at 15:34
  • @RobbieCrash Ok I performed md5sum on Image.bak and Image after performing a `cp` command as described above and the numbers they return are identical. – sdepot May 09 '18 at 15:53

0 Answers0