Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: bostaurus on 2011/04/06, 17:29:52
-
Hallo, habe vor wenigen Minuten unter KDE ein vorschriftsmäiges dist-upgrade gemacht. Nach dem Hochfahren erscheint dann die Anmeldeseite, aber nichts reagiert auf Maus oder Tastatur.
Dies ist a) eine Warnung und b) eine Bitte um Hilfe. Da ich mich gerade erst im Forum angemeldet habe, weiß ich nicht, ob diese Stellerichtig ist für Hilfesuchen. Falls nein, meine Bitte an den Admin, meinen Text zu verschieben.
MfG, B.
-
Hallo bostaurus ,
list du mal das (http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=781), dann weist du bescheid...
-
Wenn das heißen soll, ich möchte meinem Rechner irgendetwas entlocken, geht ja eben nicht. Ansonsten: Was heißt "list"? Danke, B.
-
Soll heißen: liest du mal das...
und das "das" ist ein Link zu einem Thread wo das Thema behandelt wird. Also einfach auf das "das" in susas Text klicken
-
Hallo ayla, danke für den Hinweis. Der Link ist bei mir nicht als solcher zu erkennen. Ciao! B.
-
Meine Radikalkur bestand darin, dass ich mittels einer Live-CD den Ordner /run gelöscht habe. Seitdem startet mein System zuverlässig. Das Problem ist gelöst. Gruß, Bostaurus
-
gelöst ist anders, aber naja... :S
-
Okay, ich war rabiat. Was mich bewogen hat, war Folgendes: rm bedeutet remove, löschen. r heißt rekursiv, wobei ich auf die Schnelle nicht herausgefunden hatte, was das genau in diesem Zusammenhang meint. f deutet ich als force, erzwingen. Also schlug mir Susa das Löschen vor.
Der zweite Grund ist die Dateistruktur meines Aptosid XFCE-Rechners mit demselben Kernel. Der kannte /run überhaupt nicht. Also dachte ich, so falsch kann das nicht sein.
Viele Grüße, Bostaurus
-
äh bostaurus
wenn du
rm -rf /run
in der Konsole mit root-rechten eingegeben hast dann ist es logisch, das es kein /run Verzeichnis gibt. Damit löscht du auf der Live-CD das /run - Verzeichnis.
Also korreckt wäre ja
sux
cat /etc/fstab
oder
gparted
(für bildhafte Darstellung)
um herauszufinden wie die Partition heist
nehmen wir mal an, deine root - Partition liegt auf
/dev/sda1
dann würde der Befehl
rm -rf /media/disk1part1/run
lauten
-
rm bedeutet remove, löschen. r heißt rekursiv, wobei ich auf die Schnelle nicht herausgefunden hatte, was das genau in diesem Zusammenhang meint. f deutet ich als force, erzwingen.
also der schalter r brauchst du wenn du ordner und alle subordner auch löschen willst.
Den schalter f brauchst du nur wenn du schreibgeschützte Dateien löschen willst ohne Nachfrage, hällt nicht bei fehlern etc. :)
Ein rm -r hätte in deinem Fall ausgereicht.
-
So - gerade DU gemacht,
Tastatur und Mouse PS2,
64 Bit,
alles läuft ohne den ganzen "Schnick + Schnack" - etwas Geduld spart machmal viel Zeit und Nerven.
Gruß Oldie
-
Hi
Bedeutet das, das ich einfach ein du machen kann ohne den aptosid patch rein hauen zu müssen und ohne /run zu löschen ?
Einfach ein normaled du ?
Danke
-
Also ich hab heut ein du auf 2 Systemen gefahren 32bit/64bit und beide ohne Probleme ;)
-
Bedeutet das, das ich einfach ein du machen kann ohne den aptosid patch rein hauen zu müssen und ohne /run zu löschen ?
Ja, wenn dein letztes d-u vorher dem Problem war (also noch kein /run existiert). Dann überspringst Du den Fehler.
-
Ich habe das Gefühl die User testen hier ohne Admin oder Hilfe des aptosid Teams -
das gibt es wohl nicht mehr.
Jeder auf eigenes Risiko - Zeit nehmen und etwas als Ersatz suchen - bevor man in den Abhängigkeiten der Pakter
ohne Hilfe untergeht.
Schade - das wars wohl mit aptosid/sidux - streiten wie im Kindergarten - keine Weiterentwicklung im Kopf.
Etwa drastisch - passend zur Situation und streiten wie die Kinder - einen Grund findet man immer.
oldie
-
Und was willst Du uns damit sagen?
Das Ganze hat Nichts bis Gar Nichts mit aptosid zu tun.
base-files ist ein Debian Paket und jeder, der Debian Sid benutzt, ist in diese Falle getappt, wenn er nicht aufgepasst hat.
-
Jeder auf eigenes Risiko
mit Sid immer ;) :twisted:
-
wie kommst du denn jetzt auf das schmale brett?
greetz
devil
-
Zeit nehmen und etwas als Ersatz suchen - bevor man in den Abhängigkeiten der Pakter
ohne Hilfe untergeht.
Ich bin garantiert gegenüber aptosid nicht unkritisch, eher ist das Gegenteil der Fall, aber lass bitte die Kirche im Dorf. Es hat keiner behauptet, dass sid kuschelig ist. Erst lesen, dann die Tastatur bedienen, das war aber schon immer so. Es geht einfach nicht an, unstable zu benutzen und stable zu wollen.
Zum Thema Entwicklung: Du bist grade Opfer der Weiterentwicklung geworden, mit debian stable oder auch testing wäre das wohl nicht passiert. Als sid-User stehst Du halt in vorderster Front. Die Warnungen in diesem Thread sind ernstgemeint. Die entstehen im allgemeinen dadurch, dass jemand in die Falle tappt oder sie umgeht - und den Rest warnt.
-
Ich habe das Gefühl die User testen hier ohne Admin oder Hilfe des aptosid Teams -
das gibt es wohl nicht mehr.
Jeder auf eigenes Risiko - Zeit nehmen und etwas als Ersatz suchen - bevor man in den Abhängigkeiten der Pakter
ohne Hilfe untergeht.
Schade - das wars wohl mit aptosid/sidux - streiten wie im Kindergarten - keine Weiterentwicklung im Kopf.
Etwa drastisch - passend zur Situation und streiten wie die Kinder - einen Grund findet man immer.
oldie
Was hätte irgendein (anderes) Teammitglied dem deiner Meinung nach hinzufügen sollen?
Zitate aus dem ursprünglichen Support-Thread, auf dem auch hier im zweiten Post hingewiesen wird:
1. base-files in Version 6.2 erzeugt ein Verzeichnis /run.
2. udev 167-1 benutzt dieses Verzeichnis, so es existiert
3. Nach reboot kann udev nicht starten, da /run so noch nicht in initscripts implementiert ist.
4. udev 167-1+c0.aptosid.1 sollte das Problem beseitigen.
Ein wenig: /run soll die neue Heimat von unter anderem /var/run werden. Leider ist da der udev Maintainer (wie leider sonst auch) nicht so zimperlich und lädt einfach mal hoch. Wer sich an die Millionenfachen Warnungen über conf files erinnert oder an das spezielle Handling von udev in stable weil es ältere Kernels nicht mag, der weiß was ich damit meine.
In Essenz heißt das: Aufpassen, dass udev bei einem d-u aus dem aptosid repository kommt (apt-cache policy udev), sonst booted die Kiste eventuell nicht.
Sollte das Kind bereits im Brunnen liegen, in Grub in der Bootzeile aus dem 'ro' (read-only) ein 'rw' (read-and-write) machen, hoffen dass es klappt und so schnell wie möglich unseren Hotfix installieren und neubooten…
Gruß
ayla
-
@oldie:
also alles was recht ist aber: Es wurden Lösungen empfohlen. Von einigen vielleicht etwas grob/brutal umgesetzt aber es scheint soweit erstmal für alle gelöst zu sein.
Wo ist also dein Problem :roll:
Grüße
Reiner
-
Heute d-u gemacht, keine Probleme hier!
-
Heute d-u gemacht, keine Probleme hier!
ich auch ... und auch keine Probleme
-
@oldie: Ach nö, jetzt nicht in diesem Thread auch noch das Thema, bitte...
Ist das nun richtig, /run komplett zu löschen? Muß man das ggf. wieder herstellen, wenn man es gelöscht hat? Oder wie?
-
Von der Warte aus, dass es neu ist, lass es so lange weg, bis jemand offiziell den Startschuss für die gefahrlose Nutzung des /run-Verzeichnisses gibt. Ich drücke das jetzt mal bewusst vorsichtig aus: Der alte Zustand funktioniert ja, und daran wird sich auch in der nächsten Zeit (2-10 Jahre) nichts ändern. Schöner ist es aber in neu, wenn es denn geht, auch wegen der Vorteile, die das Verzeichnis bieten wird - frühere Einbindung, zentraler Punkt für den Kram etc. Nur dass jemand ein Verzeichnis kreiert hat, heisst noch lange nicht, dass man es nutzen muss. (vgl. dazu xorg.conf und xorg.conf.d etc.)
Edit: Die weiteren Entwicklungen kann man hier finden:
grave bugs of udev (166-1 -> 167-1+gc2) <unfixed>
#621036 - udev should not assume that /run works just because it exists
-
Hier ist die weitere Entwicklung:
Changes:
udev (167-2) unstable; urgency=high
.
* Only use /run if it is a tmpfs. (Closes: #621036, #620995)
Sprinter
-
Cool, damit fliegt meine zusammengeschweinte Lösung automatisch raus. Sollte man das eventuell irgendwo im Wiki vermerken oder wie wird das später eingebunden? So wie ich das sehe, wäre es ja eine Änderung in der fstab?
-
Tja bei mir hat vmtl. das udev update(167-2) dazu geführt, das meine maus, wlan karte nicht tat und meine Uhr zwei Stunden vorging.
Nach dem Löschen den /run Verzeichnisses tut nun alles wieder, wie gewohnt.
-
Kreisch, meine Tastatur/ mouse is weg....
Start-Date: 2011-04-12 01:23:26
Commandline: apt-get dist-upgrade
Upgrade: vim-common:amd64 (7.3.154+hg~74503f6ee649-1, 7.3.154+hg~74503f6ee649-2), libgudev-1.0-0:amd64 (167-1+c0.aptosid.1, $
End-Date: 2011-04-12 01:24:27
-
Hier keine Probleme mehr bei 32Bit bzw. 64Bit Systemen :-)
-
der trick in grub von ro auf rw temporär zu wechseln hat dieses mal leider nicht funktioniert
habe nun den /run ordner gelöscht um wenigstens wieder ins system zu kommen..
-
Grad ein DU auf ner 64bit-Maschine gemacht und bisher keine Probleme ...
-
- Vor tagen klappte die udev-run conversion nach kleinen holperern, mit /run.
- Mit heutigem d-u und udev 167-2 wurde trotz mehrerer bootversuche weder meine sata festplatte (wohl meine ide-platte mit system), noch netzwerkkarte, noch mouse oder tastatur erkannt.
- Downgrade auf udev 167-1 brachte keinen erfolg.
- Löschen (bzw. wegsichern) von /run führte wieder zu einem voll funktionsfähigen system.
-
Nach d-u auf 2.6.38-2.slh.6-aptosid-amd64 und udev 167-2 wieder mal ohne Tastatur ...
rm -r /run wird wohl zum Allheilmittel.
-
rm -r /run ist nicht das Allheilmittel, kommt einem solchen in der Tat aber schon recht nahe. Das ist Linux (Unix). Wenn was da ist, wird auch versucht werden, es zu benutzen. Erst wenn es nicht da ist, wird es auch nicht benutzt. In anderen Worten: Die Chance, dass nicht alle Pakete schon vollständig mit der neuen Situation umgehen können, ist hoch. Wer Spass in den Backen hat, könnte ja mal versuchen, was passiert, wenn man das wirklich als temporäres Filesystem einbindet und an geeigneter Stelle Bericht erstatten.
Andererseits funktioniert das doch schon ganz gut - nicht mal massig und ordentlich Kernelpanic.
-
Ick versteh das nich. Mache fast täglich ein DU und hab dieses /run nicht!
Nicht das ich jetzt unbedingt scharf drauf wäre, aber tät mich schon interessieren warum es bei mir nicht auftaucht .... ;)
-
Dann hast Du wahrscheinlich genau in der Zeit, als es angelegt wurde, keinen d-u gemacht. Das war ja nur die kurze Zeit bis zum Fix, wenn ich das richtig verstanden habe.