!!2.4.18-as woody kernel patchset. (!grsec2!,!posix_acl!,...

Debian GNU/Linux

!!2.4.18-as woody kernel patchset. (!grsec2!,!posix_acl!,...

  • 1092 megtekintés

( fellow | 2004. 07. 15., cs – 03:21 )

csokar:
siganetureomban van kernel is, debian is; ha egyikben se talalod meg a valaszt, akkor irj egy kicsit bovebben a problemakrol;

( csokar | 2004. 08. 04., sze – 09:27 )

Az lenne a kérdésem, valaki találkozott már olyannal,vagy van valami elképzelése, hogy ha fordítok egy kernel minden rendben van, majd mikor megpróbálok rábbotolni a kártyára elindul és mikor a root particiok szeretné behúzni akkor elkezd pánikolnoi a kernel. A kernelbe belefordítottam a raid támogatást (fel is ismerte), és benne van az a modul is(benne!!) amitől rá tudok bootolni.

( csokar | 2004. 08. 02., h – 17:16 )

szevasztok ugyan csak kernel bajom van, van valakinek gőőze mit b.. -am el????A problémám, inkább jelenségem a következő. A raid kártyám miatt szerettem volna (kell a botolás miatt) kernel fordítanom. Vettem egy tiszta gépet és nem sikerült. (20* jára sem.)
Gondoltam kipróbálom magam, mert időm van akkor egy teljesen tiszta Sarge-ot majd közvetlen telepítés után (nincs rajta semmi), felraktam a „kernel-sorurce csomagot” és a /boot könyvtárban található config fájlt bemásoltam a /usr/src/linux/kernelxxx/ könyvtárba ezután elindítottam a make modules elmentettem és kiadtam a make dep; make bzImage; make modules; make modules_install-t lefutott hiba nélkül. Bemásoltam az imidzset a /boot könnytárba megszerkesztettem a /etc/lilo.conf-ot és kiadtam a lilo parancsom mely hiba nélkül visszatért.
Eddig minden rendben ekkor újra indítottam. Szerintem az eredeti config-ból egy tökéletes másolatok kellett volna tudnom csinálni…
Most kifagyott…
Mivel ekkor még nem tudtam mi baja szegénynek ezért, vas van bőven alapon kicseréltem az egész gépet!!! Mindenestől!!! Végig mentem minden ugyan azon a hibán, amiket az előbb sikerül végigvinnem, majd sokadik! Próbálkozásomra rájöttem, nem szereti a ReiserFs-t, semmi baj előröl e fent említett dolgok, és láss csodát, betölti, majd kiakad egy pár sorral feljebb avval, hogy nincs vagy nem tudja betölteni /lib/modules2.4.25/modules.dep-et. Megnéztem van ott néki

Feladom, elmegyek és veszek egy Microsoft Server 2003, hátha avval is előidézhetem ezeket.
A legjobban az bosszant, kellene már a gép egy hónapja sz.. vele és raid-em még sehol.
Ennek tetejébe áthívtam az egyik haveromat, aki Linux guru és sajnos Pétek 5-től Szombat 3 ig sz.. tudunk ezekkel, tehát nem biztos, hogy az ön készülékjében van a baj

( Oscon | 2004. 08. 02., h – 18:10 )

[quote:fd6e8cdcf2="csokar"]Semmi baj előröl e fent említett dolgok, és láss csodát, betölti, majd kiakad egy pár sorral feljebb avval, hogy nincs vagy nem tudja betölteni /lib/modules2.4.25/modules.dep-et. Megnéztem van ott néki?

1. A modult többnyire csak az az adott kernel tudja betölteni , amihez fordították...
tehát ha fordítottál vagy 3féle 2.4.25-ös kernelt, és közbe modulokat meg nem csináltad meg újra, ne csodálkozz ha nem
működik a "régihez fordított" modul az "új" kernellel.
2. Ha korábbi kernel is 2.4.25-ös volt, akkor fennál a lehetősége, hogy a régebbi kernel és az újabb kernel cuccai "keverednek"...
3. Ha a /usr/src/linux (vagy ahova kitömörítetted) mappában van egy Makefile fájl.
Itt van egy extraversion! Ha ide beírsz valamit pl. (-raides), akkor
a /lib/modules/2.4.25-raides mappába rakja a modulokat így nem fognak összekeveredni.
4. Ugye a System.map fájlt is bemásoltad a /boot mappába? kernelfordítás után, nem csak a bzimage-t?

5. Elsp fordítás után a második előtt célszerű kiadni a make mrproper parancsot, ami kitakarítja az előző fordítás "maradványait".
és "tiszta lapról" indulsz. konfig fájlt (.config) is kitakarítja, úgyhogy azt elöbb mentsed le.

( csokar | 2004. 08. 02., h – 18:47 )

vissza kérdezek...
mit értesz azon, hogy érted az hogy nem csináltam meg a modulokat??
A friss gépen mikor kész lettem a telepítéssel utána fordítottam le a kernel és kiadtam a make modules parancsot nem erre gondolsz????Ha többször fordítok akkor vagy a clean-t v. mrproper-t szoktam használni. A system fájlt nem másoltam át, most átmásoltam de sajna csak ettől nem lett jobb:) úgy szokott történni. vann még valami jótanács???? Most fordítok egy újat de ha nem sikerül a dunának megyek:)

( Oscon | 2004. 08. 02., h – 18:57 )

[quote:b2e2e12f45="csokar"]vissza kérdezek...
mit értesz azon, hogy érted az hogy nem csináltam meg a modulokat??
A friss gépen mikor kész lettem a telepítéssel utána fordítottam le a kernel és kiadtam a make modules parancsot nem erre gondolsz????

Majdnem jó :!:

Ez megcsinálja a modulokat, de szükséged van a make modules_install-ra még utána, ami be is rakja a /lib/modules-be és megcsinálja a "függősége(ke)t" is (modules.dep, stb.).

( FeriX v | 2004. 08. 02., h – 22:04 )

[quote:5965d7009c="csokar"]vissza kérdezek...
mit értesz azon, hogy érted az hogy nem csináltam meg a modulokat??
A friss gépen mikor kész lettem a telepítéssel utána fordítottam le a kernel és kiadtam a make modules parancsot nem erre gondolsz????Ha többször fordítok akkor vagy a clean-t v. mrproper-t szoktam használni. A system fájlt nem másoltam át, most átmásoltam de sajna csak ettől nem lett jobb:) úgy szokott történni. vann még valami jótanács???? Most fordítok egy újat de ha nem sikerül a dunának megyek:)

Én Debian alá így fordítok kernelt:
pl.
apt-get install kernel-headers-2.6.7-1-686-smp
cd /usr/src
tar xjf linux-2.6.7.tar.bz2
cd linux-2.6.7
patch -p1 <../peccsek
cp /usr/src/kernel-headers-2.6.7-1-686-smp/.config .
make menuconfig
(itt beállítom a:
- processzort
- IDE driverek közül csak azt hagyom ami az én gépemben van
- beállítom a framebuffert majd )
make-kpkg --initrd --append-to-version=-mm7-2.9 --revision=clevo-d870p-2.9 kernel_image
ahol az mm7 egy peccs, 2.9 egy verziószám.
Ha kész:
dpkg --install /usr/src/kernel-image-2.6.7-mm7-2.9_clevo-d870p-2.9_i386.deb

lilo.conf:
image=/boot/vmlinuz-2.6.7-mm7-2.9
label="DEB 2.6.7-mm7"
initrd=/boot/initrd.img-2.6.7-mm7-2.9
vga=normal #0x343 1400x1050
read-only

Ennyi.

( csokar | 2004. 08. 03., k – 09:04 )

szóval én másképpen szoktam. A fent emlitett dódszer szerint. Egyszerűen nem értem miért nem tudok egy frissen felrakott Sarge-ból csinálni egy új kernelt. Most kiváncsiságból felraktam egy woody-t és szó nélkül elkészült. Valakinek valami ötletet!!!!!!!!!!!!!!!!!!

