Aktuelles

Anfängerfragen - Linux Neuling? Hier ist der richtige Platz für deine Fragen (2)

  • Ersteller Gelöschtes Mitglied 45455
  • Erstellt am

Dani2070

Experte
Mitglied seit
30.06.2013
Beiträge
3.451
Bei Wayland ist die Anwendung über der der Mauszeiger gerade schwebt dafür verantwortlich den selbigen zu zeichen. Ich hatte mit Sway auch schon solche lustigen Effekte.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.

StylusDark

Enthusiast
Mitglied seit
16.11.2010
Beiträge
1.686
Ort
Bayern
Hey Leute, ich hoffe mal hier kann mir geholfen werden:

Code:
Samba is not being run as an AD Domain Controller: Masking samba-ad-dc.service
Please ignore the following error about deb-systemd-helper not finding those services.
(samba-ad-dc.service already masked)
Job for smbd.service failed because the control process exited with error code.
See "systemctl status smbd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript smbd, action "start" failed.
● smbd.service - Samba SMB Daemon
   Loaded: loaded (/lib/systemd/system/smbd.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2021-05-14 04:53:59 CEST; 17ms ago
     Docs: man:smbd(8)
           man:samba(7)
           man:smb.conf(5)
  Process: 6066 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS)
  Process: 6082 ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS (code=exited, status=1/FAILURE)
 Main PID: 6082 (code=exited, status=1/FAILURE)

May 14 04:53:58 pve systemd[1]: Starting Samba SMB Daemon...
May 14 04:53:59 pve systemd[1]: smbd.service: Main process exited, code=exited, status=1/FAILURE
May 14 04:53:59 pve systemd[1]: smbd.service: Failed with result 'exit-code'.
May 14 04:53:59 pve systemd[1]: Failed to start Samba SMB Daemon.
dpkg: error processing package samba (--configure):
 installed samba package post-installation script subprocess returned error exit status 1
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
 samba
E: Sub-process /usr/bin/dpkg returned an error code (1)

Ich habe einfach versucht samba auf einem Debian zu installieren und irgendwie ist es total in die Hose gegangen ...

