I have a Raspberry Pi 4 which I recently updated with sudo apt-get upgrade,sudo apt-get update,sudo apt-get dist-upgrade.

After a reboot, it says autoboot.txt not found on a 'black screen of death' (which is attached). I have tried creating one with boot_partition=0 or 1 or 2 or 6 with no success.

I went back to an archive (on a different SD card) and Pi was working fine, but crashed again after system update and reboot.

Any suggestions?

Crash report screen

  • What OS? Are you using NOOBS?
    – Milliways
    Aug 7, 2020 at 23:13
  • It was a standard Buster installation with a new Pi4. A possible explanation for the fault would be that somehow the Pi4 is thinking it is a previous edition (i.e Pi3) as from what I am reading, autoboot.txt should never be used as bootbin(?) is on EEPROM i=on Pi4.
    – rallan
    Aug 8, 2020 at 13:43
  • 1
    Normal procedure is update followed by upgrade and use apt not apt-get. Raspberry Pi OS does not use autoboot.txt and the boot screen should show 4 raspberries so we have NO WAY of knowing what you may have done (even if we could read the text in the poor image).
    – Milliways
    Aug 9, 2020 at 6:42
  • Thanks for this I have changed the order and using apt in my command file.
    – rallan
    Aug 9, 2020 at 22:54
  • Thanks for this I have changed the order and using apt in my command file. The second point is valid but WHY has a Pi 4 changed to a one raspberry and used autoboot.txt which should be 'treated' by autoboot.bin in EEPROM. It would appear that the update code does not recognise a Pi4 correctly. And it has done on two working SD versions separated by 3 months of edits? I apologise for quality of screen shot, but I am sure I would have got complaints for a high res version! and most of the shot is academic anyway indicating a look for the .elf files on the SD card rather than than the EEPROM.
    – rallan
    Aug 9, 2020 at 23:01

2 Answers 2


Somehow your boot partition is corrupted/edited/removed/illegally(without proper permission) edited. And now it can not find the partition. This happens most of the time when we are trying to edit a file in boot partition with a windows OS that has virus in it. You have to take a backup of your rootfs and reinstall everything.

  • I agree with your suggested solution but why should two previously working versions fail on a system update? fsck reports no faults on SD card and there is plenty of partition space.
    – rallan
    Aug 8, 2020 at 14:47
  • fsck will never find something like that. I have faced this at least three times. One time it was a Windows with malware. And another time it was a update fail. Aug 9, 2020 at 2:23
  • Agreed, but just mentioned to indicate no file system corruption
    – rallan
    Aug 9, 2020 at 23:03
  • @rallan I am not only talking about fs corruption. There is file permission corruption too Aug 9, 2020 at 23:39

I have resolved the problem but not why it happened in the first place.

I generated a new system image on a new SD card. There was a substantial number of missing files on the faulty SD card root partition, in particular all .elf and kernel images.

I copied the root partition across.

I then needed to edit cmdline.txt and /etc/fstab to have the correct UUID for the SD card. Rebooted and all was fine.

On a subsequent update, it was found that Kodi was not updating correctly and aborting the update. Why this should corrupt the boot partition on two relatively independent cards during a system update is the major question. I fear someone else will experience what I have.

Thanks to everyone

  • Please accept your own answer with a click on the tick on its left side. Only this will finish the question and it will not pop up again year for year.
    – Ingo
    Aug 16, 2020 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.