Flashing a Samsung stock ROM using heimdall from the command line.

I've read many times how to flash a Samsung official rom from Windows using Samsung's official tools and some other times I've read complex ways to do it using the Heimdall's grafical interface, ... but I never felt any of this ways was for me.

Fortunately I always flash custom ROMs instead, so I never had the need to flash a stock one, till recently, when I wanted to test andOTP on old Android versions, that's when I wanted to install the ancient stock versions of a couple of Samsung phones, and luckily I came to a quick commandline script that did it all for me.

WARNING: this procedure will wipe out all your data on the device in a way that you won't be able to recover it, I'm not resposable for any data loss or any damage to the device that any of the things I describe here may cause to the devices.

First of all you must unpack the stock rom (typically a zip file that inside has a whatever.tar.md5 file which is really a tar file, not a md5 one, so, you untar the tar.md5 file and you get the images of the phone's partitions (recovery.img, modem.bin, boot.img, ...) you can now remove that .tar.md5 file.

So... if you have clear that you are going to delete all your data on the phone and want to continue, I assume you have made a good backup of your data and you have verified that the backup is ok, or that you don't mind loosing it all. In any way...

You must start by wiping your data partition from your recovery or from the system itself by doing a factory reset and then going directly do the bootloader. The easiest way is by selecting reset to bootloader on the recovery after wiping data, or rebooting pressing the bootloader key convination for your device, but making sure that you didn't boot into the system after doing the wiping.

If you are sure you have formated data and booted directly to bootloader, you may need to confirm on bootloader that you want to "Continue" to flash your rom, that way you'll get to the "Downloading..." droid.

Now that we are on the bootloader on download mode we do:

heimdall print-pit --no-reboot > pit

and after we have downloaded the pit file:

heimdall flash --resume $(for i in *.*;do grep -B 1 $i pit|tr '\n' ' ';echo;done|sed "s/.*ame: \([^ ]*\) .*ame: \(.*\)/--\1 \2/"|tr '\n' ' ')

And you are done. The script will flash all the partitions that are included on the stock rom and after that it will reboot for the system to do its job after flashing, so... it will be a first time boot that will take a while, but that's it.

Just some side notes, using --no-reboot and then --resume has never really worked for me, maybe it was a problem with heimdall's version or my devices or whatever, in those cases the second heimdall command will fail, you must reboot to booloader again (without going to system, otherwise you'll have to format data again) and execute the flash command again without the --resume.

Windows and Linux software Raid dual boot BIOS machine

One could think that nowadays having a machine with software raid doing dual boot should be easy, but... my experience showed that it is not that easy.

Having a Windows machine do software raid is easy (I still don't understand why it doesn't really work like it should, but that is because I'm used to Linux software raid), and having software raid on Linux is also really easy. But doing so on a BIOS booted machine, on mbr disks (as Windows doesn't allow GPT on BIOS) is quite a pain.

The problem is how Windows does all this, with it's dynamic disks. What happens with this is that you get from a partitioning like this:

/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT /dev/sda2 206848 312580095 312373248 149G 7 HPFS/NTFS/exFAT /dev/sda3 312580096 313165823 585728 286M 83 Linux /dev/sda4 313165824 957698047 644532224 307,3G fd Linux raid autodetect

To something like this:

/dev/sda1 63 2047 1985 992,5K 42 SFS /dev/sda2 * 2048 206847 204800 100M 42 SFS /dev/sda3 206848 312580095 312373248 149G 42 SFS /dev/sda4 312580096 976769006 664188911 316,7G 42 SFS

These are the physical partitions as seen by fdisk, logical partitions are still like before, of course, so there is no problem in accesing them under Linux or windows, but what happens here is that Windows is using the first sectors for its dynamic disks stuff, so... you cannot use those to write grub info there :-(

So... the solution I found here was to install Debian's mbr and make it boot grub, but then... where do I store grub's info?, well, to do this I'm using a btrfs /boot which is on partition 3, as btrfs has room for embedding grub's info, and I setup the software raid with ext4 on partition 4, like you can see on my first partition dump. Of course, you can have just btrfs with its own software raid, then you don't need the fourth partition or anything.

There are however some caveats on doing all this, what I found was that I had to install grub manually using grub-install --no-floppy on /dev/sda3 and /dev/sdb3, as Debian's grub refused to give me the option to install there, also... several warnings came as a result, but things work ok anyway.

One more warning, I did all this on Buster, but it looks like for Grub 2.04 which is included on Bullseye, things have gotten a bit bigger, so at least on my partitions there was no room for it, so I had to leave the old Buster's grub around for now, if anybody has any ideas on how to solve this... they are welcome.