/ Boot bölümü gerçekte ne içindir?

Linux bölümleri ve dosya sistemleri ( LPIC 1 Sertifikasyon İncil ) hakkında nispeten eski bir metin okuyorum . Diyor ki:

Linux açılış yükleyicilerinin bazı sürümleri, diskteki ilk 1024 silindirin dışındaki bir çekirdeğe erişemez. / Boot bölümünü sürücünün başına koyarak, açılışta çekirdeğe erişirken sorun yaşamadığınızdan emin olabilirsiniz. Bu problem, en sık Linux kullanan ve ilk bölümdeki başka bir işletim sistemiyle çift önyükleme durumlarında kendini gösterir.

Bir önyükleyici neden " diskteki ilk 1024 silindirin dışındaki çekirdeğe erişemedi "?

Ayrıca, " / boot bölümünü sürücünün başına koymak " ne anlama geliyor?

Bu, Linux'un kendisinden ziyade çok eski bir BIOS ve bootloader'a sahip olmanın getirdiği bir sınırlamadır. BIOS, diskin yalnızca ilk 1024 silindirine erişebilecektir ( hangi silindirlerin / kafaların / sektörlerin olduğu hakkında daha fazla bilgi için buraya bakınız ). Bu sınırlama, basit doğası gereği, kendi disk sürücülerine sahip olmayacak ve diske erişmek için BIOS servislerini kullanacak olan yükleme yükleyicilerini de kapsayacaktır.

Bu, hem bootloader'ın hem de çekirdeğin (bootloader'ın yüklenmesi işi olduğu için) bu sınırlamaya sahip sistemlerdeki ilk 1024 silindir içinde olması gerektiği anlamına geliyordu. Bunu yapmanın basit bir yolu /bootçekirdeği içeren ayrı bir bölüm oluşturmak ve onu sürücünün başına koymaktı (genellikle sadece ilk bölüm yaparak). Bu, fiziksel olarak bölümün çok büyük olmaması şartıyla fiziksel olarak ilk 1024 silindir içinde bulunacağı anlamına gelir.

Sınırlama artık bir sorun değil çünkü sadece eski BIOS'lar için geçerli. Ayrıca, birçok modern önyükleyici (örneğin GRUB) kendi disk sürücülerine sahiptir ve bu nedenle BIOS servislerine güvenmeleri gerekmez. Modern önyükleyiciler /bootbaşka amaçlar için de kullanabilirler , ancak artık hem ayrı bir bölmede hem de ilk 1024 silindir içinde olmaları gerekmemektedir (her ne kadar /bootayrı bir bölmede olması gereken birçok durum olsa da ).

Tarih

