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

  • Ersteller Gelöschtes Mitglied 45455
  • Erstellt am
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?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Fedora swappt inzwischen auf zram, das wäre vielleicht eine Alternative für den einen oder anderen.
 
Na, wenn's nicht mehr als bsdtar ist, kann man ja auch GNU tar verwenden ;)
 
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.
 
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.
 
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..)
 
Das habe ich tatsächlich auch gedacht und ausprobiert, sogar grub komplett neu installiert, aber es legt dummerweise diesen Eintrag nicht automatisch an :cautious:
 
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:
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!
 
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?
 
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:
@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...
 
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.
 
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.
 
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...
 
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.
 
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:
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:
leider keine chance. Hab das ganze ohne WWW Zugang versucht und nicht zum laufen bekommen.
Bester Weg scheint, den Kernel auf 5.11 zu bringen , denn da ist die Unterstützung mit drin.

Gibt es keine Liste die zuverlässig die Hardwareunterstützung für Kernel 5.4 darlegt?
 
Nach einer fixen Google Suche nach kernel "5.4" 82574l gabs nen paar interessante Treffer.
Ich habe jetzt nur quer gelesen, würde allerdings eher davon ausgehen das es irgendwie ab 5.4.11 funktioniert, aber sauber erst ab Kernel 5.5.
Der e1000e Treiber der dafür zuständig zeichnet war anfangs etwas hakelig.

EDIT
Fall es von Interesse ist:

Ganz vergessen, aber seit zwei Tagen verteilt Ubuntu 20.04 den 5.11 im HWE Paket :)
 
Zuletzt bearbeitet:
Ich habe eine 256GB SDD mit einem Btrfs welches ich nutze um regelmäßig Snapshots anzulegen und habe darauf auch noch ausreichend freien Speicher. Als ich letztens mal das Tool Filelight bemüht habe ist mir etwas interessantes aufgefallen:

Snapshots.png


Die Anzahl der Snapshots werden schon richtig dargestellt, aber die Größe von fast 1TB ist schon faktisch unmöglich. Was macht Filelight da?
 
Die Anzahl der Snapshots werden schon richtig dargestellt, aber die Größe von fast 1TB ist schon faktisch unmöglich. Was macht Filelight da?
Vermutlich wird das die Snapshots einfach als normale Ordner sehen und das dann effektiv mehrfach zählen. Mit Snapshots und ähnlichem haben viele Programme solche Probleme.
 
Filelight kann nicht separieren welche Dateien in mehreren Snapshots sind (und damit eigentlich nur 1-fach Speicherplatz belegen) und welche nicht. Und selbst wenn er es könnte, es wäre darstellungstechnisch schwierig. Somit verdoppelt sich der von Filelight angezeigte belegte Speicher beim ersten Snapshot, verdreifacht sich beim zweiten und so weiter. Wenn du auf Btrfs Kompression aktivierst, wird das Problem noch lustiger.
 
Hallo liebe Leute,

ich versuche es mal hier - kann eventuell sein das ich einen eigenen Thread dazu eröffnen muss/sollte ...

Ich würde mich als halbwegs erfahrenen, durchschnittlichen Benutzer bezeichnen der auch bereit ist etwas zu "lernen" (aber kein Pro). Dank diverser Seiten/Anleitungen würde ich es mir zu trauen Archlinux zu verwenden.
Gerne würde ich W10 (W11) beiseite lassen und komplett zu Linux wechseln.
Jetzt zu meiner/meinen Fragen.
Kann man bei meinem (durchschnittlichen) Wissenstand Archlinux verwenden und damit arbeiten (ich habe schon einige male Ubuntu, Mint usw. verwendet, aber nie auf lange Zeit).
Ich werde hauptsächlich Office, QGIS verwenden. Streaming dienste wie Netflix, Amazon usw. sollten ja ohne Probleme laufen.
Affinity dürfte vermutlich nicht mehr ganz so einfach zu verwenden sein, oder?
Meine Hardware reicht für meine Anforderungen voll und ganz (Dell XPS2720; CPU i7 4790S).
Mit Mint hatte ich das Problem dass ich keine Auflösung höher 1920x1080 verwenden konnte - mein Monitor hat eine Auflösung von 2560x1440; ist die Auflösung in Archlinux möglich (sollte ja kein Problem darstellen, oder?).
Muss ich mit Treiberproblemen rechnen. Mein PC ist bald 10 Jahre alt.

Mir ist klar das meine Fragen ein wenig "viel" sind aber wenn mir erfahrene Benutzer ein wenig aus ihren Erfahrungen berichten können dann kann ich eventuell besser einordnen ob das Vorhaben für mich überhaupt realistisch ist oder eben nicht ...

Vielen Dank & LG
 
Ich bin vor gut 1 1/2 Jahren mit Manjaro KDE in das kalte Linuxwasser gesprungen, mittlerweile taxiere ich einen Umzug auf ein reines Arch. Ich wollte keine zu steile Lernkurve, sondern einfaches learning-by-doing, das hat ganz gut funktioniert. Als Neuling würde ich definitiv ein Arch-Derivat wie Manjaro oder zumindest eins mit grafischen Installer wie EndeavourOS empfehlen. Ich würde ja sagen, dass Arch einfach zu lernen ist, aber ich habe mich nie wirklich mit anderen Linuxfamilien auseinandergesetzt, daher kann ich das schlecht bewerten. Das Arch-Wiki ist aber erste Sahne!
Ansonsten mache ich damit fast genau dasselbe wie zuvor auf Windows auch, man muss sich teils nur andere Ansätze suchen und verstehen, dass Linux kein Windows ist.
Mein 4930k auf einem RIVE ist auch nicht mehr der jüngste, ebenso hat mein Monitor eine Auflösung von 2560x1440. Meine nv Karte hat ganz schön gezickt im Dual-Monitor Betrieb, das habe ich dann aber aufgelöst und anders umgesetzt, seither ist Ruhe.
Was die Anwendungen angeht würde ich mal ins Arch Repository schauen, Office mit diversen Anwendungen (Libre, Only, Free) ist kein Problem, QGIS gibt es als Flatpak (läuft also auf jedem Linux), nur Streaming geht soweit ich weiß nur in 720p, aber da kann ich schlecht was zu sagen da ich das nicht nutze.
€: Zumindest für Netflix gibt es was bei Snapcraft.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh