Fragen zu guter Upgradepraxis bei GPUs von AMD und Intel

C

cabriofahrer

Well-Known Member
Das Problem ist allgemein bekannt und taucht hier im Forum an mehreren Stellen auf: Nutzer mit AMD und Intel GPUs bekommen manchmal bei einem Upgrade von einer Minor-Version zur nächsten nach einem Neustart einen Kernel Panic, man kommt dann wohl nicht herum, drm-kmod aus den Ports zu komplilieren, was wiederum voraussetzt, dass man die Sources braucht, die man in den meisten Fällen bei einer Frischinstallation auch nicht installiert hat. Ich möchte gerne hier meine Erfahrungen auf Maschinen schildern, die keine Nvidia GPU haben und Eure Meinungen / Vorschläge hören, wie man denn bei solchen Maschinen am besten bei einem Upgrade vorgeht.
Zunächst wird man wohl sagen können, dass man im Vorfeld verhindern sollte, dass der Rechner nach dem freebsd-update install wieder in den graphischen Modus bootet und das Kernelmodul lädt, also Einträge in der /etc/rc.confwie lightdm_enable="YES"und kld_list="radeonkms"entfernt.
Dann wäre es, nehme ich an, richtig an dieser Stelle ein pkg upgradezu machen. Dann mittles kldloaddas Kernelmodul laden und hoffen, dass es dann nicht schon crasht oder erst nach einem startx. Wenn X normal startet, ist alles OK und man kann sich freuen. Doch wenn es crasht, muss man das Kernelmodul drm-kmod selbst bauen. Dazu später noch eine Frage, weil drm-kmod ja der Metaport ist.
Man muss dazu natürlich die Ports installiert haben, aber dummerweise auch die Sourcen.
Doch vorweg ein Beispiel auf einem Rechner mit einer Radeon-Karte (Turks), wie ich da herumkam: Bei Einbau der Radeon-Karte war das System auf 13.2 (amd64) und alles war gut. Eines Tages brachte ich es auf 13.3 und dann hatte ich schon den Crash. Da es zu der Zeit schon 14.0 gab, brachte ich das System eben auf 14.0 und alles war wieder in Ordnung.
Doch vor einigen Tagen kam ich mal auf die Idee, das alte 2006 MacBook wieder einzuschalten. Auch wenn ich das Teil gar nicht benutze, wollte ich doch mal upgraden. Es war auf i386 14.0 und ich wollte es auf 14.1 bringen. Und hier dann doch der Kernel Panic. Also wollte ich ausprobieren, ob das Problem mit dem Kompilieren von drm-kmodgelöst werden konnte. Da die Ports nicht installiert waren, musste ich das erstmal nachholen und tat das mittles pkg install portsnap(Hier musste ich noch /usr/local/etc/portsnap.confeditieren bevor das Tool portsnapfunktionierte.
Das Kompilieren von drm-kmodergab schnell einen Fehler, da die Sourcen natürlich auch nicht installiert waren. Da man das bei einer Frischinstallation in bsdinstalleinfach auswählen kann, suchte ich nach einer Methode das mit bsdinstallnachzuholen und wurde dann fündig:

unix.stackexchange.com

What is the proper method to add missing distributions to a running FreeBSD?

My FreeBSD 10.0 machine was installed by the hosting company and they left out several distributions. Specifically: src/src world/doc world/games world/lib32 How best to add those back into the mi...
unix.stackexchange.com unix.stackexchange.com

Hat so nicht 100%-ig gestimmt und konnte ich mithilfe von man bsdinstallund etwas Probieren dann hinkriegen:

Code: 
export DISTRIBUTIONS="src.txz"
export BSDINSTALL_DISTDIR=/usr/freebsd-dist              # Musste ich mit mkdir vorher noch erstellen und stimmt nicht mit dem Pfad aus dem Thread überein
export BSDINSTALL_DISTSITE="https://download.freebsd.org/releases/i386/14.1-RELEASE/"      # In meinem Fall
bsdinstall distfetch

export BSDINSTALL_CHROOT=/
bsdinstall distextract

Klappte wunderbar und dann konnte ich erfolgreich /usr/ports/graphics/drm-kmodkompilieren. Dabei werden eine Menge Ports mit Firmware für AMD und Intel GPUs kompiliert, liege ich also richtig in der Annahme, dass man nicht den Metaport braucht sondern nur drm-510-kmod oder drm-515-kmod und den bestimmten Firmware Port für seine GPU? Wobei ich im vorliegenden Fall gar nicht weiß, welcher hier für den Intel GMA 950 Chip zum Tragen kommt?
Jedenfalls hat es geklappt, die Konsole ändert sich ohne Crash bei kldload i915kms. Zum Starten von X muss allerdings zusätzlich xf86-video-intelinstalliert werden.

Auf der anderen Seite habe ich noch ein anderes Notebook mit einem Radeon HD 6250 Chip auf dem ich kürzlich eine Frischinstallation von 14.1-RELEASE-p3 amd64 machte und dort gibt es keine Probleme. Ich nehme an, beim Macbook mit 14.1 i386 war das anders, weil i386 natürlich nicht mehr so gepflegt wird?
Aber eingangs erwähnte ich ja, dass ich auf einem 13.2 amd64 mit dem Turks Radeon nach dem Upgrade auf 13.3 den Kernel Panic hatte. Irgendwann demnächst steht ein Upgrade dieses Rechners (mit Turks) auf 14.1 an und ich bin mir jetzt nicht sicher, ob es mit Packages klappen wird oder ob ich wieder Ports und Sources installieren muss?
Gibt es also irgendeine Möglichkeit, im Vorfeld zu wissen, ob ein Upgrade mit Packages klappen würde oder nicht? Oder ist man als Nutzer von Intel und AMD GPUs immer dazu verdammt, ab und an dieses Problem mit dem Kernel Panic zu haben? Ist ziemlich ärgerlich, denn dann ist in jedem Fall ein full fsck angesagt. Gibt es sonst noch irgendwelche Vorschläge / Ergänzungen / Klarstellungen zum Thema?
 
Gibt wohl noch eine andere Methode die Sourcen nachträglich auf die Schnelle zu installieren. Habe ich vor Jahren benutzt.
'fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/14.1-RELEASE/src.txz
tar -C / -xzvf src.txz
'
Aber keine Garantie, daß das heute auch noch geht.

Ansonsten könnte man in der rc.conf beim Setzen des Treibers noch auf eine Variable abfragen, man beim booten setzt. Variable da, dann Treiber nicht installieren.
 
Also wenn das Problem immer damit gelöst ist die Treiber aus den Sourcen zu bauen, würde ich den halt immer frisch aus den Sourcen bauen?

(Ich hab wenig Ahnung von der Thematik tbh)
 
CommanderZed schrieb:
Also wenn das Problem immer damit gelöst ist die Treiber aus den Sourcen zu bauen, würde ich den halt immer frisch aus den Sourcen bauen?
Zum Vergrößern anklicken....
Nein, eben nicht, da es eben ziemlich (Zeit-) aufwendig ist. Das schöne ist doch, wenn man das alles nicht braucht und alles unkompliziert mit Packages geht. Die Sourcen nehmen auch viel Festplattenplatz weg, ich glaube so 2 GB.
 
cabriofahrer schrieb:
Nein, eben nicht, da es eben ziemlich (Zeit-) aufwendig ist. Das schöne ist doch, wenn man das alles nicht braucht und alles unkompliziert mit Packages geht. Die Sourcen nehmen auch viel Festplattenplatz weg, ich glaube so 2 GB.
Zum Vergrößern anklicken....

Das ist im Jahr 2024 ja nicht viel, und son update kann man ja auch z.B. nachts laufen lassen per script. Und auch ggf. auf der schnellsten maschine die man so hat und dann halt auf die anderen verteilen.
 
cabriofahrer schrieb:
Gibt es also irgendeine Möglichkeit, im Vorfeld zu wissen, ob ein Upgrade mit Packages klappen würde oder nicht? Oder ist man als Nutzer von Intel und AMD GPUs immer dazu verdammt, ab und an dieses Problem mit dem Kernel Panic zu haben? Ist ziemlich ärgerlich, denn dann ist in jedem Fall ein full fsck angesagt.
Zum Vergrößern anklicken....
Also, ich würde ja einfach vor jedem Upgrade ohnehin einen ZFS-Snapshot anlegen, dann könnte ich im Zweifel wieder zurück und würde mir dann einfach das entsprechende Memstick-ISO meiner gewünschten FreeBSD-Version herunterladen und eine Frischinstallation machen, denn da gibt es ja offenbar keine Probleme. Nachdem ich das Basissystem installiert habe, spielt mir
Code: 
pkg install drm-kmod
doch automatisch den korrekten Treiber drauf. Den Treiber samt Firmware aus den Ports zu bauen scheint mir etwas aufwendig, das würde ich nur machen, wenn es gar keine andere Möglichkeit gibt.
 
Nein, die packages auf den Package-Servern sind / werden gegen die .0 Release gebaut. Darumuß man selber bauen, wenn sich später was an den entscheidenden Stellen im Kernel ändert.
 
serie300 schrieb:
Nein, die packages auf den Package-Servern sind / werden gegen die .0 Release gebaut. Darumuß man selber bauen, wenn sich später was an den entscheidenden Stellen im Kernel ändert.
Zum Vergrößern anklicken....
Müsste das dann nicht eigentlich heißen, dass eine Frischinstallation bei entsprechenden Änderungen im Kernel dasselbe Problem verursacht? Ich komme gerade nicht so ganz hinter meinen Denkfehler in der Hinsicht, aber es ist auch noch früh am morgen. ;)
 
serie300 schrieb:
Nein, die packages auf den Package-Servern sind / werden gegen die .0 Release gebaut. Darumuß man selber bauen, wenn sich später was an den entscheidenden Stellen im Kernel ändert.
Zum Vergrößern anklicken....
Ich glaube, das wurde in den anderen Threads hier auch erwähnt und das ist wohl auch genau das Problem. Hat irgendetwas mit einem "ABI change" zu tun. Und ich glaube, das würde tatsächlich bedeuten, dass:
Macke1979 schrieb:
Müsste das dann nicht eigentlich heißen, dass eine Frischinstallation bei entsprechenden Änderungen im Kernel dasselbe Problem verursacht?
Zum Vergrößern anklicken....
Aber wenn das Problem bekannt ist, warum werden dann die Packages auf den Package-Servern gegen die .0 Release gebaut und nicht für das jeweilige Minor-Release? M.E. sind auch andere Kernel-Module davon betroffen, z.B. auch virtualbox. Das ist doch echt Panne, oder?
 
Die werden nicht starr gegen .0 gebaut, irgendwann wird das schon angehoben. Das Problem bleibt aber das gleiche, das Paket kann gegen ein neueres oder auch älteres FreeBSD gebaut sein als gerade installiert ist. Gerade wird z.B. FreeBSD 14.0 und 14.1 supported aber nur gegen eines davon kann das Paket gebaut sein.
 