( Névtelen (nem ellenőrzött) | 2004. 07. 12., h – 09:17 )

Hello
remlem tudsz rajtam segíteni, olyan problémám van, hogy szükségem van egy raid kontroller-re és mindenütt azt olvastam, hogy kernel fordítás útán tudom használni.
Problémám: Dselect-tel felraktam a kerner-source csomagot, ki is csomagoltam a /usr/scr/ könyvtárba létre hozott egy kernel-source2.4.18-as könyvtárat. Beszereztem egy új kernelt2.4.6 kicsomagolva ugyanitt található. A kérdésem úgy hangozna mit csináljak avval, hogy ha elinditom a „make menuconfigot” akkor a kernel verzió számát amit kiír az 2.4.18 és nem az új, hogyan tudnám kicsrélni????

( Oscon | 2004. 06. 30., sze – 02:02 )

Pontcho örömére úgyfest elkészült a nagy mű!...-))

Nagyban köszönhetően PaXTeam olvtársunk szakértői segítségének!

A kernelt nem lehet letölteni (mivel elfogyott a tárhelyem), csak a patch-et., amivel a forrást fel kell pacsálni.

http://startadsl.hu/oscon/patchset-debian-woody-2.4.18-gekaichromage.patch

a fájl mérete 5449422 byte.

csak és kizárólag az itt található kernel-re alkalmazható, a vanilla 2.4.18-ra sem megy fel.
kizárólag a debianizált 2.4.18-14.3(woody)-ra, semmi másra!:

http://packages.debian.org/stable/devel/kernel-source-2.4.18

Doksi:
A patch-et a kicsomagolt forrásfába a /usr/src/linux kell bemásolni/+letölteni.
itt kell kiadni a

patch -p1 -E < patchset-debian-woody-2.4.18-gekaichromage.patch

parancsot, ez integrálja a patchset-et a forrásfába.

ezután make (config/menuconfig/xconfig) al lehet nekiállni a fordításnak...

!!!FONTOS. duplikáltan szerepel az ipsec_tunneling (crypto szekció), és az ip-ip-encaps (tunnell mode) a (networking/freeswan) opcióban.
A kettő együttes kiválasztása esetén a kernel valószínűleg nem fordul le a duplikáció miatt.
Ajánlott ilyenkor a freeswan -t használni, a crypto/ipsec_tunnelling használata nem ajánlott.

A freeswan opcióban 2 AES modul szerepel egy "sima", és egy x86opt...mindkettő kiválasztása esetén
a kernel valószínűleg nem fordul le. Mindenképpen ajánlott csak az egyiket kiválasztani!!!

grsecurity/Pax_controlban a MACsystem integration/direct opció használata nem ajánlott, helyette vagy MAC/none, vagy
MAC/hook...

grsec/address space protection/disalloww elf text relocations funkció használata nem ajánlott, használata kernel
fagyáshoz vezethet, veszélyes.

gracl -hez jelenleg a grsecurity cvsből érhető el gradm 2.0.1 ami szükséges az RBAC/ACL rendszer vezérléséhez.

-----------

A patch részei vagy valamilyen formában, vagy teljes egészében.:

Debian GNU/Linux 3.0.r2 disztribúcióból:

kernel-patch-freeswan
i2c-source
lm-sensors-source
kernel-patch-2.4-grsecurity

Molnár Ingó-tól:

http://people.redhat.com/~mingo/O(1)-scheduler/sched-2.4.18-A1

Andreas Grünbacher-től:

http://acl.bestbits.at/old/v0.8/diff/linux-2.4.18acl-0.8.28.diff.gz
http://acl.bestbits.at/old/v0.8/diff/linux-2.4.18ea-0.8.26.diff.gz

International kernel patch:

http://www.kernel.org/pub/linux/kernel/crypto/v2.4/testing/patch-int-2.4.20.1.bz2

GrSecurity:

