Oppdatere kernel med yum?

[Hagforce]

Hei

 

Kjører FC4 på en maskin, og skulle forlengst oppdatert kernel.

Har kjørt yum install kernel.

Men en må vel gjøre mer enn som så?

 

Noen tips til hvordan man trygt gjør dette uten at systemet tryner

[v3g4rd]

* Last ned kernel fra kernel.org.

* Pakk den ut under /usr/src

* Kjør "make menuconfig"

* [gjør de endringene du trenger + lagre]

* make && make modules && make modules_install && make bzImage

* Flytt den nye kernelen til /boot og konfigurer lilo eller grub

[Hagforce]

He he, det der lukter server som ikke starter opp etterpå

Har jo installert den nye kjernen via yum...

[v3g4rd]

Hvis du har installert en ny (prekompilert) kernel, er nok det eneste du trenger å gjøre å endre på konfigurasjonsfilen til grub eller lilo.

 

Jeg bruker ikke grub selv, men dette finner du nok lett ut av gjennom google.

 

Bruker du lilo, er det ikke verre enn at du redigerer /etc/lilo.conf og legger til følgende på bunnen av filen:

image = /path/til/kernel
root= /harddisk/som/skal/monteres/på/"/"
label = ny_linux_kernel
read-only

Når der er gjort, kjører du /sbin/lilo og får (mest sannsynlig) tilbakemelding om at oppsettet ditt er lagret på MBR.

 

Det lukter forresten bare "server som ikke starter etterpå" de første 3-5 gangene du kompilerer kernel selv. Etter det fungerer en egenkompilert kernel mye bedre enn en prekompilert en, og systemet ditt starter dessuten mye raskere.

 

edit: det er forresten mulig at yum gjør dette automatisk for deg. Hvilket versjonsnummer kommer opp når du skriver "uname -a"?

Endret 16. april 2008 av v3g4rd

[agvg]

Lenge siden jeg brukte FC4 men Yum skal da ta hånd om hele prosessen.

Normalt ligger den gamle kjernen som backup.

[Hagforce]

Det ser ut til at dere har rett, ser at yum har lagt inn den nye kjernen i grub.

 

Takker for hjelp

[agvg]

Etter det fungerer en egenkompilert kernel mye bedre enn en prekompilert en, og systemet ditt starter dessuten mye raskere.

 

Definer mye bedre i denne sammenhengen?

Tviler sterkt på at dette er verd bryderiet, og det er noe herk uten like og surre med ting utenfor pakkesystemet annet enn i reine nødstilfeller.

Og ja, har fiklet nok med dette kjernekompileringssurret til at jeg er sjeleglad jeg slipper.

[v3g4rd]

Definer mye bedre i denne sammenhengen?

Tviler sterkt på at dette er verd bryderiet, og det er noe herk uten like og surre med ting utenfor pakkesystemet annet enn i reine nødstilfeller.

Noen (av mange) fordeler:

* Optimaliserer systemet til å passe eget hardware

* Resulterer ofte i lavere minneforbruk

* Kernelen kan patches med drivere som ikke følger med som standard

* Reduserer størrelsen på kernelen

 

Selv har jeg erfart at jeg fikk mye bedre resulteter i Super PI ved å bruke av mine egne kerneler fremfor de som følger med Slackware til vanlig.

 

Nå har jeg aldri kompilert kernel selv i Fedora, så det er mye mulig at det fører til problemer når du bruker dependency-baserte pakkesystemer. I Slackware derimot, medfører det ingen problemer hvis du har kompilert kernel noen ganger først. For min del måtte jeg kompilere kernel 4 ganger før jeg klarte å bygge den første som ikke resulterte i kernel-panic. Per i dag er det egentlig ren plankekjøring, og er (ofte) det første jeg gjør når jeg setter opp et nytt linux-system.

 

Og ja, har fiklet nok med dette kjernekompileringssurret til at jeg er sjeleglad jeg slipper.

Da er det jo ikke verre enn at du prøver en gang til? Du kan tross alt ikke ødelegge noe, og du lærer utrolig mye av å kompilere egen kernel.

[agvg]

Har aldri hatt noe behov for og kompilere kjerner de siste årene, std kjernene til RedHat gjør jobben. Da jeg drev med dette var jo da man måtte gjøre det for og få ting til og fungere.

Gir meg dårlige minner om ISDN-kort og Linux, det var ganske bratt til tider.

[Harkonnen]

Noen av problemene med å kompilere kjerne selv:

* Du brekker som regel oppstartscriptene. Når du integrerer moduler som de prøver å laste i kjernen.

* Du får ikke med deg distrospesifikke patcher.

 

Og når det kommer til ytelse tjener du nok mer på å slå av tjenester du ikke bruker enn å rekompilere kjernen og kanskje spare ett par megabyte. Og i Linux er det ikke noe reelt ytelsestap ved å bruke moduler over å kompilere saker inn i kjernen. Og distrokjernene består som regel av en liten kjerne men en haug moduler. Så da er du like langt.

 

Det som faktisk er en fordel med å kompilere din egen kjerne er sikkerhet.

Du kompilerer inn alt som er nødvendig i kjernen og fjerner muligheten til å laste moduler. Da kan ikke laste inn ondsinnet kode i kjernen.

Endret 18. april 2008 av Harkonnen

[v3g4rd]

* Du brekker som regel oppstartscriptene. Når du integrerer moduler som de prøver å laste i kjernen.

Hvilken distro dreier dette seg om? Jeg har aldri hatt dette problemet selv, og jeg har kompilert kerneler på Slackware, Arch og OpenBSD.

 

* Du får ikke med deg distrospesifikke patcher.

Slackware kommer ikke med distrospesifikke patcher, og jeg har ikke vært ute for at driverne mine ikke støttes . Jeg tror heller ikke Arch gjør dette, men det er jeg faktisk ikke helt sikker på. Kernelen jeg laget for Arch fungerte som fjell når den var ferdig.

 

Og når det kommer til ytelse tjener du nok mer på å slå av tjenester du ikke bruker enn å rekompilere kjernen og kanskje spare ett par megabyte.

Dette er jeg ganske så uenig i. Kanskje det ikke er så farlig for enkelte, men jeg synes det er veldig greit at maskinen min booter flere sekunder raskere enn hva den gjør med en generic kernel. Hvordan du konfigurerer kernelen har dessuten mye å si om hvordan du skal bruke maskinen i etterkant. Selv ønsker jeg å kunne gjøre hverdagslige ting samtidig som jeg kompilerer programvare, og det fungerer ikke med mindre du har aktivert rettferdig scheduling.

 

Dette er nå hvertfall min mening

[Manuel]

* Optimaliserer systemet til å passe eget hardware

Dette blir synsing. Ytelsesforskjellen fra x86-32 til x86-64 er minimal. Vi har ingen grunn til å tro at tilgang på et par ekstra instruksjoner gjennom å gå fra i486 til f.eks Core 2 Duo har noen som helst praktisk eller målbar betydning.

 

* Resulterer ofte i lavere minneforbruk

Noen ganger, men den eneste grunnen til å ikke "velge inn alt" er at man ikke har lyst til å vente på kompileringen av alle modulene du ikke trenger. Siden Linux er en modulær kjerne så vil ikke flere moduler bruke mer minne med mindre man spesifikt laster dem inn med insmod/modprobe bare for å kaste bort minne.

 

* Kernelen kan patches med drivere som ikke følger med som standard

Etter min mening, den ene og eneste fordelen. For min egen del var det lenge siden jeg hadde behov for å kompilere inn støtte for "bleeding edge"-maskinvare eller Con Kolivas sine fiktivt responsforbedrende patcher.

 

* Reduserer størrelsen på kernelen