Hab schon autoclean / clean und purge + neuinstallation versucht. Irgendwie hilft nix :(
 

Elmario

Urgestein
Mitglied seit
21.01.2006
Beiträge
5.061
Hallo!
Versuche mal samba direkt zu starten, ohne service und mit mehr verbosity:
Code:
smbd -d=10
Das sollte die nötige Information liefern, was schief geht.
 
Zuletzt bearbeitet:

Fallwrrk

Enthusiast
Mitglied seit
11.12.2011
Beiträge
5.447
Ort
NRW
Swap ist immer nice to have. Mit dem Dateisystem hat das nichts zu tun (außer du nutzt ZFS).
 

fax668

Experte
Mitglied seit
08.06.2015
Beiträge
1.692
Ich habe das (unabhängig vom Dateisystem) heutzutage eigentlich gar nicht mehr auf meinen Systemen. Wer Suspend to Disk machen will, kann das noch brauchen. Ansonsten wird meiner Erfahrung nach ein System, das anfängt zu swappen, so langsam, dass es ohnehin nicht mehr brauchbar ist. Da lasse ich lieber ein paar Prozesse gleich sterben und fahre das System kontrolliert runter oder beende den Prozess, der zu viel Speicher benutzt.
 

Liesel Weppen

Experte
Mitglied seit
20.07.2017
Beiträge
3.515
Ich habe das (unabhängig vom Dateisystem) heutzutage eigentlich gar nicht mehr auf meinen Systemen. Wer Suspend to Disk machen will, kann das noch brauchen. Ansonsten wird meiner Erfahrung nach ein System, das anfängt zu swappen, so langsam, dass es ohnehin nicht mehr brauchbar ist. Da lasse ich lieber ein paar Prozesse gleich sterben und fahre das System kontrolliert runter oder beende den Prozess, der zu viel Speicher benutzt.
Ich hatte auch schon Fälle, wo es mir lieber war, wenn ein Programm wegen out-of-Memory abstürzt, statt das da dann massiv rumgeswappt wird. Das taugt aber meiner Erfahrung nach nur, wenn du mehr oder weniger einen oder nur wenige Prozesse hast, die sehr viel RAM brauchen. In einer echten Multitaskinganwendung wirds damit aber oft sehr kompliziert.
Zudem werden zunächst erstmal verzichtbare Teile aus dem RAM in den Swap verlagert, kommen aber aus dem Swap schneller zurück, wenn wieder RAM frei wird.
Und zudem schadet es (mit halbwegs modernen Betriebssystemen) nicht, wenn Swap vorhanden ist.

Suspend-to-Disk hat damit überhaupt nichts zu tun. Sowohl Windows als auch Linux benutzen für STD nicht irgendwelche Swapfiles/-partitionen sondern was für STD dediziertes. Iirc ist es unter Windows die hyberfil.sys direkt auf C (wenn man da nicht manuell was geändert hat) während der Swap idR c:\pagefile.sys ist. Das liegt auch schlicht und einfach daran, das das Pagefile überhaupt nichts damit zu tun hat, wieviel RAM man im System hat, während das STD-File exakt so groß ist, wie man eben RAM im System hat. Bei 32GB RAM hat man also unter Windows auch schonmal immer eine 32GB große Datei auf der Platte liegen, solange man Hibernate nicht deaktiviert.
 

fax668

Experte
Mitglied seit
08.06.2015
Beiträge
1.692
Zudem werden zunächst erstmal verzichtbare Teile aus dem RAM in den Swap verlagert, kommen aber aus dem Swap schneller zurück, wenn wieder RAM frei wird.
Du hast offenbar noch nicht erlebt, wie das ist, wenn jeder Tastendruck mehrere Minuten braucht.

Suspend-to-Disk hat damit überhaupt nichts zu tun. Sowohl Windows als auch Linux benutzen für STD nicht irgendwelche Swapfiles/-partitionen sondern was für STD dediziertes. >8>8>8 Vollkommen irrelevante Ausführungen zu Windows gelöscht 8<8<8<
Was Linux betrifft, täuscht du dich: https://legacy.thomas-leister.de/arch-linux-suspend-disk-hibernate-einrichten/

Swap auf alle Fälle. Entweder als Partition oder Swap-File. Sonst gibt es bei manchen Programmen Performanceprobleme.
Was sollen denn das für Programme sein?
 

1701

Semiprofi
Mitglied seit
20.05.2021
Beiträge
53
Ort
Kobol
Fedora swappt inzwischen auf zram, das wäre vielleicht eine Alternative für den einen oder anderen.
 

Elmario

Urgestein
Mitglied seit
21.01.2006
Beiträge
5.061
Na, wenn's nicht mehr als bsdtar ist, kann man ja auch GNU tar verwenden ;)
 

Ape11

Urgestein
Mitglied seit
05.12.2010
Beiträge
6.792
Na, wenn's nicht mehr als bsdtar ist, kann man ja auch GNU tar verwenden ;)
bsdtar ist für Arch und wahrscheinlich auch für Manjaro relevant - genauer gesagt AUR bzw. Entpacken von Quellcode. ;) Welche anderen Programme betroffen sein könnten, habe ich bisher nicht getestet und auch keine Lust dazu.
Wer so sehr Angst davor hat, dass sein System durch Einsatz vom Swap lahm wird, kann die swappiness auch auf 10 oder niedriger stellen.
 

King Loui

Banned
Mitglied seit
12.02.2017
Beiträge
235
Der Eintrag meines Manjaros im UEFI ist verschwunden, nachdem ich den Datenträger vom System getrennt hatte, um den Bootmanager eines Windows zu reparieren.
Manajro ist zwar weiterhin bootfähig mit SuperGrub, aber
Code:
efibootmgr
bestätigt mir, dass der Eintrag fehlt. Nach ein wenig suchen bin ich im Arch-Wiki gelandet. Die Option --disk kann ich 1 zu 1 übernehmen, weil /boot/efi als source auch bei mir /dev/nvme0n1p1 ist. Aber was soll ich als --loader in den Befehl schreiben? /EFI/refind/refind_x64.efi finde ich eher verwirrend den hilfreich.
 

Elmario

Urgestein
Mitglied seit
21.01.2006
Beiträge
5.061
Ich habe ja UEFI nach wie vor auf jedem Gerät deaktiviert und kenne daher diese Details nicht.. aber kann man das nicht einfach per "update-grub" automatisch beheben? (Aus dem laufenden OS von supergrub gebootet oder per chroot-Methode..)
 

King Loui

Banned
Mitglied seit
12.02.2017
Beiträge
235
Das habe ich tatsächlich auch gedacht und ausprobiert, sogar grub komplett neu installiert, aber es legt dummerweise diesen Eintrag nicht automatisch an :cautious:
 

Elmario

Urgestein
Mitglied seit
21.01.2006
Beiträge
5.061
Hm.. also dem hier nach sollten dieses File bei Manjaro wohl "bootx64.efi" heißen und in /boot/efi liegen. Keine Ahnung, ob das für UEFI vielleicht dann als /EFI/ geschrieben werden muss, weil UEFI ja sowieso schon innerhalb der Partition (also innerhalb von /boot) sucht.
Probier doch mal aus:
Code:
--loader /boot/efi/bootx64.efi
oder:
Code:
--loader /EFI/bootx64.efi
oder gar:
Code:
--loader /EFI/boot/efi/bootx64.efi
Andersits wird auf der Manjaroseite dieses File gar nicht direkt angegeben, sondern nur das Verzeichnis:
Code:
"sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck"

Also wäre auch das noch eine Option :)
 
Zuletzt bearbeitet:

King Loui

Banned
Mitglied seit
12.02.2017
Beiträge
235
Andersits wird auf der Manjaroseite dieses File gar nicht direkt angegeben, sondern nur das Verzeichnis:
Code:
"sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck"

Also wäre auch das noch eine Option :)

Das hat bestens funktioniert! Der Eintrag wurde korrekt angelegt und die Kiste lädt den Grub Begrüßungsbildschirm von Manjaro.
Besten Dank!
 

Louisiana

Experte
Mitglied seit
16.11.2019
Beiträge
2.895
Ort
New Orleans
Hi, bis eben wusste ich nicht mal, das wir hier ein Linux Sub haben :)

Folgendes Problem:
Ich möchte Zwei Befehle bei jedem Neustart ausgeführt haben, allerdings ist das über /etc/rc.local nicht möglich.
Die Verwendete Linux Distri ist Volumio, das auf Debian basiert, wenn ich mich nicht irre, und dort geht das leider seit der neusten Version nicht mehr.

Soweit ich das nun mitbekommen habe, wäre die einfachste Lösung einen Cronjob zu erstellen?
Allerdings mache ich da irgendwas falsch, denn passieren tut nichts.

Ich habe mir Uhubctl installiert - https://github.com/mvp/uhubctl und möchte nun das nach jedem Neustart der folgende Befehl ausgeführt wird:
sudo ./uhubctl -l 1-1 -p 2 -a off

Der Pfad zu Uhubctl sollte dieser sein: /usr/sbin/uhubctl

Weiterhin möchte ich, das nach dem Neustart dies ausgeführt wird:
sudo /opt/vc/bin/tvservice -o

All meine bisherigen Versuche sind leider gescheitert, ich muss aber dazu sagen, dass ich von Linux so sehr wenig Ahnung habe.
Die meisten meiner Probleme konnte ich dank Google lösen, aber an den oben genannten scheiter ich kläglich.

Denke mal, dass es für jemanden der sich mit Linux auskennt eine Lachnummer ist?
 

Elmario

Urgestein
Mitglied seit
21.01.2006
Beiträge
5.061
Hallo!

Bei Cron dürfte es sich meistens um Probleme mit Nutzerrrechten handeln.
1. Der Pfade "./uhubctl" macht so wohl auch nicht viel Sinn, weil uhubctl wahrscheinlich nicht im aktuellen Directory liegt. Hast du uhubctl erfolgreich kompliliert und per "sudo make install" installiert?
Danach tippe mal "which uhubctl" und du siehst, wo es wirklich liegt (den ganzen Pfad). (Korrekt sollte es wohl /usr/sbin/uhubctl sein).

2. Hast du udev erfolgreich angepasst, so dass uhubctl ohne root und ohne sudo läuft?
3. Wie sahen denn deine bisherigen Versuche aus?
 
Zuletzt bearbeitet:

Louisiana

Experte
Mitglied seit
16.11.2019
Beiträge
2.895
Ort
New Orleans
@Elmario

Vielen Dank schon mal für Deine Antwort.
sudo make install habe ich in der Tat vergessen, nachdem ich das ausgefährt habe, kasm in der Konsole folgendes zurück:

volumio@audiophonics:~/uhubctl$ sudo make install install -m 755 -d /usr/sbin install -m 755 uhubctl /usr/sbin

Wenn ich per cd uhubctl in das Verzeichniss wechsele, kann ich eben mit sudo ./uhubctl -l 1-1 -p 2 -a off wunderbar die Ports abschalten.


So sieht die Abfrage aus: sudo uhubctl, welche dieses Ergebniss bringt:

volumio@audiophonics:~$ cd uhubctl volumio@audiophonics:~/uhubctl$ sudo uhubctl [sudo] password for volumio: Current status for hub 1-1.1 [0424:2514, USB 2.00, 3 ports, ppps] Port 1: 0503 power highspeed enable connect [0424:7800] Port 2: 0100 power Port 3: 0100 power Current status for hub 1-1 [0424:2514, USB 2.00, 4 ports, ppps] Port 1: 0503 power highspeed enable connect [0424:2514, USB 2.00, 3 ports, ppps] Port 2: 0100 power Port 3: 0100 power Port 4: 0100 power Current status for hub 1 [1d6b:0002 Linux 4.19.118-v7+ dwc_otg_hcd DWC OTG Controller 3f980000.usb, USB 2.00, 1 ports, ppps] Port 1: 0503 power highspeed enable connect [0424:2514, USB 2.00, 4 ports, ppps]

Ausserdem kann ich, wenn ich mich in dem uhubctl Verzeichnich befinde so: sudo uhubctl -l 1-1 -p 2 -a off die Ports ausschalten.
Ergebniss:

volumio@audiophonics:~/uhubctl$ sudo uhubctl -l 1-1 -p 2 -a off Current status for hub 1-1 [0424:2514, USB 2.00, 4 ports, ppps] Port 2: 0100 power Sent power off request New status for hub 1-1 [0424:2514, USB 2.00, 4 ports, ppps] Port 2: 0000 off

Das ganze mag ich aber natürlich nicht bei jedem Neustart machen, sondern es eben automatisieren.

Versucht habe ich es so, aber bitte nicht lachen, ich habe wie gesagt keine Ahnung :d

Per: sudo nano /lib/systemd/system/Shutoff.service habe ich diese erstellt:

[Unit] Description=My Shut Off USB Service After=multi-user.target [Service] Type=idle ExecStart=sudo uhubctl -l 1-1 -p 2 -a off [Install] WantedBy=multi-user.target

Im Nano Editor dann mit Ctrl + o geschrieben, und dann mit Ctrl und X verlassen.

Danach die Rechte angepasst und aktiviert:

sudo chmod 644 /lib/systemd/system/Shutoff.service sudo systemctl enable Shutoff.service

Passiert aber leider nichts...
 

