Jump to content

General troubleshooting (Magyar)

From ArchWiki
Fordítás állapota: Ez az oldal az angol General troubleshooting című oldal magyar nyelvre lefordított változata. Utolsó fordítás dátuma: 2026.11.02. Amennyiben a lefordítás időpontja óta az angol nyelvű oldalon történtek újabb módosítások, akkor Ön segíthet hozzászinkronizálni az angolhoz ezt a magyar nyelvű fordítást.

További oldalak az adott témakörben

Ez a cikk néhány általános hibaelhárítási módszert ismertet. Alkalmazásspecifikus problémák esetén kérjük, tekintse meg az adott program wikioldalát.

Általános eljárások

This article or section needs expansion.

Reason: Tekintettel ennek az oldalnak a nevére, az alapvető, "magától értetődő" megoldásokat valahol meg kellene említeni, például a hidegindítást (talán kifejezetten rámutatva, hogy ez másképp történik egy asztali számítógép és egy laptop esetében), a legújabb verzióra való frissítést stb… (Discuss in Talk:General troubleshooting (Magyar))

Rendkívül fontos, hogy mindig el legyenek olvasva a megjelenő hibaüzenetek. Néha nehéz lehet a megfelelő hibaüzenetekhez hozzájutni. (Például a grafikus felhasználói felülettel rendelkező alkalmazásoknál nehéz lehet hozzájutni a hibaüzenetekhez).

  1. Futtassa az alkalmazást parancssorban annak érdekében, hogy a kimenetet ellenőrizni lehessen.
    1. Ha továbbra sincs elég információ a hibakereséshez, akkor növelje a kimenet részletességét. (Általában ez az alkalmazás futtatásakor a --verbose/-v/-V vagy --debug/-d segítségével érhető el).
    2. Néha nincs ilyen paraméter az alkalmazás futtatásához, és a kimenet részletességének megnövelését direktívaként kell megadni az alkalmazás beállításfájljában.
    3. Egy alkalmazás naplófájlokat is használhat, amelyek általában a /var/log, $HOME/.cache vagy $HOME/.local könyvtárban találhatók.
    4. Ha nincs mód a részletesség növelésére, akkor mindig van lehetőség a strace és hasonló programok futtatására.
  2. Ellenőrizze a rendszernaplót. Lehetséges, hogy egy hiba nyomokat hagy a naplóban is, különösen amikor a hiba más alkalmazásoktól függ.
    1. A dmesg parancs a kernel gyűrűpufferéből (angolul: ring buffer) olvas. Ez akkor hasznos, amikor a számítógép adathordozója valamilyen okból nem érhető el, de ez hiányos naplókat is eredményezhet, mivel a kernel gyűrűpufferének a mérete nem végtelen. Ha lehetséges, akkor Ön használja a journalctl parancsot.
    2. A journalctl több szűrési lehetőséggel rendelkezik, mint a dmesg, és alapértelmezés szerint ember által olvasható időbélyegeket használ.
  3. Mindig érdemes kicsit beleolvasni a vonatkozó hibakövető rendszerekbe (angolul: issue trackers) annak érdekében, hogy kiderüljön, vannak-e már a felhasználók által beküldött hibajelentések. Lehetséges ugyanis, hogy már mások beküldték a nálunk is jelentkező hiba hibajelentését, és sokszor ott olvasható is lesz a probléma megoldása.
    1. A szoftver közvetlen fejlesztőinek (upstream-ek) választásától függően általában létezni szokott egy hibajegyző rendszer, és néha egy fórum is, vagy akár például egy IRC csatorna is szokott létezni.
    2. Létezik az Arch Linux bug tracker (ez, ahogy a neve is mondja, egy hibakövető rendszer az Arch Linux számára), amelyet elsősorban a szoftvercsomagolási hibákkal kapcsolatban kell használni.

További támogatás

Ha Önnek további segítségre van szüksége, akkor a kérdéseit felteheti a fórumban vagy a megfelelő IRC csatornán is.

