Could not boot into RPi3 with kernel 4.4.0-1038-raspi2

[Taihsiang Ho]

This issue was reported in this mailing list thread first https://lists.ubuntu.com/archives/snapcraft/2016-December/002138.html

Hardware: RPi3
Image: http://www.finnie.org/software/raspberrypi/ubuntu-rpi3/ubuntu-16.04-preinstalled-server-armhf+raspi3.img.xz

[Steps to Reproduce]
1. Install the image in an SD card. Use it to boot into the system.
2. Issue the command "sudo apt-get update; sudo apt-get install linux-image-4.4.0-1038-raspi2 linux-headers-4.4.0-1038-raspi2 linux-raspi2-headers-4.4.0-1038 -y"
3. Reboot

[Expected Result]
Boot into the system with kernel 4.4.0-1038-raspi2

[Actual Result]
The system stop at the booting session with the message 'Starting kernel...' and never goes to the login session.

[Additional Info]

4.4.0-1029-raspi2 and 4.4.0-1034-raspi2 were used as the forementioned apt installation steps. They work well. They could go to the login session and ready for use.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Anthony Somerset (anthonysomerset)]

i note in removing these problem packages and downgrading to 1034 that there appears to be different subversions of the 1038 build

root@piserver2:~# apt-get purge linux-image-4.4.0-1038-raspi2 linux-headers-4.4.0-1038-raspi2 linux-raspi2-headers-4.4.0-1038
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  linux-headers-4.4.0-1038-raspi2* linux-headers-raspi2* linux-image-4.4.0-1038-raspi2* linux-image-raspi2* linux-raspi2* linux-raspi2-headers-4.4.0-1038*
0 upgraded, 0 newly installed, 6 to remove and 0 not upgraded.
After this operation, 182 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 95924 files and directories currently installed.)
Removing linux-raspi2 (4.4.0.1038.37) ...
Removing linux-headers-raspi2 (4.4.0.1038.37) ...
Removing linux-headers-4.4.0-1038-raspi2 (4.4.0-1038.45) ...
Removing linux-image-raspi2 (4.4.0.1038.37) ...
Removing linux-image-4.4.0-1038-raspi2 (4.4.0-1038.45) ...

where as the 1034 build the sub versions all match for the relevant packages: 4.4.0-1034.41

[Kyle Nitzsche (knitzsche)]

Any progress on this? I hit the same issue ("Starting kernel" then nothing) when trying to boot a client image on the pi3. Cheers.

[Simon Davis (davis-decent)]

The same here. Installed, upgraded (not a quick process), configured during the update, rebooted, system lost. Hangs on "Starting kernel".

Completely breaking a working system via its own update process is a critical bug, the importance level should be raised.

[Joel Abrahams (abrahaja)]

I'm having the same issue with a pi3. This started right before Christmas for me.

[Simon Davis (davis-decent)]

PI3 here too.

[Anthony Somerset (anthonysomerset)]

for those that are are in the unbeatable state - the way to recover without data loss pending fixed kernel

either mount the ubuntu raspberry pi image or write it to another SD card, copy the files from the small boot partition (i did all to be safe) e.g. boot.scr vmlinuz etc to a folder on your machine or better still to the sd card of the failing install and overwrite the original files (take a backup first) - this will allow you to reboot into the older kernel and to properly cleanup the 1038 version until its fixed

[Anthony Somerset (anthonysomerset)]

By image i mean the one available here: https://wiki.ubuntu.com/ARM/RaspberryPi

[Simon Davis (davis-decent)]

I did not have to issue apt install linux-*. In my case, apt update && apt dist-upgrade was enough to break the system as a new kernel had been installed automatically. Some people reported that apt update followed with apt upgrade break it too. This makes a big difference as the impact of the bug will be much higher in the near future.

It is a nasty bug when you break the system in the process of taking care of it using distribution's fundamental tools. Moreover, if you are successful hot-fixing it, the system cannot be subjected to updates / upgrades since then.

Does anybody know of a better fix than copying the backed up files over the new ones?

[Tianon Gravi (tianon)]

I got the breaking-update automatically via unattended-upgrades -- no human intervention of any kind. Simply rebooted the RPi3 after the holidays and it failed to come back up.

To fix it, I used "qemu-user-static"'s ARM emulation to get a chroot into the SD card's system on my laptop, and then I did "apt-get purge linux-image-4.4.0-1038-raspi2 linux-headers-4.4.0-1038-raspi2 linux-raspi2-headers-4.4.0-1038" so that it'd force the older kernel to be the latest (make sure you do in fact have the older kernel package installed -- "dpkg -l | grep linux-image").

That also purged the "linux-image-raspi2" metapackage, so I'm not likely to get any further automatic kernel updates (which really is a bad thing, given that they're likely to contain security fixes), but until this is fixed, I'm not willing to risk it (need the box to be up and running more urgently).

[Joachim Marthinsen Giæver (giaever-online)]

Same with to kernel «1040» as well, I upgraded through «dist-upgrade» today (11. january 2016). Tried to roll back by mounting the sd-card and chroot (sudo proot -q qemu-arm -S /path/to/fs), then:

# ls /boot/
System.map-4.4.0-1009-raspi2 initrd.img
System.map-4.4.0-1040-raspi2 initrd.img-4.4.0-1009-raspi2
abi-4.4.0-1009-raspi2 initrd.img-4.4.0-1040-raspi2
abi-4.4.0-1040-raspi2 initrd.img.old
config-4.4.0-1009-raspi2 vmlinuz
config-4.4.0-1040-raspi2 vmlinuz-4.4.0-1009-raspi2
firmware vmlinuz-4.4.0-1040-raspi2
grub vmlinuz.old
# sudo apt-get purge linux-*-4.4.0-1040-raspi2
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'linux-tools-4.4.0-1040-raspi2' for glob 'linux-*-4.4.0-1040-raspi2'
Note, selecting 'linux-headers-4.4.0-1040-raspi2' for glob 'linux-*-4.4.0-1040-raspi2'
Note, selecting 'linux-image-4.4.0-1040-raspi2' for glob 'linux-*-4.4.0-1040-raspi2'
Package 'linux-tools-4.4.0-1040-raspi2' is not installed, so not removed
The following package was automatically installed and is no longer required:
  linux-raspi2-headers-4.4.0-1040
Use 'sudo apt autoremove' to remove it.
The following packages will be REMOVED:
  linux-headers-4.4.0-1040-raspi2* linux-headers-raspi2*
  linux-image-4.4.0-1040-raspi2* linux-image-raspi2* linux-raspi2*
0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
After this operation, 112 MB disk space will be freed.
Do you want to continue? [Y/n] y
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
 LANGUAGE = "en_US",
 LC_ALL = (unset),
 LC_PAPER = "nb_NO.UTF-8",
 LC_NUMERIC = "nb_NO.UTF-8",
 LC_IDENTIFICATION = "nb_NO.UTF-8",
 LC_MEASUREMENT = "nb_NO.UTF-8",
 LC_NAME = "nb_NO.UTF-8",
 LC_TELEPHONE = "nb_NO.UTF-8",
 LC_ADDRESS = "nb_NO.UTF-8",
 LC_MONETARY = "nb_NO.UTF-8",
 LC_TIME = "nb_NO.UTF-8",
 LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 78930 files and directories currently installed.)
Removing linux-raspi2 (4.4.0.1040.39) ...
Removing linux-headers-raspi2 (4.4.0.1040.39) ...
Removing linux-headers-4.4.0-1040-raspi2 (4.4.0-1040.47) ...
Removing linux-image-raspi2 (4.4.0.1040.39) ...
Removing linux-image-4.4.0-1040-raspi2 (4.4.0-1040.47) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-1040-raspi2 /boot/vmlinuz-4.4.0-1040-raspi2
update-initramfs: Deleting /boot/initrd.img-4.4.0-1040-raspi2
run-parts: executing /etc/kernel/postrm.d/zz-flash-kernel 4.4.0-1040-raspi2 /boot/vmlinuz-4.4.0-1040-raspi2
Ignoring old or unknown version 4.4.0-1040-raspi2 (latest is 4.4.0-1009-raspi2)
The link /boot/vmlinuz is a damaged link
Removing symbolic link vmlinuz
 you may need to re-run your boot loader[grub]
