In our office, a little Raspberry Pi is responsible for displaying current graphs and monitoring data via its HDMI output to a TV screen. It's been running for months without interruption and I thought I'd run an update on it.
As Raspberry is running on Raspbian, which is based on Debian, there's of course the well known apt-get update/apt-get upgrade commands. I then followed these commands with "rpi-update" -> big mistake.
After rpi-update finished, it's output advised me to reboot the system. Which I did. And the Pi didn't boot anymore. Instead just the red power led was on but nothing else worked. Turns out, rpi-update is bad and shouldn't be launched. Great. Now that I learn that afterwards it's too late.
But not all hope is lost. I removed the microSD card and inserted it into my notebook which I had booted with grml64. The microSD card was detected as /dev/mmcblk0 as seen in dmesg:
[ 49.005314] mmc0: new high speed SDHC card at address 59b4
[ 49.023019] mmcblk0: mmc0:59b4 00000 7.35 GiB
[ 49.025442] mmcblk0: p1 p2 < p5 p6 > p3
With fdisk some more details can be seen:
fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 7.4 GiB, 7892631552 bytes, 15415296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (locical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1660e00a
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 1673828 1665637 813.3M c W95 FAT32 (LBA)
/dev/mmcblk0p2 1679360 15333375 13654016 6.5G 5 Extended
/dev/mmcblk0p3 15333376 15398911 65536 32M 83 Linux
/dev/mmcblk0p5 1687552 1810431 122880 60M c W95 FAT32 (LBA)
/dev/mmcblk0p6 1818624 15333375 13514752 6.5G 83 Linux
The current /boot of the Raspberry Pi can be found in partition 5. I mounted the partition and took a look at the files:
mount /dev/mmcblk0p5 /mnt
ls -la /mnt
drwxr-xr-x 3 root root 16384 Jan 1 1970 .
drwxr-xr-x 29 root root 200 Dec 1 2015 .
-rwxr-xr-x 1 root root 41 Dec 1 09:03 .firmware_revision
-rwxr-xr-x 1 root root 18693 Apr 27 2015 COPYING.linux
-rwxr-xr-x 1 root root 1447 Apr 27 2015 LICENCE.broadcom
-rwxr-xr-x 1 root root 18974 Sep 25 2013 LICENCE.oracle
-rwxr-xr-x 1 root root 10125 Dec 1 09:02 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root 9846 Dec 1 09:02 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root 9850 Dec 1 09:02 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root 11113 Dec 1 09:02 bcm2708-rpi-2-bcm.dtb
-rwxr-xr-x 1 root root 17900 Dec 1 09:02 bootcode.bin
-rwxr-xr-x 1 root root 120 Jan 1 1980 cmdline.txt
-rwxr-xr-x 1 root root 1757 Jan 1 1980 config.txt
-rwxr-xr-x 1 root root 6449 Dec 1 09:02 fixup.dat
-rwxr-xr-x 1 root root 2473 Dec 1 09:02 fixup_cd.dat
-rwxr-xr-x 1 root root 9687 Dec 1 09:02 fixup_db.dat
-rwxr-xr-x 1 root root 9691 Dec 1 09:02 fixup_x.dat
-rwxr-xr-x 1 root root 137 May 6 2015 issue.txt
-rwxr-xr-x 1 root root 4059512 Dec 1 09:02 kernel.img
-rwxr-xr-x 1 root root 4035396 Dec 1 09:02 kernel7.img
-rwxr-xr-x 1 root root 310 Jan 1 1980 os_config.json
drwxr-xr-x 1 root root 6144 Dec 1 09:02 overlays
-rwxr-xr-x 1 root root 2731192 Dec 1 09:02 start.elf
-rwxr-xr-x 1 root root 604792 Dec 1 09:02 start_cd.elf
-rwxr-xr-x 1 root root 4866440 Dec 1 09:02 start_db.elf
-rwxr-xr-x 1 root root 3820296 Dec 1 09:02 start_x.elf
And here you can see my screwup: The modified files with the timestamp from Dec 1 09:02.
Luckily there's a boot.bak created by rpi-update in partition 6. The boot.bak folder contains the old boot files.
mkdir /mnt2
mount /dev/mmcblk0p6 /mnt2
ls -la /mnt2/boot.bak/
drwxr-xr-x 3 root root 16384 Jan 1 1970 .
drwxr-xr-x 29 root root 200 Dec 1 2015 .
-rwxr-xr-x 1 root root 18693 Apr 27 2015 COPYING.linux
-rwxr-xr-x 1 root root 1447 Apr 27 2015 LICENCE.broadcom
-rwxr-xr-x 1 root root 18974 Sep 25 2013 LICENCE.oracle
-rwxr-xr-x 1 root root 4702 Apr 27 2015 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root 4423 Apr 27 2015 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root 5690 Apr 27 2015 bcm2708-rpi-2-bcm.dtb
-rwxr-xr-x 1 root root 17900 Apr 27 2015 bootcode.bin
-rwxr-xr-x 1 root root 120 Jan 1 1980 cmdline.txt
-rwxr-xr-x 1 root root 1757 Jan 1 1980 config.txt
-rwxr-xr-x 1 root root 6161 Apr 27 2015 fixup.dat
-rwxr-xr-x 1 root root 2366 Apr 27 2015 fixup_cd.dat
-rwxr-xr-x 1 root root 9216 Apr 27 2015 fixup_db.dat
-rwxr-xr-x 1 root root 9214 Apr 27 2015 fixup_x.dat
-rwxr-xr-x 1 root root 137 May 6 2015 issue.txt
-rwxr-xr-x 1 root root 3974884 Apr 27 2015 kernel.img
-rwxr-xr-x 1 root root 3930004 Apr 27 2015 kernel7.img
-rwxr-xr-x 1 root root 310 Jan 1 1980 os_config.json
drwxr-xr-x 1 root root 4096 Jan 1 1980 overlays
-rwxr-xr-x 1 root root 22664088 Apr 27 2015 start.elf
-rwxr-xr-x 1 root root 567672 Apr 27 2015 start_cd.elf
-rwxr-xr-x 1 root root 4644712 Apr 27 2015 start_db.elf
-rwxr-xr-x 1 root root 3621768 Apr 27 2015 start_x.elf
So the content from boot.bak can be copied to the current /boot partition:
rm -rf /mnt/*
cp -Rp /mnt2/boot.bak/* /mnt/
After that, the Raspberry Pi was able to boot again.
No comments yet.
AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Database Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Icingaweb Icingaweb2 Influx Internet Java KVM Kibana Kodi Kubernetes LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Office PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMWare VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder