Sistem Güncelleme ve Çekirdek İşlemleri
From OpenBSD Belgeleme Projesi
OpenBSD'nin Çeşitleri
Üç “çeşit” OpenBSD vardır:
- -release: Altı ayda bir çıkan OpenBSD sürümü.
- -stable: Realese sürümüyle birlikte güvenlik ve çalışma açısından kritik olan yamalar.
- -current: Yeni geliştirme süreci devam ederken yayınlanan, sonucunda bir sonraki release olacak sürüm.
Eğer bu türlerin oluşumunu bir grafik ile gösterirsek, aşağıdaki gibi bir durum oluşur:
bu türlerin oluşumunu bir grafik ile gösterirsek, aşağıdaki gibi bir durum oluşur:
,------o-----------o----X 3.5 Stable
| . .
| . ,------o---------o----X 3.6 Stable
| . | . .
| . | . ,----o----------o--> 3.7 Stable
| . | . | . .
| . | . | . ,-----o--> 3.8 Stable
| . | . | . | .
| . | . | . | .
-->3.5Rel----->3.6Rel----->3.7Rel----->3.8Rel----> Current
Zaman --->
-Current aktif geliştirme sürecinde yayınlanır ve en sonunda bir sonraki OpenBSD -release sürümü olur. Her altı ayda bir, OpenBSD’nin yeni bir sürümü yayınlandığında -current etiketi kaldırılır ve yerine -release etiketi konur: kaynak ağacının tarihi hakkında bir hatırlatma. Hiçbir -release sürümü değiştirilmez, CD ve FTP sunucularında ne varsa aynısıdır.
-Stable, -release sürümüne dayanır ve OpenBSD’nin temel geliştirme işleminin bir şubesidir. Eğer -current sürümünde çok fazla önemli düzeltme yapılırsa, bunlar -stable şubesine "geri yollanır" (eklenir), bu yüzden -stable sürümleri ayrıca "yama sürümü" olarak da bilinir. Yukarıdaki gösterimde dikey noktalı çizgiler bug düzeltmelerinin -stable şubeleriyle birleşmesini belirtir. Yine yukarıdaki örnekten görebileceğiniz gibi, 3.5-stable sürümü 3.7-release ile ve 3.6-stable sürümü 3.8-release sürümünün çıkması ile sona ermiştir – eski sürümlerin desteklenmesi genel olarak iki önceki sürüme kadar olmaktadır. Eski sürümler için devamlı destek sağlamak zaman ve kaynak harcamasına sebep olduğundan, daha çok yeni özelliklere odaklanmayı uygun görüyoruz. -stable sürümü tasarımı gereği aynı -release sürümünden kolaylıkla oluşturulabilir (örneğin, 3.8-release’ten 3.8-stable’e geçmek).
-stable sürümü -release sürümüyle birlikte errata sayfasında bulunan bazı yamalar ile errata sayfalarıyla ilgili olmayan bazı basit düzeltmeleri içerir. Genellikle, -stable sürümünün işleyişi -release’in oluştuğu temel ile aynıdır. Eğer man sayfalarının değişmesi gerekiyorsa, bu büyük ihtimalle -stable sürümüne eklenmez. Başka bir deyişle, -stable sürümüne yeni aygıt desteği EKLENMEZ, yeni özellik desteği ise eğer çok önemli bulunmadıysa nadiren eklenir.
"-stable" isminin -current sürümünün güvenilir olmadığını göstermediğini belirtmekte bir yarar var. Aslında, -current sürümü değişip gelişirken, -stable sürümünün işeyişi hiçbir zaman değişmez, yani sisteminizin nasıl çalıştığını tekrar öğrenmenize veya yeni konfigurasyon dosyaları oluşturmanıza gerek kalmaz. Gerçekten, bizim hedefimiz OpenBSD’yi sürekli geliştirmek olduğundan, -current sürümünü -stable sürümüne göre daha yararlı bulabilirsiniz.
Dikkat: -current sürümü hareketli bir hedeftir. Her dakika değişir, ve sizin kaynak kodlarını edindiğiniz süre içerisinde defalarca değişebilir. Geliştiriciler sistemin derlenebilirliğinden ve çok önemli bugların olmamasından emin olmak için çok fazla çalışırlarken, edindiğiniz -current kaynağını derleyememeniz ve beş dakika sonra her şeyin çalışması da olağanlık dahilindedir. Ayrıca, bayrak günleri ve büyük sistem değişiklikleri gibi geliştiricilerin önemli çalışmalar yaptıkları zamanlar olacaktır, bu durumda kaynak-tabanlı güncelleştirmeler mümkün olmayacaktır. Eğer bunlara hazır değilseniz, -current sürümünden uzak durun.
Çoğu kullanıcı -stable veya -release sürümlerini kullanırlar. Bununla birlikte, pek çok insan -current sürümünü üretim sistemlerinde kullanır ve bazı insanlar için bugları bulmanın veya yeni özellikleri test etmek daha önemlidir. Ancak, eğer problemi nasıl tanımlayacağınızı, nasıl teşhis edeceğinizi ve nasıl çözeceğinizi bilmiyorsanız, kendisinize (veya başka birisine) -current sürümünü kullanarak "projeye yardım ediyorum" demeyin. "Bu çalışmıyor" cümlesi yararlı bir bug raporu değildir. "Pciide sürücülerinde yapılan bazı değişimler benim Slugchip-tabanlı IDE arayüzümün uyumluluğunu bozdu, çalışan ve çalışmayan sistemlerin dmesg çıktıları aşağıdaki …" yararlı bir rapor olabilir.
Bazı durumlarda ise "normal" kullanıcılar uç noktalarda yaşamak isterler ve -current sürümü kullanırlar. Bunun en yaygın sebebi kullanıcının -release’in desteklemediği (ve böylece, -stable’da da olmayan), bir cihaza sahip olması, yada -current sürümündeki bir yeni özelliği kullanmak istemesidir. Bu durumda, çözüm -current sürümü veya cihazı kullanmamak olacaktır ki, -current kullanmak daha iyi bir çözüm gibi gözükür. Ancak, kimse geliştiricilerden işe el atmasını beklemelidir.
Snapshot’lar
OpenBSD’nin resmi sürümleri dışında, bazı FTP sitelerinde snapshotlar yayınlanmaktadır. Adından da anlaşılacağı gibi bunlar, herhangi bir anda kaynak ağacında bulanan belirli bir platform için geliştirilmiş koddan alınıp oluşturulur. Unutmayın ki, bazı platformlar için sbapshot’ların hazırlanıp dağıtıma sunulması GÜNLER alabilir. Snapshot’ların çalışabilir veya yüklenebilir olduğuna dair bir garanti yoktur. Genellikle, koddaki bir değişiklik yeni bir snapshot oluşturulmasına sebep olur. Bazı platformlar için snapshot’lar neredeyse günlük oluşturulurken, bazıları için bu süre daha uzundur. Eğer -current sürümünü kullanmak istiyorsanız, en güncel snapshot ihtiyacınız olan tek şey olabilir ve sisteminizi bir snapshot’la yükseltmek kaynak kodundan -current sürümüne geçmeden önce yapılması gereken bir işlemdir.
Bazen kullanıcılar bir snapshot oluşturmak için kullanılan kodun tam olarak aynı kopyasını bulup bulamayacaklarını sorarlar. Cevap, hayır olur. Öncelikle bunu yapmanın özel bir yararı yoktur. İkincisi, snapshot’lar isteğe göre oluşturulurlar, zaman elverdiği ve kodların ulaşılabilirliğinin olduğu sürece. Hızlı donanım platformlarında, günde birkaç adet snapshot yayınlanabilir. Yavaş olanlarda ise, bu süre haftalara kadar uzayabilir. Her Snapshot’ta onu oluşturana ait kaynak kodundaki etiket veya işaretler genellikle farklı olacaktır.
İşleri Senkron olarak yürütmek
OpenBSD’nin bütün halindeki bir işletim sistemi olduğunu anlamak çok önemlidir, sadece çekirdek ve birkaç uygulamadan oluşan bir paket değil. Çekirdeğinizin, “kullanıcı alanınızın” (desteklenen uygulamalar ve dosyalar) ve port ağacınızın senkron olarak çalıştığından emin olmalısınız, yada istenmeyen olaylar gelişecektir.
Başka bir deyişle (İnsanlar sürekli hata yaptıklarından), sadece bir aylık olan sistemdeki yepyeni portları kullanamazsınız, ya da çekirdeği -current sürümü ile derleyip daha sonra -release sürümü kullanıcı alanıyla çalışmasını beklersiniz. Evet, bunun anlamı eğer port ağacına yeni eklenmiş bir programı yüklemek istiyorsanız, sisteminizi güncellemeniz gerekecektir. Üzgünüz, ama yine hatırlatalım, OpenBSD kısıtlı imkânlara sahiptir.
Şunu anlamalıyız ki, bu güncelleme işi sadece tek yönlü olarak gerçekleşir: eskiden yeniye, ve -stable sürümden -current sürümüne doğru. 3.8-current sürümünü (veya bir snapshot’ı) kullanırken birden çok tehlikeli bir iş yaptığınızı düşünüp, sisteminizi 3.8-stable sürümüne güncelleyemezsiniz. Sisteminizi derme çatma bir bölümden yeniden yüklemek gibi desteklenmeyen bir yol seçmek konusunda yalnız başınasınız, OpenBSD geliştirme takımından yardım beklemeyin.
Evet, bunun anlamı -current sürümünü kullanmadan önce uzun ve iyice düşünmeniz gerektiğidir.
Sistemimi neden kaynaktan derlemeliyim?
Aslında, çok büyük ihtimalle buna gerek duymazsınız.
Kaynaktan derleme YAPMAMAK için bazı sebepler:
- Sistem yükseltmek amacıyla kendi sisteminizi derlemek desteklenmez.
- Kendi sisteminizi derleyerek daha iyi bir performans elde EDEMEZSİNİZ.
- Derleyici seçeneklerini değiştirmek sisteminizi geliştirmek yerine büyük ihtimalle çalışmaz duruma getirecektir.
Kaynaktan derleme yapmak istetecek veya zorunda bırakacak bazı sebepler:
- Yeni özellikleri test etmek ya da geliştirmek.
- Sisteminizi derlemek bilgisayar büyük baskı yükler, bu yüzden bazen kaynaktan derleme oluşturduğunuz sistemin doğru şekilde çalışacağının güvencesini oluşturur.
- Stable şubesini izlemek isteyebilirsiniz.
- Bazı özel uygulamalar için OpenBSD’nin özelleştirilmiş olarak yüklemek isteyebilirsiniz.
OpenBSD takımı -current koduna dayanan snapshot’ları temel olarak tüm platformlar için yayınlar. Büyük ihtimalle bu -current sürümünü kullanmak için kullanacağınız tek şeydir.
Kaynaktan derlemenin en belirgin sebeplerinde biri de -stable şubesini takip etmektir, çünkü sadece kaynaktan derlemeyi destekler.
OpenBSD’yi kaynaktan oluşturma
Oluşturma işleminin bir özeti
OpenBSD’nin kaynaktan kurulması birkaç aşamadan oluşur:
- En yakın güncel sürüme yükseltme.
- Uygun kaynak kodunun edinilmesi.
- Yeni çekirdeğin oluşturulması ve boot edilmesi.
- "Kullanıcı alanı"nın oluşturulması ("make build").
Bazı kullanıcıların yükseltme amaçları ve X uygulamasını yükleme isteğine göre yapmak isteyeceği bir çift ek aşama da vardır:
- Bir "realese" sürümünü kurma.
En yakın güncel sürüme yükseltme ve kurma
Kaynaktan kurulumun birinci aşaması en yakın güncel sürümün yüklü olduğundan emin olmaktır. Aşağıdaki tabloyu nerede olduğunuzu, neyi amaçladığınızı ve hangi ikili dosyalar ile başlamanız gerektiğini belirlemek için kullanın:
Başlangıç Hedef İkili dosya güncelleme Sonra Eski -release Yeni release En yeni release Tamam! -release -stable En yeni release -stable indir ve kur. Eski -stable -stable En yeni release -stable indir ve kur. -release -current En son Snapshot (isteğe bağlı) -current indir ve kur. Eski -current -current En son Snapshot (isteğe bağlı) -current indir ve kur.
İkili dosya güncellemesini yükleme medyasındaki "Upgrade" seçeneği ile yapmanız önerilir. Eğer bu mümkün değilse, ikili dosyaları burada gösterildiği gibi de oluşturabilirsiniz. İki türlü de, tüm yükseltme işlemini yeni kullanıcı ekleyerek ve /etc dizini değişikliklerini yaparak tamamlamalısınız.
Uygun kaynak kodunun edinilmesi
OpenBSD kaynak kodları CVS sürümü bir kontrol sistemi ile yönetilir ve cvs(1) istenilen kaynak kodu ağacının bir kopyasının kendi makinenizde derlenmek üzere indirmenizi sağlar. Bu işlem AnonCVS sunucusu kullanılarak (OpenBSD projesi içinde kullanılan tüm kaynak ağacına erişebileceğiniz bir makine.) veya CVSup ve CVSync gibi paket olarak edinilebilen programlar aracılığıyla yerel bir makineden yapabilirsiniz. CVSup ayrıca " checkout " modunda da kullanılabilir, ama burada bahsedilmeyecektir. Eğer kaynak kod ağacı sağlamak istediğiniz birden fazla makine var ise, CVSup veya CVSync ile kurulup yönetilebilen yerel bir CVS deposu kullanmak işinize yarayabilir.
Hangi AnonCVS sunucusunu kullanmak istediğinize karar verdikten sonra, kaynak ağacınızda " checkout" ile denetleme yapmak zorundasınız. Daha sonra, "updates" ile güncelleştirilmiş dosyaları yerel ağacınıza ekleyebilirsiniz.
CVS(1) komutu birçok seçeneğe sahiptir, bunlardan bazıları kullanışlı bir kaynak ağacının denetlemesi ve güncellenmesi için gereklidir. Diğer komutlar ağacın bozulmasına yol açabilir. Burada talimatları anlamak ve izlemek önemlidir.
-current sürümünü takip etmek
Bu örnekte, açık bir AnonCVS sunucusu kullandığımızı varsayacağız: anoncvs@anoncvs.example.org:/cvs.
Aynı zamanda sizin sh(1) kabuğunu kullandığınızı da varsayıyoruz, eğer farklı kabuk kullanıyorsanız bazı komutları değiştirmek zorundasınız.
-current sürümünün CVS kaynak ağacını edinmek için, şunu uygulayabilirsiniz
# cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -P src
Ağacı indirdikten sonra, güncelleme işlemini yapabilirsiniz:
# cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -Pd
-Stable sürümünü takip etmek
Eğer alternatif bir kaynak ağacı "şubesini" denemek isterseniz, mesela –stable şubesi gibi, denetleme işleminde bir "-r" değişikliği yapmanız gerekecektir:
# cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -rOPENBSD_3_8 -P src
Bu işlemler OPENBSD_3_8 şubesinin, başka deyişlerle "yama şubesi" yada "-stable" kaynak dosyalarının edinmenizi sağlar. Kodları benzer şekilde güncelleyebilirsiniz:
# cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -rOPENBSD_3_8 -Pd
Aslında, CVS denetlenen dosya sistemine bir "işaret" atacak kadar naziktir; yani eğer bilerek bayrağı temizlemez veya "update" komutunda "-A" seçeneğini kullanmazsanız, komuttaki "-rOPENBSD_3_8" kısmını ezberlemek zorunda değilsiniz. Ancak, CVS komut satırına daha fazla seçenek kullanmak daha az kullanmaktan daha iyidir.
Şu ana kadar sadece "src" ağacı anlatıldıysa da, aynı işlemleri "XF4" ve "ports" için de tekrarlayacaksınız. OpenBSD’nin tüm kısımlarının senkron olarak çalışması için, tüm ağaçların aynı anda denetlenmesi ve güncellenmesi gerekir. Denetlemeleri tek satırdan oluşan komut halinde yapabilirsiniz (-stable için):
# cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -rOPENBSD_3_8 -P src ports XF4
Ancak, güncellemeler her dizin için ayrı olarak yapılmalıdır.
Bu noktada, -stable veya -current sürümlerinden bağımsız olarak elinizde kullanışlı bir kaynak ağacı bulunmalıdır. Hangi ağacı edindiğinizden emin olur -- -stable sürümünü hedeflerken -current sürümünü derlemeniz çok mümkündür.
Ağacı önyükleme: src.tar.gz, sys.tar.gz
Tüm kaynak ağacını AnonCVS sunucusundan indireceğiniz gibi, OpenBSD CD’si ve FTP sunucusundaki kaynak dosyalarını "önyükleyerek" hem zaman hem de bandwitdh kazanmış olursunuz. Bu eğer -stable sürümü kullanıyorsanız geçerlidir ve sürümler ve –release şubesi ile aralarında sadece birkaç dosya farkı vardır. Kaynak ağacını CD’den /usr/src dizinine aktarmak için(CD’nin /mnt dizinine aktarıldığı varsayılarak):
# cd /usr/src; tar xzf /mnt/src.tar.gz # cd /usr; tar xzf /mnt/XF4.tar.gz # tar xzf /mnt/ports.tar.gz
Kaynak dosyaları FTP sunucularından ağacın sadece bir parçası ile ilgilenenlerin indirme süresini azaltmak amacıyla iki ayrı dosya olarak indirilebilir. Bu dosyalardan sys.tar.gz çekirdeğin oluşturulması için kullanılan dosyaları ve src.tar.gz ise, "kullanıcı alanı" uygulamaları ve diğer port ağacı ve X11 kaynakları hariç diğer dosyaları içerir. Ancak, genellikle bu iki dosyanın birlikte yüklenmesini istersiniz. src.tar.gz ve sys.tar.gz /usr dizinine indirildiği varsayıldığında:
# cd /usr/src # tar xzf ../sys.tar.gz # tar xzf ../src.tar.gz # cd /usr # tar xzf XF4.tar.gz # tar xzf ports.tar.gz
Çoğu kullanıcı tüm dosyaları açmak istemez, ancak sistemi senkron tutmak gerektiğinden ağacın tüm bölümlerini kurmak ihtiyacını duyarsınız.
Bilinen CVS ipuçları
Daha önceden belirtildiği gibi, geçerli bir OpenBSD src ağacının elde edilmesi için bazı seçeneklerin kullanılması zorunludur. Yukarıdaki "-P" seçeneği bunlardan biridir: Bu seçenek, boş dizinleri "budar" (temizler). Seneler boyunca, OpenBSD kaynak ağacında dizinler yaratılmış ve silinmiştir ve bazı eski dizinlerin isimleri şu an dosya ismi olarak kullanılmaktadır. "-P" seçeneğini kullanmadan, ağacınız başarıyla DERLENEMEZ.
Benzer durum 'update' komutundaki -d seçeneği için de geçerlidir – son denetlemenizden sonra ağacınıza eklenmiş olabilecek dizinleri yaratır.
Tecrübeli CVS kullanıcıları neden CVSROOT’un belirlenip kullanıldığını merak edebilirler, çünkü cvs(1) denetlenmiş ağaç için CVS sunucusunun yerini kendisi belirleyecektir. Bu doğrudur, ama pek çok durumda kullanıcılar öntanımlı anoncvs sunucusundan farklı sunucuları denemek isterler ve birçok insan CVS deposunun önceden belirtilmesini tavsiye eder. Ayrıca, CVSROOT değişkeninin doğrudan cvs(1) komutu ile birlikte kullanılabileceği gibi, burada sadece başka bir şeyin onu çiğnemediğini görmek için kullanılmıştır, (bu durumda kullanılmasaydı, cvs(1) hata verecekti.) fakat cvs(1) komutunda kullanılması diğer tüm değerleri çiğneyecektir.
Bu örnekte dikkat edilmesi gereken, up komutu ile -Pd seçeneğinin kullanılmasıdır. Bu da yine, şu anda son denetlemenizde olmayan ve oluşturulmamış yeni dizinlerin güncelleme işleminde yaratılmasını sağlayacak ZORUNLU seçeneklerdendir.
Ana (home) dizininizde bir .cvsrc kullanmanız genellikle öntanımlı seçenekleri belirlemek için yararlıdır. ".cvsrc" dosyasına bir örnek:
$ more ~/.cvsrc cvs -q -danoncvs@anoncvs.example.org:/cvs diff -up update -Pd checkout –P
Bu dosya ile cvs(1) komutu anoncvs@anoncvs.example.org:/cvs sunucusuna bağlanacak, tüm işlemler için istenemeyen çıktıları engelleyecek ("-q", "sessiz" için), "cvs up" komutu -Pd seçeneğini kullanmayı öntanımlayacak, "cvs diff" komutu "birleşmiş diff’lerin kullanılmasını zorlayacak ve "cvs checkout" komutu da "-P" seçeneğini kullanarak çalışmış olacaktır. Bu uygun olmakla birlikte, bu dosyanın varlığını unutursanız ya da bu dosyaya sahip olmayan diğer makinelerde aynı çalışmayı beklerseniz, problemlerle karşılaşırsınız. Kaynak ağacı çok sayıdaki ufak boyutlu dosyalardan oluştuğundan, kaynak kodunun bulunduğu disk bölümü için soft updates özelliğinin aktif edilmesi çoğu durumda daha iyi performans sağlar.
Üstteki işlemin değişimleri: Salt-oku kaynak ağacı
Bazen /usr/src/sys dizininin dokunulmamış kalmasından emin olmak istersiniz. Bu aşağıdaki işlem ile sağlanabilir:
$ cd /somewhere $ cp /usr/src/sys/arch/i386/conf/GENERIC . $ config -s /usr/src/sys -b . GENERIC $ make clean && make depend && make ... çok fazla çıktı ...
Çekirdeği root hakları olmadan yapılandırabileceğinizi unutmayın, ama çekirdek yüklemek için root haklarına sahip olmalısınız.
Çekirdeği Yapılandırma
Burada, standart bir çekirdek yapılandırmak istediğiniz (GENERIC veya GENERIC.mp) varsayılmıştır. Genellikle bu yapmak istediğiniz şeydir. Eğer standart yapılandırma işleminde usta olmadıysanız, özel bir çekirdek derleme işlemine girişmeyin.
Çekirdeğin sistemin donanıma ÇOK bağımlı bir parçası olduğu açıkça bilinir. Çekirdeğin kaynağı /usr/src/sys dizinidir. OpenBSD’nin çekirdek kodlarının bazıları tüm donanımlar için kullanılırken, diğerleri sadece tek bir işlemci veya donanıma özel olarak yapılanmıştır. Eğer /usr/src/sys/arch/ dizinine bakarsanız, kafa karıştırabilecek şeyler görebilirsiniz -- örneğin, mac68k, m68k ve mvme68k dizinlerini görebilirsiniz. Burada, mvme68k ve mac68k sistemleri aynı işlemcileri kullandıkları halde donanım yapıları çok farklı olduklarından farklı çekirdeklere gereksinim duyarlar (Bilgisayarın tasarımında işlemci dışında pek çok faktör vardır).Ancak çekirdeğin ortak kısımları m68k dizininde tutulur. Eğer bir çekirdek yapılandırıyorsanız, m68k gibi temel mimari dizinlerden korkmanıza gerek yoktur, çünkü daha çok mvme68k gibi "birleşik mimari" dizinleriyle çalışacaksınız.
Çekirdekler, /usr/src/sys/arch/<sizin_platform>/conf dizininde yer alan çekirdek konfigürasyon dosyaları temel alınarak yapılandırılır. Bir çekirdeği yapılandırmak, config(8) programını kullanarak daha sonra /usr/src/sys/arch/<sizin_donanımınız>/compile/ <Çekirdek Adı> olacak çekirdek derleme dizinini oluşturmak ve içini doldurmaktan oluşur. Bu örnek için, sizin i386 platformunu kullandığınız varsayılacaktır:
# cd /usr/src/sys/arch/i386/conf # config GENERIC # cd ../compile/GENERIC # make clean && make depend && make [...çok fazla çıktı...] # make install
Farklı donanımlar için baştaki "i386" yerine kendi donanımızı yazmanız gerekecektir. machine(1) komutu hangi donanım platformunu kullandığınızı söyleyecektir, böylece ilk satırın bir genellemesi "cd /usr/src/sys/arch/`machine`/conf" şeklinde olacaktır.
Bu noktada yeni çekirdeği aktif edebilmek için makinenizi yeniden başlatmanız gerekir. Bir sonraki adımda yeni çekirdeğin çalışıyor olmasına dikkat edin, eğer en güncel snapshot’a yükseltme işlemi için yukarıdaki tavsiyeden yararlandıysanız, pek bir şey fark etmeyecektir. Ancak, bazı durumlarda API’ler değişir ve eski çekirdek yeni uygulamaları çalıştıramaz duruma gelir, ama yeni çekirdek eskisini genellikle destekler.
Kullanıcı bölümünün oluşturulması
OpenBSD’nin kullandığı özel bir proses yapısı vardır. Diğer işletim sistemlerinde kullanıp alıştığınız proseslerin çoğunu OpenBSD üzerinde kullanamayacaksınız ve nedenini sorarsanız büyük ihtimalle size gülerler.
- Sisteminizdeki /usr/obj dizinini temizleyin ve sembolik bağlantıları oluşturun:
# rm -rf /usr/obj/* # cd /usr/src # make obj
Yukarıdaki /usr/obj dizininin kullanımımın zorunlu olduğunu unutmayın. Bu aşamada yapılacak bir hata daha sonraki yapılandırma sürecinde src ağacınızın kalanının kötü bir duruma girmesine sebep olacaktır.
- Gerekli tüm dizinlerin oluşturulduğundan emin olun.
# cd /usr/src/etc && env DESTDIR=/ make distrib-dirs
- Sistemi yapılandırın:
# cd /usr/src # make build
Bu işlem "kullanıcı bölümü" uygulamalarını uygun düzende derler ve yükler. Bu gerçekten uzun zaman alan bir adımdır – çok hızlı bir makine bu işlemi bir satin altında bir sürede bitirebilir, ama yavaş bir makinede günler sürebilir. Bu adım sonlandığında, yeni derlenmiş ikili dosyalarınız sistemde yerlerini alır.
- Eğer -current sürümü yapılandırılıyorsa: /dev ve /etc dizinlerini current.html listesindeki değişiklikler ile güncelleyin. Eğer kusursuz bir yapılandırma işlemi sonrasında -stable yüklenecek veya uygun başlangıç dosyaları yüklenecek ise, bu adım gereksizdir veya es geçilebilir.
Bir Release Oluşturmak
Bir "release" nedir ve neden bundan bir tane yapmak isteyeyim?
Release, başka bir makinede OpenBSD kurmak için kullanılabilecek dosya setidir. Eğer OpenBSD kullanan sadece bir makineniz varsa, release oluşturmak için bir sebebiniz yoktur, çünkü yukarıdaki yapılandırma işlemi size gerekeni fazlasıyla yapmış olacaktır. Release işleminin kullanılmasına bir örnek hızlı bir makinede -stable kurmak ve buradan ofisinizdeki tüm makinelerde kullanılmak üzere release yaratmak olabilir.
Release işlemi, /usr/obj dizininde bulunan ve yukarıdaki yapılandırma işleminde kullanılan ikili dosyalardan yararlanır, bu yüzden yapılandırma işlemi /usr/obj dizinini hiçbir şekilde rahatsız etmeyeceği şekilde hatasız tamamlanmalıdır. Problem oluşabilecek bir durum olarak, eğer yapılandırmada performans için /usr/obj dizinini bir bellek diski kullanıyorsanız, bilgisayarınızı "yapılandırma" ve "release" adımları arasında yeniden başlatmak istemezsiniz
Release işlemi DESTDIR ve RELEASEDIR olarak adlandırdığımız iki çalışma dizini gerektirir. "Temiz" bir OpenBSD yüklemesinde kullanılan tüm dosyalar orijinal yerleri ile DESTDIR dizinine kopyalanır. Daha sonra bu dosyalar RELEASEDIR dizinine tar(1) ile sıkıştırılır. Bu işlemin sonunda, RELEASEDIR dizini tamamlanmış bir OpenBSD release’i tutuyor olur. Release işlemi ayrıca /mnt dizinini de kullanır, bu yüzden başka bir işlem bu dizini release işlemi süresince kullanmamalıdır. Bu örnek için, DESTDIR dizinini /usr/dest ve RELEASEDIR dizini de /usr/rel olarak tanımladık.
Release oluşturma işlemi OpenBSD temelinde olmayan ve birçok ikili dosyadan tek bir ikili dosya oluşturmak için kullanılan crunch ve crunchgen(1) adında bir çift uygulamanın kullanımını gerektirir. Bu tek uygulama dosyasını çağıran uygulama hangi uygulama kısmının çalışacağını belirler. Bu birçok kişisel program dosyalarının boot disketlerinin veya diğer medyaların tekbir bellek disk çekirdeğine sıkıştırılması gibidir. Bu uygulamalar release işlemine başlamadan önce yapılandırılmalıdır. Bunlar sadece bir defa yapılandırılıp kuruldukları halde, insanların bu adımı unutmaları veya işlemin çok hızlı olması sebebiyle kullanıcılar crunch ve crunchgen adımlarını tekrarlamayı seçerler.
Bir release yapmak için root haklarına sahip olmalısınız.
Bir release yapmak
Önce, eğer bu makinede yapılmamış ise, crunch ve crunchgen yapılandırın:
# cd /usr/src/distrib/crunch && make obj depend all install
Şimdi, DESTDIR ve RELEASEDIR çevre değişkenlerini tanımlayacağız:
# export DESTDIR=/usr/dest # export RELEASEDIR=/usr/rel
Şimdi ise DESTDIR dizinini temizleyip gerekiyorsa dizinleri oluşturmalıyız:
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
RELEASEDIR dizininin bu işleme başlamadan önce boş olması gerekmez, ama eğer release dosyalarında veya onların isimlerinde bir değişiklik varsa, eski dosyalarda bırakılmış olur. Bu dizini başlamadan önce temizlemeyi isteyebilirsiniz.
Şimdi release’in kendisini yapacağız:
# cd /usr/src/etc # make release
İşlem yapıldıktan sonra, release’deki tar dosyalarının DESTDIR dizinindekiler ile uyuştuğu kontrol etmek iyi bir fikirdir. Bu adımın çıktısı çok kısa olmalıdır.
# cd /usr/src/distrib/sets # sh checkflist
Şu anda RELEASEDIR dizinindeki dosya setlerini oluşturmuş ve denetlemiş olduk. Bu dosyalar artık OpenBSD yüklemek yada güncellemek için başka makinelerde kullanılabilir.
Güvenilir release oluşturma adımlar release(8) bölümündedir.
Not: Oluşan dosyaları güncelleme veya yükleme amacı için HTTP yoluyla dağıtmak isterseniz, yeni oluşturduğunuz release’de bulunan dosyaları içeren bir "index.txt" dosyası eklemek zorundasınız.
# /bin/ls -1 >index.txt
Neden özelleştirilmiş çekirdek kullanmak zorunda olayım?
Aslında, değilsiniz.
Özelleştirilmiş bir çekirdek, sağlanan GENERIC konfigürasyon dosyası dışında başka bir konfigürasyon dosyası ile derlenmiş çekirdektir. Özelleştirilmiş çekirdek, GENERIC çekirdek gibi -release, -stable veya -current kodlarına dayanan bir çekirdek olabilir. Kendi GENERIC çekirdeğinizin derlenmesi OpenBSD geliştirme takımı tarafından destekleniyorsa da, kendi çekirdeğinizi derlemeniz desteklenmez.
Standart OpenBSD çekirdek ayarları (GENERIC) pek çok kullanıcıya uygun olacak şekilde tasarlanmıştır. Çoğu kullanıcı OpenBSD çekirdeklerinin ayarları ile oynarken gelişmiş bir sistem oluşturmak yerine sistemlerini bozmuşlardır. Tabii ki, ortada optimum performans için çekirdeği özelleştirmek gerektiğini düşünenler vardır, ama bu OpenBSD için geçerli değildir. Sadece ileri seviyedeki kullanıcılar, performans ile çok sıkıntısı olan uygulamalarda özelleştirilmiş çekirdek veya sistem için kafa yorabilirler
Özelleştirilmiş çekirdek kullanmanızı gerektirecek bazı durumlar:
- Gerçekten ne yaptığınızı biliyorsunuz, OpenBSD’yi çok kısıtlı RAM kaynakları olan bir makineye kurmak için kullanmayacağınız cihaz sürücülerini kaldıracaksınız.
- Gerçekten ne yaptığınızı biliyorsunuz, bazı öntanımlı seçenekleri kaldırmak ya da öntanımlı olarak aktif olmayan bazı seçenekleri eklemek istiyorsunuz (ve bunun için geçerli bir sebebiniz var).
- Gerçekten ne yaptığınızı biliyorsunuz, deneysel seçenekleri aktive etmek istiyorsunuz.
- Gerçekten ne yaptığınızı biliyorsunuz, GENERIC çekirdek tarafından karşılanmayan bir ihtiyacınız var ve eğer çalışmazsa “neden çalışmadı?” diye sormayacaksınız.
Özelleştirilmiş çekirdek kullanmanızı gerektirmeyecek bazı durumlar:
- Doğal olarak, ihtiyacınız yoktur.
- Daha hızlı bir sistem elde edemeyeceksiniz.
- Büyük ihtimalle daha güvenilmez bir makine yaratacaksınız.
- Geliştiricilerden bir yardım alamayacaksınız.
- Geliştiricilerin problem raporlarını ciddiye alması için, GENERIC çekirdek üzerinde oluşabilen bir hatayı tekrarlamanız gerekecek.
- Kullanıcılar ve geliştiriciler sisteminiz göçtüğünde size gülecek.
- Özelleştirilmiş çekirdek ayarları genellikle sisteminizi geliştirmek yerine derleyici hatalarını arttırma işini daha iyi yapar.
Cihaz sürücülerini kaldırmak sisteminizin önyükleme (boot) sürelerini arttırabilir, ama bir donanım hatası olduğunda kurtarma işlemini kompleks bir duruma sokar ve çoğu kez bu işlem yanlış yapılır. Aygıt sürücülerini kaldırmak sisteminizin belirgin şekilde hızlı çalışmasına sebep olmayacaktır, aksine daha küçük bir çekirdek oluşturacaktır. Debug ve hata kontrolünü kaldırmak ölçülebilir bir performansı verebilir, ama bu işler kötü gittiğinde sisteminize bir teşhis konulmasını imkansız yapacaktır.
Tekrar, geliştiriciler genellikle eğer aynı problem GENERIC çekirdek ile ilgili değilse özelleştirilmiş çekirdeklerle ilgili bug raporlarını göz ardı edeceklerdir. Uyarırız.
Özelleştirilmiş çekirdek oluşturma
Yukarıyı okuduğunuz ve acıdan hoşlandığınıza göre başlayabiliriz. Ayrıca hedefinizin Boot zamanında ayarlama (UKC>) ile yada GENERIC çekirdeği config(8) ile ayarlama ile ulaşılamayacak bir istek olduğunu varsayıyoruz. Eğer bu ikisi de doğru değilse, GENERIC çekirdeği kullanmaya devam edin. Gerçekten.
OpenBSD çekirdek üretimi öntanımlı olarak /usr/src/sys/arch/<arch>/conf/ konumunda olan konfigürasyon dosyaları ile denetlenir. Tüm donanımlar için GENERIC adında standart OpenBSD çekirdeğini oluşturmak için kullanılan bir dosya vardır. Ayrıca, değişik amaçlı çekirdeklerin oluşturulmasına yarayan, örneğin minimum RAM, disksiz iş istasyonu gibi, bazı konfigürasyon dosyaları da vardır. Konfigürasyon dosyası normal yüklemede /usr/src/sys/arch/<arch>/compile/ konumunda olacak derleme dizinini (../compile) oluşturan config(8) uygulaması ile işlenir. config(8) ayrıca bir Makefile ile çekirdeğin başarıyla yapılanması için gereken bazı dosyaları oluşturur.
Çekirdek Ayarlama Seçenekleri, çekirdek oluşumu sırasında sisteminize bazı özellikler ekleyen seçeneklerdir. Bu size istediğiniz desteğin sağlanmasına, gerekmeyen cihazlar için desteği kaldırmadan izin verir. Çekirdeğinizi özelleştirmek için bunun gibi pek çok seçenek vardır. Burada sadece sık kullanılan birkaçının üzerinden geçeceğiz. Seçeneklerin tam listesini görebilmek ve değişiklerden haberdar olabilmek için options(4) man sayfasına bir göz atın ve bu sayfanın sürümünün yapılandırdığınız OpenBSD ile aynı sürüm olmasından emin olun. Ayrıca, kendi donanımıza ait örnek konfigürasyon dosyalarını da kontrol edebilirsiniz.
Eğer geçerli bir sebebiniz yoksa çekirdeğinize bir seçenek eklemeyin yada bir seçeneği değiştirmeyin, kaldırmayın! GENERIC konfigürasyon dosyasını düzenlemeyin!!
OpenBSD takımı tarafından desteklenen tek ayarlama /usr/src/sys/arch/<arch>/conf/GENERIC yada /usr/src/sys/conf/GENERIC konumundaki OpenBSD takımı tarafından oluşturulan GENERIC çekirdektir (dikkat, tekrar DÜZENLENMEMİŞ olan). Özelleştirilmiş bir çekirdek için bir problemi raporladığınızda sizden aynı problemi GENERIC çekirdek üzerinde oluşturmanız istenecektir. Tüm seçenekler birbiriyle uyumlu değildirler, pek çok seçenek sistemin çalışması için gereklidir. Derlemeyi başardığınız bir çekirdeğin çalışacağı gibi bir garanti yoktur. "config(1)lediğiniz" bir çekirdeğin oluşturulabileceği gibi bir garanti de yoktur.
Donanıma özel konfigürasyon dosyalarına buradan erişebilirsiniz:
- alpha Çekirdek konfigürasyon dosyaları
- i386 Çekirdek konfigürasyon dosyaları
- macppc Çekirdek konfigürasyon dosyaları
- sparc Çekirdek konfigürasyon dosyaları
- sparc64 Çekirdek konfigürasyon dosyaları
- vax Çekirdek konfigürasyon dosyaları
- hppa Çekirdek konfigürasyon dosyaları
- Diğer Donanımlar
Bu dosyaları dikkatlice incelediğinizde en tepede şuna benzer bir ifade görürsünüz:
include "../../../conf/GENERIC"
Bunun anlamı, bu konfigürasyon dosyasının donanımdan bağımsız seçenekleri tutan başka bir konfigürasyon dosyasını referans aldığıdır. Kendi çekirdek konfigürasyonunuzu oluştururken, sys/conf/GENERIC dosyasına göz atmayı unutmayın.
Çekirdek konfigürasyon seçenekleri çekirdek konfigürasyon dosyasında şu formatta bulunmalıdır:
option isim
yada
option isim=değer
Örneğin, "DEBUG" seçeneğini çekirdeğe eklemek için şöyle bir satır oluşturmalısınız:
option DEBUG
OpenBSD çekirdeğindeki seçenekler derleyici önişlemci seçeneklerine dönüştürülür, bu yüzden DEBUG gibi seçenekler çekirdekte #define DEBUG satırına denk gelen, kaynağın bir -DDEBUG gibi bir seçenekle derlenmesini sağlar.
Bazen, önceden tipik olarak "src/sys/conf/GENERIC" dosyasında tanımlanmış bir seçeneği kaldırmak isteyebilirsiniz. Bu dosyanın bir kopyasını değiştirebileceğiniz gibi, daha uygun bir çözüm rmoption ifadesi olacaktır. Örneğin, gerçekten çekirdek içi hata ayıklamayı (debugger) kaldırmak istiyorsanız (tavsiye edilmez!), konfigürasyon dosyasına şöyle bir satır eklemelisiniz:
rmoption DDB
Yukarıdaki option DDB seçeneği src/sys/conf/GENERIC dosyasında tanımlanmıştır ama yukarıdaki rmoption satırı bunu devre dışı yapar. Tekrar, seçenekler hakkında daha çok ayrıntı için options(4) sayfasına bir göz atın. Ayrıca, birçok seçeneğin kendine ait man sayfaları olduğuna dikkat edin -- her zaman çekirdeğe ekleyeceğiniz seçenekler hakkında tüm bilgiyi okuyun.
Özelleştirilmiş çekirdek yapılandırma
Bu örnek için, boca(4) ISA çok-portlu seri kartı destekleyen bir çekirdek oluşturacağız. Bu kartın desteği diğer cihaz sürücüleriyle çakışma nedeniyle GENERIC çekirdek içinde yoktur. Özelleştirilmiş bir çekirdek yaratmanın başka bir sebebi öntanımlı çekirdekte tutmak için çok büyük olması nedeniyle RAIDframe’dir. Özelleştirilmiş çekirdek yapılandırmanın iki yolu vardır: GENERIC konfigürasyon dosyasını yedekleyip, düzenlenmiş başka bir dosyayı GENERIC dosya olarak kullanmak yada GENERIC dosyasını “include” eden başka bir dosya oluşturup içine GENERIC çekirdekte olmaya seçenekleri eklemek. İkinci durum için dosya şu şekilde olacaktır:
include "arch/i386/conf/GENERIC"
boca0 at isa? port 0x100 irq 10 # BOCA 8-port serial cards pccom* at boca? slave ?
boca(4) ile ilgili iki satır IRQ değerleri isteğe göre ayarlanarak GENERIC dosyasında yorum satırı olan satırlardan kopyalanmıştır. Bu yolla çekirdek yapılandırmanın bir avantajı GENERIC dosyasındaki değişiklikle ilgili olmayan tüm seçeneklerin güncelleşmesidir. Dezavantajı ise, diğer cihaz sürücülerinin kaldırılamamasıdır (bu genelde kötü bir fikirdir zaten).
Özelleştirilmiş bir çekirdek yaratmanın diğer yolu GENERIC dosyasının bir kopyasını alıp, buna başka bir isim vermek ve asıl dosyada istenen değişikleri yapmaktır. Bunun dezavantajı, ileride GENERIC konfigürasyon üzerindeki değişimlerim sizin kopyanıza da eklenmesi gereğidir, yada konfigürasyon dosyanızı tekrardan yapılandırmalısınız.
Her iki durumda da, özelleştirilmiş çekirdek dosyanızı oluşturduktan sonra, config(8) kullanın ve çekirdeği yukarıda belirtildiği gibi yapılandırın.
Kendi özelleştirilmiş konfigürasyon dosyanızı oluşturmak için tüm talimatlar afterboot(8) man sayfasındadır.
Acilis Zamani Konfigürasyon
Bazı durumlarda sisteminiz boot ederken çekirdeğin sistemdeki bir aygıtı bulduğunu fakat yanlış IRQ değeri belirlediğini fark etmişsinizdir. Bazen de bu cihazı ailen kullanmanız gerekebilir. Pekala, çekirdeğinizi yeniden yapılandırmadan OpenBSD’nin boot-zamanı çekirdek konfigürasyonunu kullanabilirsiniz. Bu probleminizi bir defaya mahsus çözecektir. Eğer sisteminizi tekrar başlatırsanız, aynı prosedürü tekrarlamanız gerekir. Yani bu geçici bir çözümdür ve problemi config(8) kullanarak çözmeniz gerekir. Ayrıca çekirdeğinizin option BOOT_CONFIG seçeneğini içermesi gerekir ki, GENERIC çekirdek buna sahiptir.
Bu dokümanın büyük bir kısmı boot_config(8) man sayfasında bulunabilir.
Kullanıcı Çekirdek Yapılandırmasına (User Kernel Config: UKC) boot etmek için boot zamanında –c seçeneğini kullanın
boot> boot hd0a:/bsd –c
Ya da istediğiniz hangi çekirdek ise ona boot edin. Bunu yaparsanız size bir UKC komut satırı çıkaracaktır. Buradan çekirdekte değiştirmek yada kaldırmak istediğiniz cihazlara ait komutları girebilirsiniz.
Aşağıda çok bilinen birkaç UKC komutu vardır
- add aygıt - Başkasının üstene kopyalayarak bir aygıt ekleyin.
- change aygıtno | aygıt - Bir ya da birkaç cihazı düzenleyin.
- disable aygıtno | aygıt - Bir ya da daha fazla aygıtı devre dışı bırakın.
- enable devno | device - Bir ya da daha fazla cihazı aktif yapın.
- find aygıtno | aygıt - Bir ya da daha fazla cihazı bulun.
- help - Bu komutların bir özeti.
- list - TÜM aygıtların listesini çıkarın.
- exit/quit - Boot işlemine devam edin.
- show [seçenek [değer]] - Seçenekleri olan cihazları ve varsa o seçeneğe ait değere ilişkin çıkışı görüntüle.
Çekirdeğiniz yapılandırıldıktan sonra quit veya exit komutları ile boot işlemine devam edebilirsiniz. Bundan sonra yaptığınız değişikliğin config(8) kullanarak çekirdeği değiştirme bölümünde anlatıldığı şekilde çekirdek imajında kalıcı olmasını sağlamalısınız.
config(8) kullanarak Çekirdeği değiştirme
-e ve -u seçenekleri, config(8) ile kullanıldıklarında oldukça yardımcı olabilir ve sizi uzun derleme sürelerinden kurtarabilir. -e bayrağı UKC (Kullanıcı Çekirdek Yapılandırması) çekirdeğini çalışan bir sisteme girmenizi sağlar. Değişiklikler bir sonraki başlatmada etki edecektir. -u bayrağı ise çalışan çekirdekte bir değişiklik yapılıp yapılmadığını test eder, yani sizin sisteminiz boot ederken boot -c seçeneği ile UKC’ye girip girmediğinizi sınar.
Aşağıdaki örnek ep* aygıtlarını çekirdekte nasıl devre dışı bırakılabileceğini gösteriyor. Rahat çalışmanız için -o seçeneğini kullanarak yapılan değişikliklerin belirlenmiş bir dosyaya aktarılmasını sağlamalısınız. Örneğin: config -e -o bsd.new /bsd komutu değişiklikleri bsd.new dosyasına yazar. Örneğimiz -o seçeneğini kullanmıyor, bu yüzden değişikliklere önem verilmemiştir ve çalıştırılabilir çekirdek dosyasına yazılmamıştır. Hata ve dikkat mesajları ile ilgili daha fazla bilgi için config(8) man sayfasını okuyunuz.
$ sudo config -e /bsd
OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
warning: no output file specified
Enter 'help' for information
ukc> ?
help Command help list
add dev Add a device
base 8|10|16 Base on large numbers
change devno|dev Change device
disable attr val|devno|dev Disable device
enable attr val|devno|dev Enable device
find devno|dev Find device
list List configuration
lines count # of lines per page
show [attr [val]] Show attribute
exit Exit, without saving changes
quit Quit, saving current changes
timezone [mins [dst]] Show/change timezone
nmbclust [number] Show/change NMBCLUSTERS
cachepct [number] Show/change BUFCACHEPERCENT
nkmempg [number] Show/change NKMEMPAGES
shmseg [number] Show/change SHMSEG
shmmaxpgs [number] Show/change SHMMAXPGS
ukc> list
0 audio* at sb0|sb*|gus0|pas0|sp0|ess*|wss0|wss*|ym*|eap*|eso*|sv*|neo*|cmpci*
|clcs*|clct*|auich*|autri*|auvia*|fms*|uaudio*|maestro*|esa*|yds*|emu* flags 0x0
1 midi* at sb0|sb*|opl*|opl*|opl*|opl*|ym*|mpu*|autri* flags 0x0
2 nsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
3 nsphyter* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|
vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep
*|ep*|ep* phy -1 flags 0x0
4 qsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
5 inphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
6 iophy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
7 eephy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
8 exphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
[...snip...]
ukc> disable ep
67 ep0 disabled
68 ep* disabled
69 ep* disabled
155 ep0 disabled
156 ep0 disabled
157 ep* disabled
158 ep* disabled
210 ep* disabled
ukc> quit
not forced
Yukarıdaki örnekte çekirdekteki tüm ep* aygıtları devre dışı bırakılmıştır ve boot sırasında denenmeyeceklerdir. Boot zamanında boot -c ile UKC kullandığınız bazı durumlarda, değişikliklerin kalıcı olarak yazılmasını istersiniz. Bunu yapmak için -u seçeneğini kullanmanız gerekir. Aşağıdaki örnekte, bilgisayar UKC ile boot etmiştir ve wi(4) aygıtı devre dışı bırakılmıştır. Boot -c ile yapılan değişiklikler kalıcı olmadığından, kalıcı şekilde yazılmaları gerekmektedir. Bu örnek boot -c ile yapılan değişiklikleri çalıştırılabilir çekirdek dosyası bsd.new dosyasına yazar.
$ sudo config -e -u -o bsd.new /bsd
OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Processing history...
105 wi* disabled
106 wi* disabled
Enter 'help' for information
ukc> quit
Açılış sırasında daha ayrıntılı çıktı almak
Boot esnasında daha ayrıntılı çıktı almak hata ayıklama problemlerinde çok yararlı olabilir. Eğer boot edilebilir disketiniz boot olmuyorsa ve sebebi hakkında daha fazla bilgi istiyorsanız, sadece bilgisayarınızı yeniden başlatın. "boot>" komut satırını gördüğünüzde boot -c seçeneği ile boot işlemine devam edin. Bu sizi UKC> komut satırına götürür, sonra:
UKC> verbose autoconf verbose enabled UKC> quit
Artık boot sırasında oldukça fazla ayrıntı elde edebilirsiniz
Derleme ve yapılandırma hakkında önemli problemler, sorular ve püf noktaları
Yapılandırma "Signal 11" hatası ile sonlandı
OpenBSD yapılandırması kaynaktaki diğer programlar donanımı diğer işletim sistemlerine göre oldukça zorlar, çok fazla CPU, disk ve bellek kullanımına yol açar. Sonuç olarak, eğer sorunu olan bir donanımınız varsa, yapılandırma işlemi sırasında oluşacak en muhtemel hata donanım sorunlarına bağlı Signal 11 hatasıdır, büyük olasılıkla bellek problemleri olmak üzere CPU anakart ya da ısınma sorunlarından kaynaklanmaktadır. Diğer durumlar için sisteminiz oldukça uygun olabilir, ama OpenBSD için programları derleyemez. Sorundan kurtulmanın en iyi yolu donanımızı tamir etmek ya da değiştirmek olacaktır, çünkü bu donanımlar ileride değişik şekillerde sisteminizi etkileyebilirler. Eğer gerçekten kullanmak istediğiniz ama size sorun çıkaran bir donanımınız varsa, basitçe bir snapshot yada release yükleyin. Daha fazla bilgi için, Sig11 FAQ.
="make build" işlemi "cannot open output file snake: is a directory" hatasıyla sonlandı
Bu iki ayrı hatanın bir sonucudur:
- CVS ağacını tam olarak indirmediniz yada güncellemediniz. CVS kontrolü yaparken, "-P" seçeneğini; CVS ağacını güncellerken ise "-Pd" seçeneğini yukarıda belirtildiği gibi cvs(1) ile kullanmanız gerekir. Bu seçenekler OpenBSD kaynak ağacı değiştikçe yeni dizinlerin eklenmesini yada eskilerinin kaldırılmasını sağlar.
- Yapılandırma öncesi uygun bir obj dizini yaratmadınız. Kaynak ağacını uygun bir /usr/obj dizini olamadan yapılandırmak desteklenmez.
Kaynak ağacını indirirken ve yapılandırırken talimatları takip etmek çok önemlidir
IPv6-sız sistemim çalışmıyor!
Evet. Lütfen, temel sistemde anlamını bilmediğiniz değişiklikler yapmaya kalkışmayın. Çekirdekteki küçük bir değişiklik sitemin kalan kısmına büyük bir darbe vurabilir. Lütfen bunu tekrar okuyun.
Ups! Önce /usr/obj dizinini yapılandırmayı unuttum!
"make build" işlemini "make obj" işleminden önce yapmak, nesne dosyalarınızın /usr/src dizininde dağınık şekilde oluşmasına sebep olur. Bu kötü bir şeydir. Eğer kaynak ağacının (src dizininin) tekrar indirilmesini istemiyorsanız, aşağıdaki kullanarak bir temizlik yapabilirsiniz:
# cd /usr/src # find . -type l -name obj | xargs rm # make cleandir # rm -rf /usr/obj/* # make obj
- Tavsiye: /usr/obj dizinini kendi disk bölümüne yerleştirin
Eğer sıkça yapılandırma yapıyorsanız, /usr/obj dizinini kendine ait bir disk bölümüne yerleştirmenin daha hızlı sonuçlar verdiğini görürsünüz. Yararı basittir:
# umount /usr/obj # newfs YourObjPartition # mount /usr/obj
işlemi "rm -rf /usr/obj/*" işleminden daha hızlıdır.
Kaynak Ağacının bazı bölümlerini nasıl yapılandırmam?
Bazen, kaynak ağacının bazı kısımlarını yapılandırılmamasını istersiniz, büyük ihtimalle ağaçtaki bazı paketler yerine başka uygulamalar yüklemişsinizdir ya da herhangi bir nedenle daha küçük boyutlu bir release oluşturmak istiyorsunuzdur. Çözüm /etc/mk.conf dizininde SKIPDIR seçeneğini kullanmaktır.
Not: Bu şekilde hatalı bir sistem oluşturmak mümkündür. Bu seçeneğin sonuçları OpenBSD projesi tarafından desteklenmemektedir.
Yapılandırma işlemi hakkında daha fazla bilgiyi nerede bulurum?
Aşağıda birkaç kaynak bulabilirsiniz:
- release(8)
- afterboot(8)
- mk.conf(5)
- /usr/src/Makefile
- Yama Şubeleri (-stable)
- (X için) yüklü sisteminizdeki /usr/X11R6/README dosyası.
FTP sitesinde herhangi bir snapshot göremedim. Neredeler?
Snapshot’lar eskidikleri (ya da artık gerekli olmadıkları) için veya yeni -release zamanı geldiği için kaldırılmış olabilirler.
Derleyicinin (gcc) daha yeni bir sürümü ile bir yapılandırmayı nasıl yaparım?
Aslında sadece son sürüm bir snapshot yüklemeniz yeterlidir. OpenBSD artık kaynak ağacında iki derleyiciyi desteklemektedir: pek çok donanımda kullanılan gcc v3.3.5 ve bazı çevrilmemiş platformlarda ve yeni çıkan donanımlarda eksik gcc3 desteği ya da kötü gcc3 performansı sebebiyle kullanılan gcc v2.95.3. Bu derleyiciler kaynak ağacında iki ayrı yerdedirler:
- gcc3: /usr/src/gnu/usr.bin/gcc
- gcc2: /usr/src/gnu/egcs/gcc
Bir derleyiciyi güncellemek yumurta-tavuk problemine benzer olduğundan, kaynak ağacı tarafından kullanılan derleyici değişiklikleri biraz fazla dikkat gerektirir. Derleyiciyi iki kez yapılandırmanız gerekir -- ilk yapılandırma eski derleyici tarafından oluşturulan yeni derleyicinin kodlarını oluşturur, ikincisi ise tamamıyla yeni bir derleyici oluşturur. Genel olarak, aşağıdaki prosedürü takip edersiniz:
Eğer donanımınız gcc 2.95.3 kullanıyorsa:
# rm -r /usr/obj/gnu/egcs/gcc/*
# cd /usr/src/gnu/egcs/gcc
- ya da -
Eğer donanımınız gcc 3.3.5 kullanıyorsa:
# rm -r /usr/obj/gnu/usr.bin/gcc/*
# cd /usr/src/gnu/usr.bin/gcc
v3.3.5 ya da v2.95.3 için ortak yapılandırma prosedürü:
# make -f Makefile.bsd-wrapper clean # make -f Makefile.bsd-wrapper obj # make -f Makefile.bsd-wrapper depend # make -f Makefile.bsd-wrapper # make -f Makefile.bsd-wrapper install # make -f Makefile.bsd-wrapper clean # make -f Makefile.bsd-wrapper depend # make -f Makefile.bsd-wrapper # make -f Makefile.bsd-wrapper install
Daha sonra normal make build’i çalıştırın.
/etc, /var, ve /dev dizinlerini güncellemenin en iyi yolu nedir?
Kural olarak, OpenBSD ağacındaki yazılım /etc dizinindeki dosyaları otomatik olarak güncellemez. Bunun anlamı, gerekli değişiklerin yapılması her zaman sistem yöneticisine bağlıdır. Güncellemeler sıra dışı durumlar değillerdir. Dizinlerdeki dosyaları güncellemek için, önce temel (dağıtım) dosyalarında ne gibi değişikliklerin oluştuğunu belirleyin, sonra elle bu değişikleri tekrar uygulayın.
Örneğin, yakın zamanda kaynak ağacında hangi dosyaların değiştiğini öğrenmek için:
# cd /usr/src/etc # ls -lt |more
Ardışık iki OpenBSD sürümünde, /etc dizinindeki tüm değişikleri görmek için CVS kullanabilirsiniz. Örneğin, 3.7 ve 3.8 arasındaki değişiklikleri görmek için:
# cd /usr/src/etc # cvs diff -u -rOPENBSD_3_7 -rOPENBSD_3_8
3.8 ile -current ("HEAD") arasındaki farklar için ise:
# cd /usr/src/etc # cvs diff -u -rOPENBSD_3_8 –rHEAD
/dev/MAKEDEV scripti, yapılandırma işleminin bir parçası olarak otomatik güncellenmez, ama bir çalıştırılabilir dosya güncellemesinin parçası olarak yüklenebilir. Genel kural olarak (gerekirse), güncelleme işlemi sırasında bu dosyanın bir kopyasını alıp kaynak ağacınızdan çalıştırmak iyi bir fikirdir:
# cd /dev # cp /usr/src/etc/etc.`machine`/MAKEDEV ./ # ./MAKEDEV all
Değişikleri belirledikten sonra, bunları kendinize ait değişikleri koruyarak yerel ağacınızda tekrarlayın. Release’ler arasındaki dikkat edilecek tipik /etc değişikleri:
- /etc/protocols ve /etc/services yapılan eklemeler.
- Yeni sysctls (/etc/sysctl.conf dosyasına bakın).
- Öntanımlı cron işlemlerinde değişiklikler. /etc/daily, /etc/weekly, /etc/monthly, ve /etc/security dosyalarına bakın.
- Tüm rc scriptleri, netstart dahil.
- Aygıt değişikleri, yukarıya bakın.
- /etc/mtree içinde dosya hiyerarşi değişiklikleri, aşağıyı kontrol edin.
- Yeni kullanıcı (/etc/passwd) ve gruplar (/etc/group)
Bu değişiklikler upgrade38.html (3.8-release için) yada current.html (-current için) dosyalarında özetlenmiştir.
Tüm dosya hiyerarşi değişiklerini yapmanın daha kolay bir yolu var mı?
Zaman zaman, dosya hiyerarşisinde dosyalar ve dizinler eklenebilir yada kaldırılabilirler. Ayrıca, dosya sistemi bölümleri için kullanıcı hakları değişebilir.Hiyerarşinizin güncel olup olmadığını kontrol etmenin en kolay yolu mtree(8) uygulamasını kullanmaktır.
Önce, en son kaynak kodlarını edinin ve aşağısıyla devam edin:
# cd /usr/src/etc/mtree # install -c -o root -g wheel -m 600 special /etc/mtree # install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree # mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
Artık dosya hiyerarşiniz güncellenmiştir.