[gentoo] systeem met 2 kernels: hoe?

[AlterEgo]

Ik draai op een desktop geregeld twee verschilende kernel-versies:
A) vanilla met pre-emptible patch (voor het snappy desktop gevoel)
openmosix (als ie moet mee-rekenen met de rest van het cluster).

Wanneer ik A helemaal heb ingericht via portage: NVidia-kernel; lm_sensors, ALSA etc, en ik boot dan naar kernel B, dan zit ik daar zonder werkende Nvidia-kernel (o.a.).
Dat is logisch, maar wel problematisch: opnieuw emergen is niet de oplossing, want dan worden de modules uit kernel A verwijderd.

Ik heb nu handmatig beide kernels gepatched, en dat lost het probleem wel zo ongeveer op.

Maar is er geen elegante manier te verzinnen om met behulp van portage 2 werkende kernels+"aanhang" in een systeem te krijgen

[moto-moi]

Eh.. Waarom wil je perse 2 kernels gebruiken ?

Zorg dan ervoor dat je alles in modules duwt, en laad om de 'andere' kernel te gebruiken, de bijbehorende modules.

[AlterEgo]

moto-moi schreef op 11 januari 2003 @ 14:30:
Eh.. Waarom wil je perse 2 kernels gebruiken ?

Zorg dan ervoor dat je alles in modules duwt, en laad om de 'andere' kernel te gebruiken, de bijbehorende modules.

De openmosix kernelpatch is niet te combineren met de patches die ik op de vanilla-kernel gebruik. Vandaar

Het zelfde probleem zou zich ook voordoen wanneer je een 2.5 kernel zou willen testen op een syteem waarop je normaal gesproken 2.4 draait.

Portage voorziet niet in die situatie, zover ik kan overzien.

[ Voor 30% gewijzigd door AlterEgo op 11-01-2003 14:35 . Reden: typo ]

[Verwijderd]

Het aanwezig zijn van meer kernel-sources op een systeem kan in sommige gevallen ontzettend handig zijn. Er is ook al eens een bug voor aangemaakt: http://bugs.gentoo.org/show_bug.cgi?id=11493

Wat je als tussenoplossing kan toepassen is zelf een SLOT voor je kernel aan te maken, dit doe je door de betreffende kernelversie in /var/db/pkg/sys-kernel/whatever-sources-x.y.z/SLOT aan te passen.

[AlterEgo]

Dat is niet het probleem, TM002,

het probleem is, dat ik met portage niet kernel-afhankelijk kan emergen,
en dus niet twee versies van nvidia-kernel (b.v.) kan emergen: 1 voor gebruik bij kernel A, en eentje voor bij kernel B _{terwijl dat best handig zou zijn}.
De SLOTs zijn er gewoon: emerge vanilla-sources en emerge openmosix-sources.

Wie is er "creatief met portage"

[Arioch]

Kijk eens in /usr/src nadat je 'emerge vanilla-sources openmosix-sources' gedaan hebt.
Beide kernels worden netjes in hun eigen map gezet en het resultaat wordt:
/usr/src/vanilla-sources
/usr/src/open-mosix-sources
/usr/src/linux (gelinkt naar de map van de kernel die je het laatst geëmerged hebt)

volgens mij moet het op deze manier wel lukken:

code:

rm -rf /usr/src/linux
ln -s /usr/src/linux /usr/src/vanilla-sources
emerge nvidia-kernel nvidia-glx
rm -rf /usr/src/linux
ln -s /usr/src/linux /usr/src/openmosix-sources
emerge nvidia-kernel nvidia-glx

[ Voor 4% gewijzigd door Arioch op 13-01-2003 23:03 ]

[AlterEgo]

Bl4cKH4T schreef op 13 January 2003 @ 23:02:

code:

rm -rf /usr/src/linux
ln -s /usr/src/linux /usr/src/vanilla-sources
emerge nvidia-kernel nvidia-glx
rm -rf /usr/src/linux
ln -s /usr/src/linux /usr/src/openmosix-sources
emerge nvidia-kernel nvidia-glx

Dank voor de suggestie, maar helaas: bij de tweede emerge wordt de eerste weer automagisch un-merged. Zelfs als ik nidia-kernel de eerste maal als emerge --oneshot install, of na de eerste install uit de world-file sloop. Het unmergen van bestaande of oudere versies, hoe voor de hand liggend ook, lijkt niet te omzeilen.
Op de gentoo-forums ben ik ook niet verder gekomen.

[AlterEgo]

Wat * AlterEgo zoekt, heet AUTOCLEAN (uit make.conf):

# AUTOCLEAN enables portage to automatically clean out older or overlapping
# packages from the system after every successful merge. This is the
# same as running 'emerge -c' after every merge. Set with: "yes" or "no".

AUTOCLEAN="no"

Dus met autoclean=no, zou ik een nieuw pakket moeten kunnen emergen, terwijl de oude blijft staan. Maar autoclean lijkt het "no" statement te negeren.
Kan iemand aub testen of ie het autoclean="no" werkend krijgt op zijn syteem
Het makkelijkst is dat te doen door een klein pakketje te re-emergen en het laatste stukje van de output te lezen. Thanks.

[Arioch]

Yup dat is het inderdaad. Op mijn server/testbak draai ik Gentoo 1.4rc1 Testing/Unstable en daar was dit standaard enabled. Erg handig...

[balk]

Op mijn systeem werkt autoclean wel. Ik heb em op "no" staan en als ik 'emerge clean -p' doe staan er altijd wel pakketjes klaar om verwijderd te worden. Het werkt dus wel.

Overigens, je zou misschien met ebuild een installatie half kunnen doen, en dan wel zo dat je wel installeert en niet verwijderd. man ebuild

[AlterEgo]

Grrr..
Het autoclean-feature werkt alleen als er daadwerkelijk sprake is van een versie-verschil. Daarvan is in mijn geval natuurlijk geen sprake.

[Verwijderd]

AlterEgo schreef op 13 January 2003 @ 22:38:
Dat is niet het probleem, TM002,

het probleem is, dat ik met portage niet kernel-afhankelijk kan emergen,
en dus niet twee versies van nvidia-kernel (b.v.) kan emergen: 1 voor gebruik bij kernel A, en eentje voor bij kernel B _{terwijl dat best handig zou zijn}.
De SLOTs zijn er gewoon: emerge vanilla-sources en emerge openmosix-sources.

Wie is er "creatief met portage"

Je hebt gelijk, in de eerste instantie had ik je probleem verkeerd begrepen. Je probleem stelling is me nu duidelijk. Je wil (bijvoorbeeld) media-video/nvidia-kernel tegen 2 kernelversies gecompileerd en geinstalleerd hebben zonder dat ie de "eerst geinstalleerde" unmerged. (right?)

Ik heb dit voor de gein gewoon zelf eens geprobeerd. /usr/src/linux eerst laten linken naar /usr/src/linux-2.4.19, nvidia-kernel geinstalleerd, symlink omgezet naar /usr/src/linux-2.4.20, nvidia-kernel geinstalleerd. En portage unmerged vrolijk mijn vidia.o in /lib/modules/2.4.19/video...... hmmz

Dit zou geen probleem moeten zijn want in de ebuild is dit te lezen:

code:

# The slow needs to be set to $KV to prevent unmerges of
# modules for other kernels.
LICENSE="NVIDIA"
SLOT="${KV}"
KEYWORDS="~x86 -ppc -sparc -alpha"

Het probleem is volgens mij het volgende:
${KV} wijst naar de kernelversie van de sources waarnaar /usr/src/linux is gesymlinked (mjah ik kan het even niet anders verwoorden). Dit wordt opgenomen in de volgende file /var/db/pkg/media-video/nvidia-kernel-1.0.4191-r1/SLOT
Probleem hierbij is dat wanneer ik deze kernelversie verander (en dus me symlink aanpas van linux-2.4.19 naar 2.4.20) hetzelfde SLOT file _overschreven_ wordt. hier staat dus nu 2.4.20 in ipv 2.4.19, foutje. Dit lijkt me een bug in ofwel de ebuild ofwel in portage, iig werkt het bovenstaande stukje code niet.

Wat ik heb gedaan op het op te lossen is het volgende:
De meest recente ebuild (nvidia-kernel-1.0.4191-r1.ebuild) gekopieerd naar 2 andere versies namelijk nvidia-kernel-1.0.4191-r19.ebuild en nvidia-kernel-1.0.4191-r20.ebuild (mijn 2 kernel versies). -r19 heb ik SLOT="1" gegeven, en -r20 SLOT="2", ebuild <filename> digest, en de beide versies ge-emerged, dit werkt wel. Waarom? Omdat er nu 2 verschillende directories in /var/db/pkg/media-video worden aangemaakt.

Beetje suf verhaal dit, maargoed ik hoop dat het wel is wat je bedoelde.

[AlterEgo]

Ik denk dat je benadering klopt, TM002, en bedankt voor je moeite.

Echter, jouw insteek heeft hetzelfde nadeel als mijn workaround, het handmatig patchen van beide kernels, namelijk: dat je nog steeds niet in staat bent om automatisch een wijziging door te voeren op het moment dat er een nieuw versie van bv. nvidia-kernel uitkomt: portage zal bij jou beide versies willen verwijderen na de upgrade -> dus je moet handmatig nieuwe ebuilds maken, en ik zal mijn kernels moeten patchen.

Jouw methode heeft in ieder geval een automatische trigger dat er een nieuwe versie beschikbaar is.