Sun X2100 M2 kernel

Debian GNU/Linux

sziasztok!

a segítségetek szeretném kérni a címben szereplő szerverrel kapcsolatban. a jelenlegi default kernelt szeretném leváltani egy, a rendszerhez sokkal inkább illeszkedőre. a problémám ugye az, hogy a jelenlegi kernellel csupán a meglévő ram felét használom, illetve a proci sem működik a saját rendes üzemmódjában.

akárhogy olvasgatok, nem tudok rájönni, hogy mely kernel lenne a hardver számára leginkább optimális, ugyanis nem szeretnék 64bites kernelt használni (a memória nem lesz bővítve mostanában). ha jól sejtem, egy olyan smp-kernelre lenne szükségem, amely 32bites, és kezeli az 1 gigánál több ramot is.

a kérdésem az lenne, hogy a fenti kritériumok alapján melyik kernelre van valójában szükségem? tovább nehezíti a dolgot, hogy a szerver már üzemben van, így azt már csak zárójelben jegyzem meg, hogy az sem lenne hátrány, ha magát a kernelforgatást meg lehetne úszni valahogy. :o

válaszotok előre is köszönöm!

  • 1444 megtekintés

a backportolt dolog kissé ijesztően hangzik, így ezt egyelőre talonba tenném. a másik tippet köszönöm, meglehet, hogy élek vele.

a gondjaim:

- olvastam olyat, hogy az opteron számára a k7 jelű kernel a tökéletes. bár volt, aki hozzám hasonlóan megzavarodott a témában (http://ubuntuforums.org/showthread.php?t=433682)

- nem világos, hogy a highmem a nem generic kerneleknél mindnél elérhető-e?

- illetve, hogy mondjuk ez így valóban ilyen egyszerű lenne? http://portal.censornet.com/s.nl/ctype.KB/it.I/id.958/KB.61/.f

csupa kétely vagyok :o

hoh? te ezt nem gondolod komolyan, ugye?

ott a sok sufnidisztro (frugal, uhu, debian, etc), amit fejlesztok a szabad idejukben barkacsolnak tobb-kevesebb (inkabb kevesebb) sikerrel. es ott van a rhel ill a suse enterspajz, amit emberek azert barkacsolnak, mert fizetest kapnak erte; van normalis QA, stb.

eles kornyezetben nem hasznalnek olyat, amit emberek hobbibol fejlesztenek. ha meg nincs ra penzed (marmint a supportra), mert ertesz hozza, de szeretnel egy normalisan osszerakott rendszert, ott a centos, ami egy az egyben SRPM -bol forgatott rhel.

just my 2 cents

nem fikazasrol van szo.
egyet kell ertsek nagyzvel.
pl debiant felraktam ultra5 re nem volt kepes kezelni ket szerencsetlen halokartyat, a 2dikat eth1_renemtomminek nevezte el bese lehetett konfolni. felmentem freenodera hummogtek valami udev rulest nem jott be. mast mit csinalhacc? semmit
rhel/sle* nel legalabb tudod h _van_ szuport ha "akarod".

lehet akarmilyen organization az nem segit

Ha megnyugtat a support sem fog tudni segiteni az esetek nagy reszeben, csak mondogatjak, hogy upgradelj erre meg arra, mert addig nem foglalkozunk veled, majd ugyanugy szetteszik a kezuket, maradsz magad. Ez foleg a csoda-lol RH/Susu parosra ertendo, amit itt par elmebeteg enterspajznak hiv, a debiant meg sufnituningnak. Jajj, tudom, fuj linugszmegdebianmegjujjcsunyageenu.
Azt meg vegkepp nem ertem hogy ha akkora support elharcos vagy miert debiant raktal ra az ultra5re es miert varod el hogy a szemhej puder deviceodat is felismerje outofbox.

:) ugye te sem gondoltad teljesen komolyan? Jobb lehet egy olyan dist, ahol patkolják a kernelt, backportok is akadnak benne - és lehet, hogy ez a supportált verzió... - mint egy másik "sufnidisztro"? Egyáltalán mit jelent a support egy átlagos esetben? Telefon, szerelő, telepítési tanácsadó, programfejlesztő?
Akkor már inkább Solaris, az supportált is ha akarod, ráadásul stabil tud lenni.

Igazad lehet, de egy rhel esetén sem hiszek igazán a vanillaközeliségben :) /ettől még kedvelem, de nem tartom kiválóbbnak többinél/.
Sajnos volt kellemetlen tapasztalatom egy nem neves vas esetén rhel/centos/fedora esetén, s előbbinél a support sem tudott segíteni - igaz debian is megakadt nálunk ugyanitt, de végül egy újabb ubuntu felismerte az ominózus vezérlőt.
Ettől függetlenül szerverre szerintem is: amit jól ismersz és amit megbízhatónak tartasz - jelen esetben szerintem ha nem gnu kellene a topicnyitó szerint akkor Solaris.

miota attertek az "uj, innovativ" kernelfejlesztesi modellre, azota 3 dolgot tehet egy disztib:
- allandoan a legujabb kernelt hasznalja (2.6.24 jelenleg) az OSSZES supportalt OS verzioban
- marad egy "LTS" kernelnel (2.6.16, 2.6.22 ha jol emlekszem)
- backportol minden security fix-et es egyebet maganak arra a verziora, amit az adott OS hasznal

a legtobb disztrib a 3. utat valasztja, ami egyenlo azzal, hogy agyon kell patch-elni a kernelt.

a kereskedelni OS-ek pedig kenytelenek a tamogatott OS-ek altal hasznalt, meglevo kerneleiket modositani, backportolni az osszes feature-t. es ezaltal megvalositani azt, amire a kedves kernel fejlesztok sz@rnak nagy ivben: kompatibilitas, mind forras mind binaris szinten.

emellett az enterprise disztrib-eknek van egy szolgaltatasa: a hw (jellemzoen server / workstation) gyarto fizet az OS keszitojenek, hogy tamogassa a gepet, igy a gep arusitasaval egy idoben elerheto hozza a validalt OS. nem minden esetben tokeletes, de sokkal tobb, mint amit egy olyan distrib nyujt, akik meg jo esellyel nem lattaik ilyen hw-t.

1 pelda:
- 2005 ev elejen vettunk egy gepet, amiben SAS volt. a 2.6.14-es kernelben jelent meg a SAS, mint SCSI transport layer. a RHEL4 a 2.6.9-es kernelbe backport-olta az uj drivereket, igy a vas hasznalhato lett es a binaris kompatibilitas is megmaradt, ami nem art, ha hasznalsz kereskedelmi termekeket (pl. IBM ClearCase) hasznalsz.

( tast | 2008. 01. 31., cs – 14:37 )

Miért nem használod az amd64-es Debian-t? Nekem több X2100 fut remekül vele:

root@ss1:/root# uname -a
Linux ss1 2.6.18-5-amd64 #1 SMP Tue Oct 2 20:37:02 UTC 2007 x86_64 GNU/Linux

Ha már van egy rendes géped, akkor használd ki amit tud.

bevallom őszintén nem gondolkodtam egyéb alternatívában. úgy gondolom, a debian (a lassú fejlődési ciklusa ellenére - vagy éppen amiatt) tökéletesen megfelel arra a célra, amire használom. a milliónyi leírás, és a hatalmas felhasználótábor szintén pozitívum. egymilliárd légy nem tévedhet, ugye... :)

egyébként természetesen szívesen ismerkednék más rendszerekkel is, de a napi feladatok mellett sajnos nem jut időm kísérletezgetni, az az igazság.

Világos. Amúgy nincs bajom a Debian-nal.

(Ha viszont egyszer beindulna az OpenSolaris, főleg debian-szerűen (Project Indiana, Nexenta)- amit egyesek éppen ezért utálnának.. -, akkor talán sokkal könnyebb lenne átváltani rá, ha valaki akar (aki debian linux-on "nőtt fel"). Szerintem nem véletlen, hogy erre gyúrnak Ian bácsiék a Sun-nál.. Na de ez csak elmélet, még messze van, ha egyáltalán lesz belőle valami..)

(ld.
http://hup.hu/node/50395
http://hup.hu/node/49569 )

( fabrik | 2008. 01. 31., cs – 16:04 )

nagyon szépen köszönöm az egyéb rendszerekre vonatkozó javaslatokat, de mint azt írtam, ez egy működő szerver, lényegében a kérdésem nem arra próbált irányulni, milyen rendszer szolgálná ki jobban a most is hibátlanul működő debian helyett az igényeimet.

( godot v | 2008. 01. 31., cs – 16:05 )

Ehh....

Etch-nél 1GB-nél több ram esetén:

apt-get install linux-image-2.6-686-bigmem

vagy használhatsz 64 bites kernelt 32 bites userlandel

apt-get install linux-image-2.6.18-6-amd64

( fabrik | 2008. 02. 04., h – 15:18 )

nos. hosszú 3 órán vagyok túl. :)
a 2.6-amd64-k8-smp telepítése után a szerver így cirka 200km távolságból azt mondta, hogy semmit. se ping, se levelezés, se semmi. szerencsére a szolgáltató maximálisan készségesen állt a problémához, így a 3 órás kieséstől eltekintve minden ok. végülis a régi kernellel fut a vas, amit nagyon sajnálok :(

a probléma?

"ip6tables v1.3.6: can't initialize ip6tables table `filter': Invalid argument
Perhaps ip6tables or your kernel needs to be upgraded."

a bugs.debian.org szerint igen, ez egy létező hiba http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411663

tippem sincs, mi lenne a megoldás, bár igazából mára elég volt egy ilyen leállás :(

(eszem ágában sincs flame-t szítani, de szeretném elejét venni a korábbi parttalan os-vitáknak. a többi, korábban említett rendszernél is ugyanígy előfordul ez a hiba:
http://www.google.com/search?q=Perhaps+ip6tables+or+your+kernel+needs+t….)

akkor ez a linux kernel szimpla hibája .. a 2.6.25-ös kernelben igencsak át lesz gyúrva az iptables és a külön ipv4-es és ipv6-os iptables össze lesz "fésülve", azonban a kompatibilitás elvileg megmarad... majd meglásssuk (mondta a vak is ..)

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.18-rc0-szami1