Náhlý pád s zobrazením černé obrazovky / dev / sda1:
On 15 února, 2021 by adminNěkdy, bez zjevného důvodu, moje obrazovka najednou zhasne a zobrazí pouze jeden řádek textu :
/dev/sda1: clean 1068388/64102400 files, 29744985/256399616 blocks
jako by se systém restartoval. Poté se ale nic neděje a musím stisknout resetovací tlačítko.
To se stalo třikrát. Jednou hned po novém startu v dopoledních hodinách a nikdy se spuštěným velkým úkolem (pouze otevření prohlížeče – ne reprodukovatelné). Nikdy se to nestalo při extrémním zatížení (trénování neuronových sítí), takže jsem si docela jistý, že to není problém s teplem, jako v tomto příspěvku .
V souboru /var/log/kern.log
jsem našel následující podezřelé řádky
... [ 0.024000] tsc: Fast TSC calibration failed ... ... [ 0.796335] dpc 0000:00:01.1:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 6, DL_ActiveErr+
, kde se poslední řádek zobrazí třikrát řádek, ale nevím, co to znamená.
Používám:
- OS: Ubuntu 18.04
- jádro: 4.15.0 -39-generic (x86_64)
- Desktop: GNOME Shell 3.28.3
- Display Driver: NVIDIA 396.45
- Compiler: Clang 3.3 + LLVM 3.3 + CUDA 9.2
- Souborový systém: ext4
Na zcela novém stolním počítači se specifikacemi:
- Procesor: AMD Ryzen Threadripper 1900X 8- Core @ 3,80 GHz (16 jader)
- Základní deska: ASRock X399 Professional Gaming
- Paměť: 64512 MB
- Disk: 1050 GB Crucial_CT1050MX + 4001 GB Elements SE 25FF
- Grafika: 2x SLI NVIDIA GeForce GTX 1080 Ti 11264 MB
Co by mohlo být příčinou tohoto p roblem?
smartctl
V reakci na komentáře je výstup z
sudo smartctl --all /dev/sda
=== START OF INFORMATION SECTION === Device Model: Crucial_CT1050MX300SSD1 Serial Number: 173818DBA7DB LU WWN Device Id: 5 00a075 118dba7db Firmware Version: M0CR060 User C apacity: 1.050.214.588.416 bytes [1,05 TB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Form Factor: 2.5 inches Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-3 T13/2161-D revision 5 SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sat Nov 17 14:39:52 2018 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 2783) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 13) minutes. Conveyance self-test routine recommended polling time: ( 3) minutes. SCT capabilities: (0x0035) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 100 100 000 Pre-fail Always - 0 5 Reallocated_Sector_Ct 0x0032 100 100 010 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 454 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 333 171 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 172 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 173 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 1 174 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 1 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 000 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 194 Temperature_Celsius 0x0022 074 059 000 Old_age Always - 26 (Min/Max 16/41) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 100 100 000 Old_age Always - 0 202 Unknown_SSD_Attribute 0x0030 100 100 001 Old_age Offline - 0 206 Unknown_SSD_Attribute 0x000e 100 100 000 Old_age Always - 0 246 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 945594898 247 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 29549867 248 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 8744251 180 Unused_Rsvd_Blk_Cnt_Tot 0x0033 000 000 000 Pre-fail Always - 4424 210 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.
Aktualizace (odhlášení místo černé obrazovky)
Právě teď jsem místo černé obrazovky bez zjevného důvodu odhlášen ze svého účtu. Zdá se, že tyto problémy spolu souvisejí. Přibližně v době této události Vim zdůrazňuje tyto řádky v kern.log
:
Nov 19 09:44:52 Gauss kernel: [ 0.793729] dpc 0000:00:01.1:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 6, DL_ActiveErr+ Nov 19 09:44:52 Gauss kernel: [ 0.793735] dpc 0000:00:03.1:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 6, DL_ActiveErr+ Nov 19 09:44:52 Gauss kernel: [ 0.793744] dpc 0000:40:03.1:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 6, DL_ActiveErr+ ... Nov 19 09:44:52 Gauss kernel: [ 0.890282] RAS: Correctable Errors collector initialized. ... Nov 19 09:44:52 Gauss kernel: [ 1.026963] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... Nov 19 09:44:52 Gauss kernel: [ 2.927217] scsi 10:0:0:1: Failed to get diagnostic page 0x1 Nov 19 09:44:52 Gauss kernel: [ 2.927219] scsi 10:0:0:1: Failed to bind enclosure -19 ... Nov 19 09:44:52 Gauss kernel: [ 5.227132] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro ... Nov 19 09:44:52 Gauss kernel: [ 5.602354] thermal thermal_zone0: failed to read out thermal zone (-61)
Komentáře
Odpovědět
Vypadá to, že váš server s grafickým uživatelským rozhraním X11 nebo Wayland havaruje a přepne vás zpět na konzolu pro textový režim. Jeden řádek textu pravděpodobně pochází z kontroly souborového systému, ke které došlo při spuštění systému před přepnutím do režimu grafického uživatelského rozhraní. Protože Ubuntu 18.04 spouští grafické uživatelské rozhraní na první virtuální konzole, nebude tato virtuální konzole reagovat, pokud dojde k chybě serveru GUI a nebude restartován.
(Jiné distribuce Linuxu tradičně používaly 7. virtuální konzoli pro grafické uživatelské rozhraní, což způsobilo, že se systém automaticky vrátil k výchozí 1. virtuální konzole s funkční výzvou k přihlášení při havárii serveru X11. Ubuntu zřejmě přesunul Server GUI na první virtuální konzoli, aby se zajistil plynulejší přechod mezi úvodním spuštěním a přihlášením GUI, ale pokud dojde k chybě serveru GUI, budete nyní muset znát virtuální konzoly, abyste získali přístup k přihlášení v textovém režimu prompt.)
Řádky ve vašem /var/log/kern.log
jsou všechny protokolovány během několika sekund po spuštění linuxového jádra (podle hodnoty seconds-since-startup v hranaté závorky na začátku každého řádku), takže pravděpodobně přímo nesouvisí.
Zkuste stisknout Control + Alt + F2 . Pokud je jádro stále naživu, měla by se nyní na černé obrazovce zobrazit výzva k přihlášení v textovém režimu. Potom se můžete přihlásit a zkusit sudo systemctl restart gdm
restartovat grafické uživatelské rozhraní nebo shromažďovat protokoly a další informace o odstraňování problémů v textovém režimu. Restartování gdm
vás může automaticky vrátit do grafického uživatelského rozhraní, ale relace přihlášení na druhé virtuální konzole zůstane stále přihlášená: pravděpodobně mezi nimi můžete přepínat pomocí Control- Alt-F1 a Control-Alt-F2 .
Jelikož protokol jádra nic neukazuje, může se stát, že jádro je v pořádku a jen desktop havaruje . V takovém případě mohou být užitečnější další soubory protokolu:
-
/var/log/gdm.log
-
/var/log/Xorg.0.log
pokud existuje (hmm, jaký je ekvivalent pro Wayland?)
Zřeknutí se odpovědnosti: Ubuntu 18.04 jsem sám nevyzkoušel; tato odpověď je založena pouze na tom, co jsem četl o tom.
Komentáře
- Neexistuje žádný
gdm.log
, alegrep -E "EE|WW" Xorg.0.log
uvádí několik řádků, včetně “ Nepodařilo se otevřít zařízení DRM „. Může to souviset s mými GPU?Tady je pastebin: paste.ubuntu.com/p/zJ9Gqhfq9B - Všimněte si, že
Xorg.0.log
bude nahrazeno pokaždé, když se spustí server X11, takže pokud jste ‚ již restartovali grafické uživatelské rozhraní nebo restartovali systém po havárii, podívejte se na konecXorg.0.log.old
místo. - ok, tady je celý
Xorg.0.log.old
soubor: paste.ubuntu .com / p / 925mb7xMtz Děkujeme za vaši pomoc! Uvádíxf86CloseConsole: KDSETMODE failed
aVT_GETMODE
aVT_ACTIVATE
. A předem zmínil můj GPU. - Hmm, to vypadá jako úspěšné vypnutí serveru X11 bez významných chyb. Pokud tento protokol pochází z havárie, důvodem je pravděpodobně to, že proces správce zobrazení havaruje a způsobí, že relace X11 skončí jako vedlejší efekt. Existuje ve vašem systému nějaký soubor protokolu odpovídající
/var/log/*dm.log
? Nebo pokud je Ubuntu 18.04 standardizováno najournald
založené protokolování, ujistěte se, že existuje/var/log/journal
adresář a měli byste být schopni používatsudo journalctl -xb -1
pro zobrazení protokolů předchozího bootování až po vypnutí. - Měl jsem si zapsat přesné časy, kdy k tomu došlo. Dnes jsem dostal jen neočekávané odhlášení.
*dm.log
neexistuje, alejounal
vše fungovalo. Sem jsem vložil protokoly kolem kritického bodu v čase: paste.ubuntu.com/p/37XmRYRpVK
Odpověď
Může to být trochu dlouhý zásah, ale měl jsem přesně stejné příznaky, jaké jste dnes popsali na mém počítači (zhroucení a později odhlášení místo černé obrazovky).
Jsem také na Ubuntu 18.04 a používám GPU Nvidia.
Každý, kdo uvádí, že předpokládá, že by to mohl být problém s ovladači Nvidida, rozhodl se dát odpověď v tomto vlákně výstřel, i když se na náš problém vztahovala jen částečně:
-
Odstraňte své ovladače nvidia pomocí
sudo apt-get purge nvidia*
-
Restartovat
-
Nainstalujte ovladače Nvidida znovu
Doposud jsem již neměl černé obrazovky ani náhlé odhlášení
Komentáře
- Dobře, ‚ zkusím to!
- G Pokud nám problém vyřešil, pošlete nám aktualizaci.
- Rychlá poznámka: Protože používám
zsh
musel jsem umístitnvidia*
do uvozovek, viz github.com/robbyrussell/oh-my-zsh/issues/6748 .
Odpověď
Další řešení zde. Už jsem měl stejný problém a nenašel jsem žádné z navrhovaných řešení, která by byla pro můj případ užitečná. Použil jsem pracovní stanici VMware a čelil stejnému problému, když se Ubuntu spustí. Hlavním důvodem havárie v mém případě nebyl kvůli ovladači grafické karty nebo podobným věcem. V nainstalovaném Ubuntu nebylo dost volného místa. Proto jsem k vyřešení problému postupoval podle následujících kroků.
1) změňte konfigurační soubor .vmx přidáním následujícího řádku:
bios.bootDelay = „50000“
* To vede k delšímu spuštění zpoždění, proto můžete použít Shift + Enter pro vstup do Grub Menu.
* Pokud máte problém s otevřením souboru .vmx v systému Windows, nejprve změňte příponu souboru na .txt, poté do ní přidejte výše uvedený řádek a soubor uložte a poté změňte příponu zpět na .vmx
2) Spusťte VMware a spusťte Ubuntu
3) Po kliknutí na obrazovku stiskněte a podržte klávesu Shift a poté stisknutím klávesy Enter přejděte do nabídky grub.
4) vyberte Pokročilé možnosti pro Ubuntu.
5) vyberte root a stiskněte klávesu Enter.
6) Nyní máte přístup root ke smazání libovolného souboru uvolnit volné místo v Ubuntu.
Všimněte si, že někteří uživatelé pro přístup k terminálu navrhli použít Alt + Shift + F2 nebo F3. To pro mě nefungovalo, protože jsem neměl heslo pro uživatele root. Následující kroky mi však pomohly problém vyřešit.
Hodně štěstí, Hamed
Odpověď
V mém případě to bylo kvůli gdm3 nefunguje. Takže jsem to restartoval pomocí těchto příkazů:
sudo service gdm3 status (to ckeck status) sudo service gdm3 start
Nezáleží na tom, jestli používáte lightgdm, gdm nebo gdm. Chcete-li zjistit, který používáte zkuste sudo service --status-all | grep gdm
odpověď
Zde je další řešení, které jsem ještě neviděl jinde jsem si myslel, že to může být užitečné sdílet.
Používám Ubuntu 20.04 LTS, amd64 distro a po spuštění “ / dev / sda1: clean … “ chyba.V mém případě byla sekundární příčinou problému to, že disk byl plný .
Pokud tedy máte tento příznak, zkuste rychle df
nebo df -h
zjistit, kolik místa vám zbylo oddíl (y). Pomocí příkazů du
nebo du -h
můžete vyhledávat v adresářích, které obsahují velké množství dat. Řešení může být stejně jednoduché jako mazání nepotřebných souborů.
V mém případě se ale ukázalo, že adresář / var / log měl asi 100 GB (?!), Což bylo způsobeno nějakým problémem v systému neustále psát do souboru / var / log / syslog a nakonec zaplnit disk. To byla tedy hlavní příčina problému. V tomto okamžiku si nejsem jistý, jaký zdroj je viníkem, ale kontrola souboru / var / log / syslog může ve vašem případě poskytnout nějaké ukazatele. Pokud je to váš případ také, doporučuji prozkoumat, jak správně odebrat soubor / var / log / syslog, a pak zkuste vyřešit primární příčinu problému.
Protože můj systém nemá žádné důležité věci, proto jsem neměl zájem uchovávat soubory protokolu, nainstaloval jsem balíček logrotate a nastavil denní rotaci a konfiguraci systému tak, aby rotovaný soubor odstranil. Také jsem našel velký soubor deníku, takže jsem nastavil cronjob jako root, abych odstranil soubory deníku starší než 1 den. To můžete provést crontab -e
jako root a přidat tento řádek na konec souboru:
0 * * * * journalctl –vacum-time = 1d
Pro dobrou míru jsem také provedl cyklus apt-get update
a apt-get upgrade
.
Doporučuji některé další čtení:
https://ma.ttias.be/clear-systemd-journal/
https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/588 https://askubuntu.com/questions/515146/very-large-log-files-what-should-i-do https://kifarunix.com/how-to-configure-log-rotation-with-logrotate-on-ubuntu-18-04-lts/
Bavte se laděním a hodně štěstí,
8bitrocks
Odpověď
V počítači jsem měl problém, který souvisí s tímto /dev/sd*: clean
problém. Nechtěl jsem otevřít novou otázku, protože jich už je tolik a také proto, že můj problém se zdá být nyní vyřešen. Takže jsem se rozhodl napsat odpověď na související téma (kde mohu napsat odpověď a nepotřebuji 10 reputačních bodů nebo něco podobného).
Než začnu, některé specifikace:
- Ubuntu 18.04.4
- Mám dvojí bootování s Windows
- Můj počítač má grafickou kartu AMD Radeon RX 5500 XT
Pro více specifikací na to právě teď nemyslím — jen mi dejte vědět.
Moje první setkání s tímto problémem vypadalo takto: Vybral jsem si Ubuntu v nabídce dual-boot . Tato nabídka má fialové pozadí. Když jsem kliknul, vstup do nabídky zmizel (jako by měl), ale fialové pozadí zůstalo po dobu nejméně 15 minut. Rozhodl jsem se restartovat. Po nějakém googlení se mi podařilo vstoupit do režimu obnovy, kde jsem upravil /etc/default/grub
řádek
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
Restartoval jsem pouze proto, abych viděl obrazovku blikající následující zprávou
/dev/sdb1: Superblock last mount time is in the future. (by less than a day, probably due to the hardware clock being incorrectly set) /dev/sdb1: Superblock last write time is in the future. (by less than a day, probably due to the hardware clock being incorrectly set) /dev/sdb1: clean, 30163/6594560 files, 5137309/26366943 blocks
každých ~ 10 sekund po dobu ~ 0,5 sekundy. Zde jsem již „věděl“, že tento problém souvisí s nainstalovanými grafickými ovladači. Znovu jsem restartoval v režimu obnovení, abych odinstaloval ovladače grafické karty AMD.
$ amdgpu-pro-uninstall
Poté se Ubuntu normálně spustil, kromě skutečnosti, že byl pouze 1 monitor rozpoznán s rozlišením 1024×768, které jsem nemohl změnit (mám 2 monitory s 1920×1080). Po dalším googlení jsem změnil soubor etc/fstab
z
# /etc/fstab: static file system information. # # Use "blkid" to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sdb1 during installation UUID=b440d779-f2d8-4e85-a425-86c264cf1086 / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/nvme0n1p2 during installation UUID=4E80-9146 /boot/efi vfat umask=0077 0 1 # /home was on /dev/sdb3 during installation UUID=3b2456a3-8d84-41f8-81b1-094c3014126f /home ext4 defaults 0 2 # swap was on /dev/sdb2 during installation UUID=5d727b45-f3f0-40ad-8f6b-41528f8fb611 none swap sw 0 0
na
# /etc/fstab: static file system information. # # Use "blkid" to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sdb1 during installation UUID=b440d779-f2d8-4e85-a425-86c264cf1086 / ext4 errors=remount-ro 0 0 # /boot/efi was on /dev/nvme0n1p2 during installation UUID=4E80-9146 /boot/efi vfat umask=0077 0 1 # /home was on /dev/sdb3 during installation UUID=3b2456a3-8d84-41f8-81b1-094c3014126f /home ext4 defaults 0 2 # swap was on /dev/sdb2 during installation UUID=5d727b45-f3f0-40ad-8f6b-41528f8fb611 none swap sw 0 0
(Změnil jsem poslední číslo 1
na 0
v prvním řádku bez komentáře) . Přeinstaloval jsem ovladač AMD GPU, restartoval a problém byl pryč. Píšu to na svých 2 monitorech s rozlišením 1920×1080. Také jsem odstranil nomodeset
v /etc/default/grub
.
Takže pokud má někdo stejný problém, možná tato osoba najde moji odpověď a možná můj přístup problém vyřeší.
smartmontools
a zkontrolovat data SMART vašich disků.smartctl --all /dev/sda
.