The link /boot/initrd.img is a damaged link
Removing symbolic link initrd.img
 you may need to re-run your boot loader[grub]
Purging configuration files for linux-image-4.4.0-1040-raspi2 (4.4.0-1040.47) ...
Examining /etc/kernel/postrm.d...

[Simon Davis (davis-decent)]

Critical bug making installations unbootable, still unassigned, looks like it's time to move to another distro.

[hackeron (hackeron)]

I'm having the same issue, linux-image-4.4.0-1009-raspi2 boots without issues, upgrading to linux-image-4.4.0-1040-raspi2 and the Raspberry Pi 3 does not boot anymore :( - any solution except downgrading?

[hackeron (hackeron)]

As a workaround for those that haven't bricked their Raspberry, run this to prevent bricking until this is resolved:

sudo apt-mark hold linux-raspi2 linux-image-raspi2 linux-headers-raspi2

[Michael Shi (mklnz)]

Same here, no human intervention of any kind. Had a working RPI before, then suddenly one day stopped working.

[Joachim Marthinsen Giæver (giaever-online)]

Unfortunately, all of mine have upgraded, but I only rebooted one of them - and hoping the others will keep running until a fix is out. Or do anyone know a step by step solution for this, that wont prevent further updates later, ref: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1652270/comments/10.

Thanks!

[Burkhard Obergöker (glimfindel)]

I saw the same here, so I set the packages linux-raspi2 linux-image-raspi2 and linux-headers-raspi2 to hold (as mentioned above) and reinstalled the last working kernel 4.4.0-1034:
 dpkg-reconfigure linux-image-4.4.0-1034-raspi2

My test with the latest version 4.4.0-1040 still shows the same bug.

[Simon Davis (davis-decent)]

Is it possible to let us know if/when this bug is going to be fixed? Look, this is not a minor one, we have bricked devices and it happened via official (automatic) distribution update process. I have never experienced such a faux pas with another distro in 20+ yrs experience. I think that a bug of this importance require much higher attention.

[hackeron (hackeron)]

Any updates on this? - it's a critical issue that is bricking all raspberry pi units out there without any user intervention...

[Michael Shi (mklnz)]

Can't believe this is still not fixed, had to move to Raspbian, but probably a wise decision in the long run if something like this happens again.

[Simon Davis (davis-decent)]

