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

ssh fwup vs. nerves_hub fwup race condition? #36

Open
dognotdog opened this issue Nov 29, 2021 · 0 comments · May be fixed by #48
Open

ssh fwup vs. nerves_hub fwup race condition? #36

dognotdog opened this issue Nov 29, 2021 · 0 comments · May be fixed by #48

Comments

@dognotdog
Copy link

Environment

Pkg: nerves_toolchain_armv6_nerves_linux_gnueabihf
Vsn: 1.4.3
Type: toolchain
BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

Pkg: mobile_rpi0
Vsn: 1.17.0
Type: system
BuildRunner: {Nerves.Artifact.BuildRunners.Docker, [make_args: ["source", "all"]]}

Pkg: nerves_system_br
Vsn: 1.17.0
Type: system_platform
BuildRunner: {nil, []}

Pkg: nerves_toolchain_ctng
Vsn: 1.8.4
Type: toolchain_platform
BuildRunner: {nil, []}

Current behavior

I've been wondering how I corrupted an SD card before, and now I found at least one way: with an active deployment running and fwup in progress, but also local performing a fwup via ssh, it looks like the two update processes simultaneously wrote to the "unused" partition, resulting in complete garbage.

As an aside, is the on-disk cecksum not verified on firmware updates?

On rpi0, this lands in an infinite reboot cycle.

Expected behavior

Noticing corruption before reboot.

Companion issue on nerves_hub_link: nerves-hub/nerves_hub_link#98

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

Successfully merging a pull request may close this issue.

1 participant