[e-smith 5.5]Problemen na overschrijven libc.so.6

[simon]

Mijn neef heeft op zijn servertje thuis E-Smith 5.5 draaien. Dat loopt aardig en wel. Hij rommelt lekker aan, totdat:

Hij een rpm installeert die een nieuwere versie van libc.os.6 nodig heeft. Hij download van een of andere site een nieuwere versie van libc.os.6 en pleurt die in /lib/ . En geeft een commando om dit te bevestigen ofzo. Dit allemaal via putty, en daarna ploft de verbinding er meteen uit.

De server hangt volledig, en moet gerestart worden, na de restart komt er een melding: File to short.

Nu is het probleem dat de server nogal belangrijke data bevat (school, werk, email enz...) en dat er liever niet gereïnstalled wordt.

Is er enige mogelijkheid dit nog te fixen?

[Fatal-Error]

Vanaf floppy of cd booten en dan de oude libc.so terugkopiëren. Of de oude rpm installeren als de bootcd al die tools aan boord heeft. Vanaf de bestaande installatie zul je weinig meer kunnen gebruiken zonder de goede libc, zo'n beetje alles is met die library gelinkt.

[Bebob_NL]

Bedankt simon voor je snelle post om meer informatie over dit probleem te vragen. Ik zit hier dus met de gebakken peren. Ik heb nu een extra harddisk geplaatst: hda genaamd op IDE controller 1. De oude gecrashde hda heb ik op controller nr2 als master gezet, dus dat is hdc geworden. Nu wil ik vanaf de verse tijdelijke installatie van E-smith op de nieuwe hda de libc file copieren naar de oudere gecrashde e-smith op hdc .
Hiervoor moet ik hdc zien te mounten, maar dit schijnt volledig onmogelijk te zijn. hij staat niet in /mnt en mount /dev/hdc werkt ook niet. Na wat rondspeuren heb ik wel een document gevonden (http://members.home.nl/timothee/extrahd.pdf), dat wist mijn hele harddisk en dat mag niet gebeuren.

Iemand een idee over hoe ik hdc aan kan spreken/mounten?

[Verwijderd]

Om te bepalen welke partities je hebt:

code:

fdisk -l /dev/hdc

Er verschijnt een lijstje met partities, alle partities met id 83 zijn Linux schijven met eventueel data.
Om al die partities te mounten kun je het best even een aantal dirs aanmaken in /mnt . Dit aantal kun je dus zien met die fdisk output. Voor elk van de partities kun je het volgende ingeven

code:

mkdir /mnt/hdc1
mount -t ext2 /dev/hdc1 /mnt/hdc1

Waarna je de files via /mnt/hdc1 moet kunnen benaderen.

[Bebob_NL]

Bedankt, het probleem is opgelost inmiddels. Vrotogel, bedankt voor je code, die heeft me flink geholpen.

[deadinspace]

Simon schreef op 11 February 2003 @ 15:53:
Hij download van een of andere site een nieuwere versie van libc.os.6 en pleurt die in /lib/

Iets anders: hoe heb je die nieuwe libc.so.6 in /lib gezet? Met cp libc.so.6 /lib toevallig?

[simon]

deadinspace schreef op 12 February 2003 @ 16:41:
[...]

Iets anders: hoe heb je die nieuwe libc.so.6 in /lib gezet? Met cp libc.so.6 /lib toevallig?

Het is al opgelost, maar het lijkt me wel interessant om dat te achterhalen, zelf wist hij het niet.

Maar het was een 'fikse' klap

[deadinspace]

Nouja, met cp kan het iig goed fout gaan.
cp opent de source file om te lezen, en de destination file om te schrijven, en gooit dan de inhoud over. Hierbij wordt de destination file dus niet verwijderd, het is en blijft dezelfde file, alleen met een andere inhoud na het kopieren.

Het probleem is dat programma's die gestart zijn gebruik maken van die lib. Als je die library die op de HD staat wijzigt, dan wordt dat doorgevoerd in de draaiende programma's, en draaiende programma's hebben het er niet zo op dat een library die ze gebruiken onder hun neus wordt verbouwd

Wat gebeurt er dus? cp begint met kopieren, en wijzigt dus je libc6. *Elk* programma op je computer maakt van libc6 gebruik, dus *elk* programma gaat over de zeik. Kortom: haal het stof maar van je reset-knop.
Maar daar houdt het niet op... cp was aan het kopieren, maar tijdens het kopieren gaat ook cp zelf over de zeik. Daarom is je libc6 deels oude, deels nieuwe lib. Gevolg: geen enkel prog wil nog starten, dus booten wil ook niet echt opschieten.

Hoe moet je je libc6 dan wel (handmatig) upgraden?
Verwijder de oude, en kopieer/move een nieuwe naar /lib .

Als je een file die in gebruik is door een of meer processes verwijdert dmv de unlink() system call, dan wordt die file niet meteen verwijderd door de kernel. De directory-entry wordt wel verwijderd, dus de file is niet meer zichtbaar, maar de data zelf blijft gewoon staan, zodat het process dat de file open heeft nog van de file gebruik kan maken.

Als een draaiend process tegen een library gelinkt is, dan heeft dat process die library open. Als je libc6 dus verwijdert, dan blijven processes dus gebruik maken van die onzichtbare file waarvan alleen nog de data bestaat. Als je dan een nieuwe libc6 naar die plaats kopieert, dan maken nieuw gestarte processes gebruik van die nieuwe libc6, en processes van voor de upgrade van de oude.
De oude file wordt pas echt verwijderd op het moment dat geen enkel process hem nog open heeft.

Dat verwijderen, nieuwe file maken is ook de manier waarop rpm en dpkg files vervangen (onder andere vanwege bovenstaande reden). Wat me meteen tot het volgende leidt: waarom niet libc6 upgraden via een rpm? Of zijn die niet goed te vinden voor E-smith?

Bovenstaande wijsheid heb ik trouwens sinds ik "strip *" deed in /usr/lib op een remote bak. Vond (onder andere) ssh niet lief

Je kunt het zelf uit proberen door een of andere file (een plaatje bv) over een library heen te kopieren. Als je bijvoorbeeld /usr/lib/libgnome zo verneukt, dan storten alle draaiende gnome progs als kaartenhuizen in elkaar

Als je dit wil proberen dan spreekt het voor zich dat je een backup van de lib in kwestie moet maken (zodat je het daarna weer werkend kunt maken), en dat je geen al te cruciale lib moet uitzoeken