Linux çekirdeğini güncelleme, sistemin kalanını olduğu gibi bırakma


25

Ben bir OpenBSD kullanıcısıyım. In OpenBSD SSS diyor:

OpenBSD, senkronize tutulması amaçlanan eksiksiz bir sistemdir. Bir çekirdek ve birbirlerinden ayrı olarak yükseltilebilecek yardımcı programlar değildir.

Bir sistemi yükselttiğinizde tek seferde yaparsınız; çekirdek ve taban sistemi değiştirilir. Sonra gidip 3. parti paketlerinizi güncelleyin . Eğer kaynaktan derlerseniz, çekirdeği yeniden derler ve yeniden başlatırsınız. Sonra temel sistemi ve daha sonra kurduğunuz paketleri yeniden kurarsınız. Her şeyi yeniden oluşturduğunuzdan bu yana birkaç hafta / aydan uzun bir süre geçmişse, önce bir enstantane kurup oradan yeniden oluşturun (en güncel CVS şubesini takip ediyorsanız).

Eşit olmayan bir çekirdek, temel sistem ve / veya 3. parti paketlere sahip olmak olası bir sorun kaynağıdır ve az ya da çok az, resmi posta listelerinden ciddi bir yardım almanıza engel olur.

Bu konuda oldukça iyiyim. Aslında, bu OpenBSD kullanmamın sebeplerinden biri. Sistemi tutarlı bir birim yapar ve zihinsel bir bakış açısı oluşturmamı kolaylaştırır.

Linux'ta nasıl bir şey? Farkında olduğum çoğu Linux, BSD'ler ile aynı anlamda bir "temel sisteme" sahip değil, dağıtım sağlayıcısı tarafından toplanmış bir paket koleksiyonuna sahip. Daha sonra başka bir yazılım buna yerel bir yönetici tarafından, başlangıçtan itibaren ne ile daha sonra eklenmiş olanlar arasındaki sınırın en iyi ihtimalle bulanık olduğu şekilde eklenir.

Linux'un (genel olarak) kullanıcı alanı eşleşmesi için güçlü bir çekirdeği yok mu? Çekirdek, bildiğim kadarıyla, diğer yazılım paketlerinde olduğu gibi güncellendi ve bunun mümkün olduğu konusunda beni biraz şaşırttı. Buna ek olarak, bazılarının bile (OpenBSD'de önerilmeyen) özel çekirdekleri derlediğini ve açılış menülerinde listelenen çok sayıda farklı çekirdek sürümünün bulunduğunu ekleyin.

Bir Linux sisteminin çeşitli alt sistemlerinin birbirlerinden bağımsız olarak güncellenmelerine rağmen birbirleriyle işbirliği yapabileceklerini kim ya da ne garanti eder?

Bu sitede başka bir kullanıcı istediği için soruyorum nedeni bana daha yeni bir sürümü ile yaptığı Linux sisteminde çekirdek değiştirilmesi olsun "yapılabilir olurdu". İşlerin OpenBSD tarafından bakıldığında, evet, bunun sistemi bozmayacağının garantisini vereceğimi söyleyemedim.


Yukarıda "Linux" u "Linux dağıtımı", çekirdek + yardımcı programları için bir kısayol olarak kullanıyorum.


OpenBSD'nin sadece tek bir dağıtıma sahip olduğunu söylemenin bir başka yolu. Normal bir Linux sistemindeki çoklu grub menüsü girişleri, (genellikle) en yeni olanın bir nedenden dolayı önyükleyememesi durumunda daha önceki bir çekirdeğe düşmek içindir.
Thorbjørn Ravn Andersen

Yanıtlar:


29

Linus Torvalds, kullanıcı alanı gerilemelerine neden olan çekirdek değişikliklerine karşı çok güçlü bir görüşe sahiptir (ayrıntılar için " Linux çekirdeği: kullanıcı alanını kırma " sorusuna bakın).

Kullanıcı alanı ve çekirdek arasındaki arayüz sistem çağrıları tarafından sağlanır. Daha yeni çekirdeklerde daha fazla sistem çağrısı olabilir ve bu değişiklikler varolan uygulamaları bozmadığında çıkanlardaki değişiklikler olabilir. Bir sistem çağrısı arayüzünün flag parametresi olduğunda, yeni çekirdekler genellikle yeni işlevselliği yeni bir bit bayrağıyla gösterir. Bu şekilde çekirdek, eski uygulamalarla geriye dönük uyumluluğu korur.

Mevcut arayüzü kullanıcı alanını bozmadan değiştirmek mümkün olmadığında, genişletilmiş işlevsellik sağlayan ek sistem çağrıları eklenmiştir. Bu nedenle dup, umountsistem çağrısının üç sürümü ve iki sürümü vardır .

Sabit bir kullanıcı alanına sahip olma politikası, çekirdek güncellemelerinin kullanıcı alanı uygulamalarında nadiren sorunlara neden olmasının nedenidir ve genellikle çekirdeği yükselttikten sonra sorun beklemiyorsunuzdur.

Bununla birlikte, çekirdek arayüzleri ve diğer uygulama detayları için aynı API kararlılığı garanti edilmez . Sysfs (on /sys) ve procsfs (on /proc/), düşük düzey uygulamalar tarafından kullanılan çalışma zamanı yapılandırması, donanım, ağ, işlemler vb. Hakkında çekirdek uygulama ayrıntılarını gösterir. İyi bir sebep varsa, bu arayüzlerin çekirdek versiyonları arasında uyumsuz bir şekilde değişmesi mümkündür. Değişiklikler hala mümkünse uyumsuzlukları en aza indirmeye çalışmaktadır ve uygulamaların ara yüzleri sorunlara neden olabilecek en az şekilde nasıl kullanabileceği konusunda kurallar vardır . Bu etki de sınırlıdır, çünkü düşük seviyeli olmayan uygulamalar bu arayüzleri kullanmamalıdır.

@PeterCordes bir değişiklik olmadığını işaret procfs veya sysfs da dağılımları komut init tarafından kullanılan bir uygulama kırar, aa sorunu olabilir.

Bu, dağıtımınızın çekirdeği (uzun vadeli destek veya ana hat) nasıl güncellediğine ve dağıtımlar genellikle aynı zamanda güncellenmiş araçları gönderdiği için sorunların nispeten nadir olmasına bağlıdır.

@StephenKitt , yükseltilmiş kullanıcı alanının çekirdeğin daha yeni bir sürümünü gerektirebileceğini, bu durumda sistemin eski çekirdeğe önyükleme yapamayabileceğini ve dağıtım sürüm notlarının uygun olduğunda bundan bahsettiğini ekledi.


1
Uzun vadede, bu açıklamanın çekirdek-kullanıcı arayüzünün bir özeti ile (aka sistem çağrıları) bir özeti ile genişletilmesi faydalı olacaktır, çünkü farklı şekilde yapılandırılmış çekirdeklerin uygulamaları bozmadığı mekanizmayı açıklar.
wallyk

3
Procfs ( /proc) ve sysfs ( /sys) bile aynı "kullanıcı alanını bozma" politikasını / felsefesini izleyerek mümkün olduğu kadar sabit tutulur. Ayrıca, ioctl()cihaz dosyalarındaki kodlar en.wikipedia.org/wiki/Ioctl . Basit sistem çağrısı ABI uyumluluğunun çok ötesine geçiyor, ancak iyi bir neden olduğunda dediğiniz gibi, işler değişiyor /procve değişiyor /sys. Programların çoğunu doğrudan kırmaz, ancak dağıtımınızın init betikleri tarafından kullanılan düşük seviyeli bir kullanıcı alanı programını bozarsa, bir sorunla karşılaşabilirsiniz. Neyse ki bu nadirdir.
Peter Cordes

Aslında IIRC rfkillanahtarı gibi bazı dosyalar bazı çekirdek güncellemeleri arasında konum değiştirmiştir. Yani /procve /syssistem arayüzü daha çok daha az kararlıdır. Neyse ki, dağıtımlar genellikle büyük bir dağıtım sürümü yükseltmesi olmadığı sürece bu tür çekirdek yükseltmelerini içermez.
Ruslan

3
Burada göz önünde bulundurulması gereken iki husus vardır: çekirdeği yükseltme ve kullanıcı alanını yükseltme. Çekirdeğin ABI kararlılığı sayesinde, çekirdeğin yükseltilmesi oldukça güvenlidir ( genellikle /procve hatta /sysdeğişir - taşınma yıllar alır). Ancak, kullanıcı alanını yükseltmek yeni bir çekirdeğe ihtiyaç duyabilir ve yeterince yeni bir çekirdeğiniz yoksa, başlatılamaz bir sisteme sahip olabilirsiniz. Distro sürüm notları uygun olduğunda bundan bahseder (bu yüzden dağıtımları kör şekilde yükseltme, sürüm notlarını okuyun).
Stephen Kitt

1
/ Proc ve / sys dosyalarında ve yeni alanlara daha fazla alan eklemek için kullanıcı alanının bunları nasıl okuması gerektiği konusunda kurallar vardır. / proc / stat, örneğin veya / proc / meminfo. Kullanıcı alanının eklenen alanları yoksayması beklenir.
Zan Lynx,

11

Linux çekirdeği ve tarihsel olarak GNU projesi tarafından geliştirilen kullanıcı araçları tarafından yönetilen bir Linux dağıtımının kullanıcı alanı gevşek bir şekilde birleştirilmiştir. Bu kısmen tasarım gereği, kısmen de zorunluluk gereğidir.