Megjegyzés A támogatás CSAK ÉS KIZÁRÓLAG az Arch Linux számára van biztosítva, tehát az Arch-alapú disztribúciókhoz nincs támogatás biztosítva.

Amikor Ön támogatást kér, akkor a teljes kimenetet/naplókat tegye közzé. Tehát ne csak azokat a dolgokat tegye közzé, amelyeket Ön lényegesnek tart. Az információforrások a következők:

  • Bármely parancs teljes kimenetét tegye közzé. Tehát ne csak azokat a kimenetrészeket tegye közzé amelyeket Ön relevánsnak gondol, hanem egy az egyben az összes kimenetet tegye közzé.
  • Tegye közzé a systemd naplóját (systemd journal).
    • A bőségesebb kimenet érdekében használja a systemd.log_level=debug boot paramétert. Ez hatalmas mennyiségű kimenetet fog előállítani, ezért csak akkor engedélyezze, amikor valóban szükség van rá.
    • Ne használja a -x paramétert, mert ez feleslegesen zsúfolttá teszi a kimenetet és ezáltal a kimenet nehezebben lesz olvasható.
    • Használja a -b kapcsolót, kivéve, ha Önnek a korábbi rendszerindításból származó naplókra van szüksége. Ennek hiánya rendkívül nagy méretű szövegbeillesztésekhez vezethet, amelyek akár a pastebin-re történő szövegfeltöltésekhez is túl nagyok lehetnek.
  • Releváns beállításfájlok. (Ezek a releváns config fájlok.)
  • Érintett illesztőprogramok (Ezek az érintett driver-ek.)
  • Érintett szoftvercsomagok verziói.
  • Kernel: journalctl -k vagy dmesg. (Mindkettő root jogosultságokkal).
  • Xorg: A beállítástól függően a használt képernyőkezelő is releváns itt.
    • Az Xorg.log több helyen is megtalálható lehet: A rendszernaplóban, a /var/log/ könyvtárban vagy az $HOME/.local/share/xorg/ könyvtárban.
    • Néhány képernyőkezelő (display manager), mint például a LightDM, a Xorg.log fájlt is elhelyezheti a saját naplókönyvtárában.
  • A pacman: Ha egy friss frissítés elrontott valamit, akkor nézze meg a /var/log/pacman.log fájlban.
    • Hasznos lehet a pacman --debug paraméterének a használata.

Az információk közzétételének egyik jobb módja a pastebin használata.

Ezután megjelenik egy link, amelyet Ön beilleszthet a fórumba vagy az IRC csatornán a beszélgetéshez.

Ezenkívül érdemes lehet áttekinteni a hogyan kell megfelelően jelenteni a problémákat című cikket, mielőtt kérdezne.

Boot problémák

This article or section needs expansion.

Reason: From Talk:Installation guide#Buggy graphics driver, maybe add something about trying nomodeset on some hardware? (Discuss in Talk:General troubleshooting (Magyar))

A rendszerindítási (bootolási) problémák diagnosztizálásakor nagyon fontos tudni, hogy a rendszerindítás (bootolás) pontosan melyik szakaszban hibásodik meg.

  1. Firmware (UEFI vagy BIOS) szakasza
    1. Általában csak nagyon alapvető hibakeresési eszközökkel rendelkezik.
    2. Győződjön meg arról, hogy a Secure Boot (biztonságos rendszerindítás) le van tiltva.
    3. Ha a rendszerbetöltő (boot loader) nem található, akkor egy UEFI shell segíthet.
  2. Boot loader szakasza
    1. Az egyik leggyakoribb dolog, amit itt csinálunk, az a kernelparaméterek módosítása.
    2. A rendszerbetöltési szakaszban (bootolási szakaszban) előforduló gyakori rendszerindítási problémákat (bootolási problémákat) az ACPI okozhatja.
  3. initramfs szakasza
    1. Általában vészhelyzeti parancssort biztosít (emergency shell).
    2. A kiválasztott hookoktól függően vagy a dmesg, vagy a naplófájl érhető el benne.
  4. Tényleges rendszer szakasza
    1. Attól függően, hogy mennyire sérült a rendszer, elegendő lehet a hibakereső parncssor (debug shell) egyszerű meghívása.

Ha bármelyik szakasz által biztosított hibakereső segédprogramok nem elegendőek a hibás komponens megjavításához, akkor például próbáljon meg egy USB adathordozót a legújabb Arch Linux ISO lemezképfájllal használni.

Parancssori üzenetek

A rendszerindítási (bootolási) folyamat után a képernyő törlődik, és megjelenik a bejelentkezési ablak, így a számítógép felhasználói nem tudják elolvasni az init kimenetét és a hibaüzeneteket. Ez az alapértelmezett viselkedés módosítható az alábbi szakaszokban ismertetett módszerekkel.

Vegye figyelembe, hogy a választott beállítástól függetlenül a kernelüzenetek a rendszerindítás (tehát a bootolás) után a journalctl -k vagy a dmesg paranccsal jeleníthetők meg az ellenőrzés céljából. Az aktuális rendszerindítás összes naplójának a megjelenítése érdekében használja a journalctl -b parancsot.

Flow control

Ez egy alapvető kezelési mód, amely a legtöbb parancssorra vonatkozik, beleértve a virtuális konzolokat (VC):

  • A kimenet szüneteltetése érdekében nyomja meg a Ctrl+s billentyűkombinációt.
  • Folytathatja a Ctrl+q billentyűkombinációval.

Ez nemcsak a kimenetet szünetelteti, hanem a parancssorra írni próbáló programokat is, mivel ezek a write() hívások során blokkolódnak, amíg a kimenet szünetel. Ha az init lefagyottnak tűnik, akkor győződjön meg arról, hogy a rendszerparancssor nincs szüneteltetve.

A már megjelenített hibaüzenetek megtekintése érdekében olvassa el a Getty#Operációs rendszer elindulásának az üzenetei maradjanak meg a tty1 parancssorban című leírást.

További kernelüzenetek megjelenítése

A legtöbb kernelüzenet rejtve marad a rendszerindítás (tehát a számítógép bootolása) során. Ön különböző kernelparaméterek hozzáadásával további üzeneteket láthat. A legegyszerűbbek a következők:

  • debug, amelynek a következő hatásai vannak:
    • A kernel megemeli a parancssor naplózási szintjét úgy, hogy a kernel naplópufferében található összes üzenet kiíródik a parancssorra. [1]
    • A systemd megemeli a naplózási szintjét, így olyan hibakeresési üzeneteket is naplóz, amelyek egyébként sehol sem keletkeznének. [2]
  • ignore_loglevel, aminek ugyanolyan hatása van a kernelre, mint a debug vagy a loglevel=8 (mivel a hibakeresési üzenetek 7-es szinten vannak), de megakadályozza, hogy a naplózási szint később, a rendszerindítás során emelkedjen.

További hozzáadható paraméterek, amelyek bizonyos helyzetekben hasznosak lehetnek:

  • A earlyprintk=vga,keep, amely a kernel üzeneteit írja ki a rendszerindítási folyamat legelején, arra az esetre, ha a kernel összeomlana, mielőtt a kimenet megjelenne. Az EFI rendszerekhez a vga-t efi-re kell állítani.
  • A log_buf_len=16M egy nagyobb (16 MiB) kernel-üzenetpuffert foglal le annak érdekében, hogy a hibakeresési kimenet ne legyen felülírva.

Hibakeresési kernelüzenetek létrehozása

A #További kernelüzenetek megjelenítése jelzi, hogy miként kell a kernel naplópufferét a parancssorban megjeleníteni, de maga a puffer nem fog olyan üzeneteket tartalmazni, amelyeket ne tartalmazott volna már a parancssor (a debug systemd kimenetén kívül). A következő néhány bekezdés azokat a módszereket tárgyalja amelyekkel a kernel naplójából részletesebb információkat lehet kinyerni.

Dinamikus hibakeresés

A pr_debug vagy kapcsolódó függvényekkel (például a dev_dbg(), drm_dbg(), és bt_dev_dbg() függvényekkel) kiírt üzenetek nem jelennek meg, ezért Önnek a következőt lépéseket kell megtennie:

  • Módosítsa a kernel forráskódját úgy, hogy a kívánt helyen definiálva legyen a DEBUG.
  • Használja a kernel dinamikus hibakeresés funkcióját a hibakeresési üzenetek engedélyezéséhez.

Ez a szakasz a dinamikus hibakeresés használatát tárgyalja, ami akkor hasznos, amikor Ön már átnézte a kernelnaplót az információs naplókig bezárólag, és még több hibakeresési információra van szükség egy adott helyről.

Először is, Ön olyan kernelt kell, hogy futtasson, amely a CONFIG_DYNAMIC_DEBUG kernelbeállítással lett forráskódból lefordítva bináris kernelkódra. Ez már a linux esetében is így van, így nincs szükség semmilyen teendőre, amikor Ön ezt a kernelt használja.

Ezután Önnek tudnia kell, hogy honnan szeretné látni a hibakeresési üzeneteket. Íme néhány lehetőség:

  • A kernelmodul nevét használjuk, amikor a probléma egyetlen modulra korlátozódik. Például az Intel grafikus kártyával kapcsolatos hibaelhárításhoz érdemes lehet az i915 DRM kernelmodullal foglalkozni.
  • Going with a directory in the kernel that corresponds with functionality you are interested in. You will want to check out (or navigate online) the kernel source code to understand the structure. As an example, to inspect debug messages for all DRM kernel modules, you could go with the path drivers/gpu/drm.

Using that "source" of messages, you have to come up with a dynamic debug query that indicates which debug messages to enable, of the format: 

match_type match_parameter flags

Where:

  • match_type is the type of match to make. Corresponding to the two options given earlier, this could be module or file.
  • match_parameter is the module or file path to watch. In the latter case, using asterisks for wildcards is permissible.
  • flags dictates what to do with the match. This could be +p to start printing its messages, or -p to undo that.

Some examples of queries are:

  • module i915 +p to print debug messages from the i915 kernel module.
  • file drivers/gpu/drm/* +p to print debug messages from DRM drivers.
  • file * +p to print debug messages.

Finally, to actually enact the query, you can either:

  • Do so during runtime, by running:
# echo "query" > /sys/kernel/debug/dynamic_debug/control
This assumes that debugfs is mounted at /sys/kernel/debug/, which you can verify using mount . [3]

This is a greatly simplified overview of dynamic debug's capabilities; see the documentation for further details.

Subsystem-specific debugging

There are also a number of separate debug parameters for enabling debugging in specific subsystems e.g. bootmem_debug, sched_debug. Also, initcall_debug can be useful to investigate boot freezes. (Look for calls that did not return.) Check the kernel parameter documentation for specific information.

netconsole

netconsole is a kernel module that sends all kernel log messages (i.e. dmesg) over the network to another computer, without involving user space (e.g. syslogd). Name "netconsole" is a misnomer because it is not really a "console", more like a remote logging service.

It can be used either built-in or as a module. Built-in netconsole initializes immediately after NIC cards and will bring up the specified interface as soon as possible. The module is mainly used for capturing kernel panic output from a headless machine, or in other situations where the user space is no more functional.

Be aware that you need to set the kernel options debug and ignore_loglevel for netconsole to send out kernel messages.

Helyreállító parancssorok

Helyreállító parancssorok (recovery shells). Getting an interactive shell at some stage in the boot process can help you pinpoint exactly where and why something is failing. There are several kernel parameters for doing so, but they all launch a normal shell which you can exit to let the kernel resume what it was doing:

  • rescue launches a shell shortly after the root file system is remounted read/write
  • emergency launches a shell even earlier, before most file systems are mounted
  • init=/bin/sh (as a last resort) changes the init program to a root shell. rescue and emergency both rely on systemd, but this should work even if systemd is broken.

Another option is systemd's debug-shell which adds a root shell on tty9 (accessible with Ctrl+Alt+F9). It can be enabled by either adding systemd.debug_shell to the kernel parameters, or by enabling debug-shell.service.

Figyelmeztetés Remember to disable the service when done to avoid the security risk of leaving a root shell open on every boot.

Debugging kernel modules

See Kernel modules#Obtaining information.

Debugging hardware

Debugging freezes

Unfortunately, freezes are usually hard to debug and some of them take a lot of time to reproduce. There are some types of freezes which are easier to debug than others:

  • Is sound still playing? If so, just the display may be frozen. This may be a problem with the video driver.
  • Is the machine still responding? Try SSH if switching to another TTY does not work.
  • Is the disk activity LED (if present) indicating that a lot is being written to disk? Heavy swapping may temporarily freeze the system. See this StackExchange answer for information about freezes on large writes.

If nothing else helps, try a clean shutdown. Pressing the power button once may unfreeze the system and show the classic "shutdown screen" which displays all the units that are getting stopped. Alternatively, using the magic SysRq keys may also help to achieve a clean shutdown. This is very important because the journal may contain hints why the machine froze. The journal may not be written to disk on an unclean shutdown. Hard freezes in which the whole machine is unresponsible are harder to debug since logs can not be written to disk in time.

Remote logging may help if the freeze does not permit writing anything to disk. A crude remote logging solution, which needs to be invoked from another device, can be used for basic debugging: 

$ ssh freezing_host journalctl -f

Many fatal freezes in which the whole system does not respond anymore and require a forced shutdown may be related to buggy firmware, drivers or hardware. Trying a different kernel (see Kernel#Debugging regressions) or even a different Linux distribution or operating system, updating the firmware and running hardware diagnostics may help finding the problem.

Tipp It is recommended to try to update the firmware of the device, since these updates may fix strange issues.

If a freeze does not permit gathering any kind of logs or other information required for debugging, try reproducing the freeze in a live environment. If a graphical environment is required to reproduce the freeze or if the freeze can be reproduced on the archiso, use the live environment of a different distribution, which is preferably not based on Arch Linux to eliminate the possibility that the freeze is related to the version or patches of the kernel. Should the freeze still happen in a live environment, chances are that it may be hardware-related. If it does not happen anymore, it is necessary to be aware of the differences of both systems. Different configurations, differences in versions and kernel parameters and other, similar changes may have fixed the freeze.

However, a blinking caps lock LED may indicate a kernel panic. Some setups may not show the TTY when a kernel panic occurred, which may be confusing and can be interpreted as another kind of freeze.

Regressziók hibakeresése

Figyelmeztetés This tends to cause partial upgrades, which are a necessary evil in this specific case. Proceed with caution and prepare a method to recover your system, just in case this scenario prevents a normal boot.

If an update causes an issue but downgrading the specific package fixes it, it is likely a regression. If this happened after a normal full system upgrade, check your pacman.log to determine which package(s) may have caused the issue. The most important part of debugging regressions is checking if the issue was already fixed, as this can save much time. To do so, first ensure the application is fully updated (e.g. ensure the application is the same version as in the official repositories). If it already is or if updating it does not fix the issue, try using the development version, usually a VCS version, which may already be packaged in the AUR. If this fixes the issue and the version with the fixes is not yet in the official repositories, wait until the new version arrives in them and then switch back to it.

If the issue still persists, debug the issue and/or bisect the application and report the bug on the upstream bug tracker so it can be fixed.

Megjegyzés The kernel needs a slightly different approach when debugging regressions.

Egyes perifériák nem használhatók a kernel frissítése után

This will manifest commonly (but probably not only) as:

  • newly plugged USB devices showing up with dmesg but not in /dev/,
  • file systems unable to be mounted if they were not already used before the kernel update,
  • the inability to use a wired/wireless connection on a laptop if it was not already used before the kernel update,
  • FATAL: Module module not found in directory /lib/module/kernelversion when using modprobe to load a module that was not already used before the kernel package update.

As partially covered in System maintenance#Restart or reboot after upgrades, the kernel is not updated when you update the package but only once you reboot afterwards. Meanwhile, the kernel modules, located in /usr/lib/modules/kernelversion/ are removed by pacman when installing the new kernel. As explained in FS#16702, this approach avoids leaving files on the system not handled by the package manager but leads to the aforementioned symptoms. To fix them, reboot systematically after updating the kernel. The long-term evolution, yet to be implemented, will be to use versioned kernel packages : the main blocker being how to handle the removal of the previous kernel versions once they are not needed anymore.

Another solution is available as kernel-modules-hook, where two pacman hooks use rsync to keep the kernel modules on the file system after the kernel update and linux-modules-cleanup.service that marks the old modules for removal four weeks after once enabled.

Package management

See Pacman#Troubleshooting for general topics, and pacman/Package signing#Troubleshooting for issues with PGP keys.

Fixing a broken system

If a partial upgrade was performed, try updating your whole system. A reboot may be required. 

# pacman -Syu

If you usually boot into a GUI and that is failing, perhaps you can press Ctrl+Alt+F1 through Ctrl+Alt+F6 and get to a working tty to run pacman through.

If the system is broken enough that you are unable to run pacman, boot using a monthly Arch ISO from a USB flash drive, an optical disc or a network with PXE. (Do not follow any of the rest of the installation guide.)

Mount your root file system: 

# mount /dev/rootFileSystemDevice /mnt

Mount any other partitions that you created separately, adding the prefix /mnt to all of them, i.e.: 

# mount /dev/bootDevice /mnt/boot

Try using your system's pacman while chrooted: 

# arch-chroot -S /mnt
# pacman -Syu

If that fails, exit the chroot, and try: 

# pacman -Syu --sysroot /mnt

If that fails, try: 

# pacman -Syu --root /mnt --cachedir /mnt/var/cache/pacman/pkg

fuser

This article or section needs expansion.

Reason: Needs more information about its usage (Discuss in Talk:General troubleshooting (Magyar))

fuser is a command-line utility for identifying processes using resources such as files, file systems and TCP/UDP ports.

fuser is provided by the psmisc package, which should be already installed as a dependency of the base meta package. See fuser(1) for details.

Session permissions

Megjegyzés You must be using systemd as your init system for local sessions to work.[4] It is required for polkit permissions and ACLs for various devices (see /usr/lib/udev/rules.d/70-uaccess.rules and [5])

First, make sure you have a valid local session within X: 

$ loginctl show-session $XDG_SESSION_ID

This should contain Remote=no and Active=yes in the output. If it does not, make sure that X runs on the same tty where the login occurred. This is required in order to preserve the logind session.

Basic polkit actions do not require further set-up. Some polkit actions require further authentication, even with a local session. A polkit authentication agent needs to be running for this to work. See polkit#Authentication agents for more information on this.

Message: "error while loading shared libraries"

If, while using a program, you get an error similar to: 

error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory

Use pacman or pkgfile to search for the package that owns the missing library: 

$ pacman -F libusb-0.1.so.4
extra/libusb-compat 0.1.5-1
    usr/lib/libusb-0.1.so.4

In this case, the libusb-compat package needs to be installed. Alternatively, the program requesting the library may need to be rebuilt following a soname bump.

The error could also mean that the package that you used to install your program does not list the library as a dependency in its PKGBUILD: if it is an official package, report a bug; if it is an AUR package, report it to the maintainer using its page in the AUR website.

További olvasnivaló a témában