smart os
It's can run xfce4 in smartos
Proyek ini menunjukkan cara dengan cepat membuat sistem operasi Linux yang kompak dan berfungsi penuh. Alamat proyek adalah https://github.com/superconvert/smart-os
Mengapa kita memilih versi server untuk produksi?
Versi server tidak berisi sebagian besar paket yang bergantung pada sistem jendela; Jika sistem dilengkapi dengan paket -paket ini, akan ada masalah dengan beberapa versi paket, masalah kompilasi, masalah ketergantungan, masalah tautan, dan masalah runtime, yang akan menyebabkan banyak gangguan pada pekerjaan kami. Selain itu, memecahkan masalah ini tidak ada artinya, kita membutuhkan versi murni dari paket ketergantungan
Mengapa sistem jendela bekerja begitu besar?
Semua paket (kecuali alat) yang kami instal menggunakan APT, secara teoritis kita perlu menyusun kode sumber, termasuk dependensi dan adhesi paket, yang perlu diselesaikan. Ini adalah beban kerja yang sangat besar. Tidak ada jalan, tidak ada apa pun di sistem baru, dan lingkungan yang diperlukan perlu disediakan oleh kami. Proyek A tergantung pada paket B, paket B tergantung pada paket C, paket C dan paket C tergantung pada paket d. Yang harus kita lakukan adalah menyusun semua paket!
Script ini dibuat di Ubuntu 18.04. Sistem lain tidak boleh banyak berubah. Teman yang membutuhkannya dapat memodifikasinya sendiri.
Persiapkan lingkungan sistem. Karena kernel perlu dikompilasi, Anda perlu menginstal lingkungan yang diperlukan untuk kompilasi kernel. Karena BusyBox perlu dikompilasi, Anda dapat menginstal lingkungan yang diperlukan sendiri sesuai kebutuhan.
./00_build_env.shKode Sumber Kompilasi (Kernel, GLIBC, BusyBox, GCC, Binutils)
./01_build_src.shBuat disk sistem (penting, langkah ini menginstal sistem ke dalam file sistem)
./02_build_img.shJalankan Sistem Smart-OS
./03_run_qemu.sh 或 ./04_run_docker.shApakah mudah membuat sistem operasi? Ruang disk dapat diperluas secara sewenang -wenang, dapat diakses secara online, dan dapat diperluas sesuai kebutuhan. Saya telah berhasil mencobanya dan menjalankan server streaming Smart_RTMPD di Smart-OS
+----------------------------------------------------------------+-----------------------------------------+-----------------------------------------+
| Host | Container 1 | Container 2 |
| | | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| | Newwork Protocol Stack | | | Newwork Protocol Stack | | | Newwork Protocol Stack | |
| +------------------------------------------------+ | +-------------------------+ | +-------------------------+ |
| + + | + | + |
| ............... | .................... | ........................... | ................... | ..................... | .................... | .................... |
| + + | + | + |
| +-------------+ +---------------+ | +---------------+ | +---------------+ |
| | 192.168.0.3 | | 192.168.100.1 | | | 192.168.100.6 | | | 192.168.100.8 | |
| +-------------+ +---------------+ +-------+ | +---------------+ | +---------------+ |
| | eth0 | | br0 | < --- > | tap0 | | | eth0 | | | eth0 | |
| +-------------+ +---------------+ +-------+ | +---------------+ | +---------------+ |
| + + + | + | + |
| | | | | | | | |
| | + +------------------------------+ | | |
| | +-------+ | | | |
| | | tap1 | | | | |
| | +-------+ | | | |
| | + | | | |
| | | | | | |
| | +-------------------------------------------------------------------------------------------+ |
| | | | |
| | | | |
+--------------- | ------------------------------------------------+-----------------------------------------+-----------------------------------------+
+
Physical Network (192.168.0.0/24)Karena Smart-OS menginstal Pustaka Dinamis GLIBC, ini sangat bergantung pada Library Loader/Linker Dynamic LD-Linux-X86-64.SO.2. Karena aplikasi dihubungkan melalui kompilasi dinamis, ketika aplikasi yang membutuhkan tautan dinamis dimuat oleh sistem operasi, sistem harus menemukan dan memuat semua file pustaka dinamis yang dibutuhkannya. Pekerjaan ini dilakukan oleh ld-linux.so.2. Saat program dimuat, sistem operasi akan menyerahkan kontrol ke ld-linux.so alih-alih alamat entri normal program. ld-linux.so.2 akan mencari dan memuat semua file perpustakaan yang diperlukan, dan kemudian menyerahkan kontrol ke portal awal aplikasi. LD-Linux-X86-64.SO.2 sebenarnya adalah rantai lunak LD-linux.so.2. Itu harus ada di bawah /lib64/ld-linux-x86-64.so.2. Kalau tidak, BusyBox kami yang dikompilasi secara dinamis tergantung pada perpustakaan GLIBC. Pemuatan perpustakaan GLIBC membutuhkan LD-Linux-X86-64.so. Jika tidak ada di direktori /lib64, itu akan menyebabkan sistem menjadi panik langsung. Masalah ini membutuhkan perhatian khusus! Lai Lai
Qemu umumnya memiliki jendela kecil setelah startup. Setelah kesalahan terjadi, pada dasarnya tidak ada cara untuk membaca log kesalahan. Maka Anda perlu menambahkan konsol = TTYS0 ke item startup Grub. Pada saat yang sama, Qemu-System-X86_64 menambahkan output port serial ke file -serial file: ./ qemu.log, jadi debugging jauh lebih nyaman. Setelah debugging, Anda perlu menghapus konsol = TTYS0. Jika tidak, konten di /etc/init.d/rcs tidak dapat ditampilkan.
Versi GLIBC yang kami kompilasi biasanya lebih tinggi dari versi yang disertakan dengan sistem. Kami dapat menulis program uji Main.c untuk menguji apakah GLIBC berhasil dikompilasi. Misalnya:
# include < stdio.h >
int main () {
printf ( " Hello glibc n " );
return 0 ;
}Kami mengkompilasi
gcc -o test main.c -Wl,-rpath=/root/smart-os/work/glibc_install/usr/lib64 Kami berhasil menjalankan program ./test, dan kami biasanya melaporkan kesalahan yang mirip dengan /lib64/libc.so.6: Versi `glibc_2.28 'tidak ditemukan atau segmen program secara langsung. Faktanya, inilah alasan mengapa tidak ada loader/linker perpustakaan dinamis yang ditentukan dan lingkungan sistem. Biasanya ketika kami mengkompilasi pustaka GLIBC, direktori kompilasi akan secara otomatis menghasilkan file skrip testrun.sh, dan kami menjalankan program di direktori kompilasi.
./testrun.sh ./test Ini biasanya berhasil dilakukan. Kami juga dapat menyimpan kalimat berikut ke dalam skrip, dan juga tidak masalah untuk menjalankan tes.
exec env /root/smart-os/work/glibc_install/lib64/ld-linux-x86-64.so.2 --library-path /root/smart-os/work/glibc_install/lib64 ./testBagaimana cara melacak perpustakaan mana yang dimuat oleh program yang dapat dieksekusi? Cukup gunakan ld_debug = libs ./test. Kami memuat perpustakaan dan memaksa preload perpustakaan untuk menggunakan LD_PRELOAD untuk memaksa preload perpustakaan
Saat kami mengkompilasi Kairo, kami biasanya menghadapi banyak masalah. Apa yang harus kita lakukan jika ada masalah dengan kompilasi Kairo? Beberapa pesan kesalahan sulit untuk dicari di Internet untuk melihat file config.log yang dihasilkan selama kompilasi. Pesan kesalahannya sangat rinci! Anda dapat menyelesaikan masalah sesuai dengan informasi prompt
Tentang variabel sistem init BusyBox, bahkan jika parameter kernel Grub digunakan, tidak mungkin untuk lulus variabel lingkungan. Init BusyBox akan secara otomatis menghasilkan jalur variabel lingkungan default, sehingga kode sumber perlu diubah untuk mendukung jalur yang disesuaikan. Tentu saja, mode login shell akan membaca /etc /profile. Untuk mode non-login, mode ini tidak valid, jadi ada batasan untuk lulus /etc /profil.
Pengetahuan ini melibatkan pengetahuan yang relatif besar. Ada relatif sedikit artikel yang secara khusus memperkenalkan kompilasi dan penggunaan XFCE4 di Cina, termasuk di luar negeri. Saya juga menyeberangi sungai dengan merasakan batu -batu dan mencoba menunjukkan pengetahuan ini dengan jelas. Saya akan membuka bab khusus untuk menjelaskan hal ini. Untuk transplantasi XFCE4 ke Smart-OS, ia akan mengungkapkan rahasia sistem grafis kepada orang Cina. Untuk detailnya, silakan merujuk ke xfce4.md.
Beban kerja integrasi seluruh sistem grafik sangat besar, melibatkan semua aspek sistem. Ada informasi sistematis yang relatif sedikit tentang aspek ini di luar negeri, dan hampir kurang di Cina. Tujuannya adalah untuk DIY semua lingkungan dan proyek open source pribadi untuk membuat seluruh sistem grafik berjalan utuh. Smart-OS bukan yang pertama, tetapi pada dasarnya adalah tiga teratas. Saya belum tahu. Seluruh proses integrasi sangat panjang, dan saya mengalami banyak masalah. Saya tidak akan membicarakan tugas -tugas berulang ini melalui debugging dan kompilasi yang berkelanjutan. Beban kerjanya sangat besar. Saya hampir bisa menggambarkan pekerjaan saya dengan keras. Sama sekali bukan berlebihan untuk menggambarkan pekerjaan saya. Kedua, saya menemukan banyak poin pengetahuan, banyak di antaranya dipelajari dan dijual segera. Saya perlu dengan cepat memahami mekanisme kerja, menyebabkan masalah, dan kemudian menyelesaikan masalah. Mari kita bicara tentang ide keseluruhan secara kasar, yang akan memfasilitasi para sarjana baru untuk dengan cepat memahami ide -ide, memberikan panduan tentang pemeliharaan sistem, dan menyediakan model untuk menyelesaikan masalah sistem.
Direktori USR merinci singkatan dari USR = sumber daya sistem UNIX. Perpustakaan /Lib adalah perpustakaan tingkat kernel, /usr /lib adalah perpustakaan tingkat sistem, dan /usr /local /lib adalah perpustakaan tingkat aplikasi; /LIB berisi banyak perpustakaan yang digunakan oleh program yang dapat dieksekusi di /bin && /sbin. /USR/LIB Hampir semua perpustakaan yang dirujuk oleh program yang dapat dieksekusi sistem diinstal di sini, dan/usr/lokal/bin banyak perpustakaan yang dirujuk oleh program yang dapat dieksekusi level aplikasi ditempatkan di sini
Ramfs:
RAMFS adalah sistem file yang sangat sederhana. Ini secara langsung memanfaatkan mekanisme cache yang ada dari kernel Linux (sehingga kode implementasinya sangat kecil. Karena alasan ini, fitur RAMFS tidak dapat diblokir melalui parameter konfigurasi kernel. Ini adalah sifat alami kernel). Ini menggunakan memori fisik sistem untuk membuat sistem file berbasis memori dengan ukuran dinamis. Sistem tidak akan mendaur ulangnya, dan hanya pengguna root yang menggunakannya.
TMPFS:
TMPFS adalah turunan dari RAMFS, yang menambah batas kapasitas dan memungkinkan data ditulis untuk bertukar berdasarkan RAMF. Karena penambahan dua fitur ini, pengguna biasa juga dapat menggunakan TMPF. TMPFS menempati memori virtual, tidak semua RAM, dan kinerjanya mungkin tidak setinggi RAMFS
RAMDISK:
Ramdisk adalah teknologi yang menggunakan area dalam memori sebagai disk fisik. Dapat juga dikatakan bahwa RamDisk adalah perangkat blok yang dibuat dalam sepotong memori untuk menyimpan sistem file. Untuk pengguna, RamDisk dapat diperlakukan sama dengan partisi hard disk yang biasa. Sistem ini juga akan menyimpan cache yang sesuai dalam memori, mencemari cache CPU, kinerja yang buruk, dan memerlukan dukungan driver yang sesuai.
ROOTFS:
ROOTFS adalah contoh RAMF spesifik (atau TMPFS, jika TMPF diaktifkan), selalu ada dalam sistem Linux2.6. Rootfs tidak dapat dihapus (daripada menambahkan kode khusus untuk mempertahankan daftar tertaut kosong, lebih baik untuk selalu menambahkan node Rootfs, sehingga lebih mudah untuk pemeliharaan kernel. Rootfs adalah instance kosong dari ramfs dan mengambil ruang yang sangat sedikit). Sebagian besar sistem file lainnya diinstal pada rootF dan kemudian mengabaikannya. Ini adalah inisialisasi startup kernel dari sistem file root.
Rootf dibagi menjadi rootf virtual dan rootf nyata.
Rootf virtual dibuat dan dimuat oleh kernel itu sendiri dan hanya ada dalam memori (initramfs berikutnya juga diimplementasikan atas dasar ini), dan sistem filenya adalah tipe TMPFS atau jenis RAMFS.
ROOTFS nyata berarti bahwa sistem file root ada di perangkat penyimpanan. Selama proses startup, kernel akan memasang perangkat penyimpanan ini pada rootfs virtual, dan kemudian beralih / node direktori ke perangkat penyimpanan ini. Dengan cara ini, sistem file pada perangkat penyimpanan akan digunakan sebagai sistem file root (initramdisk berikutnya diimplementasikan berdasarkan ini), dan jenis sistem filenya lebih kaya, yang dapat menjadi ext2, yaffs, yaffs2, dll., Yang ditentukan oleh jenis perangkat penyimpanan tertentu.
Sistem file startup kami sebenarnya adalah menyiapkan file untuk rootfs, sehingga kernel dapat dieksekusi sesuai keinginan. Dalam sistem Linux awal, hanya hard disk atau floppy disk umumnya digunakan sebagai perangkat penyimpanan untuk sistem file root Linux, sehingga mudah untuk mengintegrasikan driver perangkat ini ke dalam kernel. Namun, dalam sistem tertanam saat ini, sistem file root dapat disimpan ke berbagai perangkat penyimpanan, termasuk SCSI, SATA, U-Disk, dll. Oleh karena itu, jelas tidak nyaman untuk menyusun semua kode driver perangkat ini ke dalam kernel. Dalam modul kernel mekanisme pemuatan otomatis udev, kita melihat bahwa udevd dapat mewujudkan pemuatan otomatis modul kernel, jadi kami berharap bahwa jika driver perangkat penyimpanan yang menyimpan sistem file root juga dapat mewujudkan pemuatan otomatis, itu akan sangat bagus. Namun, ada kontradiksi di sini. Udevd adalah file yang dapat dieksekusi. Tidak mungkin untuk mengeksekusi udevd sebelum sistem file root dipasang. Namun, jika UDEVD tidak dimulai, driver yang menyimpan perangkat sistem file root tidak dapat dimuat secara otomatis, dan simpul perangkat yang sesuai tidak dapat ditetapkan dalam direktori /dev. Untuk menyelesaikan kontradiksi ini, initrd berbasis RAMDISK (bootloader inisialisasi RAM disk) muncul. Initrd adalah direktori root kecil yang dipadatkan. Direktori ini berisi modul driver yang diperlukan, file yang dapat dieksekusi, dan skrip startup pada tahap startup, dan juga menyertakan UDEVD (iblis yang mengimplementasikan mekanisme UDEV). Ketika sistem dimulai, bootloader akan membaca file initrd ke dalam memori, dan kemudian lulus alamat start dan ukuran file initrd dalam memori ke kernel. Selama proses inisialisasi, kernel akan mendekompresi file initrd, kemudian memasang initrd yang tidak di -zip sebagai direktori root, dan kemudian menjalankan skrip /init dalam direktori root (init dalam format cpio adalah /init, sementara initrd dalam format gambar <juga dikenal sebagai initrd dari perangkat blok lama atau initrd dalam format file mirror> adalah format cermat tradisional> adalah /diinisi. Anda dapat menjalankan udevd di sistem file initrd dalam skrip ini, biarkan secara otomatis memuat driver realfs (sistem file nyata) untuk menyimpan perangkat dan membuat node perangkat yang diperlukan di direktori /dev. Setelah Udevd secara otomatis memuat driver disk, Anda dapat memasang direktori root nyata dan beralih ke direktori root ini.