Sant nok for de få opsjonene som må kompileres inn i kjernen. Egentlig bare et problem der maskinen kjernen skal kjøre på har mindre enn 20 MiB RAM. De færreste kompilerer Linux-kjernen for å bruke det i kaffetrakteren eller mobiltelefonen.

 

Selv har jeg erfart at jeg fikk mye bedre resulteter i Super PI ved å bruke av mine egne kerneler fremfor de som følger med Slackware til vanlig.

Nå skal jeg ikke underminere dine erfaringer, men hvis det hadde vært en stor forskjell ved bruk av Super PI, så ville jeg heller hatt mistankte om at sammenlikningsgrunnlaget var en gammel 2.4-kjerne kontra 2.6, og at den gamle kjernen ikke hadde støtte for SSE/SSE2/3DNow!

 

Jeg mener ikke å starte en krangel her, men diskusjonen er ikke så ensidig som at man får en mer "effektiv" kjerne hvis man kompilerer den selv. Med mindre man lar det være en risikosport å oppdatere kjernen, så må man også kompilere alle tredjeparts moduler i etterkant. Selv med en KISS-distro som Arch, og AUR, så er det litt stress å kompilere modulene for grafikkortet, nettverkskortet og webkameraet. Dessuten er det herlig å seile på distribusjonen sitt eget pakkesystem siden dette, etter denne diskusjonen i betraktning, sparer brukeren for mye unødvendig hodebry og potensielle underlige feil fordi kjernen sin ABI endrer seg oftere enn de fleste skifter sokker.

 

For de som bruker Slackware så er dette selvsagt et ikke-tema siden pakkesystemet fortsatt står på stedet hvil i år 1992 ("Duck & hide").

[Harkonnen]

* Du brekker som regel oppstartscriptene. Når du integrerer moduler som de prøver å laste i kjernen.

Hvilken distro dreier dette seg om? Jeg har aldri hatt dette problemet selv, og jeg har kompilert kerneler på Slackware, Arch og OpenBSD.

 

* Du får ikke med deg distrospesifikke patcher.

Slackware kommer ikke med distrospesifikke patcher, og jeg har ikke vært ute for at driverne mine ikke støttes . Jeg tror heller ikke Arch gjør dette, men det er jeg faktisk ikke helt sikker på. Kernelen jeg laget for Arch fungerte som fjell når den var ferdig.

Slackware og Arch er ikke representative distroer når det gjelder den typiske out-of-the-box-distroen med binærpakkesystem. (Og OpenBSD er ikke Linux)

 

Og når det kommer til ytelse tjener du nok mer på å slå av tjenester du ikke bruker enn å rekompilere kjernen og kanskje spare ett par megabyte.

Dette er jeg ganske så enig i. Kanskje det ikke er så farlig for enkelte, men jeg synes det er veldig greit at maskinen min booter flere sekunder raskere enn hva den gjør med en generic kernel. Hvordan du konfigurerer kernelen har dessuten mye å si om hvordan du skal bruke maskinen i etterkant. Selv ønsker jeg å kunne gjøre hverdagslige ting samtidig som jeg kompilerer programvare, og det fungerer ikke med mindre du har aktivert rettferdig scheduling.

 

Dette er nå hvertfall min mening

Hvis du virkelig vil tjene inn tid ved oppstart lar du maskinen stå på hele døgnet ( unngår det ) eller så kan du bruke suspend to ram.

Og de fleste distroer sin default kjerne har god responstid ved interaktivbruk selv om maskinen er under last.

[v3g4rd]

Jeg har virkelig ikke tid eller bry til å starte en krangel om dette emnet. Selv opplever jeg at systemet mitt blir mer responsivt, raskere og stabilt ved at jeg kompilerer kernelen selv.

Dette er min mening, og hvis folk spør hvordan de skal oppdatere kernelen deres så videreforteller jeg de positive egenskapene jeg selv har erfart ved å gjøre dette selv.

 

Og for opplysning, jeg er fullt klar over at OpenBSD ikke er Linux, men takk for informasjonen.