http://cvsweb.grsecurity.net/index.cgi/grsecurity2/
http://grsecurity.net/grsecurity-1.9.9h-2.4.20.patch
http://grsecurity.net/grsecurity-2.0-2.4.26.patch
http://www.grsecurity.net/~spender/grsecurity-2.0.1-2.6.7.patch

Oscon:

../include/linux/linux_logo.h
../Makefile: extraversion

( tast | 2004. 07. 12., h – 09:39 )

[quote:2c61607978="csokar2"]Hello
remlem tudsz rajtam segíteni, olyan problémám van, hogy szükségem van egy raid kontroller-re és mindenütt azt olvastam, hogy kernel fordítás útán tudom használni.
Problémám: Dselect-tel felraktam a kerner-source csomagot, ki is csomagoltam a /usr/scr/ könyvtárba létre hozott egy kernel-source2.4.18-as könyvtárat. Beszereztem egy új kernelt2.4.6 kicsomagolva ugyanitt található. A kérdésem úgy hangozna mit csináljak avval, hogy ha elinditom a „make menuconfigot” akkor a kernel verzió számát amit kiír az 2.4.18 és nem az új, hogyan tudnám kicsrélni????

Aranyos vagy, de fuss neki megegyszer szerintem :)

Azzal ha elarulod, hogy melyik RAID vezerlorol van szo, akkor tobben tudnak segiteni.
A Debian Woody vagy Sarge? Mint korabban is emlitettek a 2.6-os kernellel sok problema lesz Woody-n.
Ha dselect-el felraktad a kernel source csomagot akkor az egy tomoritett allomany hoz letre a /usr/src konyvtarban. Ezt tomoritsd ki, es csomagold ki. Igy kapsz egy kernel-source* nevu konyvtarat. Hasonlo modon beszerezhetsz es installalhatsz egy vanilla kernel forrast is, ez valamilyen linux* nevu konyvtarat hoz letre a /usr/src-ben. Ha barmelyik konyvtarban csinalsz egy make menuconfig-ot akkor annak a megfelelo kernel verziot kell mutatnia.

( Oscon | 2004. 06. 30., sze – 02:09 )

A szükséges, és ajánlott userspace programokat forrással kicsit(?) később töltöm majd fel, most már ehhez álmos vagyok.

(chpax 0.7, !!!!gradm 2.0.1!!!!, paxtest, paxctl, setbatch, stb...)

---------

kis kedvcsinálónak

Paxtest 0.9.6 kimenet: (alapértelmezés "make generic" után)

-----

[code:1:d8c3aced82]PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux osconsfortress 2.4.18-gekaichromage #1 2004. jún. 30., szerda, 00.59.46 CEST i686 unknown

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Killed
Anonymous mapping randomisation test : 16 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 25 bits (guessed)
Main executable randomisation (ET_EXEC) : 16 bits (guessed)
Main executable randomisation (ET_DYN) : 17 bits (guessed)
Shared library randomisation test : 16 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Killed
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Killed
[/code:1:d8c3aced82]

-----------

Paxtest 0.9.6 kimenet RANDEXEC-el:
(chpax -X rettofunc1 rettofunc2)

[code:1:d8c3aced82]
PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux osconsfortress 2.4.18-gekaichromage #1 2004. jún. 30., szerda, 00.59.46 CEST i686 unknown

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Killed
Anonymous mapping randomisation test : 16 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 25 bits (guessed)
Main executable randomisation (ET_EXEC) : 16 bits (guessed)
Main executable randomisation (ET_DYN) : 17 bits (guessed)
Shared library randomisation test : 16 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Killed
Return to function (strcpy, RANDEXEC) : Killed
Return to function (memcpy) : Killed
Return to function (memcpy, RANDEXEC) : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Killed

[/code:1:d8c3aced82]

( Pontscho | 2004. 07. 12., h – 10:14 )

[quote:9611d9adb2="Oscon - nem bejelentkezve"]1. A debianizált 2.4.18 használt kernel verzió, amit itt, és fusiban használok.

