lawik
I built the nerves container repo for rpi4.
Building the firmware went fine. The target device is a CM4 that is running Nerves, happily.
Could it be a partition resize or something?
lawik@monolith:~/nervescloud/contain$ ./upload.sh nerves-7170.local
Path: ./_build/nerves_containers_rpi4_dev/nerves/images/contain.fw
Product: contain 0.1.0
UUID: 5b76be06-ce28-55b8-b55f-d71226ae873f
Platform: rpi4
Uploading to nerves-7170.local...
fwup: Please check the media being upgraded. It doesn't look like either the A or B partitions are active.
I don’t know how to dig in and do what it is asking me to do. Check the media 
Where Next?
Trending in Questions
Other Trending Topics
Latest Nerves Threads
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
My first step would be checking
nerves_fw_activeinNerves.Runtime.KVas well as consultingfdiskto see if there are partitions as expected on the device.fhunleth
The
rpi4fwup.configstill uses partition offsets to determine whether it’s running off the A or B partition. See this line for requiring that the partition offset be the B partition’s offset for a partition A update to happen.One way to fix this is to use something else to determine which partition is active. For example, you could delete that line and add this instead to check the U-Boot environment variable that
Nerves.Runtime.KVsees (also make the corresponding change for upgrading the a partition):However, before you do this, make sure that your new A or B partitions don’t overlap with the old ones. If they do, you could be overwriting the partition that you’re running off of to perform the update.
It’s pretty tricky to deploy firmware updates that enlarge root file systems. Hopefully you don’t have to do this on remote devices. If I had to do this on a lot of devices, I’d looks to see how much can be done with the padding between filesystems. If the partitions are back-to-back with no room to grow (like the default rpi4 ones), then I’d look into ways to avoid growing them. If there were no way, then I think that’s I’d create a firmware with an initramfs that knows how to move everything. I’d use an initramfs so that Linux won’t have mounted the root or data partitions that would be moved.
Hope that helps.
lawik
Thanks, that clarifies things. I don’t need to do this for anything important. But figured this was not well known so might as well ask