FREE LOOK

Erst einmal sollten alle Dateien kopiert werden, welche Ihr ben�tigt. In meinem Fall kopiere ich die Firmware in den internen Speicher, meines Xiaomi-Smartphones. Wenn Ihr nur TWRP flashen wollt, um dann SuperSU (Root) zu flashen, dann ist das nat�rlich nicht notwendig (nur die SuperSu zip-Datei kopieren).
Bei xiaomi.eu wird euch auf der selben Seite TWRP angeboten, wie oben im Screenshot zu sehen.
TWRP herunterladen und in den ADB Ordner verschieben (Windows). Unter Linux spielt es keine Rolle, wo die Datei abgelegt wird.
Ihr musst dann die Datei auspacken, wenn diese als .zip-Datei angeboten wird.
Wir ben�tigen eine .img-Datei.
Eigentlich ist das nicht notwendig aber am besten die Datei umbenennen - recovery.img
Dann k�nnt Ihr die Befehle weiter unten einfach kopieren und m�sst diese nicht anpassen. 
Unter Windows wird oft die Dateiendung nicht angezeigt --> Rechtsklick --> Eigenschaften --> Dateityp -- > (.img)
CMD als Administrator ausf�hren, euer Xiaomi-Smartphone/Tablet in die Fastboot Mode versetzen und mit dem Rechner verbinden (nicht �ber USB-Hub, USB 3.0 und USB 3.1 - unter Linux ist es egal).
1. Verzeichnis wechseln (da wo sich adb befindet)
2. Den Befehl dir ausf�hren und dabei achten, dass das Recovery als .img-Datei aufgelistet wird.
3. �berpr�fen, ob Fastboot euer Ger�t findet fastboot devices
4. Mit fastboot flash recovery recovery.img das Recovery flashen und am Ende sollte OKAY sowie Finished angezeigt werden, wie oben im Bild. Habt Ihr die Datei nicht wie oben umbenannt, dann Befehl anpassen.
5. Mit fastboot boot recovery.img das ganze beenden und schon bootet euer Smartphone/Tablet TWRP.
Unter Linux w�rde das ganze so aussehen, dann aber auch mit Punkt 5 direkt zu TWRP booten.
Das Erste was passieren k�nnte - TWRP ist chinesisch.
Oben im Screenshot - sorry f�r die schlechte Bildqualit�t - k�nnt Ihr sehen, wo Ihr es umstellen k�nnt (Select Language --> von Chinese auf German oder English umstellen).
Setzt einen Haken unter Never show this screen during boot again und best�tigt mit Swipe to Allow Modifications.

Tipp: Es gibt f�r sehr beliebte Ger�te oft "official TWRP".
Einfach mal nach eurem Ger�t suchen (externe Link zu TWRP)

Bei jedem Ger�t kann es Unterschiede geben...
Beispiel: Das Recovery kann nur geflasht werden, wenn sich bereits TWRP auf dem Ger�t befindet.
Ihr flasht euch somit zuerst TWRP von Xiaomi.eu und dann das Official TWRP per TWRP selbst.
Install
Install Image (unten rechts, da von Werk aus auf ZIP gestellt ist) --> TWRP ausw�hlen --> Swipe to flash
Reboot --> System
Schon habt Ihr das neuste TWRP Recovery und es kann dann auch mit der Tastenkombination gebootet werden. Oft in Foren ein h�ufiges Problem...