Hm... Vielleicht wäre es sehr vernünftig, so lange wie möglich auf einem Minor-Release zu bleiben, um die Wahrscheinlichkeit derartiger Überraschungen zu minimieren. Dennoch habe ich nun für den Fall des Falles (mit der Git-Methode, weil es portsnap ja nicht mehr gibt) meinen Ports-Tree vorsichtshalber mal auf den aktuellen Stand gebracht und nach Anleitung von @cabriofahrer seinem Startpost (Danke geht an dieser Stelle raus) die Kernel-Sourcen nachinstalliert. Ist ja jetzt nicht sooo viel zusätzlicher Plattenplatz, der da beansprucht wird und sollte es tatsächlich mal zum Crash kommen, könnte ich somit notfalls drm-kmod aus den Ports neu bauen. Ist ja eigentlich auch kein großer Weltuntergang und ein kleines Kernelmodul samt Abhängigkeiten zu compilieren wird sicher nicht so viel Zeit beanspruchen wie das Compilieren einer komplexen GUI-Anwendung.
 
Das Problem wird sogar im Handbook erwähnt (unter "Warning"), obwohl keine Lösung dafür angeboten wird. Es heißt einfach: "...might not be suitable... be prepared to build the module from source."

docs.freebsd.org

Chapter 26. Updating and Upgrading FreeBSD

Information about how to keep a FreeBSD system up-to-date with freebsd-update or Git, how to rebuild and reinstall the entire base system, etc
docs.freebsd.org docs.freebsd.org

Etwas weiter oben im Handbook noch eine weitere interessante Information zum Thema Sourcen:

docs.freebsd.org

Chapter 26. Updating and Upgrading FreeBSD

Information about how to keep a FreeBSD system up-to-date with freebsd-update or Git, how to rebuild and reinstall the entire base system, etc
docs.freebsd.org docs.freebsd.org

"Individual components can instead be specified, such as src/base or src/sys."

Heißt das, wenn man src/base oder src/sys unter "Components" in /etc/freebsd-update.conf einträgt, dass die Sourcen auch mit einem freebsd-updateaktualisiert werden?

Also was müsste da genau rein, um die Sourcen bei einem freebsd-updatemit zu aktualisieren? src/base oder src/sys oder beides?

So sieht meine /etc/freebsd-update.confauf meinem Hauptrechner aus:

Code: 
$ more /etc/freebsd-update.conf

# Trusted keyprint.  Changing this is a Bad Idea unless you've received
# a PGP-signed email from <security-officer@FreeBSD.org> telling you to
# change it and explaining why.
KeyPrint 800651ef4b4c71c27e60786d7b487188970f4b4169cc055784e21eb71d410cc5

# Server or server pool from which to fetch updates.  You can change
# this to point at a specific server if you want, but in most cases
# using a "nearby" server won't provide a measurable improvement in
# performance.
ServerName update.FreeBSD.org

# Components of the base system which should be kept updated.
Components src world kernel

# Example for updating the userland and the kernel source code only:
# Components src/base src/sys world

# Paths which start with anything matching an entry in an IgnorePaths
# statement will be ignored.
IgnorePaths

Bei einem freebsd-updatewerden bei mir aber keine Sourcen aktualisiert, mein Verzeichnis "/usr/src"
ist leer.
In "man freebsd-update" steht auch ein Beispiel:

Code: 
Components               The parameters following this keyword are the
                              components or sub-components of FreeBSD which
                              will be updated.  The components are “src”
                              (source code), “world” (non-kernel binaries),
                              and “kernel”; the sub-components are the
                              individual distribution sets generated as part
                              of the release process (e.g., “src/base”,
                              “src/sys”, “world/base”, “world/catpages”,
                              “kernel/smp”).  Note that prior to FreeBSD 6.1,
                              the “kernel” component was distributed as part
                              of “world/base”.

                              This option can be specified multiple times, and
                              the parameters accumulate.

Also weiß ich jetzt trotzdem nicht, was genau in "Components" stehen müsste.

Und im Handbook steht:

"However, the best option is to leave this at the default as changing it to include specific items requires every needed item to be listed. Over time, this could have disastrous consequences as source code and binaries may become out of sync."

Yamagi schrieb:
Das ist genau der Grund, aus dem DRM mit 15.0 vielleicht ins Basissystem zurückwechseln wird.
Zum Vergrößern anklicken....
Interessante Information. Wo stammt die her? Wäre natürlich super!
 
cabriofahrer schrieb:
Bei einem freebsd-updatewerden bei mir aber keine Sourcen aktualisiert, mein Verzeichnis "/usr/src"
ist leer.
Zum Vergrößern anklicken....
Das ist merkwürdig. Also bei mir:
Code: 
root@freebsd:~ # freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.1-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 19 patches.....10.... done.
Applying patches... done.
The following files will be updated as part of updating to
14.1-RELEASE-p4:
/usr/src/contrib/llvm-project/libcxx/include/string
/usr/src/crypto/openssh/log.c
/usr/src/crypto/openssh/sshd.c
/usr/src/crypto/openssh/version.h
/usr/src/crypto/openssl/crypto/x509/v3_utl.c
/usr/src/sbin/ifconfig/af_inet.c
/usr/src/sys/cam/ctl/ctl.c
/usr/src/sys/cam/ctl/ctl_private.h
/usr/src/sys/conf/newvers.sh
/usr/src/sys/contrib/libnv/bsd_nvpair.c
/usr/src/sys/contrib/libnv/nvlist.c
/usr/src/sys/contrib/openzfs/module/zfs/dbuf.c
/usr/src/sys/fs/nfsclient/nfs_clrpcops.c
/usr/src/sys/kern/kern_ktrace.c
/usr/src/sys/kern/kern_umtx.c
/usr/src/sys/netpfil/pf/pf.c
/usr/src/sys/netpfil/pf/pf_lb.c
/usr/src/usr.bin/calendar/calendar.c
/usr/src/usr.sbin/bhyve/pci_xhci.c
/usr/src/usr.sbin/bhyve/tpm_ppi_qemu.c
(END)
Und ein freebsd-update install hat meine Sourcen aktualisiert. Von daher (als normaler User):
Code: 
shinji@freebsd:~ $ ls /usr/src
bin            crypto            lib            Makefile.inc1        release            share            tools
cddl            etc            libexec            Makefile.libcompat    RELNOTES        stand            UPDATING
contrib            gnu            LOCKS            Makefile.sys.inc    rescue            sys            usr.bin
CONTRIBUTING.md        include            MAINTAINERS        ObsoleteFiles.inc    sbin            targets            usr.sbin
COPYRIGHT        kerberos5        Makefile        README.md        secure            tests
shinji@freebsd:~ $
Meine /etc/freebsd-update.conf sieht so aus:
Code: 
# Trusted keyprint.  Changing this is a Bad Idea unless you've received
# a PGP-signed email from <security-officer@FreeBSD.org> telling you to
# change it and explaining why.
KeyPrint 800651ef4b4c71c27e60786d7b487188970f4b4169cc055784e21eb71d410cc5

