gnux
Jungspund
Hallo,
ich habe leider keinen bisherigen beitrag für mein problem gefunden. (ich hoffe keinen übersehen zu haben.....)
ich nutze ein suse 10.0x86_64 auf einem amd athlon64 3500.
es lief bisher alles einwandfrei. habe stets alles mit zusätzlichen yast repositories auf dem neuesten stand gehalten.
als das system zum letzten mal lief habe ich meine dslverbindung so eingestellt das sie während dem bootvorgang startet und den ntp-server so eingerichtet das er während dem bootvorgang synchronisiert. hat alles wunderbar funktioniert. server war auch erreichbar. dann habe ich kde auf version 3.5.1-27 geupdatet. als ich eben neu starten wollt bleibt der bootvorgang einfach bei "starting powersaved (accessing ACPI events over acpid) done" stehen. also er schließt das skript korrekt ab macht dann aber nicht weiter. er hatte während dem booten mit dem ntp server verbunden.
ich habe eine rescue system gestartet meine linux partition gemountet und mit chroot in sie gewechselt yast gestartet und meine änderungen rückgängig gemacht. also das die dsl verbindung manuell gestartet wird und ntp ausgeschaltet.
ohne gewünschten erfolg. ich habe es mit diversen bootparametern probiert unter anderem acpi=oldboot
ich habe auch die yast systemreparatur von der dvd laufen lassen. dabei wurde nur festgestellt das angeblich glibc-2 pakete defekt seien die er "repariert" hat.
in mehrern bootanläufen kam er eben über die "starting powersaved stelle raus" nun ist er bei "xendomains skipped" stehen geblieben. (das skipped ist normal, da ich xen nicht eingerichtet habe). was mich nur noch verwirrt ist das normalerweise xen und xendomains vor starting powersaved ge-skipped wird. jetzt startet er aber zuerst powersaved und bleibt dann nach xendomains stehen. nach einigen neustarten ist die reihenfolge wieder wie vorher. also er bleibt wieder nach dem starten von powersaved stehen. mit acpi=off fängt er nicht mal an zu booten.
falls mir irgendjemand helfen kann wäre ich sehr glücklich, da ich im moment sehr verzweifelt bin.
ich hoffe ich habe genug informationen gegeben, damit ihr euch einen groben überblick verschaffen könnt.
viele grüße
gnux (dankbar für alles............ :-/ )
update: so ich kann nun definitiv sagen das das stocken des bootprozess nicht von meinen änderungen kam( die ja funktionierten und ich nun auch schon wieder rückgängig gemacht habe) sondern von dem update das ich via yast vor dem reboot ausgeführt habe. seit diesem update möchte er nämlich erst acpi via acpid ansprechen was aber offensichtlich nicht so ganz funktioniert. habe auf einem der andern rechner nämlich die gleichen updates gemacht und der bleibt an der gleichen stelle hängen.
ein freund von mir hat mit seinen suse10.0 rechnern das gleiche problem.
ich würde auf jeden fall momentan auf die neuesten kde updates verzichten!!! mir ist es schleierhaft wie eine kdebase 3.5.1-27 ein system derart zerschießen kann.
via failsafe lassen sich die meisten maschinen wieder booten. (bei einem bekannten geht bei den bootoptionen wohl auch acpi=off apm=off; bei mir jedoch nicht. bei einem rechner funktioniert nicht mal der failsafe!!)
ich habe leider keinen bisherigen beitrag für mein problem gefunden. (ich hoffe keinen übersehen zu haben.....)
ich nutze ein suse 10.0x86_64 auf einem amd athlon64 3500.
es lief bisher alles einwandfrei. habe stets alles mit zusätzlichen yast repositories auf dem neuesten stand gehalten.
als das system zum letzten mal lief habe ich meine dslverbindung so eingestellt das sie während dem bootvorgang startet und den ntp-server so eingerichtet das er während dem bootvorgang synchronisiert. hat alles wunderbar funktioniert. server war auch erreichbar. dann habe ich kde auf version 3.5.1-27 geupdatet. als ich eben neu starten wollt bleibt der bootvorgang einfach bei "starting powersaved (accessing ACPI events over acpid) done" stehen. also er schließt das skript korrekt ab macht dann aber nicht weiter. er hatte während dem booten mit dem ntp server verbunden.
ich habe eine rescue system gestartet meine linux partition gemountet und mit chroot in sie gewechselt yast gestartet und meine änderungen rückgängig gemacht. also das die dsl verbindung manuell gestartet wird und ntp ausgeschaltet.
ohne gewünschten erfolg. ich habe es mit diversen bootparametern probiert unter anderem acpi=oldboot
ich habe auch die yast systemreparatur von der dvd laufen lassen. dabei wurde nur festgestellt das angeblich glibc-2 pakete defekt seien die er "repariert" hat.
in mehrern bootanläufen kam er eben über die "starting powersaved stelle raus" nun ist er bei "xendomains skipped" stehen geblieben. (das skipped ist normal, da ich xen nicht eingerichtet habe). was mich nur noch verwirrt ist das normalerweise xen und xendomains vor starting powersaved ge-skipped wird. jetzt startet er aber zuerst powersaved und bleibt dann nach xendomains stehen. nach einigen neustarten ist die reihenfolge wieder wie vorher. also er bleibt wieder nach dem starten von powersaved stehen. mit acpi=off fängt er nicht mal an zu booten.
falls mir irgendjemand helfen kann wäre ich sehr glücklich, da ich im moment sehr verzweifelt bin.
ich hoffe ich habe genug informationen gegeben, damit ihr euch einen groben überblick verschaffen könnt.
viele grüße
gnux (dankbar für alles............ :-/ )
update: so ich kann nun definitiv sagen das das stocken des bootprozess nicht von meinen änderungen kam( die ja funktionierten und ich nun auch schon wieder rückgängig gemacht habe) sondern von dem update das ich via yast vor dem reboot ausgeführt habe. seit diesem update möchte er nämlich erst acpi via acpid ansprechen was aber offensichtlich nicht so ganz funktioniert. habe auf einem der andern rechner nämlich die gleichen updates gemacht und der bleibt an der gleichen stelle hängen.
ein freund von mir hat mit seinen suse10.0 rechnern das gleiche problem.
ich würde auf jeden fall momentan auf die neuesten kde updates verzichten!!! mir ist es schleierhaft wie eine kdebase 3.5.1-27 ein system derart zerschießen kann.
via failsafe lassen sich die meisten maschinen wieder booten. (bei einem bekannten geht bei den bootoptionen wohl auch acpi=off apm=off; bei mir jedoch nicht. bei einem rechner funktioniert nicht mal der failsafe!!)
Zuletzt bearbeitet: