Sürücü / bölüm numarası neden hala kullanılıyor?

Çoğu zaman, özellikle önyükleme yükleyicileriyle uğraşırken, sayısal sürücü ve bölüm numaralarının kullanıldığını göreceğim. Örneğin, /boot/grub/grub.cfggördüğüm kadarıyla set root='hd0,gpt2', UEFI önyükleme girişlerim genellikle sürücü / bölüm numaralarına başvuruyor ve önyükleyicilerin söz konusu olduğu hemen hemen her bağlamda kırpılıyor gibi görünüyor.

Artık UUID ve PARTUUID'e sahip olduğumuza göre, bölümleri bu şekilde ele almak inanılmaz derecede dengesiz görünüyor (afaik, sürücülerin her zaman aynı sırayla monte edileceği garanti edilmez, bir kullanıcı mobolarına takılan sürücülerin sırasını taşıyabilir, vb.)

Bu yüzden sorularım iki yönlü:

1. Bu adresleme düzeni yukarıda özetlediğim gibi kararsız mı? Standartta bir şey eksik miyim, bu şema beklediğimden çok daha güvenilir mi, yoksa bu adresleme şeması, sürücülerinizin sadece bir farklı bir düzen mi yoksa bunları anakartınızdaki farklı yuvalara mı takıyorsunuz?

2. Yukarıdaki sorunun cevabı evet ise, neden bu adresleme şeması kullanılmaya devam ediyor? Her şey için UUID veya PARTUUID kullanmak çok daha kararlı ve tutarlı olmaz mıydı?

Basit numaralandırma şeması son sistemlerde gerçekte kullanılmamaktadır ("son zamanlarda" Ubuntu 9 ve üstü olması nedeniyle, diğer dağıtımlar da o dönemde uyarlanmış olabilir).
Kök bölümünün düz numaralandırma şemasıyla ayarlandığını gözlemlemeniz doğrudur. Ancak bu, yalnızca bir sonraki komutla geçersiz kılınan varsayılan veya geri alma ayarıdır, örneğin:

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

Bu, kök sisteminin dosya sisteminin UUID'sine göre seçilmesini sağlar.

Uygulamada, düz numaralandırma şeması genellikle sabittir (donanım değişikliği olmadığı sürece). Öngörülemeyen numaralandırmayı gözlemlediğim tek örnek, ilk gelen hizmet sunumuna göre numaralandırılan ve daha sonra IDE sürücüleri olarak taklit edilen birçok USB sürücüsüne sahip sistemdi. Bu işlemlerin hiçbiri doğal olarak kaotik değildir, bu yüzden bu belirli sistemlerin BIOS uygulamasında bir sorun olduğunu varsayıyorum.

Not: Bu bağlamdaki "kök bölümü", önyükleme yapılacak bölüm anlamına gelir, "kök aka. / Dosya sistemi" içeren bölümden farklı olabilir.

Açıkçası, UUID hiç adresleme yapmıyor .

Adresleme çok, çok basit: X sürücüsü Y sektörünü okuyun - ya da başka. Bellek adresini Z okuyun - ya da başka. Adresleme basit, hızlı, yorum için fazla yer bırakmıyor ve her yerde.

UUID adreslemiyor. Bunun yerine, arama, bulma, bazen cihazların görünmesini bekliyor ve ayrıca dosya sistemlerini (★) anlıyor . Ve kaç cihaz bulunduğuna bağlı olarak, çok uzun zaman alabilir. Ve bir kez bulundu, geri normal adresleme olduğunu.

GRUB'da buna search(★★) denir ve yalnızca GRUB kanatları büyüdüğünde kullanılabilir (arama, desteklediği her dosya sistemi gibi bir modüldür, bu nedenle yalnızca çekirdek yüklendikten sonra kullanılabilir). Linux'ta, adı (örneğin) var findfs, findfs bir dosya sistemi veya bölüm arayan sistemde blok cihazlarını arayacaktır .