Elmario

Urgestein
Mitglied seit
21.01.2006
Beiträge
5.061
Es ist wichtig, dass man sich im Klaren ist, ob man ein Boot-Kommando als user (und als welcher) ausführen möchte, oder als root, weil es abhängig davon Unterschiede gibt wie das Kommando auszuführen ist, und viele Dinge auch nur als das Eine oder das Andere funktionieren. Es gibt kaum was Ekligeres, als in Boot-Skripten mit sudo usw. herumexperimentieren zu müssen. Vorzuziehen ist natürlich die Verwendung als einfacher Nutzer (also nicht Root), um nicht unnötig die Anzahl der Sicherheitslücken zu erhöhen. Auch kann es die spätere Benutzung vereinfachen.

Nach der eigentlichen Installation "sudo make install" sollte es nicht mehr nötig sein, uhubctl aus dem Build-Verzeichnis zu starten.
Es sollte nun also aus jedem Verzeichnis heraus per "sudo uhubctl" funktionieren". OK soweit?
Das nächste Ziel ist nun, auch das "sudo" einsparen zu können und uhubctl einfach als Nutzer auszuführen. Dazu führe mal den Abschnitt "Linux USB permissions" durch.
Erfolgreich warst du, wenn du aus jedem beliebigen Verzeichnis uhubctl ohne sudo ausführen kannst. Danach geht's dann erst weiter mit der Boot-Ausführung des Kommandos als einfacher User.
 

1701

Semiprofi
Mitglied seit
20.05.2021
Beiträge
53
Ort
Kobol
Sagt "systemctl status Shutoff.service" irgendwas brauchbares? sudo brauchst du nicht, da das so sowieso als root ausgeführt wird. Versuch es mal mit dem vollständigen Pfad zu uhubctl.

Selbst erstellte Systemd Units gehören afaik in /etc/systemd/system, wobei das mit deinem Problem nichts zu tun haben wird.
 

Louisiana

Experte
Mitglied seit
16.11.2019
Beiträge
2.895
Ort
New Orleans
Es ist wichtig, dass man sich im Klaren ist, ob man ein Boot-Kommando als user (und als welcher) ausführen möchte, oder als root, weil es abhängig davon Unterschiede gibt wie das Kommando auszuführen ist, und viele Dinge auch nur als das Eine oder das Andere funktionieren. Es gibt kaum was Ekligeres, als in Boot-Skripten mit sudo usw. herumexperimentieren zu müssen. Vorzuziehen ist natürlich die Verwendung als einfacher Nutzer (also nicht Root), um nicht unnötig die Anzahl der Sicherheitslücken zu erhöhen. Auch kann es die spätere Benutzung vereinfachen.
Eventuell sollte ich erwähnen, dass ich für gewöhnlich nicht mit Linux arbeite, und das auch so gesehen nicht vorhabe.
In meinem Fall geht es darum, Volumio auf einem Raspberry Pi 3B+ anzupassen.
Aber dennoch danke für den Tipp. :)

Nach der eigentlichen Installation "sudo make install" sollte es nicht mehr nötig sein, uhubctl aus dem Build-Verzeichnis zu starten.
Es sollte nun also aus jedem Verzeichnis heraus per "sudo uhubctl" funktionieren". OK soweit?

Das funktioniert nun einwandfrei, ich kann aus jedem beliebigen Verzeichnis heraus sudo uhubctl ausführen.
Das nächste Ziel ist nun, auch das "sudo" einsparen zu können und uhubctl einfach als Nutzer auszuführen. Dazu führe mal den Abschnitt "Linux USB permissions" durch.
Linux USB permissions?
Das sagt mir jetzt wierrum gar nichts.

Sagt "systemctl status Shutoff.service" irgendwas brauchbares? sudo brauchst du nicht, da das so sowieso als root ausgeführt wird. Versuch es mal mit dem vollständigen Pfad zu uhubctl.
Sagt:
volumio@audiophonics:~$ systemctl status Shutoff.service
● Shutoff.service - My Shut Off USB Service
Loaded: error (Reason: Invalid argument)
Active: inactive (dead)

