Beiträge von Sauerkraut

Die Option ist bei mir unter NetworkManager | Wi-Fi-Sicherheit > "Passwort für alle Benutzer speichern (unverschlüsselt)" zu finden.

Es wurde auch unter "/etc/NetworkManager/system-connections/" eine Datei angelegt, allerdings ohne den erhofften Effekt. Laufwerke werden nicht eingehängt mit Statusmeldung für die Unit "Network is unreachable".

Sehr geil Stephan, vielen Dank. Ist das bei dir auch mit WLAN-Verbindung?

Das die fstab in eine systemd unit umgewandelt wird, war mir nicht bewusst. Jetzt habe ich folgende Ausgabe (abgetippt)

systemd[1]: Mounting /mnt/nas/laufwerk...
mount[1761]: mount error(101): Network is unreachable
systemd[1]: Failed to mount /mnt/nas/laufwerk

- Das bestätigt, dass das Netz noch nicht da ist, richtig?

- Heißt "unreachable" dass kein Netz gefunden wurde oder dass es mangels erfolgreicher Verbindung nicht erreichbar ist?

- Der Schalter `_netdev` ist vorhanden, wirkt sich aber nicht aus wie erwartet. Vermutlich irgendwas mit systemd?

Die systemd unit-Datei habe ich unter /run/systemd/generator gefunden

[Unit]
Before=remote-fs.target

Before/After steuern also die Reihenfolge, aber ohne Rücksicht auf Status er vorher ausgeführten Einheiten.

Heißt, dass diese Einheit vor "remote-fs.target"[1] aufgerufen werden soll. Allerdings weiß ich jetzt nicht was dieses "target" macht und würde gefühlt annehmen, dass da irgendwas mit "Requires" (eine funktionierende Verbindung zum WLAN) sein sollte?

… ähm ja … ich brauche da deutlich mehr Eier, im Moment sind die klitzeklein.

Zitat von neoghb

[…] Networkmanager […] "für alle Nutzer erlauben" […] Dann verbindet er sich mit dem WLAN, noch bevor sich der Nutzer einloggt. Könnte auch helfen, falls es einfach zu lange dauert bis ein Netzwerk vorhanden ist.

Wird eine Verbindung zum WLAN erst hergestellt wenn man sich einloggt? Moment mal, also während dem ganzen Bootgeraffel, ob mit oder ohne systemd kommt überhaupt keine Verbindung mit dem WLAN zustande? Weil z.b. das Passwort im NetworkManager irgendwo rumeiert und erst der stellt dann die Verbindung damit her wenn sich angemeldet wird?

EDIT: kann systemd-networkd[2] hier helfen?

[1] https://www.freedesktop.org/so…ial.html#remote-fs.target

[2] https://www.freedesktop.org/so…test/systemd.network.html

Schade … das mit dem `_netdev` hat nicht direkt funktioniert. Wenn ich mir die Ausgabe bei booten anzeigen lasse, kommen am Ende zwei oder drei Einträge mit rotem "Failure" oder "Fail" am Anfang. Allerdings sind die halt schnell wieder verschwunden.

Jetzt wollte ich mir die anzeigen lassen

journalctl --boot > bootlog.txt

Aber irgendwie sieht mir das nicht aus wie was da am Bildschirm runter rauscht. Auch mit `journalctl --boot | grep ailed` finde ich jetzt nicht direkt einen Treffer der auf das mounten der Laufwerke hindeutet.

Vor der Problemlösung steht jetzt die Ursachenerkennung. Nur halt wieder nächstes Problem, wo finde ich denn die Dokumentation des Vorgangs?

Ah! Mercy, ich nähere mich an.

Wie ich hier https://linux.die.net/man/8/mount entnehmen kann ist `_netdev` ein Schalter für den `mount` Befehl.

Die Zeile in der fstab sieht so aus.

//192.168.0.252/laufwerk/ /mnt/nas/laufwerk cifs rw,uid=1000,gid=100,user,username=xxx,password=xxx,domain=WORKGROUP,vers=3.0,file_mode=0644,dir_mode=0755 0 0

Die Optionen nach `cifs` beziehen sich auf den Treiber, richtig? Welches sind die Schalter für `mount`, bzw. wo muss das `_netdev` platziert werden?

Hallo Leute,

Situation: Laptop, WLAN, Laufwerke eines NAS sollen beim start eingehängt werden. Aktuell über fstab.

Beobachtung: Die Laufwerke werden beim starten nicht gemountet, lassen sich aber, nachdem die Verbindung mit dem WLAN etabliert ist, per `mount` einhängen.

Vermuteter Grund: Die Verbindung zum WLAN kommt zu spät, also nach dem Lesen der fstab.

Soweit die Lage und ich bin etwas ratlos. Welche Möglichkeiten habe ich, dass die Laufwerke beim start eingehängt werden?

- Script das nach dem hochfahren die Laufwerke einhängt?

- Irgendwas mit systemd? Also Laufwerke nicht per fstab sondern per systemd (das auf die Verbindung mit dem WLAN wartet)?

- … ?

- was ganz anderes?

Vielen Dank.

ciao, Stefan