Yeah, this is definitely sad. I had to move to Raspbian, too. As this is not the first time waiting too long for fixing a serious Ubuntu bug, I am thinking of replacing Ubuntu also on my servers and desktops. :(

[Joachim Marthinsen Giæver (giaever-online)]

Guys. Remember that this is a community build, and not officially supported by Ubuntu. We need to thank those who's doing this work, as it helps out with further development of Ubuntu itself.

[Simon Davis (davis-decent)]

I understand your point and I generally agree. On the other hand, such an effort can be counterproductive and easily can cause more problems than benefits.

People install a distro in a good faith that it will work and that the maintainer will maintain it. At least, keep it in a working not bricked state. A developer of a distribution is not the only one who invests time in the project. The users do as well. And if you let a wide userbase install your distribution you are taking a bit of responsibility of the people. Giving out even a community built distro under a well recognized brand name makes people think they can trust it. It makes them think they can invest their time to installing and setting up their systems. It makes them think they will not end up with auto-bricked devices without any help or even reply after all the effort on their side.

I think that letting people know that the problem will be fixed tomorrow / by next month / never does take that much time. So, can someone inform users at least?

[Gaetan Cambier (gaetan-cambier)]

Ubuntu 16.04 for Rpi2 is a Official image : https://wiki.ubuntu.com/ARM/RaspberryPi

And rpi2 is also impacted !

[Joachim Marthinsen Giæver (giaever-online)]

I'm running a cluster of 3 RPi3 and 2 RPi2. For what I'm aware of, there's only troubles with the RPi2. Both of mine RPi2s boots as expected, so is the RPi2 bug you're referring to related to something else?

I agree to the ETA part, it's frustrating to wait for a fix - and don't even know if it comes. But the developer/maintainer explicitly note
that the RPi3 isn't official, and by that we need to understand that the work on the project can stop whenever he decide to. He's not obligated to do any action to it.

[Andreas Hösl (blafasl)]

I'm also facing this Bug with my RPi3. It does not boot with kernel >= 1038

Maybe it has something to do with the CPU? If this is the case, any new RPi2 would have the same problem! Since board revision V1.2 RPi2 is using the 64-bit BCM2837 processor from its newer sibling.

See: http://hackaday.com/2016/11/21/the-raspberry-pi-2-gets-a-processor-upgrade/

Maybe someone with with RPi2 V1.2 could confirm my assumption?

[Tianon Gravi (tianon)]

I think it's probably more likely that this is related to the changes to the dtb address over in #1636838 (although after hacking at it for a while trying to make those changes ad-hoc for verification, I wasn't able to confirm that hunch for sure).

[Gaetan Cambier (gaetan-cambier)]

For me, it's a 1.1 model

[ 0.000000] Machine model: Raspberry Pi 2 Model B Rev 1.1

CPUINFO :
Hardware : BCM2709
Revision : a01041

[Anthony Somerset (anthonysomerset)]

I also went down the root of https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1652270/comments/27 without success

i note specifically also that the PPA (https://launchpad.net/~ubuntu-raspi2/+archive/ubuntu/ppa-rpi3/) has updated packages for flash-kernel and linux-firmware-raspi2 which actually rolls in the changes mentioned in #1636838 as well as extending the change further and it doesn't fix this - i suspect its barking up the right tree though - issue seems to be not the kernel but the dtb and the address references - just trying to find the correct values that work and its proving time consuming so far for my u-boot novice brain

[Dariusz Kominiak (darkom)]

I also have the same issue as everyone here. RPi 3, Ubuntu 16.04.
I have an image of memory card just before bricking it. But when I connect it to the internet, almost immediately is taking security updates and want to restart.

If I'm on the stage when ubuntu requesting the restart, executing following command will prevent from bricking it?

sudo apt-mark hold linux-raspi2 linux-image-raspi2 linux-headers-raspi2

I doubt to experiment since I'm working on distance with this RPi and every time I need to ask someone to burn the image into memory card back...

[Andreas Hösl (blafasl)]

The problem is fixed for me. I did some tests with a fresh installation on a rpi3 with the image from https://wiki.ubuntu.com/ARM/RaspberryPi. The image did not boot after a simple apt-get update && apt-get upgrade. The kernel was not updated, still version 1009 from the image.

The uboot error was:

  ## Executing script at 02000000
  libfdt fdt_check_header(): FDT_ERR_BADMAGIC
  No FDT memory address configured. Please configure
  the FDT address via "fdt addr <address>" command.
  Aborting!
  reading vmlinuz
  6594336 bytes read in 952 ms (6.6 MiB/s)
  reading initrd.img
  9744755 bytes read in 1402 ms (6.6 MiB/s)
  Kernel image @ 0x1000000 [ 0x000000 - 0x649f20 ]
  ERROR: Did not find a cmdline Flattened Device Tree
  Could not find a valid device tree
  SCRIPT FAILED: continuing...

To fix the uboot error, you have to change the config.txt lines:
# set extended DT area
#device_tree_address=0x100
#device_tree_end=0x8000
device_tree_address=0x02008000

I changed the device_tree_address and commented out the device_tree_end. The address is the same that was changed in the file /usr/share/flash-kernel/bootscript/bootscr.rpi3 from flash-kernel package from ppa::ubuntu-raspi2/ppa-rpi3

With this changes made to config.txt I did the apt-get dist-upgrade to get the latest kernel (version 1040) and rebooted. The rpi3 started without any problems, running kernel 1040!

maybe Ryan can add some script magic to the flash-kernel package to change the config.txt during the update?

[Joachim Marthinsen Giæver (giaever-online)]

Can i ask where this config.txt file is located?

I experience this bug now, so I dont know if it's related to the topic here, or if its a new one. Haven't installed the "broken" kernels (1038 or newer), and it have working flawlessly - until I rebooted yesterday. Now I'm stuck in this loop.

But, I cant seem to find the config.txt file, but i can find /boot/config-4.4.0-1009-raspi2. But the variables you're referring to aren't in this file.

[Joachim Marthinsen Giæver (giaever-online)]

Found it, in the system-boot partition. :) And it worked! Going to unmark the 1040-kernel now on one of the cluster nodes now (easier to just copy a node if something fails), to check if it boots.

