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 '20 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 '20 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 '20 at 6:42
  • Thanks for this I have changed the order and using apt in my command file. – rallan Aug 9 '20 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 '20 at 23:01

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 '20 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. – Sohan Arafat Aug 9 '20 at 2:23
  • Agreed, but just mentioned to indicate no file system corruption – rallan Aug 9 '20 at 23:03
  • @rallan I am not only talking about fs corruption. There is file permission corruption too – Sohan Arafat Aug 9 '20 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 '20 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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