Tipp 2: Verwendet keine alten Anleitungen! Damals war TWRP unter Xiaomi nicht notwendig, deshalb funktionieren die alten Anleitungen in der Regel nicht.
Tipp 3: In einigen Anleitungen ist die Rede von "flash boot.img" - das k�nnte notwendig sein. Beim Xiaomi Redmi Note 3 Pro (Snapdragon - Kenzo) ist es nicht der Fall. Wenn Ihr diese Anleitung verwendet und beim ersten Start eine "official TWRP" flasht, dann wird TWRP �ber die Tastenkombination sicher starten. Ich hab das auch ohne official TWRP probiert... wurde Punkt 4 ausgelassen, dann wollte das Redmi Note 3 Pro nicht in den Recovery Modus booten.
Tipp 4: Sichert euer System! W�hlt den Punkt Backup aus.
Unter Name nichts eintragen (dann wird es automatisch nach Datum und Uhrzeit geordnet), System, Data und Boot anw�hlen, auf Select Storage klicken
Am besten auf die Speicherkarte oder auf einen USB Stick (�ber OTG-Kabel) Backup anlegen und mit Swipe to Backup best�tigen. Je nach System kann das auch mal ne halbe Stunde dauern aber dann k�nnt Ihr immer euer System wiederherstellen (unter TWRP auf Restore und Backup ausw�hlen).
Sollte es eine update geben - besonders wichtig f�r alle die Dev ROMs verwenden - dann kann es auch mal in die Hose gehen. Mit einem Backup k�nnt Ihr dank TWRP ganz schnell wieder zum alten System zur�ck.

Solltet Ihr Fragen haben, dann einfach schreiben. Es spielt keine Rolle, ob Ihr ein Mi5, Redmi Note 3 oder Redmi 3 habt.

It has been a busy week for disaster recovery so far - we had an outage on Monday and we had another one today.

On Monday, we lost our e-mail services. No, it had nothing to do with the Lotus Domino server. That was fine.

At first, it looked as if wed forgotten to renew our domain name. This was quickly followed with a back and forward check of various DNS services out there on the Web, our domain registrar and our Internet service providers. All seemed ok with our domain name but there was definitely something weird happening.

Eventually we discovered that our Internet service provider had their DNS running off a domain which they had forgotten to renew. Since they were providing our primary DNS, all of our inbound mail was getting confused when it went to resolve our domain.

After being told by us (yes, they were unaware of the situation despite the fact that it had occurred during the night and it wasnt noticed immediately in the morning), they quickly got to work renewing their domain. Of course, given the sorts of problems associated with domain name propagation, our problems persisted in one form or another for several hours.

Years ago, such a problem wouldve been effectively "over" within a matter of hours but unfortunately, more and more companies are outsourcing their services overseas, and it takes more than fixing the local domain services to resolve the problem.

Our Wednesday problem occurred while I was at lunch. I hurried back and arrived at a darkened building. Luckily, since we moved offices, we arent as high up as we used to be and I only had to run up six stories worth of stairs (although immediately after lunch, it felt like more than that).

It turned out that the entire local grid had lost power. Our domino server and our main file server were happily running off UPS but unfortunately the UPS handling our communications gear was not up to scratch. It didnt matter because there was no way that the UPS would be able to power our systems for more than 30 minutes. Even if this was possible, the temperature inside the computer room was rapidly climbing now that the air-conditioning was off.

We had no choice but to start shutting down the servers. It took us a little while to make that decision because we knew we had a little time and we were hoping for the power to come back on. Of course, as soon as we got halfway through the shutdown procedure, the power came back on. This was after a 45 minute outage in the centre of Sydneys CBD.

Once again, the problem was "environmental" and out of our control. We could have switched to our offsite systems but it is a hard call to make because although our systems are clustered, we have a few special requirements which make a partially manual cut-over desirable. When the cut-over is not automatic, it becomes very difficult to make a decision as to when to flip the switch.

The thing that these stories brings to mind is the fact that I keep reading anti-cloud computing "horror" stories from various vendors. In particular, they talk about Googles Gmail outages. I dont personally understand how people can think that cloud computing is any more or less unsafe than normal computing. As I said before, the problems had nothing to do with the Domino server. In fact, I cant remember a time when weve had an outage due to the Domino server.

I can remember plenty of times when we had hardware failures, ISP failures, power, air-conditioning, gas leaks and DNS failures. Weve had problems with Anti-Virus and Anti-Spam services running on the domino server - and when we moved them off the server, they still caused us the occasional problem at the gateway. Weve even had problems because of Windows itself and device driver updates. Its never domino though. The server product is entirely stable.

In some respects, our Domino mail is in exactly the same position as Gmail. Its not the product that is at fault, its the underlying infrastructure - and its out of our hands.