Vagy csak megszabtak az embernek hogy melyiket hasznalhatja, mer a tesztek a 2.4.2x - as kernelek teljes inkompetenciajat mutattak.

[quote:9611d9adb2="Oscon - nem bejelentkezve"]
Pontscho írta, hogy neki jól jönne.

Koszonom. Amint lesz idom, szet szabom en is a debil kernelem, tortent jonehany hw komp. javitas benne, foleg a via epia sorozathoz. Most akarom belepumpalni Ingo HT pecset, mer vicces ahogy egy 3g - s P4 - en merevre fagy SMP mellett.

Pontscho / fresh!mindworkz

( vmiklos | 2004. 06. 30., sze – 08:19 )

tudnátok mennyi értelme lenne ennek, ha 2.6.7re készült volna el?
minek a 2.4.18ra csinálni, amikor azt már rég el lehet felejteni :twisted:
jó, tudom az a stabil woody (költői kérdés) :wink:

( LiRul v | 2004. 06. 30., sze – 09:18 )

[quote:ad80f60c6e="vmiklos"]tudnátok mennyi értelme lenne ennek, ha 2.6.7re készült volna el?
minek a 2.4.18ra csinálni, amikor azt már rég el lehet felejteni :twisted:
jó, tudom az a stabil woody (költői kérdés) :wink:

2.6.7 eseten az egesz ertelmetlen lenne, mivel szinte minden patch mar benne van (jo, freeswan helyett szerencsere uj ipsec implemetacio kerult bele), Ingo-fele O(1) benne van, cryptoapi benne van, ext2/3 acl tudtommal benne van (ez nem biztos); egyedul a grsec kell a vanilla 2.6.7-re.

( Oscon | 2004. 06. 30., sze – 09:27 )

[quote:612b738248="vmiklos"]tudnátok mennyi értelme lenne ennek, ha 2.6.7re készült volna el?
minek a 2.4.18ra csinálni, amikor azt már rég el lehet felejteni :twisted:
jó, tudom az a stabil woody (költői kérdés) :wink:

Jó kis flame lesz ebből, de nem szeretném...:wink:

1. A 2.6-os kernelt woodyra alig lehet felkínlódni, ha kellenek modulok,akkor
kell module-init-tools, és mindjárt backportból...Amivel vagy szívsz, vagy ha szerencséd van, akkor nem.

2. Ha pl. vannak 2.4 bázisú egyéb moduljaid, akkor azokat elfelejtheted, mert
ha van is 2.6 alá, új userspace cuccot igényel, az meg új glibc-et, és vagy backport, vagy szívás.

3. Bármikor beüthet 2.6nál egy olyan változás, hogy a woodyban levő 2.2.5ös glibc már teljesen inkompaibilissá válhat 2.6os kernellel...

4. Azért a 2.6-os bugzik ám rendesen, akárhogy is szépítik. De hát még fiatal x.x.7 ...elnézzük neki. -)

5. Amig valamire van sec. support, és támogatja a HW-t, addig miért kéne elfelejteni?
Ha nem támogatja a 2.4.18 a HW-t akkor nyílván mást kell keresni. De amíg igen, addig miért nem jó?

Ráadásul ha a grsec.-ben nem lesz sec./"kernel panic" bug / ami azért nem jellemző /
addig elég egyszer megcsinálni, és valószínű, hogy ez kitart a woody végéig.

Mert ha a kernelt frissítik is sec. lyuk miatt, nagy valószínűséggel csak minimális változtatás kell a patch-on, hogy az új
2.4.18-as kernellel működjön...

Vagy még annyi sem.

A korábbi 1.9.9h-s cuccomat 2.4.24-nek "megfelelő" verzióra csináltam, és a jelenlegi
"2.4.26-os"-osnak megfelelőre (~14.3) is módosítás nélkül azonnal felment...

Tehát ha jön "új kernel", nem kell várni a hozzávaló grsec-re...
A többi meg úgyse nagyon változik, max. a schedulert kell egy két sorral kiigazítani, de valószínűleg ezt sem... :wink:

Oscon

