# Apt-get update/upgrade bricks Linux

**URL:** <https://forum.ubiquityrobotics.com/t/apt-get-update-upgrade-bricks-linux/477>\
**Category:** Uncategorized\
**Created:** [March 3, 2020, 11:36pm UTC](https://forum.ubiquityrobotics.com/t/apt-get-update-upgrade-bricks-linux/477 "2020-03-03T23:36:51Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![FolsomMike](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/folsommike/32/229_2.png) [@FolsomMike](https://forum.ubiquityrobotics.com/u/FolsomMike)\
**Post date:** [March 3, 2020, 11:36pm UTC](https://forum.ubiquityrobotics.com/t/apt-get-update-upgrade-bricks-linux/477/1 "2020-03-03T23:36:52Z")

</div>

I have flashed:

```
  2019-06-19-ubiquity-xenial-lxde-raspberry-pi.img.xz'

```

as the latest image can’t be loaded by Etcher.

When I perform: apt-get update / apt-get upgrade and reboot, Ubuntu will not start up.

I get a color swatch on the screen and a blinking green light on the Pi. Nothing happens beyond that.

Update 1:

Even though the Ubiquity site mentions that Linux will resize the file system on first boot after flashing, I performed same using raspi-config. This time the upgrade seemed to do a LOT more stuff and took a lot longer…but it DID reboot.

---

<div class="post-metadata">

**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\
**Post date:** [March 4, 2020, 8:50am UTC](https://forum.ubiquityrobotics.com/t/apt-get-update-upgrade-bricks-linux/477/2 "2020-03-04T08:50:34Z")

</div>

2019-06-19-ubiquity-xenial-lxde-raspberry-pi.img.xz after uncompressed yields an .img file of  
2019-06-19-ubiquity-xenial-lxde-raspberry-pi.img of size 4.882 GB and change.

I always start with 16GB flash card and have found that 8GB only leads to grief later on down the road.  
we ship with 16Gig Sd cards for example.

So that we better understand your equipment I again ask for exact Raspberry Pi cpu you are using and now will also ask if this is in a Magni product or you are using the image for your own project.

I have used this exact image on at least 4 private robotic and IoT projects although on those I rarely do the apt upgrade so this may be specific to the version of your raspberry pi or SD micro card size.

Thanks,  
Mark

---

<div class="post-metadata">

**Author:** ![FolsomMike](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/folsommike/32/229_2.png) [@FolsomMike](https://forum.ubiquityrobotics.com/u/FolsomMike)\
**Post date:** [March 4, 2020, 5:17pm UTC](https://forum.ubiquityrobotics.com/t/apt-get-update-upgrade-bricks-linux/477/3 "2020-03-04T17:17:29Z")

</div>

I am using 16 GB card identical to one supplied with Magni robot. I have a Magni robot. Using Raspberry Pi 3 B+, but not the original one…it seemed to have developed issues communicating with the MCB.

Is there something different about the Pi 3 B+ supplied with the Magni?

---

<div class="post-metadata">

**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\
**Post date:** [March 4, 2020, 9:56pm UTC](https://forum.ubiquityrobotics.com/t/apt-get-update-upgrade-bricks-linux/477/4 "2020-03-04T21:56:03Z")

</div>

THIS ENTRY HAS BEEN MOVED TO: [Rosrun ubiquity\_motor upgrade\_firmware.py FAILS](https://frm.ubiquityrobotics.com/t/rosrun-ubiquity-motor-upgrade-firmware-py-fails/478/3)

The entry was about serial com and this thread is about possible linux system ‘bricked’ issue.

---

<div class="post-metadata">

**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\
**Post date:** [March 5, 2020, 4:50am UTC](https://forum.ubiquityrobotics.com/t/apt-get-update-upgrade-bricks-linux/477/5 "2020-03-05T04:50:15Z")

</div>

If possible could you return back to us all of the text on the main large metal topped chip in center top of the pi? In this way if this happens to anyone else we can correlate the issue to a specific daycode. We do not at this time know of differences between Raspberry Pi 3 Model B+ units that would explain this failure. We do not ship a special version of the Pi 3 Model B+  
Thank You  
mark

---

<div class="post-metadata">

**Author:** ![mjstn2011](https://forum.ubiquityrobotics.com/user_avatar/forum.ubiquityrobotics.com/mjstn2011/32/30_2.png) [@mjstn2011](https://forum.ubiquityrobotics.com/u/mjstn2011)\
**Post date:** [March 5, 2020, 6:41am UTC](https://forum.ubiquityrobotics.com/t/apt-get-update-upgrade-bricks-linux/477/6 "2020-03-05T06:41:45Z")

</div>

Not able to recreate the bricking fault described. There may be something specific to your components that I do not have.

using a Pi 3 Model B+ a fresh image same as you used was burned to a 16GB MicroSd and on bootup that image expanded and the Pi was able to control a magni.

Then the ‘apt update’ followed by an ‘apt upgrade’ was performed which takes 20 minutes or so to complete.

After bootup serial communications was ok and I was able to query topic /battery\_state as well as run ‘twist’ to control the motors as expected.

It is unclear what led to the problem and it must be hardware specific to your setup. We can discuss offline by contacting [support@ubiquityrobotics.com](mailto:support@ubiquityrobotics.com)  
I feel in another thread we have zeroed in on a serial issue but this corruption issue I am unable to explain.
