Wie macht man ein Update/Upgrade von installierten Pkg's in NetBSD (suber)???

[quarzsnoopy]

pkg_chk kann zwar updates machen, aber eben nur mit "make update", was idR nicht viel bringt.

Es gab schon des öfteren Diskussionen darüber auf den Mailinglisten, es kann auch sein das jemand daran arbeitet die Updates effizienter zu machen.

Wenn es dich genauer interessiert, durchsuch mal tech-pkg@netbsd

Ich wollte es nicht so recht glauben, da ich in der Man-Page das auch gelesen habe:

Wusste ich auch nicht. Zumal in der man page ausdrücklich steht

"When updating packages that depend on each other pkg_chk will skip depen-
dent packages to reduce unnecessary rebuilding."

Aber "kaishakunin" scheint garnicht so unrecht zu haben!
Ich habe folgenden Test gemacht. Auf meinem frisch installiertem System hatte ich mit "make install" das nötigste (einschl. icewm-gnome) installiert. Bis hierhin hatte ich noch nicht so viele Packages drinn, habe aber schon gemerkt, dass sich nicht alle Packages mit "make install" bauen lassen.

Dann habe ich die PKGSRC auf aktuellen Stand gebracht und dann folgende Befehle abgesetzt:

pkg_chk -g
pkg_chk -ukbsD meta-pkgs/gnome
pkg_chk -ukbsD meta-pkgs/kde3

Jetzt hatte ich 225 Packages drinn (ne Menge mehr als vorher)...

Und nach dem ich meinen Laptop dann mal wieder eingeschalltet hatte, startete X11 nicht mehr...
"icewm" war weck!!! Und sicherlicherlich auch ein paar andere Packages auch...

Damit ist klar, "pkg_chk" kann NUR "...chk" richtig!
Somit komme ich um ein Script wirklich nicht herum...


Damit ist klar, nicht nur das ACPI-Powermanagement, sondern auch die Packages-Verwaltung in NetBSD können FreeBSD nicht ansatzweise das Wasser reichen. Wirklich ärgern tut mich aber nur das nicht funktionierende ACPI-Powermanagement, denn das tut auf nem Laptop schon weh!!! (Halbiert die Batteriebetriebszeit)

Mal sehen, was NetBSD noch so alles (nicht) kann...

 

[kaishakunin]

Aber "kaishakunin" scheint garnicht so unrecht zu haben!

klar
Ich hab das j a auch von Hubert Feyrer, der hat schließlich pkgsrc mit implementiert.

Wir haben auf dem Chemnitzer LinuxTag 2004 eine elend lange Diskussion über Paketupdates gehabt, und da ging es u.a. auch um pkg_chk.


Das größte Problem ist halt die rekursive Abhängigkeit verschiedener Pakete. Wenn es irgenwo hakt, ist der ganze Unterbaum verloren.

 

[quarzsnoopy]

klar
Ich hab das j a auch von Hubert Feyrer, der hat schließlich pkgsrc mit implementiert.

Wir haben auf dem Chemnitzer LinuxTag 2004 eine elend lange Diskussion über Paketupdates gehabt, und da ging es u.a. auch um pkg_chk.


Das größte Problem ist halt die rekursive Abhängigkeit verschiedener Pakete. Wenn es irgenwo hakt, ist der ganze Unterbaum verloren.

Nächstes Mal werde ich Dir gleich glauben.
Aber gereitzt hat mich soein Test doch...

 

[quarzsnoopy]

Ich habe pkg_chk schon seit geraumer Zeit nur noch benutzt um veraltete Pakete zu finden, aber IMO ist der Rechnername nützlich wenn pkgsrc via NFS für mehrere Clients bereitgestellt wird.

Ansonten sein nochmal darauf hingewiesen das ich die Updates in chroot im Wiki beschrieben habe ;-)

Habe ich mir im WIKI angesehen und ausprobiert (gleich ein Script, passend für mich, geschrieben um es zu "automatisieren"), funktioniert recht gut.
Jetzt bin ich aber noch über pkg_comp gestolpert (http://www.bsdfreak.org/modules/news/article.php?storyid=1).
Was ist eigentlich zwischen "pkgtools/pkg_comp" und "mk/bulk/mksandbox" der entscheidende Unterschied, dass Du "mk/bulk/mksandbox" benutzt und nicht "pkgtools/pkg_comp"?

 

[kaishakunin]

Nächstes Mal werde ich Dir gleich glauben.
Aber gereitzt hat mich soein Test doch...

Ich bin halt erst mit

cd /usr/pkgsrc/multimedia/mplayer && make update

tierisch auf die Schnauze gefallen.

Dann habe ich pkg_chk ausprobiert - und bin wieder ins Fettnäpfchen getreten.

Daraufhin hatte ich dann bei dem LinuxTag Hubert und die anderen NetBSD-Booth-Bunnies zu dem THema befragt. Hubert hat mir halt die bulk-skripte empfohlen, weil die sauber funktionieren und auch entsprechend getestet wurden. Das andere Shellskript hat damals noch nicht existiert.

Inzwischen habe ich in meinem Desktop-NetBSD auf Arbeite eine zweite Platte, auf der quasi meine Serverstrukturen sind. Will ich etwas updaten, probiere ich das erst auf dieser Platte aus. Klappt es, gehe ich auf die Server, klappte es nicht, fasse ich die Server nicht an.

 

[quarzsnoopy]

Fragen zur praktischen Arbeit mit der Sandkiste

Danke für Eure Unterstützung! Bin schon fast am selbst gestecken Ziel eines automatisierten Updates, habe jetzt aber noch mal in paar Fragen zur praxis...


Wie lautet eigentlich das richtige Kommando von "pkg_chk", damit er nur die veralteten Packages ausgibt (mit pkgchk.conf und ohne)? Denn ich will ja in der Sandkiste nur das bauen, was ich auch brauche, nicht immer alles.

Vielleicht so?

ohne pkgchk.conf:
pkg_chk -i

mit pkgchk.conf:
pkg_chk -c



und wie aktiviert/deaktiviert man später die Sandkiste?

aktiviren (mounten):
/usr/sandbox/sandbox mount

deaktivieren (unmounten):
/usr/sandbox/sandbox umount


Oder ist es besser (wegen der Aktuallität von kopierten Dateien) die Sandkiste nach gebrauch zu löschen und vor gebrauch wieder anzulegen?

 

[quarzsnoopy]

Noch eine Frage: "Wie kann man in NetBSD herraus bekommen, welches Package eine bestimmte Datei installiert hat?"


In FreeBSD macht man es z.B.
so: pkg_which -v /usr/local/bin/erb


In RedHat-Linux macht man das z.B.
so: rpm -qf /bin/ls
oder
so: rpm -q --whatprovides /bin/ls

 

[kaishakunin]

Noch eine Frage: "Wie kann man in NetBSD herraus bekommen, welches Package eine bestimmte Datei installiert hat?"

Von Paket zu Datei:

# pkg_info -L iozone
Information for iozone-3.226:

Files:
/usr/pkg/bin/iozone
/usr/pkg/man/man1/iozone.1
/usr/pkg/share/doc/IOzone/Iozone_ps.gz

Von Datei zu Paket:

# pkg_info -F /usr/pkg/bin/iozone
Information for iozone-3.226:

Comment:
Benchmark for file read and write speed

Description:
This test writes a X MEGABYTE sequential file in Y byte chunks, then
rewinds it  and reads it back.  [The size of the file should be
big enough to factor out the effect of any disk cache.]

Homepage:
http://www.iozone.org/

Ich habe mal ein Perlskript zusammengehackt, das die pkg_database auswertet. http://www.net-tex.de/code/pkg_db.pl erzeugt 3 HTML-Dateien, einmal als Index eine Schnellübersicht ähnlich zu pkg_info und dann vom Index aus 2 Detailseiten, einmal mit den installierten Dateien und mit der Detailbeschreibung.

 

[kaishakunin]

Wie lautet eigentlich das richtige Kommando von "pkg_chk", damit er nur die veralteten Packages ausgibt (mit pkgchk.conf und ohne)? Denn ich will ja in der Sandkiste nur das bauen, was ich auch brauche, nicht immer alles.

Vielleicht so?

ohne pkgchk.conf:
pkg_chk -i

mit pkgchk.conf:
pkg_chk -c

Ja, zumindest verwende ich immer -i um eine Übersicht zu bekommen was alles veraltet ist.

und wie aktiviert/deaktiviert man später die Sandkiste?

aktiviren (mounten):
/usr/sandbox/sandbox mount

deaktivieren (unmounten):
/usr/sandbox/sandbox umount


Oder ist es besser (wegen der Aktuallität von kopierten Dateien) die Sandkiste nach gebrauch zu löschen und vor gebrauch wieder anzulegen?

Die Sandbox ist ein chroot, also musst du als root

chroot /usr/sandbox/sandbox

ausführen um in die chroot-Umgebung zu kommen. Vorher müssen aber die null-mounts durchgeführt werden, sonst kannst du das chrot-Verzeichnis nicht benutzen. Am besten einfach die Skripte aus pkgsrc verwenden um die chroot zu initialisieren.

Zum verlassen musst du einfach die Shell verlassen idR mit exit oder logout. Normalerweise verwendet die chroot-Umgebung dein normales pkgsrc-Verzeichnis, so das die Packages dort drin liegen. Deinstallieren würde ich die Pakete nicht, vielleicht braucht das nächste Paket eines dieser als Abhängigkeit.

 

[quarzsnoopy]

Von Datei zu Paket:

# pkg_info -F /usr/pkg/bin/iozone
Information for iozone-3.226:

Comment:
Benchmark for file read and write speed

Description:
This test writes a X MEGABYTE sequential file in Y byte chunks, then
rewinds it  and reads it back.  [The size of the file should be
big enough to factor out the effect of any disk cache.]

Homepage:
http://www.iozone.org/

Danke! Ich hätte eher gedacht, dass pkg_info in NetBSD weniger Parameter hat, nicht das es andere hat....

 

[quarzsnoopy]

den Sand in der Kiste auch mal wechseln...

Also, ich hatte zwar weiter oben schon mal gefragt ob man die "sandbox" auch mal löschen und dann wieder neu bauen sollte...

Nun, ich hatte den PKGSRC-Tree mit "cd /usr/pkgsrc ; cvs update" aktuallisiert, dann die Sandkiste gemountet und wollte KDE3 bauen, ging nicht, da die Lizens für "lame" in der "/etc/mk.conf" nicht eingeschaltet war. Gut, hab ich dann eingeschaltet und versuche es nochmal... ging immer noch nicht. Ich lege die Zeile mal an den Anfang der Datei, mal in der Mitte, mal ans Ende... nichts hat die Fehlermeldung behoben. Dann sehe ich in der SandBox in der "/etc/mk.conf" nach, da ist der Eintrag garnicht drinn! OK, dann ein "/usr/sandbox/sandbox umount ; /usr/sandbox/sandbox mount", ... und ... es hat sich nichts geändert!
Also hab ich die SandKiste gelöscht und neu angelegt, dann gings!

So, das hat mich gelehrt, auch mal den Sand in der Kiste gegen neuen auszutauschen...

 

[quarzsnoopy]

seltsammes Verhalten bei "make package"... wie vermeidet man das?

Gestern Abend habe ich versucht Gnome im Sandkasten upzudaten und da konnte er z.B. von "libgnomedb" kein Package erstellen. Er hat gemeint, es ist schon eine Version von "libgnomedb" installiert...
"libgnomedb" war auch schon installiert und in der Versionsnummer gab es auch keinen Unterschied!

Nach meinem Verständnis muss ein Programm doch erst installiert werden und dann kann man davon ein Package bauen lassen.... oder?

Ich konnte erst ein Package bauen nachdem ich "pkg_delete -f 'libgnomedb*'" abgeschickt hatte. Es ging mit "make deinstall", "make reinstall" und "make replace" nicht!

Ist es vielleicht besser (zu automatisieren) wenn ich in der Sandkiste mit "pkg_chk" arbeite? Dann sollten diese installierten Packages doch automatisch gelöscht werden bevor er ein "make package" macht?
Oder ist es (für einen 100% automatisierbaren "make package") besser wenn ich vor dem Start in der Sandkiste erst alle Packages lösche:
pkg_info | while read AAA BBB;do echo $AAA;pkg_delete -f $AAA;done

 

[kaishakunin]

Gestern Abend habe ich versucht Gnome im Sandkasten upzudaten und da konnte er z.B. von "libgnomedb" kein Package erstellen. Er hat gemeint, es ist schon eine Version von "libgnomedb" installiert...
"libgnomedb" war auch schon installiert und in der Versionsnummer gab es auch keinen Unterschied!

Nach meinem Verständnis muss ein Programm doch erst installiert werden und dann kann man davon ein Package bauen lassen.... oder?

Ich konnte erst ein Package bauen nachdem ich "pkg_delete -f 'libgnomedb*'" abgeschickt hatte. Es ging mit "make deinstall", "make reinstall" und "make replace" nicht!

Wie hast du denn die Sandbox initialisiert? Normalerweie dürfen in einer frischen Sandbox exakt 0 Pakete existieren, was pkg_info auch bestätigt, wenn du schon Pakete gebaut hast, dürfen nur die gebauten da sein. Pakete im eigentlichen Host darf er gar nicht sehen.

Wenn es zu Konflikten kommt ist IMO das chroot nicht richtig durchgeführt worden. Wie gehst du denn in die Sandbox?
Erst müssen die mount_null durchgeführt werden um bestimmte Verzeichnisse (src, xrsc, pkgsrc) einzubinden und dann kannst du mit "chroot /sandbox" ind die sandbox gehen.

 

[quarzsnoopy]

Wie hast du denn die Sandbox initialisiert? Normalerweie dürfen in einer frischen Sandbox exakt 0 Pakete existieren, was pkg_info auch bestätigt, wenn du schon Pakete gebaut hast, dürfen nur die gebauten da sein. Pakete im eigentlichen Host darf er gar nicht sehen.

Wenn es zu Konflikten kommt ist IMO das chroot nicht richtig durchgeführt worden. Wie gehst du denn in die Sandbox?
Erst müssen die mount_null durchgeführt werden um bestimmte Verzeichnisse (src, xrsc, pkgsrc) einzubinden und dann kannst du mit "chroot /sandbox" ind die sandbox gehen.

Ja, richtig! So mache ich es auch!
Weiter oben hatte ich ja mal gefragt, ob die Sandbox NACH dem erstellen der benötigten Packages gelöscht werden soll, da hatte jemand gesagt, nein.
Also waren in der Sandkiste natürlich die alten Packages drinn, die ich mit dem ALTEN "pkgsrc" gebaut hatte und die ich jetzt updaten wollte...
So, das updaten hat nicht funktioniert.... verstehe ich zwar nicht, aber seit dem wird die Sandkiste bei mir für jeden einzelnen Lauf neu erstellt. Das dauert zwar manchmal länger als nötig, funktioniert aber immer, auch per "cron", und so zuverlässig wollte ich das ja haben.

Jetzt funktioniert mein Script sehr zuverlässig,
- ich kann es ohne Parameter aufrufen, dann wird alles gemacht;
- ich rufe es mit einem Dateinamen als Parameter auf, dann werden die PKGs aus der Datei gebaut;
- ich rufe es mit einem PKG-Namen als Parameter auf, dann wird nur das PKG gebaut.

Mittlerweile finde ich das PKG-bauen in der Sandkiste besser als die Variante von FreeBSD!

 

[cyberdune]

Kannst Du Dein Script mal posten,
oder besser ein kleines Howto dazu schreiben?

:-D

 

[quarzsnoopy]

...das Script... WICHTIG: erst lesen, dann verwenden!

Kannst Du Dein Script mal posten,
oder besser ein kleines Howto dazu schreiben?

:-D

Ja, mache ich hiermit.

Eines sei nur dazu noch gesagt:
Die absolute Automatisierbarkeit ist mir unter keinem OS bisher unter gekommen (weder unter Debian, FreeBSD und auch nicht unter NetBSD)! Bei FreeBSD machen fast immer irgendwelche "p5-..."-Ports Probleme und unter NetBSD ist ein ähnlich seltsames Verhalten (allerdings mit anderen Packages) zu finden. Diese Probleme liegen (nach meinen Suchergebnissen zumindest bei FreeBSD) im Menschlichen (Fehl-)Faktor der Port-Maintaner. Nun keiner ist Perfekt und so muss man immer noch mal ein Adlerauge drauf werfen...

Ich habe jedenfalls mein Script so geschrieben, dass die Fehler, die automatisch auszubügeln gehen, auch (soweit möglich) ausgebügelt werden. Das kostet in meinem Fall nur Kompilierzeit, da einige Packages mehrfach kompiliert werden, eigentlich blödsinn, ist aber anders nicht besonders gut zu automatisieren...

Ich habe es eigentlich (für mich) recht gut dokumentiert, aber wenn jemand Fragen hat, kann er sie gerne stellen!
Das Script habe ich in dieser Form so das letzte mal selber benutzt, und so sind unter Umständen Einstllungen drin, die nicht jeder so will! KEINER sollte dieses Script blind anwenden!!!
Erst lesen und verstehen, dann für eigene Wünsche anpassen und erst dann anwenden!

.

Aber trotzdem eine kleine Beschreibung:
* ruft man das Script mit Parametern auf:
/home/sbin/packages-update_upgrade.sh www/firefox-bin-acroread5 emulators/wine
dann werden nur diese Packages gebaut (und die abhängigen natürlich auch);
* ruft man das Script mit einem Dateinamen als ersten Parameter auf, dann wird diese Datei als "pkgchk.conf" verwendet und alle PKGSRC-Inhalte kompiliert;
* ruft man es ohne Parameter auf, wird die Sandkiste:
- erstellt,
- eine aktuelle Packages-Liste reingelegt,
- sie gemountet,
- mit chroot eingestiegen,
- die Packages gebaut,
- ausgestiegen,
- die Sandkiste gelöscht,
- und zum Schluss alle vorhandenen Packages installiert.

Probleme die ich mit dem Script hatte, konnten auch von Hand nachvollzogen werden. Das bedeutet, eigentlich habe ich im Script kein Fehler mehr gefunden.

Verbesserungen die ich noch vorhabe sind, das ich nicht die langen "make ..."-Befehle verwenden will, sondern in der Sandkiste mit pkg_chk arbeiten will. Nur da habe ich noch nicht raus, wie man damit Packages erstellen kann...
Also einige auskommentierte Befehlszeilen sollten nie einkommentiert werden, da sie nur zu Testzwecken irgendwann mal eingetragen wurden, naja lesen...

.

.

. [ich hatte zuerst ein altes Testscript gepostet, das nicht funktioniert]

. [das habe ich jetzt gelöscht, und das richtige angehängt]

.

.

 

[quarzsnoopy]

Ports-Tree vs. PKGSRC

Leider habe ich mittlerweile feststellen müssen, dass im PKGSRC von NetBSD mehr Fehler enthalten sind (besonders auf Gnome bezogen) als in FreeBSD's Ports-Tree. Es ist mir bis jetzt nicht gelungen (egal ob mit Script oder von Hand, es kamen immer die selben Fehlermeldungen) Gnome-2 komplett zu installieren!

Das frustriert erst recht, wenn man versucht die kaputten src-Packages als Binär-Packages zu installieren und dabei auf sämtlichen Spiegelservern für NetBSD 2.0.2 nur "amd64"-Packages findet.
Für NetBSD-RELEASE-2.0 ist (z.B. gnome2-media) auch nirgends zu finden...

Hat dafür jemand eine Lösung gefunden?
Beim kompilieren von "gnome2-media", zum Beisliel, findet er eine "*.h"-Datei nicht.
Ich habe in dem Makefile die entspechende Zeile auskommentiert und hoffe jetzt, dass er das jetzt hinbekommt. Kann ich aber erst nach der Arbeit, heute Abend, sehen.

 

[tenco]

Wirklich ärgern tut mich aber nur das nicht funktionierende ACPI-Powermanagement, denn das tut auf nem Laptop schon weh!!! (Halbiert die Batteriebetriebszeit)

Warum, was funktioniert denn nicht? Bzw. wie kann mensch denn mit acpi Energie sparen?

 

[mawei]

Es ist mir bis jetzt nicht gelungen (egal ob mit Script oder von Hand, es kamen immer die selben Fehlermeldungen) Gnome-2 komplett zu installieren!

Das frustriert erst recht, wenn man versucht die kaputten src-Packages als Binär-Packages zu installieren und dabei auf sämtlichen Spiegelservern für NetBSD 2.0.2 nur "amd64"-Packages findet.
Für NetBSD-RELEASE-2.0 ist (z.B. gnome2-media) auch nirgends zu finden...

Eventuell PRt #30139?
Siehe: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=30139

Ansonsten, amd64 hat auch kein gnome2-media, und die pkgsrc-2005Q2 binaries von i386/2.0 funktionieren auch mit 2.02.

Aber vermutlich kann man Dir auf tech-pkg@netbsd.org besser weiterhelfen.

Viel Glueck!

 

[quarzsnoopy]

Warum, was funktioniert denn nicht? Bzw. wie kann mensch denn mit acpi Energie sparen?

Als noch FreeBSD 4.9 drauf war, sah die Sache genauso aus wie jetzt mit NetBSD 2.0.2. Der CPU-Lüfter von meinem Laptop ging nie aus und der Akku hielt max. 45 Min.

Mit FreeBSD 5.x ging der Lüfter nur manchmal an und der Akku hielt ca. 1 Stunde und 25 Min....
und das wollte ich auch unter NetBSD, aber ich habe irgendwo vor ca. 4 Monaten mal gelesen, dass NetBSD-2-ACPI die CPU (noch) nicht in den Suspend-Mode schicken kann.
Wie es mit NetBSD 1.x aussieht weiss ich nicht, aber ich denke auf keinen Fall besser.

 

[quarzsnoopy]

Eventuell PRt #30139?
Siehe: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=30139

Ansonsten, amd64 hat auch kein gnome2-media, und die pkgsrc-2005Q2 binaries von i386/2.0 funktionieren auch mit 2.02.

Aber vermutlich kann man Dir auf tech-pkg@netbsd.org besser weiterhelfen.

Viel Glueck!

Danke.
Ich hab auch schon gesucht (und nicht gefunden), aber jetzt hab ich die Nase voll. Meine Zeit verplemper ich nicht mit soeinem Package, das ich ohnehin kaum benutze.

 

[tenco]

Als noch FreeBSD 4.9 drauf war, sah die Sache genauso aus wie jetzt mit NetBSD 2.0.2. Der CPU-Lüfter von meinem Laptop ging nie aus und der Akku hielt max. 45 Min.

Hast du denn ACPI in den Kernel kompiliert? Der Standard-Kernel von 2.0.2 hat AFAIK kein ACPI. (kurzes "find /usr/src/ -name GENERIC|xargs acpi...) acpi ist noch nicht mal in -current in GENERIC angeschaltet.

 

[quarzsnoopy]

Hast du denn ACPI in den Kernel kompiliert? Der Standard-Kernel von 2.0.2 hat AFAIK kein ACPI. (kurzes "find /usr/src/ -name GENERIC|xargs acpi...) acpi ist noch nicht mal in -current in GENERIC angeschaltet.

Natürlich!
der GENERIC kann ja nix:

bash-3.00# cat /usr/src/sys/arch/i386/conf/MYKERNEL202LAPTOP | grep -i acpi
acpi0 at mainbus0
options ACPI_PCI_FIXUP # PCI interrupt routing via ACPI
options ACPI_ACTIVATE_DEV # If set, activate inactive devices
options ACPICA_PEDANTIC # force strict conformance to the Spec.
options ACPI_DISABLE_ON_POWEROFF # disable acpi on power off
# ACPI devices
acpiacad* at acpi? # ACPI AC Adapter
acpibat* at acpi? # ACPI Battery
acpibut* at acpi? # ACPI Button
acpiec* at acpi? # ACPI Embedded Controller
acpilid* at acpi? # ACPI Lid Switch
acpitz* at acpi? # ACPI Thermal Zone
#attimer* at acpi? # AT Timer
com* at acpi? # Serial communications interface
fdc* at acpi? # Floppy disk controller
#joy* at acpi? # Joystick/Game port
lpt* at acpi? # Parallel port
#mpu* at acpi? # Roland MPU-401 MIDI UART
npx* at acpi? # Math coprocessor
pckbc* at acpi? # PC keyboard controller
#pcppi* at acpi? # AT-style speaker sound
#wss* at acpi? # NeoMagic 256AV in wss mode
#spic* at acpi? # Sony Programmable I/O Controller

 

[tenco]

Natürlich!
der GENERIC kann ja nix:

Wusste garnicht das der Suspend-Mode soviel ausmacht. Sowas kenn ich eigentlich nur daher, dass CPU-Frequency-Scaling nicht unterstützt wird. Sorry, da kann ich dir nicht weiterhelfen...

 

[quarzsnoopy]

Wusste garnicht das der Suspend-Mode soviel ausmacht. Sowas kenn ich eigentlich nur daher, dass CPU-Frequency-Scaling nicht unterstützt wird. Sorry, da kann ich dir nicht weiterhelfen...

Ich weiss nicht welche Funktion dafür genau veratwortlich ist ("CPU-Frequency-Scaling" ist schon logisch), ich weiss nur, das es bei FreeBSD-5 mit ACPI funktioniert und bei NetBSD-2 weder mit noch ohne ACPI. Also müssen die noch dran arbeiten! Leider...

Ich hatte ja auch nur gelesen, dass NetBSD den "Suspend-Mode" nicht kann. Ob der dafür verantwortlich ist weiss ich nicht, und welche Modi NetBSD-ACPI auch nicht kann weiss ich auch nicht...

Auf jeden Fall kann es nicht genug!!!