Pembaruan OTA Embedded Linux – Bagian 1: Dasar-dasar & Implementasi
Kebutuhan akan Pembaruan
Setelah produk Embedded Linux meninggalkan laboratorium dan memasuki lapangan, menentukan bagaimana produk akan menerima pembaruan menjadi keputusan desain yang krusial.
Meskipun aplikasi yang sempurna mungkin terlihat imun terhadap perubahan, kenyataannya adalah perangkat lunak tidak terhindar dari bug dan, untuk perangkat yang terhubung ke jaringan atau Internet, patch keamanan seringkali tidak dapat dihindari. Bahkan firmware yang sempurna secara teoretis harus mengakomodasi kerentanan dalam perpustakaan pihak ketiga.
Pertimbangkan kerentanan Heartbleed (CVE-2014-0160) yang mengekspos pustaka kriptografi OpenSSL. Kelemahan ini mempengaruhi sekitar dua-tiga pertiga semua situs web dan, hingga saat ini, tak terhitung perangkat Embedded Linux masih mengirim dengan build OpenSSL yang belum di-patch, sehingga mereka terpapar eksploitasi.
Pembaruan Berbasis Blok vs. Berkas
Mekanisme pembaruan untuk Linux dapat secara luas diklasifikasikan menjadi pendekatan berbasis blok dan berkas. Pembaruan blok menimpa seluruh partisi atau perangkat blok dalam satu operasi atomik, sedangkan pembaruan berkas mengganti berkas atau paket individu—mirip dengan cara “apt-get upgrade” bekerja pada distribusi desktop atau server.
Untuk Embedded Linux, pembaruan berbasis blok disukai karena seluruh filesystem biasanya dihasilkan oleh satu pipeline build dan footprint penyimpanan produk tetap. Memperbarui seluruh partisi dalam satu langkah juga menyederhanakan rollback: salinan gambar sebelumnya dapat dipertahankan sampai yang baru diverifikasi.
Memastikan Pemulihan Setelah Pembaruan Gagal
Tidak ada perangkat yang boleh ditinggalkan dalam keadaan tidak dapat digunakan, terutama jika kehilangan daya atau kegagalan penulisan terjadi selama flash. Mitigasi umum adalah mempertahankan partisi sekunder yang dapat mengambil alih jika gambar utama gagal boot.
Gambar 1. Pemulihan dalam event kegagalan – opsi fallback (Sumber: ByteSnap)
Dua pola umum ada:
Strategi partisi penyelamat – Bootloader memulai gambar penyelamat kecil yang dapat meluncurkan firmware utama setelah pembaruan selesai. Ini memungkinkan partisi utama menempati sebagian besar ruang penyimpanan, tetapi memerlukan dua reboot (ke penyelamat, lalu ke utama).
Strategi dual-rootfs – Dua filesystem root penuh dipertahankan berdampingan. Bootloader beralih di antara mereka pada waktu boot. Ketika pembaruan diterapkan, gambar nonaktim ditimpa, dan hanya satu reboot yang diperlukan. Pendekatan ini menghemat ruang per gambar, tetapi menghasilkan pemulihan yang lebih cepat dan tanpa downtime.
Jika penyimpanan melimpah, metode dual-rootfs biasanya direkomendasikan karena kesederhanaan dan performanya. Pendekatan penyelamat berguna ketika gambar utama besar dan ruang cadangan untuk rootfs duplikat terbatas.
Perhatikan bahwa bootloader biasanya tidak dapat diubah dalam pengaturan ini. Untuk memperbarui bootloader, Anda memerlukan partisi bootloader tambahan dan Board-Management Controller (BMC) yang mampu mengatur perpindahan—solusi yang meningkatkan kompleksitas dan biaya hardware.
Gambar 2. Pemulihan dalam event kegagalan – Board Management Controller (Sumber: ByteSnap)
Karena BMC menambahkan hardware dan firmware tambahan, sebagian besar desainer memilih untuk membuat bootloader semu mungkin dan terandalkan sehingga tidak pernah membutuhkan pembaruan OTA.
Memanfaatkan Variabel Lingkungan U-Boot
U-Boot menyimpan lingkungan non-volatil yang dapat diquery dari Linux dan dimanipulasi selama boot. Variabel ini ideal untuk mengkode partisi aktif, melacak keberhasilan boot, dan mengatur logika fail-over.
Pola umum termasuk:
Mengatur flag sebelum beralih ke gambar baru.
Meningkatkan variabel “boot count” pada setiap boot yang berhasil.
Mereset flag setelah ambang keberhasilan boot tercapai.
Dengan menyimpan status ini di U-Boot, bootloader dapat secara otomatis melakukan rollback ke gambar sebelumnya jika yang baru gagal boot sejumlah kali yang dapat dikonfigurasi.
Gambar 3. Variabel lingkungan U-Boot (Sumber: ByteSnap)