Tüm blok cihazlarından geçer, onları bekleme modundan çıkarır, verileri okur ve UUID olması gerektiği gibi benzersiz değilse ( ddkazadan sonra veya benzeri) sonuç hala rastgele olabilir veya UUID değiştiğinde sonuç alamazsınız - UUID'ler de yapılandırma hatalarına eğilimlidir.

Genel olarak, UUID'ler harika ve elbette varsa, her yerde kullanmalısınız, özellikle de geleneksel adresleme başarısız olmak zorunda olduğunda, çünkü Linux'ta sürücü sırası rastgele; ancak karmaşıklığın basit adreslemenin ne anlama geldiğinin üzerinde ve ötesinde olduğunu anlayın. Ve özellikle önyükleyicilerin ilk aşamalarında, henüz bir seçenek olmayabilir. Adresleme önce gelir, büyüyen kanatlar daha sonra gelir.

Önyükleyici için, çaba sarf etmek gerekli olmayabilir (her önyükleyici GRUB gibi çok çeşitli dosya sistemlerini desteklemez). Durum hd0nedeniyle "BIOS'un önyükleme yaptığımız disk" olacağı garanti edilirse (BIOS sağlar) ve bu nedenle rasgele sürücü sırası sorunlarını devre dışı bırakabiliyorsanız, UUID araması yapın.

Konfigürasyonunuzda istediğinizi söylemek için yeterince eminseniz hd0,gpt2ve olması gerekir ve aksi halde olamazsa, bu şekilde kullanmanın yanlış bir yanı yoktur. Bazen, sade ve basit adresleme gayet iyi çalışır.

(★) Bunu daha önce burada ETİKETLER için açıklamıştım ...

Etiketler için genel bir standart yoktur, hepsi el örgüsüdür, örneğin util-linux'daki süper blokların bu uygulamasına bakın . Yarın yeni bir dosya sistemi icat ederseniz, etiketi olsa bile, destek eklenene kadar görünmez.

... ve UUID'ler için de aynı.

(★★) Aslında, GRUB'un searchbir --hintseçeneği var ve ... şimdi kaynak kodunu kontrol etmedim ve kılavuzlarında bile belgelenmedi, ancak böyle bir seçenek size her iki dünyanın en iyisini vermek için mantıklı olacaktır: ipucu söylemelidir searchiçin önce bu bölümü kontrol ve UUID maçlar beklendiği gibi, eğer cihazı tespit az çaba ve aynı değilse, hala bir şekilde çalışan tutmak için tam şişmiş aramaya geri düşeceğiz .

Buna ek olarak, daha önce bulunan UUID'ler önbelleğe alınma eğilimindedir, bu yüzden aradığınız UUID'nin aslında bir yerde olması koşuluyla tüm cihazların tekrar tekrar tekrar tekrar geçmesi gerekmez. ilk etapta önbellek haline getirin.

Ayrıca etiketleri de unutmayın. UUID'ler kadar benzersiz değil, daha bilgilendirici ve fstab'ınızı insan tarafından okunabilir hale getiriyorlar. Masaüstünüz veya küçük bir şirketseniz - başka bir deyişle, birkaç ila birkaç düzine sürücü yönetiyorsanız, etiketleri UUID'lere tercih edebilirsiniz.

@ Frostschutz'un sorunuza mükemmel cevabını göz önünde bulundurarak , muhtemelen "klasik" cihaz bağlantı adreslemesini tercih edeceğiniz bir senaryo, özellikle işe alınan VM (kısaltılmış, kafa karıştırıcı, "IaaS") bulutlarında VM kurulumudur. Bir Ubunzima 04.18 görüntüsünü özelleştirmek istediğinizi varsayalım . 2 diskli (tek kullanımlık) bir VM yaratırsınız: biri (tek kullanımlık) sistem sürücüsü, ikincisi taktığınız ve özelleştirdiğiniz. Muhtemelen, UEFI önyükleme bölümünü de eklersiniz, eğer yeni diskinizde daha yeni bir grub oluşturmak istiyorsanız. /mntAşağıdaki hedef bölümler için bağlama noktaları seçtiğinizi varsayarsak , istediğiniz bağlama tablosu şöyle görünür

/dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

