search

theypsilon / Update_All_MiSTer

All-in-one script for updating your MiSTer
GNU General Public License v3.0
664 stars 28 forks source link

Possible corruption when running update.sh from update_all.sh #66

Closed starquake closed 3 years ago

starquake commented 3 years ago

I've seen claims on the MiSTer FPGA that this script can cause corruption if this script runs update.sh and the OS is updated. And that you have to check and run update.sh instead of update_all.sh if there is an update.

Example: https://misterfpga.org/viewtopic.php?p=32387#p32387

Is that true?

Does update_all write to paths that are contained in the mounted linux image?

Does update_all work in a way that the reboot is postponed and there could potentially be writes to that linux image?

theypsilon commented 3 years ago

The short answer is no, it's most probably not true.

That being said, I understand your concern, cause I've heard people saying this in a number of places. To address this concern, I've just changed the script, and it now updates Linux at the very end, right before rebooting.

According to my understanding, the problem that some people rarely experience won't be solved by updating linux right before reboot as update_all does now, nor by running the official update script in isolation. In other words, was not a problem unique to previous versions of update_all, and the reason why previous update_all usage was actually fine, is because no services nor modules were being reloaded during the scripts that were running after a Linux update. They were just doing pretty light tasks such as copying files and such, which should be totally fine. Keep in mind that all the relevant parts of the system are kept alive in the RAM after an update. And the reboot was happening by default at the end of update_all anyways. The problem is more likely to be the result of corrupted files, maybe because corrupted downloads or because something went wrong in the physical layer. Time will tell.

starquake commented 3 years ago

Amazing! Thanks a lot!

durkada commented 3 years ago

Just as an FYI, I had this problem happen to me on September 1st. Finally gotten around to fixing it.

Not much of a fix -- simply had a secondary MiSTer I hadn't updated. Copied over the linux dir from the older and it would boot again.

Not much to see in the logs generated by the update script, and, of course, /var/log is in tmpfs... So, its going to be a mystery. If you do care, I can 7z the old (broken) linux dir if you are curious.

durkada commented 3 years ago

Ran the updater and it broke again. One thing I noticed is that it downloaded and extracted the release_20210906.7z twice.

Once near the beginning and again as the final act.