Sboot.bin Fail
Catherine Rubeo
I pulled out a Samsung Galaxy S6 that has not been used in a while. It has never been rooted or had custom software, and it was working last time. But now it was not starting up, it got stuck at the boot animation with blinking Samsung logo.
I booted in download mode and tried flashing the original software with Odin 3.14 on a Windows 10 computer. This phone is SM-G920F from Vodafone Italy. I downloaded the newest software from SamMobile, G920FXXU6EVG1.
Odin failed while transferring system.img and now the phone only starts up to a screen saying "An error has occurred while updating the device software. Use the Emergency recovery function in the Smart Switch PC software." Download mode works, but recovery mode does not.
This phone has re-activation lock enabled, so flashing a custom recovery like TWRP also fails (I do not mind tripping Knox), with error "Custom Recovery Blocked By R/L". I know the Google and Samsung account credentials to remove the lock, but the phone needs to start up to enter them!
My /boot partition is nearly full and I get a warning every time I reboot my system. I already deleted old kernel packages (linux-headers...), actually I did that to install a newer kernel version that came with the automatic updates.
The headers are installed into /usr/src and are used when building out-tree kernel modules (like the proprietary nvidia driver and virtualbox). Most users should remove these header packages if the matching kernel package (linux-image-*) is not installed.
It selects all packages named starting with linux-headers- or linux-image-, prints the package names for installed packages and then excludes the current loaded/running kernel (not necessarily the latest kernel!). This fits in the recommendation of testing a newer kernel before removing older, known-to-work kernels.
Your boot partition is full. Since this is a kernel update, these files will be copied to the boot partition so you need to clean in out. Here is a blog post that will show you how to clear the old kernel images with one command. I'll give a basic synopsis of the method. Use this command to print out the current version of your kernel:
Make sure your current kernel isn't on that list. Notice how this is the majority of the final command (down below). To uninstall and delete these old kernels you will want to pipe these arguments to:
And that one command will take care of everything for you. I will confirm that this does work perfectly but never trust anybody on the internet. :) For more info, the blog post gives a very good explanation of what each part of the command does so read through it so you are satisfied that it does what you want it to do.
Right-click each of those linux packages and choose the option "Mark for Complete Removal". Finally click the apply button. This will remove all the files and any associated files. Your /boot folder should now be a bit tidier.
Thank you for your detailed post of your problem, this got me going in the right direction. Although it is useful to keep previous kernel files you can remove all of them in one go, check this post:
How to Remove All Unused Linux Kernel Headers, Images and Modules
You can stop using a separate /boot partition, then you won't have such limited space there. To do this, unmount the partition, then mount it somewhere else and copy all of the files there to the /boot directory in your root partition, then remove the entry from /etc/fstab and reinstall grub. For example ( you will need to use the correct partition ):
You can then use gparted to delete the old /boot partition, and possibly extend the root partition to use that space. To extend the root partition you will need to boot from the livecd, and the free space needs to be immediately to the right. If the /boot partition is currently to the left of the root partition, then you will need to first move the root partition to the left, then extend it, but this can take a very, very long time, so may not be worth the trouble.
Ubuntu as a desktop OS of simple everyday usage has no reason to be installed with separate /boot partition and something like this will NOT offer something to a "common user"... So a solution is a fresh install without /boot partition and this way you will never have such a problem
linux-headers-* aren't kernels. Kernel packages are the ones named linux-image-*. The ones named linux-headers-* are development packages for compiling kernel modules: they don't live in the /boot directory and are not required for general day to day use of your system.
The files you listed in /boot do include several old kernel images (vmlinuz*) and compiled initrd images (initrd.img*) for those kernels, which is an indication that you still have a lot of old kernel packages installed.
There is usually no need for more than two kernels to be installed - the one currently in use and the previous one to that (as a fallback). So you can start removing the older ones, one by one, like this:
Make sure you substitute "3.2.0-23-generic" with the actual kernel version you want to remove! Also, don't remove packages such as linux-image-generic. You have to be really careful not to remove the currently running kernel or you won't be able to boot (Ubuntu may or may not warn you about doing this).
I had this problem and more as I removed some initrd-img-xxx files manually from the /boot and I had a problem that these old versions keep generated and filling in the /boot folder. To fix it I followed the following:
--keep=1 means the command will keep 1 kernel older than the current kernel, so 2 in total, if there are at least so many installed. It might keep even more, if you have more than one meta kernels installed. --clear-boot is probably unnecessary; it will purge kernels unknown to the package management system. --optimize is not necessary, but it will speed up the process, if you have many kernels to remove.
My server was doing this, too. Literally none of the expected answers here worked since these require some working room on /boot for them to complete. If the boot partition is full, it will abruptly end without deleting any of the images.
The only thing that worked for me was to review the current image, then to manually sudo rm filename for the oldest image files (each had -3.16.0-30 in their names). Once that was done, then sudo apt-get autoremove had the wiggle-room it needed to do its job. It did highlight some errors associated with that version, for example: "depmod: FATAL: could not load /boot/System.map-3.16.0-30-generic: No such file or directory" but that is to be expected.
In order to do this, you would first need to shrink the other partitions, but this is made more complicated by the fact that one or more of them are encrypted, to the extent that I'm having trouble finding reliable documentation for how it should be done.
Out of the box, Ubuntu keeps 3 kernels. As far as I understand, this logic is baked into the packages that handle the logic for apt autoremove and there's no way to change it without recompiling those packages. So I suppose that would be a possible "fix," but it doesn't seem to be a viable fix as far as I'm concerned.
However, when installing updates, Ubuntu will install additional kernels first before removing old kernels, so /boot runs out of space. Here's the log from the last time I ran into this error during an update:
apt-get purge or apt-get autoremove will only work when the space remaining isn't enough for installing the kernel but still enough for basic apt operations. If the disk is completely full then unfortunately all apt or dpkg calls will fail. In that case you should remove the files from /boot, but rm /boot/$OLD_KERNEL directly like in some other answers is not safe and you should follow the official steps on Ubuntu wiki:
If you cannot remove more unused files and if you have other partition with/or free space on same device, you can resize of /boot partition by parted/gparted. (It is included on installation media, too.)
If you have ever opened sboot.bin in an hex editor, you have probablynoticed that the bootloader image embeds trusted drivers. They are stored inthe binary in the MobiCore Load Format, the format also used to store trustedapplications on the filesystem. This file format is partially documented byTrustonic [2]. Blobs in the image can be located with the MobiCore LoadFormat's Magic MCLF:
Without going too deep into the details, MobiCore blobs contain sectionsmapped in memory into different segments. The interesting fact about thesesblobs is the .text section holding ARMv7 instructions while Samsung S6'sSBOOT is entirely made of AArch64 instructions.
SBOOT follows a proprietary format that is not documented. In my previousblogpost, I detailed how to load it into IDA Pro. Below, I recallthe parameters to correctly load sboot.bin for the Samsung Galaxy S6:
Looking for instructions that read or write to the register VBAR_EL3 led meto identify the Exception Vector Table used by the bootloader in AArch64state and the runtime service descriptors rt_svc_descs array.They are respectively located at 0x210F000 and 0x210EB50:
I also recovered a few symbols along the path to identify thert_service_descs. This is basically where I left off in the previousarticle. Let me detail how I enhanced IDA Pro's database on this binary.That way, it is going to be easier for interested readers to follow myexplanations and repeat the steps.
As mentioned in the previous article, SBOOT is partly based on ARM TrustedFirmware (ATF) [6], an open-source project that provides a referenceimplementation of secure world software for ARMv8-A., including a SecureMonitor executing at Exception Level 3 (EL3). For bootloaders running theAArch64 processor state, ATF defines 5 sequential stages:
The ATF documentation [7] states that it is possible to boot directly intoBL31 and thus, to get rid of BL1 and BL2 which are redundant withmanufacturer's proprietary boot ROM. This is the case on S6'sSBOOT: Samsung only borrowed code from BL31 (EL3 Runtime Software). Sincethe source code is available, one can browse the code, recompile it, createfunction signatures, do binary diffing in order to recover as many symbols aspossible and make the reverse engineering process easier.