[Anthony Somerset (anthonysomerset)]

i can confirm that

To fix the uboot error, you have to change the config.txt lines:
# set extended DT area
#device_tree_address=0x100
#device_tree_end=0x8000
device_tree_address=0x02008000

commented device_tree_end out and made sure device_tree_address was the correct value (0x02008000)

fixes things for me - currently booting into 1042

i note that the flash-kernel and linux-firmware-raspi2 updates recently accounted for changing the device_tree_address but neither comment or hide device_tree_end - i suspect if you worked out the correct value for this then it would also still work

[Andreas Hösl (blafasl)]

I have looked a little deeper into the packages and have found the script linux-firmware-raspi2.postinst inside linux-firmware-raspi2. The script changes the device_tree_address in the config.txt from 0x02000000 to 0x02008000

0x02000000 is the value which is inside the config.txt on my raspi2. This ensures that the raspi2 can successfully boot after the upgrade.

I think the following lines in the .postinst script could fix the problem:

    if grep -q "device_tree_address=0x100" /boot/firmware/config.txt; then
        sed -i.bak 's/device_tree_address=0x100/device_tree_address=0x02008000/' /boot/firmware/config.txt
    fi
    if grep -q "device_tree_end=0x8000" /boot/firmware/config.txt; then
        sed -i.bak '/device_tree_end=0x8000/d' /boot/firmware/config.txt
    fi

I did a quick shell test and the config.txt was changed as expected. Not shure if it is the best way to handle it, but it should work ;-)

[Simon Davis (davis-decent)]

I can confirm that editing the config.txt file BEFORE proceeding the upgrade process solves it all. Very good job, sirs!

Unfortunately, one question remains. Is it really wise to invest time into building and taking care of a system based on a distro that will let you down and keep without any help, or even a word? Bricked for months? This is a very bitter experience for me.

[StatnMap (seb44550)]

I can also confirm that editing config.txt worked, but I had to remove the ppa (ppa:ubuntu-raspi2/ppa-rpi3) first.

If it can help somebody else, here is what I did.
I was stuck with the "starting kernel" message, just after boot.
1/ I removed the sd card from the raspberry and put it in another computer :

cd system-boot
mv initrd.img initrd.img.ori
mv initrd.img.bak initrd.img
mv bcm2710-rpi-3-b.dtb bcm2710-rpi-3-b.dtb.ori
mv bcm2710-rpi-3-b.dtb.bak bcm2710-rpi-3-b.dtb
mv boot.scr boot.scr.ori
mv boot.scr.bak boot.scr
mv vmlinuz vmlinuz.ori
mv vmlinuz.bak vmlinuz

2/ Put the sd card back in the raspberry, it should start up and uname -r should display 1034
3/ Comment the ppa:ubuntu-raspi2/ppa-rpi3 in /etc/apt/sources.list
sudo apt-get update
4/ Re-install kernel (from the offical Canonical rpi2)
sudo apt-get install --reinstall flash-kernel linux-firmware-raspi2
sudo reboot
5/ Normally you're stuck again at the boot but for another reason. So remove again the sd card from the raspberry and put it in another computer. This time modify the config.txt file in system-boot as follows :