Ok, Invalid Argument ist klar, dann sollte mein Fehler wohl nur da liegen...
 

Louisiana

Experte
Mitglied seit
16.11.2019
Beiträge
2.895
Ort
New Orleans
Ok, jetzt sehe ich das auch.
Aber ganz ehrlich, da führt eines zum anderen.
Replace 2001 with your vendorID...
Was ist denn eine Vendor ID?

Ich wollte es jetzt nicht unbedingt zur Wissenschaft machen, zumal ich - wenn einmal eingerichtet - es nicht mehr brauchen werde, und somit mit Sicherheit schnell wieder vergessen habe.

Ich hab nun versucht, der Einfachheit halber, es mit crontab -e zu lösen - @Reboot /home/volumio/uhubctl sudo uhubctl -l 1-1 -p 2 -a off

Geht auch nicht.
Liegt wahrscheinlich daran, dass ich irgendein falsches Verzeichnis angegeben habe, aber da geht es ja schon los... Der Pi läuft Headless, was im Alltäglichen Betrieb wunderbar funktioniert, da ich meine Musik per Volumio App steure, um nun aber durch Verzeichnisse zu naviegieren, oder gar zu suchen, wo uhubctl liegt, kann ich leider nicht mal eben einen Explorere öffenen und suchen, ich muss alles mit Konsole machen, wobei ich aber leider die Befehle nicht kenne...

Leider fehlt es mir aber an Zeit und Muse, um mal eben noch mal die Feinheiten eines Linux Systems zu lernen, ich habe es mir leichter vorgestellt, dann müssen die Ports eben anbleiben.
 

Louisiana

Experte
Mitglied seit
16.11.2019
Beiträge
2.895
Ort
New Orleans
Erfolgreich warst du, wenn du aus jedem beliebigen Verzeichnis uhubctl ohne sudo ausführen kannst. Danach geht's dann erst weiter mit der Boot-Ausführung des Kommandos als einfacher User.
Da es mir doch keine Ruhe lässt, habe ich es nun zumindest so geregelt, dass ich bei "sudo" kein Passwort mehr eingeben muss.

Nachtrag:
Ich habe es gelöst bekommen :)

crontab -e

dann wie folgt:

@reboot sudo uhubctl -l 1-1 -p 2 -a off

einfacher geht es wohl nicht :d

Eventuell lese ich mich doch mal tiefer in die Materie ein, aber jetzt dann zumindest ohne Zwang.
 
Zuletzt bearbeitet:

Strikeeagle1977

Experte
Mitglied seit
02.09.2019
Beiträge
1.367
Ort
42xxx, wo die U-Bahn an der Decke hängt
Leider finde ich auf die schnelle nichts dazu im Netz oder in den bekannten großen Foren.

Wir der Intel Intel Gigabit CT Desktop Adapter von Linux Mint mit Kernel 5.4 anstandslos erkannt? Müsste ein Intel Chip Intel® 82574 L sein.

Gerne auch Hilfe zur Selbsthilfe, wenn es zuverlässige Quellen und Datenbanken gibt, wo ich so etwas gut recherchieren kann.

Hintergrund ist ein AMD B550 Board, welches aber den RTL8125 verbaut hat. Bekanntlich wird der noch nicht sauber in 5.4 versorgt und mangels PCI Slot muss ich mir ne PCIe Karte kaufen. mit Kernel 5.11. soll Support bereits drin sein, aber ohne LAN oder Wlan kein Kernelupgrade.
Broadcom wäre für mich Nr.1 weil diese angeblich anstandslos voLinux unterstützt werden, aber bevor ich nen billige RTL8111H neu kaufe, könnte ich günstig an die Intel Karte kommen.
 
Zuletzt bearbeitet:
Oben Unten