( vmiklos | 2004. 06. 30., sze – 09:38 )

hát flame lesz belőle, az biztos. konkrétan van a közelemben ~20 gép, alaplapra integrált videokártyával, és a vesafb megy a 2.6tal, kikapcsolás megy velük, 2.4gyel meg soha nem jött össze. ha veled is így lenne, akkor te is otthagynád a 2.4et :D

( csokar | 2004. 07. 12., h – 17:01 )

valaki fel tudná sorolni, hogy milyen csomagokat rakjak fel egy idegen csomag fordításához???kernel2.6.6.

( Névtelen (nem ellenőrzött) | 2004. 06. 30., sze – 09:54 )

[quote:06d338fa3e="vmiklos"]hát flame lesz belőle, az biztos. konkrétan van a közelemben ~20 gép, alaplapra integrált videokártyával, és a vesafb megy a 2.6tal, kikapcsolás megy velük, 2.4gyel meg soha nem jött össze. ha veled is így lenne, akkor te is otthagynád a 2.4et :D

Ez így van!
Nálad a 2.4 nem alternatíva, egyről beszélünk.

De amíg a HW-ket támogatja addig jó.
Nálad azért nem, mert nálad a HW-khez már "túl régi" a 2.4.18...

Én többségében "fusiba" se a legmodernebb cuccokkal találkozom, finoman szólva... :wink:

A "régebbieket" meg azért a 2.4.18 támogassa.

( cstamas | 2004. 06. 30., sze – 10:06 )

jó ha nem 2.6.x kernel (mert szerverre még én se biztos hogy ilyet tennék) akkor miért nem 2.4.26? én van ahol már két hónapja fut egy olyan változat amiben a XFS ACL-t barátkoztattam össze a grsec-kel ;-)

2.4.18 óta a disk alrendszer is sokat javult.

( tast | 2004. 07. 12., h – 17:41 )

[quote:f925aa9896="csokar"]valaki fel tudná sorolni, hogy milyen csomagokat rakjak fel egy idegen csomag fordításához???kernel2.6.6.

apt-get install kernel-package

make menuconfig

make-kpkg -revision your_kernel.1.0 kernel_image

cd ..
dpkg -i kernel-image.........deb

( csokar | 2004. 07. 22., cs – 20:52 )

Most sikerült ma másodszorra el… a kernel:) de az első alkalommal még idejében észrevettem, most pedig ráboot-oltam és kész a …
Meg lehet következőleg azt csinálni, hogy menüsen látnám az összes indítható kernel (Pl: Boot manager)????
Hiba, amivel elszállt:
Kernel is big: kernel setup stack overlaps lilo second stage.
Én ezt értem, de mit kellene, csináljak vele????

( Oscon | 2004. 07. 22., cs – 22:10 )

[quote:503a192abb="csokar"]Most sikerült ma másodszorra el? a kernel:) de az első alkalommal még idejében észrevettem, most pedig ráboot-oltam és kész a ?
Meg lehet következőleg azt csinálni, hogy menüsen látnám az összes indítható kernel (Pl: Boot manager)????
Hiba, amivel elszállt:
Kernel is big: kernel setup stack overlaps lilo second stage.
Én ezt értem, de mit kellene, csináljak vele????

Nem igazán tiszta, hogy most lilo-t, vagy grubot, vagy mit használnál boot-managernél, és hogyan!
Ha a "LILO szabvány" boot menüje elég, én a következő módszert használom vele.

1. LILO-t az MBR-be tettem...
2. /etc/lilo.confba raktam - sok más egyéb :) között -
egy
delay 20
és egy
timeout 70
bejegyzés...
bekapcsolás után a kaszni 20 másodpercig vár, aztán betölti az alapértelmezett kernelt.
Ha ekkor megnyomják a Control-t, akkor előjön a menü, amiből lehet választani.

( csokar | 2004. 07. 14., sze – 21:11 )

Egy gyors kérdés kernel fordítás után szerkesztettem az /etc/boot.con-ot jó is lett a teszten mikor úraindul nem kérdezi melyiket szeretném, csak ö elindítja valamelyiket.??, Hogyan tudnám megnézni melyik indult el?? Hogyan javíthatnám ki, hogy müködjön a menü???

( Névtelen (nem ellenőrzött) | 2004. 06. 30., sze – 11:52 )

[quote:8b4bdf004d="cstamas"]jó ha nem 2.6.x kernel (mert szerverre még én se biztos hogy ilyet tennék) akkor miért nem 2.4.26? én van ahol már két hónapja fut egy olyan változat amiben a XFS ACL-t barátkoztattam össze a grsec-kel ;-)

2.4.18 óta a disk alrendszer is sokat javult.

Ezen is gondolkodtam egy jódarabig, aztán megmaradt a dolog a 2.4.18on.

Talán az ext2/ext3hoz való "ragaszkodás" miatt, talán mert van olyan kernel modul, ami 2.4.21, vagy 2.4.22 felett már nem ment, ill. ment volna új userspace progival, csak annak meg új glibc kellett volna...

Talán mert Mingo schedulerjéhez sincs pecs egyébként. sec. supportja mindkettőnek van
2.4.26/debianized 2.4.18.

Meg aztán ott is ua. várnom kell az új grsec-re a kiadás után, ezt meg tényleg úgy szántam, hogy most kiszenvedem, aztán woody-kernelek végéig ez kitart úgy, ahogy van.

(mert ez a patchset rohadt kurva nehezen jött össze , ezt beismerem, és akkor még nagyon finom voltam)

( Névtelen (nem ellenőrzött) | 2004. 06. 30., sze – 12:07 )

Tudom, hogy nagyobb igény lett volna egy 2.6.7 + grsec 2.0.1-re, vagy
egy 2.4.26+ patchset-re, de - most tudom kicsit önző vagyok, nézzétek el - nekem speciel, sokkal
jobban jött egy ilyen debianizált 2.4.18-as patchset.

1. A debianizált 2.4.18 használt kernel verzió, amit itt, és fusiban használok.

Tudom, hogy sokaknak a 2.4.18 driverszinten már kevés, vagy a woody. Nekem elég, itt is, másutt is.
Amint nekem sem lesz elég, nyílván más megoldást fogok én is keresni.

2. a külső modulok közül szinte mindig van olyan verzió, ami ehhez létezett.
és mondjuk kernel után kell fordítani. pl. winből jött bináris winmodem modul, wireless driver, alsa, stb...
A másik ilyen kernel a 2.4.20...(a 2.4.20-ról tértem vissza a debianizált kernelre...)

A 2.4.18as elég szép kort megélt, majdnem fél évet.
Ennél jobb, csak a 2.4.20 lett volna, ha lett volna rá sec. support a woodytól.

3. Ha kijön sec. módosítás miatt egy új kernel, nem kell várni, "amíg" a kiegészítők elkészülnek - kvázi azonnal van openbsd security level :wink: - azonnal mehet rá a patchset úgy ahogy van. A sarge-ig simán kihúzom vele. attól függ az egész, hogy a PaX, grsec-ben ne legyen olyan bug, ami miatt nem tudom használni..., vagy nem ér semmit. De erre mondhatjuk hogy nem jellemző, hogy "bug"-zik, pláne 2.4-el...

Ha van más, akinek ez a patchset így használható, a megadott helyről le tudja tölteni, ki tudja próbálni, hogy megfelel-e neki, vagy sem, stb.

Ha valakinek nem felel meg, nem jó a kernel, azt sajnálom. neki ez nem használható.

Üdv.
Oscon

Pontscho írta, hogy neki jól jönne.

( GCS v | 2004. 07. 14., sze – 21:32 )

[quote:156b8b09e7="csokar"]Hogyan tudnám megnézni melyik indult el??

uname -a

[quote:156b8b09e7="csokar"]
Hogyan javíthatnám ki, hogy müködjön a menü???

Attol fugg, mi a hiba. Latatlanban eleg nehez. Egyebkent sem vagyok Grub guru. :(