OK, ich werd es so versuchen. Allerdings erst in ein paar Tagen. Just heute wurden die Quellen bei NVIDIA aktualisiert und die Paket tragen nun den Zusatz "k6.5.3_1" im Namen. Da ich grade auf Kernel 6.5.3-1 war (6.5.4 war blockiert) dachte ich mir ich versuch’s noch mal. Also das Update hat funktioniert. Den Kernel 6.5.4 habe ich dann wieder freigegeben und darauf aktualisiert, in Erwartung danach ein rollback machen zu müssen. War aber nicht so, der Kernel wurde aktualisiert. Wieso konnte ich jetzt den Kernel aktualisieren, obwohl die NVIDIA-Treiber für einen kleinere Version davon gedacht sind? mmmh ja, die Versionsnummern des Kernels und des Treibers sind scheinbar nur bedingt aussagekräftig bezüglich der Kompatibilität.

Danke für die Hilfe, evtl. hinterlasse ich hier noch die eine oder Nachricht falls sich was ergibt.

Schönen Abend noch.

Keine Ahnung! Ich bin der noob

Also wenn ich mich wieder nullen (auf nouveau) möchte, wie genau gehe ich jetzt vor?

1. per zypper alles Pakete entfernen die mit dem NVIDIA Krempel zu tun haben. Also diese

S | Name                      | Type    | Version                  | Arch   | Repository
--+---------------------------+---------+--------------------------+--------+-----------------------
i | kernel-firmware-nvidia    | package | 20230829-1.1             | noarch | Haupt-Repository (OSS)
i | libnvidia-egl-wayland1    | package | 1.1.12-1.2               | x86_64 | Haupt-Repository (OSS)
i | nvidia-computeG05         | package | 470.199.02-57.1          | x86_64 | NVIDIA
i | nvidia-computeG05-32bit   | package | 470.199.02-57.1          | x86_64 | NVIDIA
i | nvidia-gfxG05-kmp-default | package | 470.199.02_k6.5.2_1-57.1 | x86_64 | NVIDIA
i | nvidia-glG05              | package | 470.199.02-57.1          | x86_64 | NVIDIA
i | nvidia-glG05-32bit        | package | 470.199.02-57.1          | x86_64 | NVIDIA
i | x11-video-nvidiaG05       | package | 470.199.02-57.1          | x86_64 | NVIDIA
i | x11-video-nvidiaG05-32bit | package | 470.199.02-57.1          | x86_64 | NVIDIA

2. dann das NVIDIA Repository entfernen

3. dann entferne ich alle nouveau Pakete, ausgenommen das Paket libdrm_nouveau2, also diese

S  | Name               | Summary                                                      | Type
---+--------------------+--------------------------------------------------------------+--------
Behalten i  | libdrm_nouveau2    | Userspace interface for Kernel DRM services for NVIDIA chips | package

Entfernen i  | libvdpau_nouveau   | VDPAU state tracker for Nouveau                              | package
Entfernen i+ | Mesa-dri-nouveau   | Mesa DRI plug-in for 3D acceleration via Nouveau             | package
Entfernen i+ | xf86-video-nouveau | Accelerated Open Source driver for nVidia cards              | package

4. dann enfernen ich die Datei /usr/lib/modprobe.d/nvidia-default.conf, da darin der nouveau geblacklisted ist.

Oder?

Mit den NVIDIA Treibern wurden doch irgendwelche Schlüssel für das secure boot eingesetzt. Wie spielen die dann da rein?

Du hast also nur dieses eine Paket?

Zitat

Allerdings musste ich den xf86-video-nouveau-Treiber deinstallieren

Oh, ich dachte das sei der Treiber … Kannst Du mir mal zeigen welche Pakete Du da installiert hast?

EDIT bei mir sieht es im Moment noch so aus:

S  | Name               | Type    | Version              | Arch   | Repository
---+--------------------+---------+----------------------+--------+-----------------------
i  | libdrm_nouveau2    | package | 2.4.116-1.1          | x86_64 | Haupt-Repository (OSS)
i  | libvdpau_nouveau   | package | 23.1.7-1699.358.pm.3 | x86_64 | (System Packages)
i+ | Mesa-dri-nouveau   | package | 23.1.7-1699.358.pm.3 | x86_64 | (System Packages)
i+ | xf86-video-nouveau | package | 1.0.17-4.5           | x86_64 | Haupt-Repository (OSS)

@matbhm Danke für die Auskunft. Die kernel-Version habe ich von dem Paket nvidia-open-driver-G06-signed-kmp-default Ist das Paket ein "mitrollender" Ersatz für den proprietären Treiber von NIVDIA?

Zitat

Nouveau soll diese Abstürze verursacht haben? Kann ich fast nicht glauben? Hast du den Nouveau selber installiert?

Ja ich hatte da was selbst installiert, wie oben schon geschrieben bin ich mir aber auch nicht 100% sicher welches Paket oder welche Pakete da eigentlich notwendig sind. Das die Abstürze mit nouveau in Verbindung stehen kann ich natürlich nicht mit 100%iger Sicherheit behaupten, es sind mehr Indizien.

1. Mit KSystemLog (Priorität "Kritisch" und "Fehler") bin ich nach so einem crash zur ungefähren Zeit vor dem reboot gescrollt und fand dort Einträge zum Nouveau.

2. Vor dem NVIDIA Treiber ist mehrmals die Woche, mach mal sogar mehrmals am Tag die Kiste abgeraucht und nur noch ein harter Reset geholfen hat. Das ist komplette verschwunden.