Çekirdek ve temel kullanıcı alanının birlikte tasarlandığı ve sürdürüldüğü BSD'lerin aksine, Linux çekirdeği ve kullanıcı alanı farklı insanlar tarafından geliştirilmiş ve korunmuştur. Bu yüzden, onları sıkıca birbirine bağlı tutmak, toplum istese bile, sanmıyorum ki zor olurdu.

Ayrıca @sebasth, Linux çekirdeği projesinin ana politikasının kullanıcı alanını kırmaması gerektiği konusunda mükemmel bir noktaya değindi. Elbette ki hangisi gevşek kuplajı zorlayan başka bir faktördür.

Bununla birlikte, hala bir dereceye kadar eşleşme vardır. Yeterince eski bir Linux çekirdeği modern dağıtımlarla çalışmayacak.


2
@Abigail bu nitel toplamadır, ancak kullanıcı alanı eksik çekirdek özellikleri için uygun geri dönüşler (hatta bozulmuş geri dönüşler) uygularsa, ileriye dönük uyumluluk sağlanabilir . Kuşkusuz çoğu zaman arzu edilmez hatta buna değmez, ancak bazı yazılımlar bunu yapar ( glibcörneğin). (Ama evet, bu bir çekirdek vaadi değil, bir kullanıcı vaadi vaadidir.)
Stephen Kitt

7

Anladığım kadarıyla Linux çekirdeğin kendisi , ve diğer her şey yardımcı. Çekirdeği, genellikle çekirdeğin kendisinden ziyade kitaplıklara bağlı olduğundan, (çok sayıda) kurulu paketten bağımsız olarak yükseltebilirsiniz . Genelde yalnızca çekirdek sürümleri ile donanım sürücüleri (örneğin GPU sürücüleri) arasındaki bağlantıyı göreceksiniz. Bazı yazılımlar yalnızca çekirdeğin belirli sürümleriyle uyumludur, ancak bu programların kişisel belgelerinde belirtilmelidir.

Bir sistemde kurulu iki çekirdek paket paketinin olması oldukça yaygındır - şu anda kullanılan paket ve önceden kurulmuş paket. Yükseltme yaparken, yeni sürümün doğru bir şekilde çalışmasını sağladıktan sonra, en eskisi kaldırılabilir ve hala bilinen bir güvenliğe sahip olursunuz. Örneğin Red Hat (ve kuzenleri) package-cleanup --oldkernels --count 2bunu otomatik olarak yapmak zorunda.


Çekirdek sürümüne bağlanması gerektiğini düşündüğünüz kmod gibi bir şey bile , hangi sürümlerle çalışacağına biraz karar vermiştir.
Ignacio Vazquez-Abrams

4

Buradaki tüm iyi tartışmaların yanı sıra, yardımcı olacak birkaç nokta daha ekleyebilirim.

Çekirdek ekip politikasını zaten biliyoruz ve Linux dağıtımları olarak çekirdek kaynak kodunu olabildiğince saf tutmaya çalışıyoruz. Bunun anlamı, ne zaman bir kırılganlık meydana gelirse veya bir düzeltme eki gerektiren bir şey olursa, çekirdek ekibini bilgilendiririz ve yamalar konusunda yardım etmeye çalışırız, ama sonunda nihai karar çekirdek ekibindendir.

Bazı dağıtımlar diğerlerinden daha fazla ek yamalar ekler, ancak ana fikir geliştiricilerden geldiği gibi bu fikri saklamaktır. Açıkçası, özel çekirdek konfigürasyonuna ihtiyaç duyan bazı programlar var, özellikle de sanallaştırma ve üçüncü taraf sürücüler ve genellikle ikisi de belirli bir çekirdek sürümüyle veya en azından çok eski olmayan bir sürümle çalışmak için kullanılıyor ... nedense deniyorlar. en yeni çekirdek özellikleriyle çalışmak ve bu nedenle, onları eski bir çekirdekle çalıştırmayı denerseniz düzgün çalışmayabilirler.

Akılda tutulması gereken ilave bir unsur, tüm Linux dağıtımlarının tüm yazılımın sistemle uyumlu olmasını sağlayan bir bakım ekibine sahip olmasıdır. Bu yüzden hemen hemen her dağıtım istikrarlı ve dengesiz bir sürüme sahiptir. Geliştiriciler "kararsız" yazılımla çalışırlar ve hepsi test edildiğinde onu kararlı olarak işaretlerler, ancak bundan sonra normal bir kullanıcı paketi yükseltebilir, böylece sizden normal bir kullanıcı olduğunu söyleyen kişi yazılımın% 90 güvenli bir şekilde test edildiğinden emin olabilir .

Öyleyse, topluluk kim ve ortak yaklaşım ne olmalı, birlikte çalışan bir yazılıma ihtiyacımız var, sistemi bozmamaya ihtiyacımız var, bu yüzden Filesystem Hierarchy Standard gibi standartlara uymaya çalışıyoruz .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.