Böylece, mevcut, sağlayıcı tarafından sağlanan, buluta hazır görüntüden 2 özdeş sürücü oluşturur, bunları yeni bir VM'ye bağlar ve önyükler. Doğal olarak,

• Hayali Ubunzima 04.18'in istisna olmadığı tüm modern işletim sistemi dağıtımları, UUID adlı bağlara güveniyor.
• Aynı görüntüden çıkarılan tüm sabit sürücüler aynı UUID'ye sahiptir. UUID'ler benzersizdir, o zaman ne ters gidebilir?

Tüm bunların olup olmadığını zaten görüyorsunuz.

Bu frankencontraption ilk kez önyüklendiğinde, sda9EFI önyükleme bölümü olarak seçildi , ancak Linux sdb1kök FS olarak yeniden takmaya karar verdi :

/dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

Açma komut dosyam bunun için oldukça hazırlıksız olduğundan, sonunda frankenbuild sırasında günlükte şikayet eden tek bir araç olmadan, önyüklenemeyen bir dud imajım var!

Tabii ki montaj masasını günlüklere yazdırdım. Ve elbette dağınıklığı tespit etmek çok zordur, çünkü montaj (8), rastgele ve cihazların monte edildiği sıraya göre montajları yazdırır, bu yüzden hemen fark etmedim şaşırtıcı değildi. Ve hayal edin, aynı senaryo (ancak farklı görüntülerden disklerle) daha önce 15 yaşındaki Glenfiddich kadar pürüzsüz çalıştı. Tahmin et kaç saatimi saçımı çekerek günlüğün üzerinden geçirerek problemi anlamaya çalışıyorum?

Masaüstü PC'den, yönlendiriciye gömülü bir Linux'a, Android telefonunuza, bir bulut veri merkezine kadar hiçbir durum için iyi ve zor kurallar yoktur. Bir SO cevabının objektif olması gerekiyor ve deneyimlerim veya tercihlerim elbette değil. Bu yüzden bölümleri tanımlamanın farklı yöntemleri arasından seçim yaparken mantıksal akıl yürütme örnekleri göstermeyi tercih ederim:

• Yapmamak için bir nedeniniz yoksa yalnız bırakın . UUID'ler çoğu modern dağıtım için varsayılan değerdir. İkinci bir sürücü eklemek söz konusuysa, o zaman deneyin ve karar verin. Muhtemelen bilmeniz gerekmeyecek. Sisteminiz hala önyükleme yapıyorsa ve yeni cihazı görebiliyor ve bölümleyebiliyorsanız, fstab'a biçimlendirip ekleyebilirsiniz (UUID, LABEL veya bir /devbağlantı ile aynı hususlar geçerlidir). Sadece sisteminiz ekstra sürücüyü taktıktan sonra önyüklemeyi reddettiğinde, bir sorununuz var demektir (ve belki de UEFI BIOS'ta önyükleme sırasını değiştirmek en hızlı yoldur).

  Pragmatik olarak, kendi masaüstünüzde hangi SATA konektörünün hangi sürücüye gittiğini etiketlemek en hızlı ve en kolay çözüm olabilirken, sistemin önyükleme şeklini değiştirmek ve oldukça olası bir önyükleme hatasından kurtulmak, muhtemelen en kötü zaman kazıcıdır. Ancak, ekstra bir sürücüye atmanın sizi rahatsız etmeye değer bir sorun olmadığını düşünen 50 programcı için yönetirseniz, en azından şansınızın sınırlarını test etmeyin ve ilk önyükleme sürücülerinin grub tarafından görüldüğünden emin olun hd0ve sistem olarak sda.

• Kendi sürücülerinizi ve bölümlerinizi masaüstünüzde veya üçünüzde veya küçük bir ortamda (yeri "başlangıç ​​ofisi" olarak komik bir şekilde çağıran yazılım mühendisleriyle dolu bir evin oturma odası) yönetmek için etiketler . Birinin makinesinden fiziksel bir sürücü çıkarırsanız, etiketleri tutarlı bir şekilde kullanırsanız nereden geldiğini bilirsiniz.

  Lsblk (8) diyorsa LABEL=bubba-boot, bubba adlı makineden çekildiğini biliyorsunuz ; ayrıca, bubba-boot , dilimin üzerinde , şımarık tadıma göre düpedüz bir çene kırıcı olan 6864c4ea-f9b9-46db-b875-4d7fc2981007'den çok daha kolay yuvarlanıyor . Etiketlerin benzersiz olmasını sağlamak artık üzerinize kayıyor, ancak karşılığında aldığınız şey etiketin anlamlılığı.

• /devAynı görüntünün ortaya çıkması nispeten kısa ömürlü, az bakım gerektiren VM'lerden oluşan bir tabur komuta ederken bağlantı tabanlı adlandırma ve tüm UUID'lerinin UU vaatlerine kadar yaşadığı haftalık ücretinize bahse girmezsiniz. Kendi fiziksel sunucunuzdaki Vyper-H veya Kugel Cloud ya da herhangi bir şey olsun, herhangi bir aklı başında VM hizmeti asla önyükleme sürücünüzü ve ikincisini ve sadece diğerini çağırmaz . Fiziksel bir makinede, SATA kablolarını yaratıcı bir şekilde bağlayarak aynı düzenlemeyi kolayca alabilirsiniz.sdesdc

  Şimdi araştırıyorum, ancak bu senaryoda, “tutarlı” Ethernet arabirimi adlandırma ile aynı rotaya gidiyorum: VM'lerde devre dışı bırakın. Beni yanlış anlamayın, PCI yuvasına 4 taktığınız NIC, bakmadığınız zamanlarda (veya belki de sizken bile; hiç utanman yok). Ne yazık ki, “VM taburu” ortamında aslında bunu yapıyorlar. Bu durumda, sağduyumuzun, eth0bir daha fazla tutarlıenp0s4f6. VM sağlayıcısı, sanal NIC numarası 1'i her zaman PCI veri yolu 0'daki yuva 4'e koymaya söz vermedi (ve belirtilen 3 varlıktan hiçbiri fiziksel olarak gerçek değildir) ve her zaman İşlev 6 olacaktır. normalde aynı sürücü modülüne sahip olduklarını düşünerek, genellikle virtio ailesinden (ve ilk NIC her zaman değilse eth0, aynı not² hala geçerlidir), ikinciden önceki ilk arayüze güvenir.

  ---

¹ Mecazi olarak. Eğer bu işi çok uzun süre kaldıysam.
² Öyleyse , sağlayıcıyı veya VM hipervizör yazılımını değiştirerek onlardan çığlık atmayı ciddi olarak düşünürdüm .

Her iki şema da çoğu linux dağıtımıyla karıştırılabilir ve eşleştirilebilir.

Kullanım durumuna bağlı olarak sonuçlar istenebilir veya istenmeyebilir - örneğin, yapılandırma dosyalarını değiştirmek zorunda kalmadan (sanal donanım veya gerçek donanım) sürücülerin sıcak değiştirilmesi aranan.

İkinci sorunuzun cevabı ("neden bu adresleme şeması kullanılmaya devam ediyor?"), Sanırım, atalet. Evet, yalnızca GPT bölümlenmiş disklerde UUID'leri kullanmak tamamen mümkündür. İçindeki /dev/xxxadlar yerine UUID'leri kullanabilirsiniz /etc/fstab. Ve şimdi Keşfedilebilir Bölümler Spesifikasyonu'na sahip olduğumuza göre , çoğu durumda artık UUID'leri belirtmeniz bile gerekmiyor, diskinizi bölüm türüyle bölümlendirin ve bölümler otomatik olarak alınacaktır. Makinemde root=giriş, çekirdek komut satırından tamamen eksik.

Önyükleme yükleyicilerinden bahsetmişken: GRUB, modern UEFI PC'lerde, makinenin önyükleme ile çok az ilgisi olduğu için çoğunlukla gereksizdir. Günümüzde GRUB yalnızca, görevin systemd-boot gibi daha basit ve daha iyi alternatiflerin bulunduğu bir çekirdek seçici programı olarak işlev görmektedir.