[LFS] locatie depmod

[Verwijderd]

Ik was bijna klaar de installatie van Linux from Scratch op mijn laptop, toen ik het eerste probleempje tegenkwam. Bij het bakken van de kernel kreeg ik een error dat het programma /sbin/depmod niet gevonden kon worden. Dat was niet ontzettend verbazingwekkend want het bestand was te vinden in /usr/sbin/depmod.

Ik heb toen een symbolische link gemaakt vanaf /sbin/depmod naar /usr/sbin/depmod. Tijdens het opnieuw compileren van de kernel heb ik geen errors meer gekregen. Merkwaardig was wel dat twee regels na dat ik voorheen die error kreeg nu het build process (error loos) klaar was.

Maar wat mijn vraag is, waar hoort het programma depmod te staan? /sbin of /usr/sbin en waarom is door de 'make install' van Modutils-2.4.19 het bestand op een andere plek neergeplaatst dan de kernel 'm nodig heeft?

iemand enig?

[Skinkie]

bij mijn LFS "distro's" staan ze allemaal in /sbin welke versie van LFS heb je gebruikt?

[Verwijderd]

Ik gebruik versie 4.0.
ik ga ff naar de prefix kijken in de installation notes

edit: ik zie geen prefix staan, dus ik heb zelf geen idee waar ie ze neer zou moeten zetten.

[_Squatt_]

Op mijn LFS (cvs van iets voor 4.0) staat depmod gewoon in /sbin, en is daar neergezet door modutils-2.4.19.

Zelf geen prefix opgegeven, gewoon: './configure && make && make install'

[Verwijderd]

_Squatt_ schreef op 28 oktober 2002 @ 21:04:Zelf geen prefix opgegeven, gewoon: './configure && make && make install'

dat is alles wat ik gedaan heb...
Ik denk dat ik het probleem weet, ik gebruikte de cut/paste mogelijk heid om de install instructies naar mijn terminal te kopieren. Waarschijnlijk stonden de install instructies van het vorige pakketje er nog in, kijk maar:
Make-3.79.1:

code:

./configure --prefix=/usr &&
make &&
make install &&
chgrp root /usr/bin/make &&
chmod 755 /usr/bin/make

dan maar deze bestanden terugkopieren

code:

depmode
genksyms
insmod
insmod_ksymoops_clean
kallsyms
kernelversion
ksyms
lsmod
modinfo
modprobe
rmmod

[FendtVario]

Wat is de waarde van je $PATH? Is de /usr/sbin hierin wel opgenomen? Zeer onwaarschijnlijk als je LFS volgt maar toch...

[deadinspace]

Slecht dat de kernel Makefiles hem in /sbin verwachten, ze moeten gewoon in $PATH kijken.

Het maakt normaalgesproken niet veel uit waar je depmod neerzet, maar /sbin is de logischste plaats, omdat je depmod nodig kunt hebben tijdens het booten of als je systeem kapot is.

[igmar]

deadinspace schreef op 28 oktober 2002 @ 21:38:
Slecht dat de kernel Makefiles hem in /sbin verwachten, ze moeten gewoon in $PATH kijken.

Het maakt normaalgesproken niet veel uit waar je depmod neerzet, maar /sbin is de logischste plaats, omdat je depmod nodig kunt hebben tijdens het booten of als je systeem kapot is.

/sbin is de gegarandeerd gemount tijdens het laden van modules, dus hij MOET in /sbin staan. Dat de kernel hem daar ook verwacht is dan ook niet meer als logisch, aangezien het kijken naar PATH een security risico is.

[deadinspace]

igmar schreef op 29 oktober 2002 @ 13:10:
/sbin is de gegarandeerd gemount tijdens het laden van modules, dus hij MOET in /sbin staan.

Kan zijn, en ik zei ook dat dat de logischte plaats is, maar dan is het nog ranzig om dat te hardcoden in de kernel Makefiles.

Dat de kernel hem daar ook verwacht is dan ook niet meer als logisch, aangezien het kijken naar PATH een security risico is.

right
Er wordt voor alles in $PATH gekeken, dus als in je $PATH infected binaries staan zijn de kernel Makefiles je laatste zorg.

[igmar]

deadinspace schreef op 29 oktober 2002 @ 15:17:
[...]

Kan zijn, en ik zei ook dat dat de logischte plaats is, maar dan is het nog ranzig om dat te hardcoden in de kernel Makefiles.

En ?? De locatie van init is ook gehardcode, en met een reden.

Er wordt voor alles in $PATH gekeken, dus als in je $PATH infected binaries staan zijn de kernel Makefiles je laatste zorg.

Een kernel kijkt NIET in je $PATH variabele, dat ding is alleen bekend in je shell en alle processen van je shell.

Zou een leuke bak wezen als je als user PATH veranderd en de kernel neemt dat braaf over, hoezo gapend veiligheidsgat...

[deadinspace]

igmar schreef op 29 oktober 2002 @ 15:58:
En ?? De locatie van init is ook gehardcode, en met een reden.

Joh, op het moment dat de kernel init start is er nog geen shell geladen en dus geen $PATH.

Een kernel kijkt NIET in je $PATH variabele, dat ding is alleen bekend in je shell en alle processen van je shell.

Nou en? Daar heb ik het ook niet over.

Jij zei dat het een security risk zou zijn als de kernel Makefiles naar $PATH zouden kijken. Ik zei dat als je gevaarlijke (als in: infected) binaries in je $PATH hebt de kernel makefiles wel je laatste zorg, omdat een simpele "ls" typen je dan al in problemen kan brengen.