Siduction Forum

Siduction Forum => Upgrade Warnings => Topic started by: seagull on 2011/04/06, 10:20:54

Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: seagull on 2011/04/06, 10:20:54
Siehe: http://aptosid.net/index.php?name=PNphpBB2&file=viewtopic&t=1093&highlight=
Title: Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: reddark on 2011/04/06, 10:42:19
Kann mensch das noch auf deutsch etwas ausführen?
Title: Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: towo on 2011/04/06, 10:45:28
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.
Title: Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: reddark on 2011/04/06, 10:52:17
danke ;)
Title: Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: DonKult on 2011/04/06, 10:52:37
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…
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: seagull on 2011/04/06, 12:02:09
Der Hotfix 167-1+c0.aptosid.1 0 beseitigt das Problem bei mir nicht.
Tastatur und Maus gehen nur nach booten mit "rw" in der grub-zeile.

Code: [Select]
Host/Kernel/OS  "aptosidbox" running Linux 2.6.37-2.slh.2-aptosid-amd64 x86_64 [ aptosid 2010-02 Κῆρες - kde-full - (201009132215) ]
CPU Info        2x AMD Athlon X2 Dual Core BE-2350 clocked at [ 2100.000 MHz ]
Videocard       nVidia C68 [GeForce 7050 PV / nForce 630a]  X.Org 1.9.5  [ 1280x1024@50.0hz ]
Processes 151 | Uptime 3min | Memory 439.3/1949.3MB | HDD Size 400GB (28%used) | GLX Renderer GeForce 7050 PV / nForce 630a/PCI/SSE2 | GLX Version 2.1.2 NVIDIA 260.19.44 | Client Shell | Infobash v3.35


Außer "altem" Kernel u. prop. NVidia ist die Maschine ok.
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: agaida on 2011/04/06, 12:12:05
debian.alfgaida.de. das udev-Paket wirst Du finden. Wenn das Paket eingespielt ist, dann /run löschen. Sonst funzt dat nich. Die Namensgebung sollte bei allen Files wirken, die nicht größer als +gc2 heissen. Um den normalen Upgradepfad nicht zu beeinträchtigen, kommt das Zeug bei mir in ein einzurichtendes experimental. Bis jetzt liegt es im normalen unstable-Pfad.
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: ralul on 2011/04/06, 12:26:44
Erinnert mich an meinen Request:
udev stabiler halten statt mit Hotfixes reparieren
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=306&highlight=udev
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: towo on 2011/04/06, 12:51:52
Man könnte auch einfach das Paket base-files downgraden, /run löschen, so der downgrade das nicht sowieso macht, udev reinstallieren.
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: bluelupo on 2011/04/06, 13:04:01
@towo: macht es Sinn das Paket base-files für ein paar Tage auf hold zu setzen, damit man heute einen d-u machen kann ohne das die oben geschilderten Probleme bekommt.
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: towo on 2011/04/06, 13:08:11
Das weiss ich ehrlich gesagt nicht, im Moment verkneife ich mir ein d-u sowieso, da relativ viel fliegen will im Moment. Ob es wirklich eine gute Idee ist, base-files zu halten, wage ich auch zu bezweifeln, da man evtl. die Transition zu /run verpassen könnte.
Vermutlich ist die einzig beste Methode im Moment, root gleich rw anstatt ro zu mounten.
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: michaa7 on 2011/04/06, 15:08:07
Quote from: "seagull"
Der Hotfix 167-1+c0.aptosid.1 0 beseitigt das Problem bei mir nicht.
Tastatur und Maus gehen nur nach booten mit "rw" in der grub-zeile.



Dies kann ich bestätigen. Meine Tastatur und die Maus (beide PS2 !) funktionierten trotz der gefixten pakete nicht. Auch ein- und ausstöpseln brachte nichts, erst ein re-boot _mit_ "rw" statt "ro" behob das problem.
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: seagull on 2011/04/06, 16:15:39
Keine Probleme mehr mit aktuellem slh-kernel (und nouveau)
Quote
Host/Kernel/OS  "nouveaux" running Linux 2.6.38-2.slh.3-aptosid-amd64 x86_64 [ aptosid 2011-01 Γῆρας - kde-full - (201102052200) ]                                                                                                        
CPU Info        2x AMD Athlon X2 Dual Core BE-2350 clocked at [ 2100.000 MHz ]                                      
Videocard       nVidia C68 [GeForce 7050 PV / nForce 630a]  X.Org 1.9.5  [ 1280x1024@0.0hz ]                        
Processes 135 | Uptime 22min | Memory 338.6/1949.1MB | HDD Size 400GB (26%used) | GLX Renderer Software Rasterizer | GLX Version Yes | Client Shell | Infobash v3.35    


und /run löschen hilft auch der fehlerhaften/alten (..37.er Kernel) Installation wieder auf die Beine.
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: spacepenguin on 2011/04/06, 17:13:36
Der aptosid-udev-fix wirkt hier bei mir auch nicht, ich hatte das andere gar nicht installiert, sondern gleich die "gefixte" Version. Das Verzeichnis /run/udev wird trotzdem angelegt und nicht /var/run/udev. Ich hab nur Tastatur und Maus (beides USB) in KDM, nachdem ich hinter den Rechner krabbele und beides aus- und wieder anstöpsele... In den virtuellen Konsolen funktioniert die Tastatur auch ohne dem... wenn man da erstmal hinkommt...
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: susa on 2011/04/06, 17:45:35
Hmm,

ich hab mich auch schon gewundert was jetzt wieder an meiner alten Kiste kaputt ist.

Nach dem ich das hier gelesen habe, habe ich in


/boot/grub/grub.cfg



Code: [Select]


### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, mit Linux 2.6.38-0.towo.1-frickel-686' --class debian --class gnu-linux --class gn$
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set=root a4711755-4711-4bf4-b88b-b54b3751de0a
        echo    'Loading Linux 2.6.38-0.towo.1-frickel-686 ...'
#linux   /boot/vmlinuz-2.6.38-0.towo.1-frickel-686 root=UUID=a4711755-4711-4bf4-b88b-b54b3751de0a ro vga$        
linux   /boot/vmlinuz-2.6.38-0.towo.1-frickel-686 root=UUID=a4711755-4711-4bf4-b88b-b54b3751de0a rw vga$
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-2.6.38-0.towo.1-frickel-686



und

Code: [Select]

rm -rf /run


gemacht und schon funzte es wieder...
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: bostaurus on 2011/04/06, 19:21:55
Hallo Susa, wo genau hast Du das rm eingefügt? Einfach druntergesetzt? Gruß, B.


//edit by DonKult: Ich hab hier eben mal deine wortgleichen/sinngleichen Doppelposts entfernt. Einmal fragen recht bestimmt. ;)
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: DonKult on 2011/04/06, 19:45:03
In der Grubconfdatei sollte man das nicht einfügen!

Susa meint sicher, dass sie das in einer Konsole (mit root Rechten) ausgeführt hat. Eventuell sogar in 'init 1' genaures wird aber nur sie wissen.

Am einfachsten ist aber wie üblich einfach warten. Mach ich auch, so eilig muss mans mit dem d-u ja auch nicht haben…
Title: [solved] Vorsicht mit d-u Maschine wird unbedienbar!!!
Post by: bostaurus on 2011/04/06, 19:55:35
Danke erstmal für das Löschen. Ich habe das nicht hinbekommen.

Zum eigentlichen Problem: Meine Radikalkur bestand darin, dass ich mittels einer Live-CD den Ordner /run gelöscht habe. Seitdem startet mein System zuverlässig. Gruß, Bostaurus