# Server or server pool from which to fetch updates.  You can change
# this to point at a specific server if you want, but in most cases
# using a "nearby" server won't provide a measurable improvement in
# performance.
ServerName update.FreeBSD.org

# Components of the base system which should be kept updated.
Components src world kernel

# Example for updating the userland and the kernel source code only:
# Components src/base src/sys world

# Paths which start with anything matching an entry in an IgnorePaths
# statement will be ignored.
IgnorePaths

# Paths which start with anything matching an entry in an IDSIgnorePaths
# statement will be ignored by "freebsd-update IDS".
IDSIgnorePaths /usr/share/man/cat
IDSIgnorePaths /usr/share/man/whatis
IDSIgnorePaths /var/db/locate.database
IDSIgnorePaths /var/log

# Paths which start with anything matching an entry in an UpdateIfUnmodified
# statement will only be updated if the contents of the file have not been
# modified by the user (unless changes are merged; see below).
UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile

# When upgrading to a new FreeBSD release, files which match MergeChanges
# will have any local changes merged into the version from the new release.
MergeChanges /etc/ /boot/device.hints

### Default configuration options:

# Directory in which to store downloaded updates and temporary
# files used by FreeBSD Update.
# WorkDir /var/db/freebsd-update

# Destination to send output of "freebsd-update cron" if an error
# occurs or updates have been downloaded.
# MailTo root

# Is FreeBSD Update allowed to create new files?
# AllowAdd yes

# Is FreeBSD Update allowed to delete files?
# AllowDelete yes

# If the user has modified file ownership, permissions, or flags, should
# FreeBSD Update retain this modified metadata when installing a new version
# of that file?
# KeepModifiedMetadata yes

# When upgrading between releases, should the list of Components be
# read strictly (StrictComponents yes) or merely as a list of components
# which *might* be installed of which FreeBSD Update should figure out
# which actually are installed and upgrade those (StrictComponents no)?
# StrictComponents no

# When installing a new kernel perform a backup of the old one first
# so it is possible to boot the old kernel in case of problems.
# BackupKernel yes

# If BackupKernel is enabled, the backup kernel is saved to this
# directory.
# BackupKernelDir /boot/kernel.old

# When backing up a kernel also back up debug symbol files?
# BackupKernelSymbolFiles no

# Create a new boot environment when installing patches
# CreateBootEnv yes
 
Macke1979 schrieb:
Das ist merkwürdig. Also bei mir:
Zum Vergrößern anklicken....
Danke für die Demonstration. Merkwürdig ist es vielleicht doch nicht, mein System ist seit 9.x upgedated und ich kann mich jetzt erinnern, dass ich irgendwann mal den Inhalt von /usr/src gelöscht habe, weil ich es seit dem Einbau der Nvidia-Karte nie gebraucht habe. Also ist der Eintrag in meiner freebsd-update.conf wohl korrekt, aber wenn das Verzeichnis leer ist, gibt es da wohl nichts upzudaten. Dank Deines Posts weiß ich jetzt, dass es funktionieren würde. Das werde ich dann bei den Rechnern mit AMD GPUs berücksichtigen.

Aus der großen Planungsliste für 15.0: https://hackmd.io/RSKUPQmXSi2XiSiVAYhNjg Alles, was nicht "Done" ist, könnte passieren, muss aber nicht. Mit von oben nach unten abnehmender Wahrscheinlichkeit, je nachdem wo es einsortiert ist
Zum Vergrößern anklicken....
Nun, wenn es mit "90% done" unter "In Progress" steht, wird es wohl so sein.
 
Also ich hab das länger nicht mehr gebaut und derzeit auch gerade keine Radeon in Betrieb, aber abseits von den benötigten 2GB für sources (die sich via git in unter einer Minute aktualisieren lassen sollten und je kürzer dieser Intervall, desto schneller gehts obendrein), dauerte der Bau von drm-kmod auch keine Minute.
Oder übersehe ich gerade was?
 
Geht zwar etwas am Thema vorbei, aber ich werf hier mal poudriere zum Bau von Paketen in den Raum. Damit lässt sich auch einfach der quarterly branch bauen.
 
mr44er schrieb:
dauerte der Bau von drm-kmod auch keine Minute.
Oder übersehe ich gerade was?
Zum Vergrößern anklicken....
Es geht nicht darum, ob der Bau von drm-kmod auf einer neuen Maschine keine Minute dauert oder auf einer älteren etwas länger und auch nicht so sehr um 2GB Speicherplatz und wie schnell die runtergezogen sind (Übrigens wirklich, bei einigen hier genannten Internetgeschwindigkeiten in D?). Es geht einfach darum, dass man manchmal nach einem Upgrade des Systems erstmal einen Kernel Panic bekommen kann und das eben unangenehm ist und man dann hinterher Hand anlegen muss und es offenbar keinen Weg gibt, das im Vorfeld überprüfen zu können.
Zum Thema auch im Zusammenhang mit git habe ich gerade noch das hier gefunden, sehr interessant:

forums.freebsd.org

How to get sources installed and have these updated by freebsd-update(8) after a base-install

At base install time using bsdinstall one can choose to install its sources and these get updated automatically with every patch/minor/major release update/upgrade. If one has choosen not to, is there an after the fact possibility to get the source tree included in such a way that it gets...
forums.freebsd.org forums.freebsd.org

Wenn man also will, dass die Sourcen danach normalerweise mit freebsd-updateaktualisiert werden, muss man dabei wohl auf die Methode achten.
 
cabriofahrer schrieb:
Übrigens wirklich, bei einigen hier genannten Internetgeschwindigkeiten in D?
Zum Vergrößern anklicken....
Der Upload ist gering, der Download ist selten schlecht. Und ich sag ja, wenn man nur das Delta laden muss, eher kein Problem.

cabriofahrer schrieb:
Es geht einfach darum, dass man manchmal nach einem Upgrade des Systems erstmal einen Kernel Panic bekommen
Zum Vergrößern anklicken....
Deswegen ja einfach immer bauen, damit man keine Kernel Panic bekommt. Daher überhaupt den "Mehraufwand" (der das geringere Übel darstellt vs. panic), um das Problem gar nicht erst zu bekommen.

cabriofahrer schrieb:
dass die Sourcen danach normalerweise mit freebsd-update
Zum Vergrößern anklicken....
git.
 
mr44er schrieb:
Deswegen ja einfach immer bauen, damit man keine Kernel Panic bekommt. Daher überhaupt den "Mehraufwand" (der das geringere Übel darstellt vs. panic), um das Problem gar nicht erst zu bekommen.
Zum Vergrößern anklicken....
Dies hat mich jetzt davon überzeugt, meinen Treiber nun doch aus den Ports zu bauen, in diesem Fall habe ich mich für drm-61-kmod entschieden. Das Compilieren hat keine 2 Minuten gedauert und es ist sicher besser, als die Ungewissheit, nach dem nächsten Upgrade eventuell einen Kernel-Panic zu bekommen.
 
Zuletzt bearbeitet:
Wenn man stur nicht bauen will oder 100% safe sein will, könnte man vorm reboot auch einfach die Zeile in rc.conf mit # entschärfen.
Nach dem reboot dann manuell die Kernschmelze riskieren: kldload amdgpu
Man muss nur dran denken. :D (aber nochmal, wenns kracht und scheppert, baut man sowieso)
 
mr44er schrieb:
Wenn man stur nicht bauen will oder 100% safe sein will, könnte man vorm reboot auch einfach die Zeile in rc.conf mit # entschärfen.
Nach dem reboot dann manuell die Kernschmelze riskieren: kldload amdgpu
Man muss nur dran denken. :D (aber nochmal, wenns kracht und scheppert, baut man sowieso)
Zum Vergrößern anklicken....
Nun, das hatte ich ja oben eingangs schon gesagt.
serie300 schrieb:
Lock ggf. Den drm-kmod noch, nicht daß er mit dem nächsten pkg Upgrade überschrieben wird.
Zum Vergrößern anklicken....
Der drm-kmod ist ja nur der Meta-Port, deswegen wird das wohl nichts bringen. Wohl eher drm-515-kmod und die Firmware-Module. Aber bevor ich das mache, kompiliere ich dann doch auch lieber neu.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben