Am 03.02. funktionierte es noch, beim nächsten Versuch am 10.02. nicht
mehr: Mint 21 nimmt eine per Hotplugging angeschlossene SATA-Platte
nicht mehr zu Kenntnis. Und nicht nur eine bestimmte, sondern alle, mit
denen ich es versucht habe.
Weitere Tests:
- Rechner mit eingelegter Wechselplatte gestartet und das BIOS Setup
angeworfen: die Platte wird erkannt
- Hotplug-Einstellungen im BIOS überprüft: es war unverändert auf
allen 8 Ports freigegeben.
- Rechner mit eingelegter Wechselplatte gebootet: die Platte wird
erkannt
Dieselben Platten lassen sich auf einem Rechner mit Mint 19 problemlos
per Hotplugging mounten.
In der Woche seit dem 03.02. kam ein Kernel-Update – womöglich hängt es
damit zusammen. Hat jemand ähnliche Probleme?
Boote doch einfach mal mit dem vorherigen Kernel. Dann siehst Du was los ist. Jack V. schrieb: > Log? +1 Moriz schrieb: > In welchem Log müsste darüber was stehen? /var/log/syslog
:
Bearbeitet durch User
Hier das Ende von syslog:
1 | Feb 12 15:01:08 mint-21 ntpd[2673]: 185.232.69.65 local addr 192.168.178.108 -> <null> |
2 | Feb 12 15:05:01 mint-21 CRON[23976]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) |
3 | Feb 12 15:08:39 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users. |
4 | Feb 12 15:10:28 mint-21 rtkit-daemon[1874]: message repeated 13 times: [ Supervising 4 threads of 3 processes of 1 users.] |
5 | Feb 12 15:15:01 mint-21 CRON[24852]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) |
6 | Feb 12 15:17:01 mint-21 CRON[25112]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) |
7 | Feb 12 15:25:01 mint-21 CRON[25864]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) |
8 | Feb 12 15:30:01 mint-21 CRON[26167]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi) |
9 | Feb 12 15:30:45 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users. |
10 | Feb 12 15:31:11 mint-21 rtkit-daemon[1874]: message repeated 7 times: [ Supervising 4 threads of 3 processes of 1 users.] |
11 | Feb 12 15:31:37 mint-21 systemd[1]: Started Run anacron jobs. |
12 | Feb 12 15:31:37 mint-21 anacron[26401]: Anacron 2.3 started on 2024-02-12 |
13 | Feb 12 15:31:37 mint-21 anacron[26401]: Normal exit (0 jobs run) |
14 | Feb 12 15:31:37 mint-21 systemd[1]: anacron.service: Deactivated successfully. |
15 | Feb 12 15:35:01 mint-21 CRON[26593]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) |
16 | Feb 12 15:45:01 mint-21 CRON[26939]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) |
Wenn ich das recht sehe, steht dort nichts von der Platte. Seit 15:00 habe ich die Platte mehrfach in den Wechselrahmen reingeschoben und wieder raus geholt.
Syslog ist heutzutage nicht mehr Default. Am einfachsten geht’s wohl, wenn du als Root ›journalctl -f‹ eingibst, und dann die Platte anschließt – dann sollte Text dazukommen, der wäre von Interesse.
Das kam nach dem Einlegen dazu:
1 | $ sudo journalctl -f |
2 | [sudo] password for inet: |
3 | Feb 12 16:15:01 mint-21 CRON[28879]: pam_unix(cron:session): session closed for user root |
4 | Feb 12 16:15:26 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users. |
5 | Feb 12 16:15:26 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users. |
6 | Feb 12 16:17:01 mint-21 CRON[28949]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0) |
7 | Feb 12 16:17:01 mint-21 CRON[28950]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) |
8 | Feb 12 16:17:01 mint-21 CRON[28949]: pam_unix(cron:session): session closed for user root |
9 | Feb 12 16:17:25 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users. |
10 | Feb 12 16:17:25 mint-21 rtkit-daemon[1874]: Supervising 4 threads of 3 processes of 1 users. |
11 | Feb 12 16:19:27 mint-21 sudo[29130]: inet : TTY=pts/3 ; PWD=/home/inet ; USER=root ; COMMAND=/usr/bin/journalctl -f |
12 | Feb 12 16:19:27 mint-21 sudo[29130]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000) |
Dasselbe, wie in syslog weiter oben… Nach dem Platte wieder rausziehen kam gar nichts
Für die Vertreter der ›old school‹ Bewegung: dmesg -w Ganz generell würde ich aber auch mal nach LPM schauen.
Den Wechselrahmen kann man wohl auch als Fehlerquelle ausschließen: Das ist ein 4-fach-Wechselrahmen, im ersten Slot hatte ich die home-Platte, die beim Boot auf die SSD gemountet wird, im 2. Slot üblicherweise bei Bedarf die andere Platte. Ich habe versuchsweise die Home-Platte in Slot 2 gebootet und die Wechselplatte in Slot 1 – geändert hat sich am Gesamtbild nichts.
Norbert schrieb: > Für die Vertreter der ›old school‹ Bewegung: > dmesg -w Old school scheint auch Ferien zu haben: Null Reaktion, wenn ich die Platte einschiebe. > Ganz generell würde ich aber auch mal nach LPM schauen. Ich habe auf die Schnelle nur gefunden, wie man die Einstellungen ändern kann. Wie kann man den aktuellen Zustand abfragen?
Mal in
1 | /sys/devices/pci………/link_power_management_policy |
schauen. Ein
1 | find /sys -name "link_power_management_policy" |
hilft bei der Suche. Edit: Meine sagen:›max_performance‹ Edit2:
1 | # find /sys -iname "link_power_management_policy" -exec cat {} \;
|
max_performance max_performance max_performance max_performance max_performance max_performance
:
Bearbeitet durch User
Moriz schrieb: > Alle 8 SATA-Ports sind auf med_power_with_dipm Na dann würde ich nur zum Spaß mal ein ›max_performance‹ mittels echo -n hinein massieren.
Ist das persistent, oder geht es nach dem Boot wieder auf med_power_with_dipm?
Moriz schrieb: > Ist das persistent, oder geht es nach dem Boot wieder auf > med_power_with_dipm? Isses nicht. Dafür gibt's andere Stellen. Müsste ich aber auch erst einmal suchen.
Ich probiere erst mal den vorherigen Kernel, ehe ich da an Einstellungen rum schraube.
Moriz schrieb: > Ich probiere erst mal den vorherigen Kernel, ehe ich da an > Einstellungen > rum schraube. ThumbUp PS. Kann es sein das in deinem System ein mobile Prozessor werkelt?
:
Bearbeitet durch User
Wenn die Festplatte vor dem Booten angeschlossen ist, wird sie dann erkannt? Spielt Kaltstart vs. Warmstart eine Rolle?
Steve van de Grens schrieb: > Wenn die Festplatte vor dem Booten angeschlossen ist, wird sie dann > erkannt? Ja > Spielt Kaltstart vs. Warmstart eine Rolle? Nein
Norbert schrieb: > Moriz schrieb: >> Ich probiere erst mal den vorherigen Kernel, ehe ich da an >> Einstellungen >> rum schraube. > > ThumbUp > PS. Kann es sein das in deinem System ein mobile Prozessor werkelt? Nein:
1 | description: Desktop Computer |
2 | product: Z690 AORUS ELITE DDR4 (Default string) |
3 | vendor: Gigabyte Technology Co., Ltd. |
4 | version: Default string |
5 | serial: Default string |
6 | width: 64 bits |
7 | capabilities: smbios-3.5.0 dmi-3.5.0 smp vsyscall32 |
8 | configuration: boot=normal chassis=desktop family=Z690 MB sku=Default string uuid=035e02d8-04d3-0532-8106-670700080009 |
9 | |
10 | description: CPU |
11 | product: 12th Gen Intel(R) Core(TM) i5-12600T |
12 | vendor: Intel Corp. |
13 | physical id: 4e |
14 | bus info: cpu@0 |
15 | version: 6.151.5 |
16 | serial: To Be Filled By O.E.M. |
17 | slot: U3E1 |
18 | size: 1534MHz |
19 | capacity: 4600MHz |
20 | width: 64 bits |
21 | clock: 100MHz |
22 | capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req umip pku ospke waitpkg gfni vaes vpclmulqdq tme rdpid movdiri movdir64b fsrm md_clear serialize pconfig arch_lbr flush_l1d arch_capabilities cpufreq |
23 | configuration: cores=6 enabledcores=6 microcode=50 threads=12 |
Nachdem im Log augenscheinlich rein gar nichts dazu aufgetaucht, würde mein nächster Blick nun in Richtung udev gehen: ›udevadm monitor‹ starten, HDD anschließen und schauen.
Auch da ist tote Hose:
1 | $ udevadm monitor |
2 | monitor will print the received events for: |
3 | UDEV - the event which udev sends out after rule processing |
4 | KERNEL - the kernel uevent |
Wenn ich aber einen USB-Stick anstecke, dann geht ein wahres Gewitter los.
:
Bearbeitet durch User
Vielleicht wird der SATA Port unerwünscht deaktiviert, wenn beim Booten keine Festplatte erkannt wurde. Eventuell findest du in den Logfiles einen Hinweis dazu.
Moriz schrieb: > Wenn ich aber einen USB-Stick anstecke, dann geht ein wahres Gewitter > los. Darum filtert man ja normalerweise auch ein wenig vor. Was macht denn LPM? ;-)
Eben habe ich mit der Vorgänger-Version des aktuellen Mint gebootet: Hotplugging funktioniert damit, ich konnte die Platte mounten.
Moriz schrieb: > Eben habe ich mit der Vorgänger-Version des aktuellen Mint > gebootet: > Hotplugging funktioniert damit, ich konnte die Platte mounten. Na das wäre doch eine wundervolle Gelegenheit erneut LPM zu überprüfen. (Und dann zu staunen)
Norbert schrieb: > Na das wäre doch eine wundervolle Gelegenheit erneut LPM zu überprüfen. > (Und dann zu staunen) Die stehen jetzt alle auf max_performance – staun…
Moriz schrieb: > Norbert schrieb: >> Na das wäre doch eine wundervolle Gelegenheit erneut LPM zu überprüfen. >> (Und dann zu staunen) > > Die stehen jetzt alle auf max_performance – staun… Darum gibt's die folgende allgemeingültige Regel: Wenn man seine Schlüssel verloren hat, dann sucht man sie nicht da wo die Laterne am hellsten scheint, sondern da wo man sie vermutlich verloren hat, ;-)
Moriz schrieb: > Eben habe ich mit der Vorgänger-Version des aktuellen Mint gebootet: > Hotplugging funktioniert damit, ich konnte die Platte mounten. Dann würde ich nun das Log vom Boot mit diesem Kernel mit dem des Boots mit dem anderen Kernel vergleichen.
Norbert schrieb: > Wenn man seine Schlüssel verloren hat, dann sucht man sie nicht da wo > die Laterne am hellsten scheint, sondern da wo man sie vermutlich > verloren hat, ;-) Also man bootet mit der Vorgängerversion ;-)
Moriz schrieb: > Norbert schrieb: >> Wenn man seine Schlüssel verloren hat, dann sucht man sie nicht da wo >> die Laterne am hellsten scheint, sondern da wo man sie vermutlich >> verloren hat, ;-) > > Also man bootet mit der Vorgängerversion ;-) Kneifzange -> Hose ;-) Edit: ahci.mobile_lpm_policy=1
:
Bearbeitet durch User
Nichtsdestotrotz ist da die grundlegende Vorgehensweise der Mitgabe von Kernelparametern beim Boot beschrieben.
Moriz schrieb: > Norbert schrieb: >> ahci.mobile_lpm_policy=1 > > ??? Sorry, da war ich ein wenig kryptisch. Also, wenn man diesen Parameter direkt beim Booten übergibt, sollte das Power-Mismanagement ausgeschaltet werden. Wenn du's nur mal kurz ausprobieren möchtest, kannst du den Bootvorgang im Grub unterbrechen und das da oben von Hand an die kernel Zeile anhängen. Wenn's gut ist, dann kann man das so im System verewigen, das es jedes Mal automagisch passiert.
ahci.mobile_lpm_policy=1 in die Boot-Kommandozeile eingetragen behebt das Problem. Fragt sich nur, wen welcher Teufel geritten hat, die Standard-Einstellung zu ändern… Vielen Dank für die Hilfe!
Moriz schrieb: > ahci.mobile_lpm_policy=1 in die Boot-Kommandozeile eingetragen > behebt > das Problem. Fragt sich nur, wen welcher Teufel geritten hat, die > Standard-Einstellung zu ändern… > > Vielen Dank für die Hilfe! Danke für die Rückmeldung. Was den Teufel angeht, der ist möglicherweise Bündnis90-Grün gekleidet, hat oftmals keine abgeschlossene Berufsausbildung und möchte als Ministerin*in unbedingt Energie sparen. Gelegentlich auch mal etwas zu viel.
Norbert schrieb: > Gelegentlich auch mal etwas zu viel. Das macht sie dann durch eine Pilgerfahrt in die Ost-Kokaine wieder wett…
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.