alles kaputt

dramen

dramen

Routinier
halöle!

habe folgendes gemacht:
k3b habe ich mir installiert
slapt-get --update
slapt-get --upgrade

während des upgrades hab ich irgendwann versucht in einem konsolenfenster 'ls -l' auszuführen. plötzlich kommt die fehlermeldung:

bash-2.05b# ls -l
Speicherzugriffsfehler

kann den xserver auch nicht starten. tippe momentan von meiner suse-partition. und das ist natürlich auch im terminal so. habe jetzt versucht von suse aus die partition zu mounten was mir auch sehr gut gelingt. mit 'chroot /mnt' komme ich wieder auf die verzeichnisebene von slackware. ls -l zeigt dann wieder die gleich fehlermeldung. blöderweise funktioniert tar auch nicht so dass ich das gesicherte /etc-verzeichnis wieder herstellen könnte.

kann mir da jemand weiterhelfen?
 
dramen schrieb:
halöle!

habe folgendes gemacht:
k3b habe ich mir installiert
slapt-get --update
slapt-get --upgrade

während des upgrades hab ich irgendwann versucht in einem konsolenfenster 'ls -l' auszuführen. plötzlich kommt die fehlermeldung:

bash-2.05b# ls -l
Speicherzugriffsfehler

kann den xserver auch nicht starten. tippe momentan von meiner suse-partition. und das ist natürlich auch im terminal so. habe jetzt versucht von suse aus die partition zu mounten was mir auch sehr gut gelingt. mit 'chroot /mnt' komme ich wieder auf die verzeichnisebene von slackware. ls -l zeigt dann wieder die gleich fehlermeldung. blöderweise funktioniert tar auch nicht so dass ich das gesicherte /etc-verzeichnis wieder herstellen könnte.

kann mir da jemand weiterhelfen?

Was ist denn, wenn Du [/mnt]/etc außerhalb der chroot-Umgebung zurücksicherst?
Ich frage mich nur, ob Dir das was bringt...
 
Zuletzt bearbeitet:
leg am besten die slackware installations cd ein, werf alle packete runter, und installier die neuen von cd.
 
das ext3 unterstützt auch das journaling, also so was wie eine wiederherstellung. hat jemand schon mal so was gemacht.

aber sonst wird mir nichts anderes übrig bleiben als die pakete neu zu installieren. interessant ist es aber trotzdem, wie so etwas zustande kommen kann und was das überhaupt ist?!
 
mit dem journalling kannst du keine daten wiederherstellen. ext3 bietet zwar einen modus an, bei dem alle daten und alle metadaten in einem journal geschrieben werden, dies ist jedoch nicht der standardmodus - standardmäßig journalisiert ext3 wie reiserfs/xfs/jfs nur die metadaten (alles andere wäre viel zu langsam). das journal wird ausschließlich vom dateisystem selber genutzt um im zweifelsfall auf die "alten" nutzdaten einer editierten datei zurückgreifen zu können - dazu werden die metadaten (also dateiname, ersteller, letzter schreibender zugriff, ...) journalisiert, die nutzdaten selbst nicht.

schade - ich habe noch nie probleme mit slapt-get gehabt, bisher lief das bei mir auf mehreren maschinen immer reibungslos (per cronjob).

mfg

bananenman
 
Dann ists wohl immer noch am besten die Distri eigenen Tools zu verwenden, schließe ich daraus, anstatt etwas zu portieren, wie hier APT.
 
volle Zustimmung, NDO...wollte gerade eine Rede über solche Tools halten, aber das hast du mir ja in kurzen Worten abgenommen :).
 
Ich nutze ausschließlich die Bordmittel installpkg, removepkg und upgradepkg für die In- bzw. Deinstallation von Slackware Paketen!

[Kurz zum eigentlichen Thema: Das Problem wäre sicherlich nicht mit installpkg aufgetreten!]

Von irgendwelchen Portierungen anderer Distributionstools für Slackware halte ich auch sehr wenig.
- Wenn einem apget besser gefällt, soll er Debian benutzen.
- Es gibt genug Distributionen auf RPM Basis.

Noch eine Spurt härter ist es mit emerde aus Slackware ein 'Gentoo' zu machen. :dreht:
Slackware ist für mich eines der, wenn nicht das Ur-Linux.
Bitte dieses nicht mit einem "Möchtegern-LFS" (für das halte ich Gentoo nämlich!!!) vermischen / kaputt machen!

Ich bin der Meinung:
Man muss eine Distribution so nehmen wie sie ist oder eine andere nehmen.

Warum entscheidet man sich erst für eine Distribution, wenn man dann doch eine andere Art von Paketverwaltung verwendet, welche ein fester Bestandteil einer Distri ist.
 
Zuletzt bearbeitet:
mo_no schrieb:
Ich nutze ausschließlich die Bordmittel installpkg, removepkg und upgradepkg für die In- bzw. Deinstallation von Slackware Paketen!

[Kurz zum eigentlichen Thema: Das Problem wäre sicherlich nicht mit installpkg aufgetreten!]

Von irgendwelchen Portierungen anderer Distributionstools für Slackware halte ich auch sehr wenig.
- Wenn einem apget besser gefällt, soll er Debian benutzen.
- Es gibt genug Distributionen auf RPM Basis.

Noch eine Spurt härter ist es mit emerde aus Slackware ein 'Gentoo' zu machen. :dreht:
Slackware ist für mich eines der, wenn nicht das Ur-Linux.
Bitte dieses nicht mit einem "Möchtegern-LFS" (für das halte ich Gentoo nämlich!!!) vermischen / kaputt machen!

Ich bin der Meinung:
Man muss eine Distribution so nehmen wie sie ist oder eine andere nehmen.

Warum entscheidet man sich erst für eine Distribution, wenn man dann doch eine andere Art von Paketverwaltung verwendet, welche ein fester Bestandteil einer Distri ist.

Im großen und ganzen gebe ich Dir ja recht - aber das einzige was mich an Slack zwischendurch genervt hat war einzig und allein das Packetmanagment. Ich fand es ziemlich blöde, dass ich keine Distri gefunden habe, die wie Slack ist und dabei ein anderes Management hat.

Inzwischen kompiliere ich mir meine Software sowieso am liebsten selbst und deshalb kann mir das herzlichst egal sein. Dennoch halte ich den Wunsch nach einem anderen Packetmanagment für berechtigt. Man kann eine Distiribution eben nicht auf das Packetmanagment reduzieren - ein Slack mit einem Management wie Debian ist immer noch was ganz anderes als Debian selbst.

Mfg, Lord Kefir
 
ich find das tgz-format auch gut - aber slapt-get bietet mir die möglichkeit automatisch und ohne jeden benutzereingriff die maschine aktuell zu halten. dazu könnte man sicherlich auch ein eigenes script verwenden, den jeweiligen patch-ordner lokal spiegeln und neue packete über cron mittels upgradepkg einspielen lassen - aber wozu? slapt-get verwendet doch genau die standard-slackware-packet-tools! wahrscheinlich währe das update auch schief gegangen, wenn es per hand über upgradepkg oder installpkg angestoßen worden wäre. und seien wir ehrlich: sowas kommt einfach vor - bei .rpm-basierenden distributionen sogar wesentlich häufiger.

mfg

bananenman
 
also bei mir gab es noch nie Probleme mit installpkg/upgradepkg/etc... :)
 
also hier werde ich höchstwahrscheinlich wieder neu installieren müssen (ist nicht so tragisch). hab's mit removepkg probiert, aber es geht kein einziges paket zum löschen. sonst hat es immer sehr gut funktioniert. mit den "slack-werkzeugen" hat es bei mir auch sehr gut geklappt. will aber nicht sagen dass slapt-get schlecht ist .... schließlich war es mein erstes update mit slackware.
 
also bei mir gab es noch nie Probleme mit installpkg/upgradepkg/etc...

wie schon gesagt: ich hatte auch noch nie probleme mit slapt-get ;) . und slapt-get nutzt zum einpflegen der packete installpkg, updatepkg und removepkg - also genau die slackware-packet-tools.

ein speicherzugriffsgfehler kann ja im übrigen durchaus andere ursachen als ein wie auch immer geartetes update haben: mal einen filesystemcheck gestartet? sind die festplatten wirklich fit (hast du mal die platte auf physikalische fehler gescannt? - mit dem tool des herstellers?)? mal memmtest drüberlaufen lassen?

mfg

bananenman
 
vermutung:

+--------------------------+
Mon Jan 24 20:41:03 PST 2005
a/aaa_base-10.1.0-noarch-1.tgz: Bumped version number to 10.1. Edited
initial email.
a/aaa_elflibs-10.1.0-i486-1.tgz: Updated initial library collection.
Please remember that (as the package description notes) this package is
only intended to be installed at an initial installation, and attempting
to "upgrade" it later may copy over newer libraries and cause damage to
your system. Some broken upgrade tools haven't learned this fact...

----
 
ok - wenn's das gewesen sein sollte, wär es ohne slapt-get nicht passiert - wenn sich dramen tatsächlich den changelog durchgelesen hätte und das elflibs-packet nicht installiert hätte (hätte er das getan?).

allerdings laufen meine maschinen hier reibungslos - trotz update - es ist also kein zwingender fehler, sondern ein "vielleicht" ... .

fragen wir ihn doch mal: hast du gestern nur k3b geupdatet? hast du seit dem 24.1. schon einmal mit slapt-get geupdatet (dann hätte die elflibs ja schon auf dem system sein müssen)? liest du den changelog wirklich regelmäßig?

ich lese den changelog nur sehr unregelmäßig - warum auch, ich pflege ja keine patche manuel ein sondern mit slapt-get ;)

mfg

bananenman
 
also den fehler hab ich letztendlich herausgefunden. es liegt an der glibc.

und zwar muss ich beim hochfahren des rechners die slackware-cd#1 mounten das paket /slackware/l/glibc-2.3.2-i486-6.tgz mit installpkg installieren (obwohl es installiert ist!!) und dann kann ich erst weiter.

wieso lädt er aber glibc nicht beim booten?!?
in /var/log/packages ist sie jedenfalls drinnen. oder liegt es jetzt vielleicht am kernel?!
[
 
hast du den kernel denn auch geupdatet?

mfg

bananenman
 
eigentlich nicht.

dramen@dramen:~$ uname -a
Linux dramen 2.4.26 #6 Mon Jun 14 19:07:27 PDT 2004 i686 unknown unknown GNU/Linux
 
so jetzt hab ich's aber :)

naja dummerweise hatte ich jedes mal nach der neuinstallation vergessen ldconfig auszuführen. somit hat er immer auf die alte datenbank zurückgegriffen!!
außerdem muss man aufpassen, dass es im /lib-verzeichnis keine andere versionen oder tote links von der gleichen bibliothek gibt.
 
dramen schrieb:
so jetzt hab ich's aber :)

naja dummerweise hatte ich jedes mal nach der neuinstallation vergessen ldconfig auszuführen. somit hat er immer auf die alte datenbank zurückgegriffen!!
außerdem muss man aufpassen, dass es im /lib-verzeichnis keine andere versionen oder tote links von der gleichen bibliothek gibt.
Warum das nicht automatisch z.B. damals als du das System geupdatet hattest, ausgeführt wurde, frage ich mich.
 

Ähnliche Themen

KDE-Problem nach Update

Zurück
Oben