/bootİşletim sistemi tarafından kullanılmayan ancak önyükleyici tarafından kullanılan dosyaları içerir . Her iki bootloader dosyasını ( /boot/grub/*Grub için olduğu gibi ) ve Linux çekirdeğini ( /boot/vmlinuz*) ve çoğu zaman ilişkili bir initrd veya initramfs dosyası bulacaksınız .

Eski BIOS'u olan bir bilgisayarda ( en yeni bilgisayarlarda bulunan yeni UEFI'nin aksine ), ROM'daki yazılım önyükleme diskinin ilk 512 baytını belleğe yükler ( önyükleme sektörü ). Yalnızca 512 bayt ile (tümü kod içermese bile: bazıları bölüm tablosu gibi veriler içeriyor) kod çok şey yapamaz - orada gerçek bir disk sürücüsü olamaz. Bu kadar sınırlı bir alanda yapılabilecek tek şey, daha fazla kod yüklemek için bir BIOS arayüzü kullanmaktır. Bu arayüz, Nth sektörünü diske yüklemek için bir komut sağlar - ve N'nin boyutu sınırlıdır, böylece diskin sadece başlangıcına bu şekilde ulaşılabilir.

BIOS arayüzü otuz yıldan biraz daha uzun bir süre önce gelişmiştir , ancak boyut sınırlamaları eski boyutlardaki BIOS'ların ve önyükleyicilerin 32 MB, 512 MB, 2 GB, 8 GB (ve muhtemelen hatırlamadığım diğer eşikler). Önyükleyicinin, doğrudan disk sürücüsüne erişmek için gereken tüm parçaları yüklemek için BIOS arabirimini kullanabilmesi gerekir. Önyükleyiciler genellikle etrafındaki tüm disk denetleyicileri için sürücü içermez, bu nedenle Linux çekirdeğini (ve initrd / initramfs) yüklemeye kadar her şeyin BIOS arabirimini kullanması gerekir ve bu nedenle diskin başına sığması gerekir.

Bunun, Linux'un veya bir dağıtımın değil, BIOS veya bootloader'ın sınırlaması olduğunu unutmayın.

/bootBugün ayır

Yeni bir BIOS ve yeni bir önyükleyici ile veya UEFI bulunan bir sistemde, boyut sınırlamaları artık geçerli değil: disk boyutlarının artık yakalanması uzun zaman alıyor. Bununla birlikte, ayrı bir /bootbölümü faydalı kılan başka kullanım durumları da vardır . Ana sistemin önyükleyicinin desteklemediği bir RAID aygıtında veya önyükleyicinin desteklemediği bir dosya sistemi türünde olmasını sağlar. Ana sistemin, Linux’in şifresini çözebileceği ancak önyükleyiciyi şifreleyemediği şifreli bir aygıtta olmasını sağlar.

Bu sınırlamaların ve kullanım durumlarının hiçbiri sizin için geçerli /bootdeğilse, ayrı bir bölüm olarak tutmak yararlı değildir. Fakat çoğu dağıtımı destekleyecek kadar insanı etkiliyorlar.

Bahsedilen BIOS probleminin yanı sıra, ayrı bir /bootbölümün /, önyükleme yükleyicisinin anlamadığı bir birim için bir dosya sisteminin kullanılmasına izin vermesi de (bunun gibi bir yükleme listesi ile sınırlandırılmadan lilo) sağlanmasıdır.

ÇİZİM ZOR

Önyükleme ... iyi ... bu gerçekten en zor kısmı. Bir bilgisayar her önyükleme yaptığında temel olarak kendini yeniden karşılar. Çeşitli bölümleriyle tanışıyor ve karşıladığı her biri için yetenek kazanıyor. Ancak, konuşması için her seferinde bir başından itibaren kendi önyükleme noktalarıyla kendisini yukarı çekmek zorunda.

Bir önyükleme işlemi tasarlarken, işin püf noktası, makineyi aşama aşama devreye sokmaktır. Botunuz hızlı ve güvenilir olmalı ve her zaman tamamen bilinmeyen bir ortamda her iki şey olmalıdır . Gerçek / Korumalı moddaki bir sohbete bile girmeyeceğim (ki söyleyebileceğim anlamına gelmez) , ancak açılışta çok şey oluyor. Bilgisayar çeşitli bileşenlerini her seferinde özümsettiği için bunu adım adım gerçekleştirir. Muhtemelen bunlardan en önemlisi, yerleşik kod yürütmekten diskteki kod çalıştırmaya veya başka bir deyişle çekirdeğin çalıştırılmasına geçiştir. Bu, bellenimin (görünüşte) işletim sistemine teslim olduğu durumdur .

Yıllar önce bu durum böyle değildi. Eskiden BIOS, Temel Giriş / Çıkış'dı - düzenli programlar, ekran çizme ve diske erişim gibi şeyler için bellenime çağrı yapardı. Bunlara kesinti denirdi - eski şapkalar, yeni nokta-matrisleri veya USR'leri için IRQ atamalarında sıkça buldukları hazların heyecanları için onları en iyi şekilde hatırlayabilir.

INT13H

Bu, BIOS'un disk erişimi için servis olarak sunduğu 13H fonksiyon dizisinin kesilmesidir ( ya INTda montaj dilinde ) . Bunlar bugün bile firmware'den diske atlamak için boot işleminde BIOS sistemleri için kullanılmaktadır.

Bir BIOS sistemi bulduğu her diskin ilk birkaç baytını kontrol edecek ve Ana Önyükleme Kaydı ( veyaMBR ) olarak tanıdığı bir model arayacaktır . Bu, onlarca yıllık fiili bir standarttır ve diskin başına yazılmış bir miktar ham, çalıştırılabilir ikili dosya içerir. MBR, BIOS diskini önyüklenebilir olarak işaretler. Ne zaman bir tane bulduğunu kontrol etmeyi bırakacak ve pratik olarak bir tane akıllıca hile yapmaksızın elde edeceğiniz tek şey. Bir tane bulduğunda onu belleğe eşler ve yürütür (Gerçek modda, ama ben hala oraya gitmiyorum) .

Yürütülen MBR neredeyse kesinlikle sistem çekirdeğiniz değildir - 512 bayt (ver veya al) bu bölümde oldukça işe yaramaz. Bu muhtemelen bir önyükleyicidir - özellikle BIOS'un birçok adresleme sınırlamasından birinin üstesinden gelmek için özel olarak tasarlanmış bir programdır - özellikle de herhangi bir dosya sistemini anlamadığı için.

Bootloader asıl çekirdeği okuduğunda ve onu bellekte çalıştırdığında (hepimiz her seferinde dua edeceğimiz için) muhtemelen bunu BIOS'a bir INT13Hkesinti çağrısı ile sorarak yapacaktır . Olmazsa - birçok meraklısı önyükleyici, dosya sistemlerini geleneksel anlamda monte eder ve kodu başka bir şekilde yürütür - o zaman, önyükleyicinin bir INT13Hveya iki olmadan çok süslü olması çok az olasıdır . Genellikle önyükleyiciler kendileri - veya kendilerinin çeşitli aşamalarını - kendilerine yüklüyorlar çünkü ilk tahsis edilen 512 bayt kendi gereksinimlerine bile uymuyor.

TAVUK VE YUMURTA

Bunların hepsi diski tartışmanın bir yoludur, biliyorum, ama bu noktadan itibaren, temel problemin - buna bir tavuk-yumurta türü diyebilir - program talimatlarını içeren diske ulaşmakta olduğu açıkça anlaşılmalıdır. disklere nasıl erişileceği hakkında . Bu sorunun anahtarı bellenim - ve EFI sistemlerinde bile çok farklı şekillerde olmaya devam ediyor - ve en zayıf olanı bellenim zincirindeki en önemli bağlantıdır.

Görüyorsunuz, çekirdek çalıştırıldığında ve donanıma erişim ve denetim için tüm sayısız yordamları başladığında, bu sorunların tümü ortadan kalkar (ya da en azından bir şekilde değişir) , çünkü modern işletim sistemleri bir sistemi tam olarak kontrol ediyor, ancak, sistemin sınırlarını yapana kadar, yalnızca üretici yazılımının izin verdiği ölçüde uzar. Bu çok şey söylüyor - BIOS 8086’dan bu yana pek değişmedi. INT13HÇağrı bir 8086 orijinali. Evet, (birçok) uzantı ve tabii ki kesmeler oldu, ama yenilikler ...?

DAHA İYİ VE DAHA İYİ

BIOS'taki değişikliklerin çoğu en iyi ihtimalle yalnızca bandaj oldu. Sabit disk olması için fiziksel olarak haritalanması gerekiyordu - verilerinin depolandığında ya da ondan alındığında geometrisinin çeşitli ve özel yönlerine değiniliyordu. Sonunda geleneksel sabit disk bunu yasaklayan bir boyuta ulaştı. Sadece soyut harita bile bir BIOS'un idare edebileceği kadar fazla bilgi değildi . Sadece Gerçek Modda çalışabileceği için, BIOS her bir kayıt başına 1 MB ile sınırlıdır. Silindir haritasını bundan daha büyük bir şekilde şişin ya da özelliklerinden herhangi birini bu kadar çok bitte ele alınabilecek olandan daha büyük hale getirin ve BIOS tam anlamıyla sınırlarını aştı.

Bu engel birçok kez karşılandı ve kırıldı . Her harita, daha yeni, daha akıllı ve daha az doğru bir şekilde soyutlanıp kodlandığında. Ve bu günlerde bir BIOS'un bir sürücüyü doğru şekilde eşlemesi tam anlamıyla imkansız. Mantıksal Blok Adresleme şu an fiili standarttır, ancak bazı Silindir / Baş / Sektör (veya CHS) çevirileri hala gereklidir. Ana kart üretici yazılımının doğruluk / sorumluluk açısından kaybettiği şey gibi, bu uzantılar soyutlanmış ve boşlukları doldurmak için disk üretici yazılımının sorumluluklarını eklemiştir.

Sorunuzda referans verilen bu kedi-fare oyunudur. BIOS, büyüklüğü nedeniyle belirli bir noktanın ötesindeki bir diski anlayamadığında, önyükleme sırasında sizin için alabilmesini isteyebileceğiniz herhangi bir veri (örneğin bir önyükleyici veya çekirdek gibi) muhtemelen bu noktanın ötesinde bulunmasaydı. Burası nereden /bootgeldi?

MAYBE GERÇEKTEN DAHA İYİ

Bugünlerde böyle şeyler, neyse ki, BIOS'un ölümü ile ilgisiz hale getirildi. 30 yıl oldu, ancak son birkaç yıl içinde büyük ölçüde UEFI (veya EFI 2.0) standardıyla değiştirildi. UEFI, ilk dakikadan itibaren bir bağlantı sağlar , Korumalı Mod'da başlatır, kendi önyükleyicisini içerir, yeniden başlatmaya devam eden flash bellek değişken depolaması sağlar, bazı umpteen zetabayt veya disk başına ne olursa olsun ... Başka. Mükemmel olmaktan uzak, ancak selefine göre çok büyük bir gelişme.

Disk şifreleme veya katmanlı dosya sistemlerini içeren özel önyükleyicilere yönelik argümanlar bile, bunların hepsinin yine de işletim sistemi çekirdeği tarafından ele alınması gerektiğini düşündüğünüzde düz düşer ve önyüklemede bir montaj sağlanmışsa , yürütmek için vurdu (özellikle Linux çekirdeğinin varsayılan yapılandırmasında, kendi başına bir EFI tarafından çalıştırılabilir olduğunu göz önünde bulundurarak) .

Bu yüzden ayrı bir /bootbölüm muhtemelen sizi fazla ilgilendirmemelidir ve eğer bir EFI sistemindeyseniz, zaten EFI modunu başlatmak için bir gereklilik olduğundan, zaten zaten bir EFI-sistem bölümünde bir analogunuz var.

Bir /bootdizinin var olduğu tarihsel olarak belirlenir ve oradan da Dosya Sistemi Hiyerarşisi Standardı'nda "sabitlenir" . Böyle bir standarda sahip olmak, programların (ve sistem yöneticilerinin) belirli konumlardaki belirli dosyaları beklemesini sağlar. Bu durumda önyükleme işlemiyle ilişkili dosyalar.

/bootBir diskin başlangıcında bir bölüme sahip olmak, mevcut tüm sürücü yelpazesindeki blokları / sektörleri endeksleyemeyen eski BIOS'lar için anlamlıydı. Bu nedenle, yüklenmesi gereken bilgilerin dizine alınabilecek bir sektörde olması gerekir; bu nedenle /boot, BIOS'un ek veri / programları yükleyebileceği ayrı bir bölüm (düşük sektör numaraları ile) BIOS kullanmadan disk aralığı).

Ayrı / önyükleme bölümünün olması da çok düzenli olabilir. Makinemde, her biri kendi bölümlerinde bulunan birçok dağıtım ve yedeklemem var, ancak hepsi aynı işletim sistemi için tüm çekirdeğin bulunduğu aynı / önyükleme bölümünü paylaşıyor. Ayrıca, tüm dağıtımlar, aynı zamanda / boot içinde olan lilo.conf'un bir ve sadece kopyasına işaret ediyor, bu yüzden çekirdekleri eklerken, ne olursa olsun çekirdeği eklerken ne halt olduğunu tahmin etmem gerekmiyor. İşte benim lilo.conf bir snip:

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y5--5-Debian1"
label  = y5:D1:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y8--5-Debian2"
label  = y8:D2:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y11-5-Debian3"
label  = y11:D3:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=w5--5-Debian1"
label  = w5:D1:16.0-4

... bu sadece Debian'ım iki diskteki yedeklemem. Çekirdekleri takip etmenin ne kadar kolay olduğunu gördün mü? (şu anda, aynı çekirdeği kullanan tüm yedeklemeler).

Her ne kadar modern sistemlerde, bir dosyanın sektörlerine bir diskin herhangi bir yerinde erişilebilir olsa da, önyükleme malzemelerini kendi önyükleme bölümleriyle, “tüm yumurtaları bir sepete koyma” ilkesiyle sınırlandırmak hala mantıklı geliyor.

Ana dosya sisteminin, bazı alt-aşamalı önyükleyicilerin bir sonraki aşamayı doğru bir şekilde okuyamayacak şekilde bozulmuş olduğunu varsayalım. Öyleyse, bootloader malzemeleri kendi bölümlerinde ise, çekirdek fsck aracılığıyla ortaya çıkabilir ve bozuk kök bölümüyle düzgün bir şekilde ilgilenebilir. Bu, kendi bölümünde olabilir.

Önyükleme bölümü, alternatif bir kök bölümünün montajı gibi, "kurtarma" için seçenekler sunabilir. Ayrıca, farklı bölümlerdeki farklı işletim sistemlerini çoklu başlatırsanız ne olur? O zaman çizme malzemeleri bu sistemlerden hiçbirine ait değildir. Kendi bölümünün olması makul. İşletim sistemi bölümlerinden herhangi birini farklı bir işletim sistemi ile değiştirebilirsiniz, ancak kalan işletim sistemlerini önyükleyebilirsiniz.

Ayrıca, ana bölümünüz için bootloader'ın anlamadığı bir dosya sistemi kullanmak istersen? Ya da diyelim ki, hangi yükleyici tarafındaki destek sadece deneysel? Bu gibi durumlarda, bir sektör haritası varsa (ve önyükleyici bu tür bir şeyi destekliyorsa, önyükleme zamanı dosyası hala kullanılabilir), eski Linux önyükleyici LILO sektör haritalarını kullandı ve dosya sistemini anlamak zorunda kalmadı hiç yapı). Ancak, sektör haritaları doğal olarak lapa lapa gibi görünüyor. Dosya sistemi yeniden düzenlenirse, sektörler etrafta hareket eder ve böylece sektör haritaları yanlış olur ve yenilenmesi gerekir, aksi takdirde sistem yeniden başlatılamaz.

Son olarak, gerçek bir bölüme sahip olmasanız bile, tüm önyükleme öğelerinin en azından altında /bootolduğu ve başka bir yere dağılmadığı fikri iyi bir fikirdir .

Bu Linux dağıtımının bir kısıtlaması değildi, fakat daha eski BIOS'ların bir kısıtlamasıydı. O günlerde, Linux'un önyüklenebilmesini sağlamak için, tüm önyükleme ile ilgili dosyalar, önyükleme yükleyicisinin ilk 1024 silindirin içine düşmesini sağlamak için sabit sürücüdeki ilk bölüm olan kendi bölümlerine yerleştirildi. 1024 silindirde bulunan boyuttan daha küçük bir bölüm oluşturun (sabit sürücüden sabit sürücüye değişir). Ancak, bu sınırdan daha büyük bir ilk bölüm oluşturursanız, önyükleyici dosyalarının 1024 silindirin dışında bulunması ve BIOS'un bunları yükleyememesi ihtimali vardır.

Aynı etkiyi, her ikisi de ilk 1024 silindir içerisindeki iki küçük bölüm oluşturarak ve tüm önyükleyici dosyalarını ikinciye koyarak elde edebilirsiniz.

Bugünlerde açılış bölümünün başka bir nedeni:

• NFS veya NBD'den önyükleme
• şifreli kök bölümü
• / boot paylaşılan betweed farklı dağıtımları