17
Şub
Chroot olabilmek için gerekli adımları yaparak başarılı bir şekilde chroot olduğumuz geçici kök dosya sistemi üzerinde, kurulan programları tast edebilmek için test araçlarının( Tcl, Expect, DejaGNU ) kurulumunu da yaptıktan sonra kök dosya sistemini oluşturmaya çalışıyoruz.

Sisteme derlemenin temel araçlarından(kernel headers, C kütüphanesi ( glibc veya uclibc veya eglibc ), binutils (linker,assembler) ve gcc) , kernel headers-2.6.30 problemsiz olarak, glibc-2.9 ise " bin/ld: final link failed: Bad value " hatasını çözümleyerek sisteme kurduk.

binutils ve gcc ile test araçlarının çalışabilmesi için PYS nin uyumlu çalışması( host sistemimiz(bizde Debian) yeterli sayıda pseudo terminaline destek vermesi) gerekliliğini öğrendik. Yaptığımız testte doğru sonuç alamadık.
$expect -c "spawn ls"
spawn ls
The system has no more ptys.Ask your system administrator to create mor
Bunun için öncelikle host sistemimizin çekirdeğinin bu desteği verir halinin paketini yapıp kurduk.Host sistemimizdeki test sonucunu "spawn ls" olarak gördük.

Chroot olurken yaptığımız adımlardaki sanal çekirdek için gerekli olan mount adımındaki -f(fake) mountlarını(gerçek bir bağlama işlemi gerçekleşmiyor.);

$mounth -vt devpts devpts $clfs/dev/pts
$mounth -vt tmps shm $clfs/dev/shm


-f siz yaptığımızda chroot olduğumuz sistemimizde de test sonucunu "spawn ls" olarak gördük. Testi geçtik.

Ardından derleme araçlarından binutils ve gcc nin kurulumu ve temel sistem için gerekecek diğer programların(pardus sürümleriyle uyumlu) kurulumunu yaptık.

Oluşturduğumuz 64 bit mimaride çalışan programlar tarafından oluşturulmuş, host sisteme bağımlılığı olmayan temel sistemi tarladık.
(pardus64-rootfs-0.1.tar)

Bir ayı geçkin bir süredir, Necdet Yücel hocamız önderliğinde dört arkadaş (serhat, metin, mete) çok şey öğrendiğimiz ve severek yaptığımız bir iş içindeyiz; Pardusun 64 bit portunu hazırlama. 07.11.2009 cumartesi 6.30 civarında önemli bir aşama kaydettik, 64 bit debian üzerinde pardus üzerinde hazırladığımız geçici sisteme chroot olduk:)

Bu süreç;

Geçici sistemi hazırlamak için üzerinde çalışacağımız sistemin Pardus olması kararını verdikten sonra, çapraz derleme(cross-coppiler) araçlarını(herhangi bir mimaride çalışan ve derleyeceği kodu çalıştığı mimariden farklı bir mimari için derleyebilen) ve bağımlı olduğu kütüphaneleri derledik. Bu adımdan sonra 32 bit mimarideki Pardus üzerinde, kodlarımızı 64 bit mimaride derleyebilir durumdaydık.

Geçici sistem için, host sisteme bağımlılığı olmayacak şekilde çapraz derleyicimiz ile 64 bit mimaride gerekli olan programları -uyum problemi oluşmaması için Pardus un kullandığı sürümlerdeki- ayrı bir dizin içerisine derledik. Host sistemde, 64 bit mimari için derlenen programlar çalıştırılamıyor ve geçici sistemin bulunduğu dizine chroot yapılamıyor çünkü çekirdek 32 bit mimaride çalışıyor.

Bu durumda iki seçenek vardı. Hazırladığımız geçici sisteme 64 bit mimaride çalışan bir sistem üzerinde chroot yapma ya da geçici sistemi boot edilebilir hale getirme. Hedef olarak temel sistemi kullanarak paket oluşturacak olan arkadaşlar için daha kolay bir yol olduğu düşünülerek boot edilebilir bir sistem oluşturma kararını aldık fakat tamamen konsolda çalışmaları gerekecekti.

Boot sürecinde, çekirdek için Pardus tarafından seçilen çekirdek sürümünü ve onun kullandığı yapılandırma dosyasını kullandık. Çekirdeğin 64 bit mimariye destek verebilmesi için 32 ve 64 bit Debian yapılandırma dosyaları arasındaki farkı yapılandırma dosyasına uyguladık.

İnitramfs için Pardus un kullandığı init dosyasını, kaynak kodunu indirip 64 bit olarak derlediğimiz busyboxı ve init kodu içerisinde çalıştırılan diğer programları (coolplug ve disktype) kullandık.

Coolplug; klcc ile derlenmiş, klibc ye bağımlı bir yazılım. Gcc ile derlediğimizde derleme de hata oluştu ve çalışmadı. Host sistemde çapraz derleme yapabilecek klcc oluşturmak yerine; aynı donanım üzerinde çalışacağı ve statik linkleme kullandığı için problem oluşturmayacağını düşündüğümüz, aynı donanım üzerinde koşan 64 bit mimariye sahip bir sistemde(Debian) derleme işlemini yapma seçimini yaptık.

Son haliyle oluşturduğumuz initramfs ile sistemi boot etmeye çalıştığımızda, init dosyasının kodlarıyla ilerleyerek busybox araçlarının ve coolplug programının çalıştığını gördük fakat coolplug ile disk bağlanırken farklı bir hata oluştu.

Sürecin zamanında ilerlemesi amacıyla boot etme sürecini sonraya ertelemeye, 64 bitlik sistemde(Debian) geçici sisteme chroot yapmaya karar verdik. Şimdi paket yapacak olan arkadaşların 64 bit mimaride çalışan bir dağıtım kurmaları ve chroot yapmaları gerekecek fakat sadece konsolda çalışmak zorunda kalmayacaklar.

Sıradaki hedefimiz ise chroot yaptığımız sistem üzerine, temel bir sistem için gereken yazılımları, paket hazırlanabilir halde olması için pisi ve onun bağımlılıklarını kurmak.



16
Kas

Artık temel sistemi oluşturmak için çalışıyoruz. Buraya gelmeden önce, hazırladığımız geçici sistemi 64bit debian üzerine taşıyarak, orada bu geçici sisteme chroot yapmıştık. Bundan sonra da bu 64bit chroot ortamında, temel bir sistemin ihtiyaç duyacağı uygulamaları (tabi ki Pardus sürümleri ile uyumlu olacak şekilde) 64bit derlediğimiz araçları kullanarak, (kısmen Pardus derleme parametrelerine bağımlı kalarak) 64bit derleyeceğiz. Chroot yaptıktan sonra, geçici sistem üzerinde FSH'ye (File System Hierarchy) bağlı kalarak gerekli dosya yapısını oluşturduk. Daha sonra da bazı uygulamaların ihtiyaç duyduğu sembolik linkleri oluşturduk. Şu anda bu sembolik linklerin bir kısmı /tools dizini altını gösteriyor. Bu sembolik linkler sistem üzerinde paketler tekrar tekrar derlendikçe silinecek, yerini kararlı sistemin kullandığı, olması gerektiği gibi olan linkler alacak (/tools dizini sistemden silinecek).

Şu anda sistemdeki tek kullanıcı olan root'un başarılı bir şekilde login işlemini gerçekleştirebilmesi için /etc/passwd ve /etc/group dosyaları oluşturuldu. Ardından da yeni oluşturulan dosya yapısı üzerinde ekstra kernel dosya sistemleri (tmpfs, devpts) bağlandı. Bu aşamadan sonra temel sistemin oluşturulmasına geçmeden önce test takımı araçları yüklendi. Bu sayede sisteme kuracağımız araçların kurulumunu test edebilecek durumda olacağız. Bu amaçla da chroot yaptığımız sistem üzerine sırasıyla TCL, Expect, DejaGNU paketlerini kurduk. Test araçlarını başarılı bir şekilde kurduktan sonra temel sistemi kurma aşamasına gelmiştik. Burada ilk önce Perl paketinin geçici bir kurulumunu gerçekleştiriyoruz. Ardından da Linux-headers ve Man Pages'ı da sorunsuz bir şekilde kurup Glibc'ye geçiyoruz. Glibc'nin kurulumu esnasında birkaç hata ile başetmek durumunda kaldık. Glibc ile ilgili ilk hatayı yapılandırma betiğini çalıştırdığımızda aldık:

/tools/lib/gcc/x86_64-unknown-linux-gnu/4.3.3/../../../../x86_64-unknown-linux-gnu/bin/ld:

/source/glibc-build/elf/librtld.os: relocation R_X86_64_PC32 against undefined hidden symbol`_begin' can not be used when making a shared object

Bu hatayı, Glibc'nin build dizini içerisindeki libc/elf/Makefile dosyasının şu satırlarını değiştirerek aştık :

— libc/elf/Makefile 2008/10/31 20:35:11 1.330

+++ libc/elf/Makefile 2009/01/31 00:20:55 1.331

- -e ’s/\. = 0 + SIZEOF_HEADERS;/& _begin = . - SIZEOF_HEADERS;/’ \

+ -e ’s/\. = .* + SIZEOF_HEADERS;/& _begin = . - SIZEOF_HEADERS;/’ \

Bunun ardında make hatasız çalıştı; ancak make install dediğimiz zaman şu hata ile karşılaşıyoruz :

[some lines stripped]

Offending line of ldd output: libgcc_s.so.1 => /tools/lib/libgcc_s.so.1

[some lines stripped]

Bu hatanın çözümü için sembolik linkleri tekrar oluştursak da, Glibc libgcc_s düzgün bir şekilde kurulamadığından şikayet ederek hata veriyordu. Bu hata libgcc_s.so.1 için birincil kütüphane olarak link oluşturulabilmesi için sadece /lib ya da /usr/lib altını geçerli kabul ettiğinden (şu anda /tools altına link verilmiş durumda) ve de binutils ve gcc kurulumlarında bu linkleme işlemlerinden kurtulacağımız için ilerlemeye devam ettik.

Glibc'nin kurulumu ardından GCC spec dosyalarını, yeni dinamik bağlayıcıyı gösterecek şekilde ayarlıyoruz. Bunun ardından da GMP, MPFR ve ZLib kurulumunu başarılı bir şekilde gerçekleştiriyoruz. Sıra Binutils kurulumuna geldiğinde daha ilk satırda PTY'lerin (pseudo terminals) doğru bir şekilde çalışıp çalışmadığı kontrolü expect -c "spawn ls" komutuyla yapılıyordu; ancak şu hata ile karşılaştık :

The system has no more ptys.Ask your system administrator to create more.

Daha sonra bu hatayı düzeltmek için araştırma yaptığımızda şuraya ulaşıyoruz :

http://www.linuxfromscratch.org//lfs/faq.html#no-ptys

Buradan yola çıkarak, testler için gerekli olan, daha fazla sayıda terminal elde etmek için üzerinde chroot yaptığımız debian çekirdeğin yeniden yapılandırılması gerekiyordu. Bu yüzden üzerinde çalıştığımız, host sistem görevini üstlenen debian-5 lenny üzerinde çekirdek kaynak kodu indirip, config dosyasında şu değerleri ayarladıktan sonra tekrar yapılandırıp, derliyoruz :

CONFIG_UNIX98_PTYS=y

CONFIG_DEVPTS_FS=y

Bu derleme işleminde oluşan çekirdeği kullanarak boot ettiğimiz debian üzerinde, temel sisteme tekrar chroot yaparak expect -c "spawn ls" komutunu verdiğimizde aynı hatayı almaya devam ediyorduk. Bu durumda derleme işleminin başarısız olduğunu düşünüp, tekrar derleme yapıp aynı komutları çalıştırdığımızda yine hata alınca, bu komutları direkt debian üzerinde çalıştırmayı denedik ve hatasız çalıştı. Çekirdeğin derlenmesi ile ilgili bir problem olmadığını gösteren bu durum, bizi chroot yaptığımızda kernel dosya sistemlerinin bağlanması sırasında bir hata olabileceği ihtimaline yönlendirdi. Sonuçta da kernel (sanal) dosya sistemleri chroot yapmadan önce olması gerektiği gibi bağlanmıyordu.

mount -f -vt devpts -o gid=4,mode=620 devpts ${CLFS}/dev/pts komutunun "-f" parametresi ile "fake" mount yapılıyordu, Bu da /dev/pts nin chroot ortamı üzerinde gerçekten mount olmamasına sebep olup, chroot içersinde de çalıştırdığımız komutun no more ptys hatası ile sonuçlanıyordu. Artık çekirdeği tekrar derlemeye gerek olmadan kernel dosya sistemlerini (/dev/pts ile tmpfs) bağladıktan sonra geçici sisteme chroot yapıp, Binutils kurulumuna devam ettik. Ardından da [1] de listelenen geri kalan paketleri sırasıyla chroot yaptığımız temel sistem üzerinde kurduk.

Temel sistemin kurulumu sona erdikten sonra artık genel Linux kurulumları ile ilgili kısmın da sonuna gelmiştik. Bundan sonra artık daha Pardus ağırlıklı bir yol izleyeceğiz. Öncelikle COMAR ve PISI'nin bu 64bit temel sistem üzerinde ayağa kaldırılması için çalışacağız. Bunun için de PISI ve COMAR'ın bağımlılıklarını çıkarıp, bunları chroot yaptığımız temel sistem üzerinde 64bit derlemek için çalışmalara devam ediyoruz. Bu amaçla önce bir bağımlılık ağacı oluşturduk. Hemen ardından bu veriler doğrultusunda toolchain olarak adlandırdığımız kernel-headers, glibc, binutils ve gcc'yi (ilave olarak make'i) chroot yaptığımız temel sistem üzerinde, pspec.xml ile belirtilmiş yamaları uygulayıp, actions.py'de yazan direktiflerle derleyerek (tabi 64bit için gerekli parametreleri uygulayarak) sisteme tekrar kurduk. Burada da amacımız bu temel araçların Pardus üzerinde çalıştığı şekilde oluşturulması ve bağımlılıkların minimuma indirilmesiydi. Bu işlemleri tüm araçların yeni derlenmiş halleri ile birbirini derleyip, tüm bağımlılıklardan kurtuluncaya kadar devam edeceğiz.

[1]http://tr.pardus-wiki.org/X86_64-64_Mimarisine_Port_Edilmesi#K.C3.B6k_Dosya_Sisteminin_Haz.C4.B1rlanmas.C4.B1

8
Kas
Yaklaşık 1 aydır üzerinde çalıştığımız projenin, hedeflediğimiz doğrultuda ilk sonucuna dün akşam ulaştık. Şu anda, 64bit Pardus için hazırladığımız geçici sisteme, 64bit Debian (Debian 5 - Lenny) üzerinde chroot gerçekleştirebiliyoruz.

Derleme araçlarını ve geçici sistemi oluştururken izleyeceğimiz yol ve yöntemler birkaç kez değişmek zorunda kaldı aslında. Çalışmalara başlamadan önce nasıl ilerleyeceğimiz konusunda, geçici bir sistem oluşturup, ardından da bu ortama chroot yaparak çalışmalara devam edeceğimizi düşünüyorduk. Çünkü; üzerinde 64bit paket derlenebilecek, chroot edilebilir geçici bir sistem oluşturmak paket derleyecek arkadaşlar için daha rahat bir geliştirme ortamı sunacaktı. Çalışmalar ilerledikçe bunun bizim planladığımız geliştirme ortamı açısından mümkün olamayacağını öğrendik. Çalışmaları üzerinde yürüttüğümüz sistem ile oluşturacağımız hedef sistem farklı mimari olacağından, chroot yapmak mümkün olmayacaktı. Oluşturulacak sistemin boot edilebilir şekilde geliştirilmesi gerekiyordu. Ardından da bu yönde ilerlemeye devam ettik. Bu arada, çalışmalara Pardus 2008'in portu için başlamışken, daha sonra kurumsal sürümün Pardus 2009 olmasından dolayı biz de yönümüzü o tarafa çevirdik. Aslında değişen pek de fazla bir şey olmadı; çünkü henüz geçici sistem aşamasındaydık. Bu yüzden de daha önceden yaptığımız işlemleri Pardus 2009 için tekrarlamış olduk bir kez daha.

Boot etme doğrultusunda çalışmalarımızı sürdürürken, neredeyse bir haftadan uzun bir süredir geçici sistemi boot etmeye çalışıyorduk. Oluşturduğumuz geçici sistem üzerindeki tüm araçlar çapraz derlenmiş 64bit derleyiciler ile oluşturulmuş ve çalıştırabilir dosyalar da statik olarak bağlanmıştı. Ancak; boot etme süreci başarısızlıkla sonuçlanıyordu. Boot için oluşturduğumuz initramfs üzerindeki init biraz oynayıp, debug bilgileri elde edince coolplug isimli, donanımı inceleyerek gerekli çekirdek modüllerini yükleyerek nodları oluşturan Pardus aracından kaynaklı bi hata olduğunu yakalayıp onu düzeltmeye çalıştık. Coolplug olması gerektiği şekilde 64bit ve statik bağlanarak derlenememişti. Bir süre bununla uğraşmak durumunda kaldık; çünkü bir çok bağımlılığı vardı. Coolplug'ı derlemek için klcc'yi (ve onun da bağımlılıklarını hallettikten sonra) çapraz derleme yapabilecek şekilde derledikten sonra, onu kullanarak coolplug'ı derlememiz gerekiyordu. Ancak, tüm bağımlılıkları 64bit ortam için sağlayasak bile, coolplug'ı derlemek için elimizdeki geçici sistemi kullanamazdık; çünkü henüz boot edemiyorduk (zaten sorun da buydu (:). İşleri daha da seri hale getirebilmek için 64bit Debian üzerinde klcc kullanarak, coolplug'ı statik bağlayıp derledik ve bu çalıştırabilir coolplug'ı geçici sistemde yerine koyduk. Artık boot edebilmeliyiz derken, coolplug hatası bizi yine üzdü. Uzun uğraşlara rağmen bu hatayı aşamadığımızdan dolayı, chroot yapabilmeyi denedik; hatta "bugün, chroot yapmadan gitmeyelim !" dedik (:

Öncelikle util-linux-ng'yi (dosya sistemleri, konsollar, disk bölümleri gibi yerleri yönetmek için çeşitli araçları içeren koleksiyon) chroot için özelleştirerek, tekrar derleyip ardından da elimizdeki geçici sistemi 64bit Debian üzerine taşıdık. /proc ve /sys'yi bağladık. Chroot için ilk denememizde "libgcc_s.so.1" bulunamadı şeklinde bir hata aldık. Bunun sebebi de geçici sistem üzerinde "lib64" isimli bir dizinden yapılan sembolik linkin hata vermesiydi. lib64 içeriğini lib içine kopyalarak chroot yapmayı denediğimizde, artık kendimizi geçici sistem üzerinde "root" kullanıcısı olarak görebiliyorduk (:

Rootfs oluşturma çalışmalarına artık bu chroot ortamı üzerinden devam edeceğiz.
21
Eki
Çanakkale 18 Mart Üniversitesi, bilgisayar mühendisliği son sınıf öğrencilerinden biri olarak, Necdet Yücel hocamızın önderliğinde, yaz başlarında duyurulan Pardus'un 64bit portunu hazırlama çalışmalarına birkaç hafta önce başladığımızı duyurmak istiyorum. Şu anda iki grup olarak yürütmeyi planladığımız çalışmaların ilk grubunda Meltem Parmaksız, Serhat İrem Ersel ve de Mete Bilgin ile beraber gerçekten verimli ve bir o kadar da eğlenceli bir ortamda çalışmalara devam ediyoruz. Öncelikle şunu söylemeliyim ki, bu proje ile bu kadar kısa bir sürede bile bir çok şey öğrendiğimize ve de daha öğreneceğimiz bir çok şey olduğuna inanıyoruz. Yaptığımız çalışmaları belgelendirip, neler ile uğraştığımızı iyi bir şekilde açıklayabilmek amacıyla çalışmalar üzerinde her adımı tartışıp, detaylar üzerinde uzun uzun konuşmamak kaçınılmaz oluyor doğal olarak. Kimi zaman derlenecek araçların beklenmedik bağımlılıkları çıkıyor; o bağımlılıkların da başka başka bağımlılıkları. Ve üstüne üstlük uygun sürüm arayışı da işin içine girince, bazen çalışma tahtamızda nokta koyacak kadar bile yer kalmadığını fark ediyoruz. Belki de okuldan daha fazla vakit geçirdiğimiz, ki gerçekten öyle, çalışma masamızda neler ile uğraştığımızı fırsat buldukça da paylaşmaya çalışacağız.

Geliştirme sürecinde nasıl bir yol izlememiz gerektiğini CLFS (Cross-Compiled Linux From Scratch ) belgesinden takip ediyoruz. "O da ne?" diyen arkadaşlara, bu belgenin içeriği ile ilgili güzel ve detaylı bir yazı dizisi hazırlayan Serhat arkadaşımızın günlüğüne bakmalarını tavsiye ediyorum.

Geçen süre zarfında çalışmalarımızın temelini oluşturan ve en çok yaptığımız işlem ise çapraz derleme (cross-compile). Hakkında detaylı bilgiye buradan ulaşabileceğiniz çapraz derleme, özet olarak üzerinde çalıştığımız mimariden (host), farklı bir mimari (target) için derleme yapma işi. Çapraz derlemede uygulamalar "host" üzerinde derleniyor; ancak "target" üzerinde çalıştırılabiliyor. Örneğin, eğer isterseniz x86 mimari üzerinde çapraz derleme ile PowerPC için sistem geliştirebilirsiniz; zaten dağıtımların günümüzde birçok mimariyi destekleyen paketleri yapma işi de bu şekilde gerçekleştiriliyor. Gömülü sistemler için geliştirme yapılırken de çapraz derlemeden yararlanıldığını görüyoruz. Pardus'u 64bit'e port etme sürecinde Pardus-2008'i kuluçka sistem olarak kullanacağız. Bu yüzden oluşturacağımız hedef sistem üzerindeki tüm araçlar da Pardus-2008'de hangi kararlı sürümü ile kullanılıyorsa o sürümü ile oluşturulacak. Ancak, çapraz derleme araçlarında böyle bir zorunluluk bulunmuyor; sonuçta onlar sadece hedef sistemi oluşturmak için geçici sistem üzerinde kullanılacak ve daha sonra silinecekler. Ancak; biz yine de bu çalışmalarımızda sürüm uyumunun her aşamada korunmasında bir sakınca görmedik.

Gelelim 3. haftasını geride bıraktığımız çalışmalarda neler yaptığımıza ve Pardus-64bit geliştirme sürecinde nerede olduğumuza. Pardus-2008'i kuluçka sistem olarak alıp, onun üzerinde önce çapraz derleme araçlarını oluşturup (gcc,glibc,binutils, ...), ardından da bu çapraz derleme araçlarını kullanarak, temel ve geçici bir sistem oluşturmayı başarabildik. Bu geçici sistem (sadece gcc, make, bash gibi komutların olduğunu düşünürsek) şu anda çok minimal bir ortam olmakla beraber, hedeflediğimiz şekilde üzerinde Pardus-64bit sistemi geliştirebileceğimiz, 32bit paketleri 64bit olarak hazırlayabileceğimiz bir ortam olacak. Ama; bunun için henüz erken tabi ki. Şimdi bu minimal sistemi nasıl kullanmamız gerektiği üzerinde çalışıyoruz: Bu minimal sisteme "chroot" yapmak ya da makineyi bu sistem ile "boot" etmek? Bu konu üzerinde uzun süre kafa yorduk."chroot" yapılan bir ortam sağlamak paket yapma işinde çalışma ortamını çok kolaylaştıran bir seçenek olmakla beraber, daha sonra bunun mümkün olamayacağını öğreniyoruz. Çünkü; farklı bir mimari için sistem geliştiriyorsak, yani "host" sistem ile "target" sistem birbirinden farklı mimariler ise "chroot" yapılamıyor. "chroot" seçeneğinin, üzerinde çalışılan mimari ile geliştirilecek mimari benzer olduğunda ve de aynı sürüm çekirdek kullandığında mümkün olduğunu öğreniyoruz. Biraz daha ayrıntıya girmek gerekirse, "chroot" seçeneği için GCC 3.0 (veya daha yeni bir sürüm) ile derlenmiş Linux 2.6.x çekirdeği gerekiyor. Bu sağlanmadığı zaman Binutils'de TLS (thread-local storage) desteği inşa edilemiyor ve NPTL (Native POSIX Threading Library) test takımı segmentasyon hatası ile sonuçlanıyor. Bu yüzden, bundan sonra artık bizim izlememiz gereken yol ise makineyi elimizdeki minimal sistem ile "boot" etmek ve geliştirme sürecine bu şekilde devam etmek. Şimdilerde elimizdeki sistemi "boot" edilebilir hale getirmek için uğraşıyoruz. Daha sonraki aşamalarda da bu minimal sistemin, üzerinde paket derlenebilir hale getirilmesi için çalışmalara devam edeceğiz.

Son olarak, kısa bir süre içerisinde, elimizdeki çalışan minimal sistemi "boot" edebilme hedefimizi gerçekleştirerek, devamında da daha detaylı bir yol haritası sunmayı planladığımızı belirtmek istiyorum.