# set extended DT area
#device_tree_address=0x100
#device_tree_end=0x8000
device_tree_address=0x02008000

6/ Now it should work. This also would mean that the special ppa for raspberry pi 3 is not anymore necessary. Currently my rpi3 work with kernel 1042. (+ Lubuntu 16.04)

[Simon Davis (davis-decent)]

I wonder how long it would take to issue official fix of a critical bug when users already sorted it out themselves. The future of this distribution looks very uncertain. That's the real message.

[Andreas Hösl (blafasl)]

I switch one of my pi3 to the server image from https://ubuntu-pi-flavour-maker.org/
There you get pi3 support with working wifi and bluetooth. They do not include any PPAs from Ubuntu, the do not use u-boot and boot like raspbian. You also have to manually update your kernel via rpi-update. The benefit is, you get the supported kernel and device-trees form the raspberry Foundation ;-)

Not sure about a distribution-upgrade in the future because they are similar to the ubuntu-mate image. The mate team say's about distribution update: save your data and flash the new distribution, then restore.
But for now it's working very well for me.

[Simon Davis (davis-decent)]

I will definitely check it out.
Thank you very much, Andreas.

[Shuhao (shuhao)]

he images listed on ubuntu-pi-flavour-maker and the one listed on https://wiki.ubuntu.com/ARM/RaspberryPi is exactly the same.

The same issue should exist on both systems.

[Andreas Hösl (blafasl)]

interresting Shuhao, a few week ago they where different!

http://web.archive.org/web/20161228144448/https://ubuntu-pi-flavour-maker.org/

They had a "minimal" and a "standard" server version and both were rpi2 and rpi3 compatible... damn...

[Susan Foreman (suforeman)]

I had a non-conforming result:

I imaged an microSD card with ubuntu-16.04-preinstalled-server-armhf+raspi3.img

I tested three methods of editing the config.txt file to apply the above mentioned changes related to `device_tree_address=0x02008000`

Test #1: edited the file before first boot.
Result: "script failed" error and timeouts attempting TFTP to get boot files

Test #2: booted the RPi3 and immediately edited the config.txt file and immediately rebooted
Result: "script failed" error and timeouts attempting TFTP to get boot files

Test #3: booted the RPi3, let it sit idle for 10 minutes and then did a few tasks such as update the tzdata. then rebooted. Then edited the config.txt file and rebooted again
Result: first reboot was successful and the second reboot resulted in "script failed" error and timeouts attempting TFTP to get boot files

It appeared that as soon as the device_tree_address was changed, the RPi3 would not boot after.

Test 4: mount the microSD card and revert the edits to config.txt
Result: boot failed with a data dump.

[Joachim Marthinsen Giæver (giaever-online)]

Hi. Could you try to:

1) on first boot, hold packages that breakes our system:
$ sudo apt-mark hold linux-raspi2 linux-image-raspi2 linux-headers-raspi2
2) Do an upgrade:
$ sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade
3) Reboot:
$ sudo reboot
4) Unhold the packages again:
$ sudo apt-mark unhold linux-raspi2 linux-image-raspi2 linux-headers-raspi2
5) Repeat step 2.
6) Power off the device and change the config file, see:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1652270/comments/31
https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1652270/comments/32
https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1652270/comments/33

[Joachim Marthinsen Giæver (giaever-online)]

... I assumed you can have a fresh install since you're mentioning "first boot".

[Joachim Marthinsen Giæver (giaever-online)]

Sorry, #6 should be done before #4. Just tested it, and it works.

[Susan Foreman (suforeman)]

I followed the [corrected[ six steps of instructions. It failed to boot at step #3 with the "SCRIPT FAILED" error and attempting to use TFTP. I downloaded the original image again and repeated the instructions with the same failure at step #3.

I attempted the test with both the image from: http://www.finnie.org/software/raspberrypi/ubuntu-rpi3 and https://wiki.ubuntu.com/ARM/RaspberryPi. The same issue occurred in all tests.

[gali (jeangali)]

If you're stuck on "starting kernel", try replacing some of the files in /system-boot/ with these: http://dl.free.fr/wqXsJ2Fq2 More details on StatnMap's comment.

[hackeron (hackeron)]

I take it this have not been fixed. I just tried installing ubuntu again, ran apt-get upgrade; apt-get dist-upgrade, rebooted and it says: ERROR: `server' not set. and Config file not found. and will not boot :(

Is there a permanent solution to this?

[Pierre Boucher (telpe)]

We're seriously 4 months into a bug that renders a Pi completely unusable and it's still not patched? Happened to me twice and it was only after extensive Googling that I even found this bug.

Come on now, this is a critical issue.

[Simon Davis (davis-decent)]

I consider this a dead distro. They SHOULD take it off the web completely and save people a lot of time. Basically, it's a trap. Someone, typically an Ubuntu user, is googling for a Raspberry distro and this comes up in the results. Being a Ubuntu distro, it looks trustworthy and familiar to the user. And then? Installed, time spent, upgrade, doh! Just causing troubles and making a bad name to the Ubuntu as whole.

If you follow the steps described above, starting with a fresh install, it works. You must make the changes before upgrading. The question is, do you really want to invest your time and effort to a distribution with literally no support and more than questionable future?

You can probably also try another distribution like DietPi.

[Anthony Somerset (anthonysomerset)]

is now a bad time to say i've been apt updating for some time just fine now, my previous instructions should still be accurate:

i can confirm that

To fix the uboot error, you have to change the config.txt lines:
# set extended DT area
#device_tree_address=0x100
#device_tree_end=0x8000
device_tree_address=0x02008000

commented device_tree_end out and made sure device_tree_address was the correct value (0x02008000)

fixes things for me - currently booting into 1042

i note that the flash-kernel and linux-firmware-raspi2 updates recently accounted for changing the device_tree_address but neither comment or hide device_tree_end - i suspect if you worked out the correct value for this then it would also still work

[StatnMap (seb44550)]

It seems that Ryan Finnie stopped maintaining this distro.
If you want to use (X)Ubuntu on your Raspi3, I recommend to install image of ubuntu-pi-flavor-maker:
https://ubuntu-pi-flavour-maker.org/download/
It works greatly.

However, the use of boot is different from the one of Ryan Finnie, this is not only a question of different ppa... This means that you have to re-install the Raspi completely from beginning.
I tried to find a way to "migrate" from Finnie's architecture to Flavor-Maker's one, but I do not know it enough to make it succeed...

Finnie's Raspi3 image in Ubuntu Wiki should be removed from documentation...

[hackeron (hackeron)]

StatnMap, what RaspberryPi do you have? - I installed https://ubuntu-pi-flavour-maker.org/download/ classic server 16.04 and ran apt-get update; apt-get dist-upgrade and this has bricked by Raspberry Pi3.

Anthony's solution worked for me, thank you!

[StatnMap (seb44550)]

I have the RaspberryPi 3 Model B Vi.2
I installed the Lubuntu 16.04.2 from flavour-makers, because I want a graphic interface for solving some problems sometimes...
Indeed, I think I read somewhere that the server version on this page was the same than the one of Ryan Finnie... Sorry...
My RaspberryPi 3 now run with kernel 4.4.38-v7+ using this Lubuntu image.

[hackeron (hackeron)]

Note, after following Anthony's tip and doing an apt-get dist-upgrade, wifi stops working :( - anyone have any ideas how to get wifi working on the latest kernel?

[Andreas Hösl (blafasl)]

The WiFi is not working because the firmware was removed from the package. I already documented the problem in https://bugs.launchpad.net/ubuntu/+source/linux-firmware-raspi2/+bug/1578745 but no reply and no fix also!

[Daniel Tripp (daniel-m-tripp)]

Meh! August 2017 - this is still an issue... looks like my brief flirtation with Ubuntu on ARM is over - and back to Raspbian...

And JUST when I'd thought it was reliable and started running pi-hole on it for a whole LAN :-(

[Adam Smith (adamsmith)]

This bug hits rpi3 users who have downloaded an unofficial image. The rpi packages you are using are from a PPA.

The official xenial versions of Flash-kernel and U-boot don't support the rpi3. They do support the early versions of the rpi2 and for these the original bug has been fixed.

Ryan Finnie's PPA contains a newer version of uboot which works considerably differently from the official xenial uboot. It's quite unfair here to heap any abuse on Ubuntu. Or Ryan for that matter.

Some good background reading can be found here http://dius.com.au/2015/08/19/raspberry-pi-u-boot/
The patch that is discussed was merged into uboot and is in the PPA. This is why different device tree addresses are needed for the rpi3 and rpi2.

[Mike Rushton (leftyfb)]

@adamsmith

The patch you mention might be in image we download, but as soon as we upgrade to a newer kernel with sudo apt-get dist-upgrade, this is when we have the issue.

You say we shouldn't blame Ubuntu or Ryan, but someone is dropping the ball on fixing this issue or submitting a patch somewhere.

Bottom line, Ubuntu server on the Raspberry Pi 3 is not a viable option for anyone at this point in time.

[Simon Davis (davis-decent)]

Adam Smith, I think we understand the risks of installing unofficial image but there still could be something to think about in my comment #23.

[Adam Smith (adamsmith)]

For what it is worth I've been working on my own stuff https://lists.ubuntu.com/archives/lubuntu-users/2017-August/011613.html

I don't use Ryan Finnie's server image, but to say it is unviable is clearly untrue. A bit of user intervention is needed, but there is nothing to stop you adding some instructions to the wiki.

[Simon Davis (davis-decent)]

Yes, as you can read I have managed to get it working but it is far beyond capabilities of many users. They expect something different than a regular update process unexpectedly bricking their devices.

[Adam Smith (adamsmith)]

There is no point getting narky about this. Yes its frustrating. This bug should be assigned to the PPA Linux-firmware-raspi2 package, but there is no facility to do that in Launchpad. You presumably have that PPA enabled, therefore they (Ryan) are the only ones who can automatically fix it.

People are using a server image, therefore it is reasonable to expect some competence. To suggest editing a text file is beyond users is a bit far fetched.

Some clear instructions on the wiki would fix this problem until a new image is built by somebody.

[StatnMap (seb44550)]

Sorry for the revival of this bug.
In this thread, I proposed solutions to unbreak the rpi3.
The truth is that I modified mine so much that it is stuck in version 4.4.0-1029-raspi2, although I have different "4.10-..." listed in my package list.
I installed many things on it, and I do not want to loose my configuration with a fresh install.
(Indeed, on this one, I am not using lubuntu from flavor-makers)

People who installed Ryan's image and succeeded in making it work, are you also stuck in 4.4.0-1029, whatever are core and grub updates ? Or did I modified something that I should not ?

Thanks

[Keijo D. Putt (keijodputt)]

Just did a fresh install on RPi3 Model B.
Got struck by the `apt update &&apt upgrade` bug, reinstalled and followed the 0x02008000 instructions successfully rebooted into an updated system.
After all updates, version is: 4.4.0-1086

Regards,
keijo!

[Markus Birth (mbirth)]

This might be related to bug #1791466

[Chris E (cbz)]

This is related to bug #1652504 and the answer #16 there is a more detailed explanation of #65 above:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652504/comments/16

As of 18.04.2 the fdt_addr has changed again, I was able to fix this via the following, first cat boot.scr on the primary partition, there's a bunch of binary at the start of the file followed by fdt_addr_r 0x03000000 - this is the new device tree address.

Use that as the base value on config.txt:

device_tree_address=0x03000000

You do not need to set device_tree_end, this got the pi booting again.