tiyn/wiki
1
0
Fork 0
mirror of https://github.com/tiyn/wiki.git synced 2025-04-02 15:07:45 +02:00
Code Issues Projects Releases Wiki Activity

arch linux: added some troubleshooting

Browse Source
This commit is contained in:
tiyn 2024-11-05 05:05:47 +01:00
parent e59df03559
commit 28486ed624
2 changed files with 63 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
wiki/linux/arch-linux.md
View File

@ -61,3 +61,55 @@ initrd /<installed microcode package>.img
```
`<installed microcode package>` is either `amd-ucode` or `intel-ucode`.
## Troubleshooting
This section addresses problems that can occur when using Arch Linux.
### Troubleshooting Setup for not Bootable Systems
This section focusses on a basic guide to troubleshoot systems that are not bootable.
To access the files of the system an Arch Linux boot stick has to be created as explained in
[a previous section](#iso-medium).
After booting into it set your keymap layout using the `loadkeys` setup similar to
[the installation preparation](/wiki/linux/arch-linux/installation.md#1-preparation).
Afterwards [mount](/wiki/linux/disk-management.md#mounting) the partition that contains the root
file system to the `/mnt` directory.
It is possible that LUKS encrypted file systems need to be
[opened](/wiki/linux/dm-crypt.md#openclose-an-encrypted-volume) and then mounted using the
`/dev/mapper` symbolic link.
On some systems there are home or boot file system that have to be mounted on `/mnt/boot` or
`/mnt/home` after mounting the root file system.
Afterwards use `arch-chroot /mnt` to get into the not bootable system.
Now the command line of the system can be accessed for troubleshooting.
After troubleshooting `exit` the system and [unmount](/wiki/linux/disk-management.md#mounting) all previously
mounted file systems and try to boot back into the system.
Probably the most common source for not bootable systems is
[the initial ramdisk](#problems-with-the-initial-ramdisk).
### Problems with the Initial Ramdisk
A common problem (especially after a interrupted update lies in the initial ramdisk environment).
An error like this will mean that the system is
[not bootable](#troubleshooting-setup-for-not-bootable-systems).
To fix this generate the initial ramdisk manually as described in
[the mkinitcpio entry](/wiki/linux/mkinitcpio.md#manually-generate-initial-ramdisk).
### Stuck in Boot Screen
There is a known problem described in the Arch Linux forums by
[TheRealNubby](https://bbs.archlinux.org/viewtopic.php?id=300292) where the system goes into a
perceived freeze after the boot process.
This problem seems to be most prevalent on systems that use an [Nvidia](/wiki/nvidia.md) GPU
since its only known occurences were found on Nvidia GTX 1080 GPUs.
The boot screen will not show any errors and when
[troubleshooting using a installation medium](#troubleshooting-setup-for-not-bootable-systems)
logs like [the ones of SystemD](/wiki/linux/systemd.md#retrieving-the-systemd-logs) will look
normal and won't show any errors.
In this case there is the possibility that logging into Arch Linux blindly will work.
For this type in user name and password some moments after the perceived freeze as you normally
would do if the login screen came up.
If the graphical interface still does not work, the command to start the graphical interface (like
`startx` for [X11](/wiki/linux/x_window_system.md) systems) can also work.

12
wiki/linux/systemd.md
View File

@ -43,7 +43,7 @@ Alternatively it can be enabled to start at every boot by running:
sudo systemctl enable unturned
```
## Start/Stop/Enable/Disable a service
### Start/Stop/Enable/Disable a service
Services can be started by running `systemctl start <service-name>`.
They respectively can be stopped by replacing the `start`
@ -51,3 +51,13 @@ keyword for `stop`.
To start the service after boot it has to be enabled.
This works accordingly with the keyword `enable`.
The `disable` keyword stops the service from starting automatically.
### Retrieving the SystemD Logs
SystemD logs can easily be found using the `journalctl` command.
One of the most notable usages of the command is for checking the logs of the previous boot.
This can be achieved by running the following command.
```sh
journalctl -b-1
```