Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
26.01.2021, 07:00:43

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
  • Mitglieder insgesamt: 25145
  • Letzte: Mike-Kiel
Statistiken
  • Beiträge insgesamt: 711067
  • Themen insgesamt: 57475
  • Heute online: 428
  • Am meisten online: 2287
  • (22.01.2020, 19:20:24)
Benutzer Online

Autor Thema:  LM19Mate Installation in Aktualisierungsverwaltung dauert SEHR lange?  (Gelesen 1556 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

PS: Funktioniert einwandfrei unter LM 19.1 Cinnamon 64Bit
Garantiert?
Miit solchen generalisierten Aussagen wäre ich vorsichtig.

Von "garantiert" hatte ich nirgends etwas geschrieben und somit auch nicht generalisiert.
Jedenfalls halte ich es für eine relevante Information, dass der Ruhezustand im Prinzip (und konkret bei meiner Konfig.) funktionieren kann (es gab da nämlich auch Antworten, die Vorbehalte erwähnten).
Zitat
Außerdem was hat jetzt der Ruhezustand (Suspend) mit "LM19Mate Installation in Aktualisierungsverwaltung dauert SEHR lange?" zu tun?
Die TE hatte ausdrücklich nach der Notwendigkeit einer Swap-Partition gefragt. Daraufhin wurde ihr von ehtron geantwortet, dass "eine swap in etwas grösser als ram, für  hibernate (ruhezustand)" benötigt wird.
Insofern scheint mir die Relevanz geklärt, insbesondere, als die TE bei einer von dir vorgeschlagenen Neuinstallation nun fundiert entscheiden kann, ob sich fürf sie die Einrichtung einer Swap-Partition lohnt.

qt-doublecmd, den ich installiert hatte.
Ist sicher nicht optimal, weil zu MATE das entsprechende *-gtk Paket gehört.
Qt (KDE) und GTK+ (Xfce, MATE, Cinnamon) sind zwei verschiedene Desktop-Grundlagen, die nicht immer perfekt zusammen passen.

@ Parmenides
Bei einer Neuinstallation sind wir ja noch nicht angekommen.
Klar, dabei stellen sich sicher noch weitere Fragen.
Wäre dann aber besser Anlass für ein neues Thema.

Dieses Gewese um den Swap ist mir persönlich zu aufgeblasen, weil meine Erfahrung ist, dass Ruhezustand (sogar manchmal Standby) bei Linux nicht immer zuverlässig funktioniert, auch wenn eine ausreichend große Partition (bzw. RAM) dafür vorhanden ist.
Deshalb verzichte ich darauf.
Mit einer SSD hat man den Rechner schnell heruntergefahren und einen flotten Neustart zur Verfügung. Unterm Strich oft schneller als sich mit irgendwelchen Macken nach Suspend herumzuschlagen.
Die GBs für die Swap-Partition gebe ich lieber der Platte als freien Speicherplatz.
« Letzte Änderung: 04.03.2019, 17:56:45 von aexe »

Off-Topic:
Dieses Gewese um den Swap ist mir persönlich zu aufgeblasen, weil meine Erfahrung ist, dass Ruhezustand (sogar manchmal Standby) bei Linux nicht immer zuverlässig funktioniert (...)
Wie gesagt, meine Erfahrung ist, dass beides ganz prima funktioniert. Auf meinem eigenen PC mag die ziemlich abgehangene Hardware von Vorteil sein. Aber auch auf einem recht aktuellen PC eines Freundes, dem ich LM 19.1 Cinnamon installiert habe, gibt es keine Probleme mit Ruhe- od. Bereitschaftszustand.
Ich finde es jedenfalls ziemlich nützlich und möchte keines von beiden missen.

Mit LM19 war der Ruhezustand ja leider entfallen. Da war ich froh, hier aus dem Forum die notwendige Unterstützung zu erhalten, wie man einen funktionierenden Ruhezustand zustande bringt.

Tja, wer lesen kann, ist klar im Vorteil, nun also nochmal im LifeSystem geguggt. Freundlicherweise funktioniert beim 19.1er-Stick zwar das WLAN, aber beim inxi-Befehl hat es sich genau wie vorher ebenfalls wieder aufgehängt :(

Aber sudo parted --list ergibt:

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

mint@mint:~$ sudo parted --list
Model: ATA WDC WD10SPZX-21Z (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size   Type     File system  Flags
 1      1049kB  738GB   738GB  primary  ntfs
 2      738GB   1000GB  262GB  primary  ext4


Warning: The driver descriptor says the physical block size is 2048 bytes, but
Linux says it is 512 bytes.
Ignore/Cancel? i                                                         
Model: Generic Flash Disk (scsi)
Disk /dev/sdb: 16.1GB
Sector size (logical/physical): 2048B/512B
Partition Table: mac
Disk Flags:

Number  Start   End     Size    File system  Name   Flags
 1      2048B   6143B   4096B                Apple
 2      2023MB  2025MB  2392kB               EFI


Model: INTEL SSDPEKKW256G8 (nvme)
Disk /dev/nvme0n1: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name                  Flags
 1      1049kB  538MB   537MB   fat32           EFI System Partition  boot, esp
 2      538MB   70.0GB  69.5GB  ext4
 3      70.0GB  77.1GB  7068MB  linux-swap(v1)  swap
 4      77.1GB  147GB   69.4GB  ext4            test
 5      147GB   181GB   34.2GB  ext4            daham
 6      181GB   256GB   75.3GB  ext4            sicher

mint@mint:~$

Die Warnung bezieht sich auf den Stick?
Die SSD-Partititionen sind:
2=LM19 / 4 = LM19.1 / 5 = home-Partition zu 4 / 6 = sicher-Partition für Timeshift.

Hilft das irgendwie weiter? *ratlosgugg*

Eine Home-Partition für zwei verschiedene Systeme würde ich nicht machen.
Kann aber daher auch nicht sicher sagen, ob das mit den aktuellen Problemen zu tun hat, falls das überhaupt der Fall sein sollte?
Ich lass /home immer auf der jeweiligen Systempartition und verwende für meine eigenen Daten (Bilder, Musik, Videos usw) eine reine Datenpartition, ohne die Konfigurationen (Dot-Files = Verzeichnisse und Dateien mit vorangestelltem Punkt). Die kommen dort höchstens mal als vorübergehende Sicherung hin.

Du könntest noch überprüfen, ob die UUIDs der Partitionen in der Datei (/media/mint/…)/etc/fstab korrekt sind. Vergleichen mit blkid
Die Warnung bezieht sich auf den Stick
Ja. Nicht wichtig.

Edit
Evtl noch mit GParted auf dem Live-System die Partitionen (Dateisysteme) auf den internen Platten überprüfen.

Sonst fällt mir im Moment nichts mehr ein.
« Letzte Änderung: 04.03.2019, 21:20:02 von aexe »

so langsam komm ich in den "Echtbetrieb" und frage mich selber, ob das wirklich nötig war/ist mit der extra home-Partition, da ich meine Dateien sowieso alle auf der daten-partition der HDD ablege. wie du schon sagst, liegen im home-verzeichnis eher mal Zwischenlagerungen, Ausprobiersachen, sowas eben. Da überleg ich also noch; bei der lm19-installation hab ich aber keine eigene home-Partition, das war ja die allererste (bzw. der damals letzte verzweifelte Versuch) mach-alles-platt-und-linux-drauf-installation.

Was das Runterfahr-Problem angeht, da hab ich mir ein Herz gefasst und statt des voreingestellten x-server-Treibers den "empfohlenen" nvidia-Treiber gewählt.
*hüstel*
unglaublich, wie schnell das Laptop runterfährt. Und dann auch wirklich AUS ist. Also: so richtig! Wow ...  :o

Somit also zumindest _dieses_ Problem gelöst. Ob sich die Sache mit dem Einfriern damit auch erledigt hat, kann ich allerdings noch nicht sagen...

Bis dahin schon mal vielen Dank an alle!

Na prima! Nvidia!  :'(
Für weitere Überlegungen wäre auf jeden Fall mal ein inxi -Fz nicht schlecht.
Wenn das nicht geht, stimmt was nicht.

Das funktioniert jetzt auch ohne Probleme:

unsers@nitro:~$ inxi -Fz
System:
  Host: nitro Kernel: 4.15.0-45-generic x86_64 bits: 64 Desktop: MATE 1.20.1
  Distro: Linux Mint 19.1 Tessa
Machine:
  Type: Laptop System: Acer product: Nitro AN515-52 v: V1.22
  serial: <filter>
  Mobo: CFL model: Freed_CFS v: V1.22 serial: <filter> UEFI: Insyde v: 1.22
  date: 10/31/2018
Battery:
  ID-1: BAT1 charge: 48.1 Wh condition: 48.1/48.9 Wh (98%)
CPU:
  Topology: Quad Core model: Intel Core i5-8300H bits: 64 type: MT MCP
  L2 cache: 8192 KiB
  Speed: 3191 MHz min/max: 800/4000 MHz Core speeds (MHz): 1: 2027 2: 1813
  3: 2009 4: 2067 5: 1837 6: 1816 7: 1881 8: 1505
Graphics:
  Device-1: Intel driver: i915 v: kernel
  Device-2: NVIDIA GP107M [GeForce GTX 1050 Mobile] driver: nvidia v: 390.77
  Display: x11 server: X.Org 1.19.6 driver: modesetting,nvidia
  unloaded: fbdev,nouveau,vesa resolution: 1920x1080~60Hz
  OpenGL: renderer: GeForce GTX 1050/PCIe/SSE2 v: 4.6.0 NVIDIA 390.77
Audio:
  Device-1: Intel Cannon Lake PCH cAVS driver: snd_hda_intel
  Sound Server: ALSA v: k4.15.0-45-generic
Network:
  Device-1: Intel Wireless-AC 9560 [Jefferson Peak] driver: iwlwifi
  IF: wlp0s20f3 state: up mac: <filter>
  Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
  driver: r8169
  IF: enp7s0f1 state: down mac: <filter>
Drives:
  Local Storage: total: 1.14 TiB used: 122.63 GiB (10.5%)
  ID-1: /dev/nvme0n1 vendor: Intel model: SSDPEKKW256G8 size: 238.47 GiB
  ID-2: /dev/sda vendor: Western Digital model: WD10SPZX-21Z10T0
  size: 931.51 GiB
Partition:
  ID-1: / size: 63.15 GiB used: 10.17 GiB (16.1%) fs: ext4
  dev: /dev/nvme0n1p4
  ID-2: /home size: 31.20 GiB used: 2.08 GiB (6.7%) fs: ext4
  dev: /dev/nvme0n1p5
  ID-3: swap-1 size: 6.58 GiB used: 0 KiB (0.0%) fs: swap
  dev: /dev/nvme0n1p3
Sensors:
  System Temperatures: cpu: 66.0 C mobo: N/A gpu: nvidia temp: 53 C
  Fan Speeds (RPM): N/A
Info:
  Processes: 246 Uptime: 1h 32m Memory: 7.63 GiB used: 1.47 GiB (19.3%)
  Shell: bash inxi: 3.0.27
unsers@nitro:~$

Na ja, die Hardware ist ziemlich neu und von Acer.
Dann noch Nvidia-Grafik und UEFI …
Damit bist Du nicht die erste, die anfangs verschärft Schwierigkeiten mit Linux überwinden muss.
Aber sieht so aus, als hättest Du es geschafft.

Falls noch nicht bekannt, bei den ubuntuusers.de findet man etliche Tipps für Acer-Ware, z. B.
https://wiki.ubuntuusers.de/EFI_Problembehebung/#Acer-Rechner
Viele Anleitungen und Infos dort passen auch für LinuxMint, weil die Basis dieselbe ist.
« Letzte Änderung: 05.03.2019, 02:18:01 von aexe »

Ja, den Link zur Extra-Problembeschreibung für Acer-Geräte hatte ich auch gefunden. Was meine erste Verzweiflung nur noch vergrößert hatte - irgendwann hatte ich den Eindruck, dass es offenbar noch niieeeeeee geklappt hat, auf einem Acer-Gerät einfach so ein Linux zu installieren. Aus dieser Verzweiflung heraus kam die Idee mit dem "mach alles weg und Linux drauf" - und genau das war ja dann der erste große Schritt in die richtige Richtung. :)

Inzwischen habe ich viel und ausdauernd und alles mögliche an dem Gerät gearbeitet und es sieht ganz danach aus, als wenn das Einfrierungsproblem ebenfalls behoben wäre. Die Lösung lautete in meinem Fall also ganz einfach: Den empfohlenen Nvidia-Treiber nehmen und alles ist gut.

Damit markier ich das Thema hiermit als gelöst. Vielen Dank nochmal an Aexe und alle, die geholfen haben.