Ekranı Bozuk Telefonu Android’siz Linux Sunucuya Çevirmek: Redmi Note 11 + Debian 13

Ailemden birisinin kullandığı Redmi Note 11’in ekranı bir gün yeşile boyandı ve bir daha düzelmedi. Ekran değişimi telefonun değerine yakın bir paraydı; atmaya da gönlüm razı olmadı. İçinde Snapdragon 680, 4 GB RAM, 64 GB depolama, WiFi ve LTE modem olan, üstelik kendi “UPS”i (bataryası) ile gelen bir cihazdan bahsediyoruz. Ben de onu 7/24 çalışan, ekransız bir Linux sunucusuna çevirmeye karar verdim.

Bu yazıda, telefonu önce Android üzerinde chroot ile kullandığım ilk denemeden başlayıp Android’i tamamen silerek saf Debian 13 çalıştırdığım son hâline kadar yaşadığım her şeyi anlatıyorum: denediğim yollar, karşıma çıkan (bazıları gerçekten sinir bozucu) sorunlar ve çözümleri. Aynı şeyi yapmak isteyenler için bir yol haritası olsun istedim.

Başlangıç: Android + chroot neden yetmedi?

İlk kurulum oldukça klasikti: Evolution X (Android 15) üzerinde Magisk ile root, /data/debian altında bir Debian chroot ve açılışta bunu ayağa kaldıran birkaç betik. Çalışıyordu ama:

• RAM’in çoğunu Android yiyordu. system_server, SystemUI, launcher, telefon servisleri… Boştayken bile ~2,3 GB kullanım vardı.
• Bazı vendor servisleri ekransız ortamda her birkaç saniyede bir çöküp yeniden başlıyordu.
• Doze, wakelock, Android’in ağ kısıtlamaları gibi “telefon” davranışlarıyla sürekli uğraşmak gerekiyordu.
• Chroot içindeki Debian gerçek bir sistem değildi: systemd yok, gerçek init yok, her şey Android’in insafına kalmış.

Hedefim netti: Android’i tamamen kaldırmak, telefonu doğrudan Debian ile açmak, WiFi’yi, modemi ve pil yönetimini saf Linux altında çalıştırmak.

Donanım ve başlangıç noktası

Ekran olmadığı için her şeyi adb, fastboot ve ileride SSH üzerinden “kör” yapmak zorundaydım. Bu, sürecin en büyük zorluğuydu: bir şey ters gittiğinde ekranda hata mesajı göremiyorsunuz.

Yol seçimi: Mainline mı, Android çekirdeği mi?

Telefonlara Linux kurarken iki ana yol var:

1. Mainline çekirdek (postmarketOS’un yaptığı gibi): Temiz ve güncel, ancak her donanımın sürücüsünün ana çekirdeğe taşınmış olması gerekiyor.
2. Telefonun kendi (downstream) Android çekirdeği: Eski (4.19) ve Qualcomm’a özel ekler dolu, ama telefonun tüm donanımı bununla zaten çalışıyor.

Araştırdığımda, postmarketOS’taki spes portunun ve SM6225 mainline çekirdek paketinin arşivlendiğini, WiFi desteğinin de belirsiz olduğunu gördüm. Ekransız bir cihazda WiFi’si çalışmayan bir sistem açmak, cihazla iletişimin tamamen kopması demek. Bu yüzden Android’in 4.19 çekirdeğini yeniden derleyip Android kullanıcı alanı yerine Debian başlatmaya karar verdim.

Adım 0: Önce yedek, sonra her şey

Qualcomm telefonlarda bazı bölümler geri getirilemez. Özellikle şunları mutlaka yedekleyin:

• persist: WiFi/Bluetooth/sensör kalibrasyonu
• modemst1, modemst2, fsg, fsc: Modemin EFS’i, yani IMEI ve şebeke kalibrasyonu
• boot, vendor_boot, dtbo, vbmeta: Android’e geri dönebilmek için

for p in persist modemst1 modemst2 fsg fsc boot_b vendor_boot_b dtbo_b vbmeta_b modem_b; do
  dd if=/dev/block/by-name/$p of=/data/local/tmp/bk/$p.img bs=1M
done

Ben toplam ~4 GB yedeği SHA256 doğrulamasıyla bilgisayara aldım. Bu yedekler olmadan hiçbir bölümü biçimlendirmeyin.

Adım 1: Çekirdeği Debian için yeniden derlemek

Çalışan çekirdeğin sürüm dizesindeki -g486124cc7bd8 kısmı, kaynağın hangi git commit’inden derlendiğini söylüyordu. ROM’un çekirdek deposunda bu commit’i bulup aynı kaynağı indirdim. Derlemeyi bilgisayarda değil, telefonun kendisinde, mevcut Debian chroot içinde yaptım (8 çekirdek, yaklaşık yarım saat).

Tuzak: /proc/config.gz yalan söylüyor

Mantıklı ilk adım, çalışan çekirdeğin yapılandırmasını /proc/config.gz‘den alıp üzerine eklemeler yapmaktı. Ama o dosyada WiFi sürücüsü bile kapalı görünüyordu, oysa WiFi çalışıyordu! Kaynağı incelediğimde, bu çekirdeğin /proc/config.gz olarak bilerek sabit bir stok yapılandırma gömdüğünü gördüm. Doğru temel, kaynak ağaçtaki vendor/spes-perf_defconfig idi.

Debian ve Docker için açılan seçenekler

Android çekirdekleri systemd’nin ihtiyaç duyduğu birçok özelliği kapatır. Açtıklarımın başlıcaları:

• DEVTMPFS, FHANDLE, AUTOFS4_FS, CGROUP_PIDS: systemd ve udev için zorunlu
• PID_NS, USER_NS, VETH, BRIDGE, IP_NF_NAT, OVERLAY_FS: Docker için
• WIREGUARD: ileride VPN için

Kapattıklarım ise şunlar:

• ANDROID_PARANOID_NETWORK: Bu seçenek açıkken yalnızca Android’in “inet” grubundaki kullanıcılar soket açabiliyor. Normal bir Linux’ta apt‘nin indirme yapan _apt kullanıcısı bile internete çıkamıyor.
• STATIC_USERMODEHELPER
• LTO/CFI: Derlemeyi saatlerce uzatıyordu, sunucu için gereksiz.

Derleme bir kez ipvlan sürücüsünde hata verdi; vendor bu ağaçta net_device_stats yapısını değiştirmiş. IPVLAN’ı kapatıp kaldığım yerden devam ettim.

Adım 2: Temiz bir Debian 13 kök dosya sistemi

Mevcut chroot’u taşımak yerine debootstrap ile sıfırdan minimal bir Debian 13 (trixie) hazırladım: systemd, udev, OpenSSH, wpa_supplicant, systemd-networkd, Qualcomm modem araçları (qrtr-tools, rmtfs, tqftpserv), libqmi ve zram. Sonuç ~600 MB.

Bu adımda iki sürprizle karşılaştım:

• apt indirmeleri sessizce takılıyordu. Sebebi yukarıda bahsettiğim PARANOID_NETWORK: Kurulum hâlâ eski Android çekirdeği üzerinde yapıldığı için _apt kullanıcısı soket açamıyordu. Geçici olarak APT::Sandbox::User "root"; ile aştım.
• IPv6 bağlantıları asılı kalıyordu. Acquire::ForceIPv4 "true"; ile çözüldü.

Adım 3: initramfs ve boot imajı – “neden recovery açılıyor?”

Çekirdeği Debian’a bağlayan şey küçük bir initramfs: busybox ile yazılmış bir /init betiği kök bölümü bölüm etiketinden bulup bağlıyor ve switch_root ile systemd’ye geçiyor. Kök bulunamazsa USB üzerinden bir kurtarma kabuğu açıyor.

Hiçbir şeyi flash’lamadan test etmek için Debian’ı önce kullanılmayan cust bölümüne kurdum (Xiaomi’nin MIUI’ye özel 2 GB’lık bölümü) ve imajı fastboot boot ile yalnızca bir kerelik başlattım. Bir sorun olursa yeniden başlatınca Android geri geliyordu.

Tuzak: Bootloader yalnızca LZ4 ramdisk kabul ediyor

İlk denemelerde telefon her seferinde Android recovery’sine düştü. Ekran olmadığı için ne olduğunu göremiyordum. Sorunu şöyle daralttım:

1. Orijinal boot imajını fastboot boot ile açtım: Android normal açıldı, yani yöntem çalışıyordu.
2. Yeni çekirdek + orijinal Android ramdisk ile açtım: Android yine açıldı ve WiFi çalıştı, yani çekirdek de sağlamdı.
3. Geriye benim ramdisk’im kalıyordu. Android’in ramdisk’lerine baktığımda hepsi LZ4-legacy sıkıştırmalıydı (02 21 4c 18). Benimki gzip’ti ve bootloader (ABL) gzip’i işleyemeyip recovery’ye düşüyordu.

find . | cpio -o -H newc | lz4 -l -12 - initramfs.cpio.lz4
mkbootimg --header_version 3 --os_version 15.0.0 --os_patch_level 2026-07 \
  --kernel Image.gz --ramdisk initramfs.cpio.lz4 \
  --cmdline "debian.root=cust firmware_class.path=/usr/lib/firmware" -o boot-debian.img
fastboot boot boot-debian.img

Ekransız hata ayıklama için kurduğum güvenlik ağları

• Kendiliğinden geri dönüş: Test açılışında WiFi 8 dakika içinde gelmezse sistem günlükleri diske yazıp kendini yeniden başlatıyor. Flash’lanmamış olduğu için de Android’e dönüyor. Böylece her denemede fiziksel olarak güç tuşuna basmam gerekmedi.
• Günlükler: initramfs her adımda dmesg çıktısını kullanılmayan logdump bölümüne, systemd de günlüğünü diske yazıyor. Sonra Android’den okuyabiliyordum.
• USB ağı: Telefon USB’ye takılınca bir RNDIS ağ aygıtı olarak görünüyor ve 172.16.42.1 üzerinden SSH ile girilebiliyor. İlk denemede Google’ın USB kimliğini (18d1) kullandığım için Windows ona ADB sürücüsünü bağladı ve ağ hiç oluşmadı. Linux Foundation kimliğine geçip Microsoft OS descriptor’ları ekleyince Windows sürücüsüz tanıdı.

Küçük bir itiraf: Bir keresinde recovery’de adb root yazdım. adbd root olarak yeniden başlayamadı, telefon USB’den tamamen kayboldu ve güç tuşuyla zorla yeniden başlatmak zorunda kaldım. Recovery’de adb’yi rahat bırakın.

Adım 4: WiFi – projenin en zor kısmı

Çekirdek açıldı, Debian açıldı, USB’den SSH ile girebiliyordum; ama WiFi yoktu. Snapdragon 680’de WiFi çipinin (WCN3988) firmware’i, modem işlemcisinin içinde çalışıyor. Yani WiFi için önce modemin açılması gerekiyor; Android’de bunu bir düzine vendor servisi yapıyor. Hepsini tek tek Linux karşılıklarıyla değiştirmem gerekti. Ortaya çıkan zincir şu:

1. IPA firmware’i (echo 1 > /dev/ipa): Ağ hızlandırıcısı
2. qrtr-ns: Modemle konuşulan QRTR protokolünün isim sunucusu
3. rmtfs: Modemin EFS’ini (IMEI vb.) sunar
4. tqftpserv ve pd-mapper: Modemin dosya ve servis istekleri
5. Modemi başlatmak: /dev/subsys_modem‘i açık tutmak
6. BDF yükleme: WiFi kart kalibrasyon verisi
7. Firmware “hazır” deyince sürücü wlan0‘ı açıyor, wpa_supplicant bağlanıyor.

Bu zincirdeki neredeyse her halka ayrı bir sorun çıkardı:

Sorun 1: pd-mapper ve tqftpserv “remoteproc” arıyor

Linux’taki bu araçlar mainline çekirdeklerin /sys/class/remoteproc arayüzünü bekliyor; Android çekirdeğinde bu arayüz yok. İkisine de küçük birer yama yazdım: remoteproc yoksa doğrudan /lib/firmware‘den okusunlar.

Sorun 2: rmtfs paylaşılan belleği bulamıyor

Android çekirdeği bu belleği rmtfs isimli bir uio aygıtı olarak sunuyor; rmtfs ise /dev/qcom_rmtfs_uio1 arıyor. Tek satırlık bir udev kuralı yetti. rmtfs’yi ayrıca -r ile salt okunur çalıştırdım; böylece modem EFS’e yazamıyor, IMEI ve kalibrasyon güvende kalıyor.

# /etc/udev/rules.d/90-qcom.rules
KERNEL=="uio*", ATTR{name}=="rmtfs", SYMLINK+="qcom_rmtfs_uio1"

Sorun 3: Modem firmware’inin bir parçası “-40 ELOOP” veriyor

Modem açılırken modem.b11 dosyası doğrudan okunamıyor ve çekirdek, kullanıcı alanındaki bir firmware yardımcısına düşüyordu. Android’de bu işi ueventd yapıyor, Debian’da ise bunu yapan hiçbir şey yoktu. Küçük bir udev kuralı ve betikle ueventd’nin bu görevini taklit ettim:

# /etc/udev/rules.d/80-firmware.rules
SUBSYSTEM=="firmware", ACTION=="add", RUN+="/usr/local/sbin/fw-helper"

# /usr/local/sbin/fw-helper (özeti)
echo 1 > /sys$DEVPATH/loading
cat /usr/lib/firmware/$FIRMWARE > /sys$DEVPATH/data
echo 0 > /sys$DEVPATH/loading

Sorun 4: WiFi firmware’i “hazır” demiyor – kapalı kaynak cnss-daemon

Modem açıldı, WiFi firmware’i bağlandı, ama “FW ready” sinyali hiç gelmedi. Android’in açılış günlüklerini karşılaştırınca farkı buldum: Android’de cnss-daemon adlı kapalı kaynak bir servis, firmware’e QMI üzerinden kartın kalibrasyon verisini (BDF, bu telefonda bd7tglu.bin) yüklüyordu. Firmware ancak bundan sonra hazır oluyordu.

Bunun yerine yaklaşık 150 satırlık bir Python QMI istemcisi yazdım. Linux’un AF_QIPCRTR soketiyle WLFW servisine bağlanıp sırasıyla cap → BDF yükleme (6 KB’lık parçalar hâlinde) → kalibrasyon raporu mesajlarını gönderiyor. Mesaj biçimlerini çekirdek kaynağındaki wlan_firmware_service_v01 tanımlarından doğruladım. İlk denemede çekirdek günlüğünde şu satırı görmek projenin en güzel anıydı:

icnss: WLAN FW is ready: 0xd87

Sorun 5: Sürücü probe’u “-14” ile düşüyor – IPA

Firmware hazırdı ama qcacld sürücüsü -14 (EFAULT) ile başarısız oluyordu. Kaynakta bu hatanın bir kaynağının WLAN ile IPA’nın SMMU yapılandırmalarının uyuşmaması olduğunu gördüm. Android, açılışta /vendor/etc/init/ipa_fws.rc içinde write /dev/ipa 1 ile IPA firmware’ini yüklüyordu. Bu adımı ekleyince wlan0 nihayet geldi ve WiFi’ye bağlandı.

Sorun 6: Bazen WiFi gelmiyor – bir yarış durumu

Birkaç açılışta her şey yolundaydı, birinde WiFi gelmedi. pd-mapper ve tqftpserv bazen exit 154 ile düşüyordu. 154 = 256 − 102, yani -ENETRESET. qrtr-ns açılışta yerel düğüm kimliğini ayarlıyor ve bu, o anda açık olan tüm QRTR soketlerini sıfırlıyor. Erken başlayan servisler bozuk duruma düşüyordu. qrtr-ns’e küçük bir bekleme ekleyerek bağımlı servislerin ondan sonra başlamasını sağladım:

# /etc/systemd/system/qrtr-ns.service.d/local.conf
[Unit]
Before=rmtfs.service tqftpserv.service pd-mapper.service qcom-modem.service

[Service]
ExecStartPost=/bin/sleep 1.5

Son ayrıntı: systemd-networkd, DHCP’de varsayılan olarak MAC yerine DUID kimliği kullanıyor ve bu yüzden bir yeniden başlatmada IP adresim değişti. ClientIdentifier=mac ve RequestAddress= ile adres sabitlendi. Arka arkaya yaptığım yeniden başlatma testlerinde WiFi her seferinde ~35 saniyede geldi.

Adım 5: Kalıcı kurulum

Test başarılı olunca Android’in userdata bölümünü (45 GB, şifreli f2fs) ext4 olarak biçimlendirdim, çalışan sistemi oraya kopyaladım ve yeni boot imajını boot_b‘ye yazdım. initramfs’e de bir güvenlik ağı ekledim: userdata bağlanamazsa otomatik olarak cust‘taki yedek Debian ile açılıyor.

İşe yarayan bir ipucu: Debian’dan doğrudan fastboot’a geçmek mümkün. İleride çekirdek güncellemesi için tuşlara gerek yok:

systemctl reboot --reboot-argument=bootloader

Pil: Şarj etmesin, deşarj da olmasın

7/24 prize bağlı bir telefonun pilini %100’de tutmak, onu şişirmenin en kısa yolu. İstediğim şuydu: pil %60 civarında dursun, telefon doğrudan USB’den beslensin, pile ne akım girsin ne çıksın.

Bu telefonda şarjı bir Maxim MAX77729 çipi yönetiyor. Çipin I2C üzerindeki bir yazmacında (adres 0x69, yazmaç 0xB7) çalışma modu var: mod 5 = şarj, mod 4 = buck açık, şarj kapalı. Mod 4’te telefon USB’den beslenirken pil devre dışı kalıyor, yani gerçek “bypass” çalışma.

# mevcut modu oku (alt 4 bit)
i2cget -f -y 0 0x69 0xB7
# bypass: şarjı durdur, sistemi USB'den besle
i2cset -f -y 0 0x69 0xB7 $(( ($(i2cget -f -y 0 0x69 0xB7) & 0xF0) | 4 )) b

Bunu bir systemd servisine bağladım: %57’nin altında şarj et, %60’ta bypass’a geç, %62’nin üstündeyse USB girişini kesip pili boşalt. Kernel’in battery_charging_enabled=0 ayarı ise USB girişini de kısıyor; o yüzden şarjı yalnızca çip moduyla yönetmek daha doğru.

Bir de hata yakaladım: USB girişi yeniden açıldığında çip kendi varsayılan moduna (şarj) dönüyordu ve kontrol 30 saniye sonra fark edene kadar pili bir puan fazla şarj ediyordu. Girişi açtıktan hemen sonra modu tekrar okuyarak bunu da çözdüm. Şu an panelde pil akımı ≈0 mA görünüyor.

Not: Modemin USB portu yalnızca 0,5 A veriyor. Anlık yük bunu aşarsa pil kısa süre destek oluyor, bu da aslında bedava bir UPS demek. Net düşüş olursa kontrol servisi %57’de tekrar şarj ediyor.

SMS: ModemManager olmadan

Telefonda SIM kart olduğu için SMS gönderip alabilmek istiyordum. Debian’daki standart araç ModemManager modemi QRTR üzerinden buldu, ancak veri arayüzünü kuramadığı için modemi hiç başlatmadı. Mainline çekirdekte bu arayüz ipa sürücüsünden geliyor; bu çekirdekte ise Android’in netmgrd‘sinin kurduğu sanal bir rmnet_ipa0 var.

Bunun yerine libqmi’nin Python bağlamalarıyla küçük bir SMS servisi yazdım:

• SIM ikincil abonelikte kalmıştı. Android çift SIM modunda (DSDS) 2. yuvadaki kartı “ikincil” olarak açmıştı, bu yüzden modem şebekeye kayıtlı değildi. QMI ile birincil aboneliğe alınca modem LTE’ye kaydoldu.
• Gelen mesajlar kaydedilmiyordu. Android’in RIL’i SMS yönlendirmelerini “sadece aktar, saklama” olarak bırakmıştı. Bunları “NV belleğe kaydet ve bildir” yaptım.
• PDU kodlama: SMS’ler 3GPP PDU biçiminde. GSM-7, UCS-2 (Türkçe karakterler), çok parçalı mesajlar ve Türkçe kaydırma tabloları için kendi kodlayıcı/çözücümü yazıp örneklerle test ettim.

# 2. yuvadaki SIM'i birincil abonelik yap
qmicli -d qrtr://0 --uim-change-provisioning-session="session-type=primary-gw-provisioning,activate=yes,slot=2,aid=..."
# gelen SMS'ler modem belleğine kaydedilsin ve bildirilsin
qmicli -d qrtr://0 --wms-set-routes="type=point,class=0,storage=nv,receipt-action=store-and-notify,type=point,class=none,storage=nv,receipt-action=store-and-notify"

Yönetim paneli ve uzaktan erişim

Son olarak sunucuyu her yerden izleyip yönetebileceğim bir web paneli yazdım (Python aiohttp, tek sayfa). Panelde:

• CPU (çekirdek bazında kullanım ve frekans), RAM, sıcaklıklar, pil (mod, akım, gerilim), WiFi ve mobil şebeke durumu, disk, servisler ve son 15 dakikanın grafiği
• SMS gönderme, alma ve silme (konuşma görünümünde)
• Şarj eşiklerini, SIM yuvasını değiştirme, servisleri yeniden başlatma, günlükleri görme

Güvenlik tarafında panel yalnızca 127.0.0.1‘de dinliyor ve dışarıya Cloudflare Tunnel ile açılıyor. Modemde port yönlendirmeye gerek kalmıyor, ev IP’si ifşa olmuyor. Parola scrypt ile saklanıyor; oturum çerezi HttpOnly, Secure ve SameSite=Strict; POST isteklerinde CSRF’e karşı özel başlık zorunlu; hatalı giriş denemeleri sınırlı ve sıkı bir Content-Security-Policy var.

SSH de aynı tünelden geçiyor. İstemci tarafında tek gereken cloudflared:

ssh -o ProxyCommand="cloudflared access ssh --hostname %h" [email protected]

Sonuç: Önce ve sonra

Hâlâ açık olan: Mobil veri

SMS ve şebeke kaydı çalışıyor, ancak mobil veri (LTE internet) henüz çalışmıyor. Android’de veri bağlantısını netmgrd, modemin Data Port Mapper servisi üzerinden kuruyor. Bunun Linux karşılığını yazmak ayrı bir proje. WiFi her zaman bağlı olduğu için şimdilik ihtiyacım yok, ama yedek internet olarak ilerde eklemek istiyorum.

Bunu yapmak isteyenlere tavsiyeler

• Yedek, yedek, yedek. Özellikle persist ve modemst/fsg bölümleri. Biçimlendirme gibi geri dönüşü olmayan adımlardan önce mutlaka.
• Flash’lamadan test edin. fastboot boot ve kullanılmayan bir bölüm (bende cust) sayesinde onlarca deneme yaptım ve telefon hiç “brick” olmadı.
• Ekransız çalışıyorsanız gözünüz olacak bir şey kurun: USB ağı, diske yazılan günlükler ve “başarısız olursa kendini yeniden başlat” mantığı.
• Android’in açılış günlüğü en iyi rehberiniz. Neredeyse her sorunun cevabını, aynı donanımın Android’de hangi sırayla ve hangi servislerle başlatıldığına bakarak buldum (dmesg, logcat ve /vendor/etc/init/*.rc).
• /proc/config.gz’ye güvenmeyin, kaynak ağaçtaki defconfig’i kullanın.
• Çekirdeği telefonun kendisinde derlemek gayet mümkün; çapraz derleme ortamıyla uğraşmanıza gerek yok.

Uyarı

Cihazınızın brick olmasından, IMEI’nizin silinmesinden, pilinizin şişmesinden, nükleer savaştan veya mevcut ekonomik krizden sorumlu değilim. Bu adımları uygulamadan önce yapacağınız değişiklikler hakkında en ufak bir endişeniz varsa lütfen araştırın ve önce yedek alın! Bu değişiklikleri yapmayı siz seçiyorsunuz; telefonunuz bir daha açılmazsa ve beni suçlarsanız, size gülerim.

Sorunuz olursa ya da aynı şeyi farklı bir telefonda denediyseniz yorumlarda yazın; deneyimlerinizi duymak isterim.