alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2022-05-14T22:18:12Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13810/etc/pam.d/sddm-autologin requires pam_tally2.so, which breaks autologin2022-05-14T22:18:12ZNoName/etc/pam.d/sddm-autologin requires pam_tally2.so, which breaks autologinAs the title states pam_tally2.so is set to required in /etc/pam.d/sddm-autologin which results in autologin not working, you'll instead be stuck with a blackscreen. A quick look inside /var/log/messages indicates that this library doesn...As the title states pam_tally2.so is set to required in /etc/pam.d/sddm-autologin which results in autologin not working, you'll instead be stuck with a blackscreen. A quick look inside /var/log/messages indicates that this library doesn't exist.
I have therefore set it to optional and that seems to fix autologin.
Is this library even relevant to the autologin feature?https://gitlab.alpinelinux.org/alpine/aports/-/issues/13804[Package proposal] openvpn-respawn-openrc2022-05-12T18:22:54Zblt[Package proposal] openvpn-respawn-openrcNot an issue but a proposal.
I experimented an issue with a not accessible remote server for a couple of weeks before I can got onsite. Server using openvpn and the server in the other end got a radius issue. The openvpn client was kill...Not an issue but a proposal.
I experimented an issue with a not accessible remote server for a couple of weeks before I can got onsite. Server using openvpn and the server in the other end got a radius issue. The openvpn client was killed and no more attempted were made.
I created a supervised version of existing openvpn-openrc to prevent this to happen, asking here first if it does make sense to propose a new package and if there is a better way to do that (I am not a dev). My tweaks are on #supervised part and on reload, all the rest is the same
Thanks!
```
#!/sbin/openrc-run
# supervised
retry="TERM/10/KILL/5/SIGTERM"
supervisor="supervise-daemon"
respawn_max=0
extra_commands="checkconfig"
extra_started_commands="reload stats"
description_reload="Reload OpenVPN using SIGUSR1"
description_stats="Dump OpenVPN statistics to syslog"
instance_name=${RC_SVCNAME#*.}
[ "$instance_name" != "openvpn" ] \
&& name="OpenVPN ($instance_name)" \
|| name="OpenVPN"
# Upper case variables are for backward compatibility with Alpine < v3.8.
: ${cfgdir:=${VPNDIR:-"/etc/openvpn"}}
: ${cfgfile:="$cfgdir/$instance_name.conf"}
: ${detect_client:="${DETECT_CLIENT:-yes}"}
: ${up_script:="$cfgdir/up.sh"}
: ${down_script:="$cfgdir/down.sh"}
: ${peer_dns:=${PEER_DNS:-"yes"}}
pidfile="/run/$RC_SVCNAME.pid"
command="/usr/sbin/openvpn"
## --daemon $instance_name
command_args="
--config $cfgfile
--writepid $pidfile
--setenv RC_SVCNAME $RC_SVCNAME
--setenv PEER_DNS $peer_dns
$command_args"
required_dirs="$cfgdir"
required_files="$cfgfile"
depend() {
need localmount net
use dns
after bootmisc
}
checkconfig() {
# Note: This is not just a check; we need to detect the mode both for
# "start" and "checkconfig" commands, that's why it's here.
if [ -z "$client_mode" ] && yesno "$detect_client"; then
cfgfile_has_option 'remote' \
&& client_mode=yes \
|| client_mode=no
fi
if [ ! -e /dev/net/tun ]; then
if ! modprobe tun; then
eerror "TUN/TAP support is not available in this kernel"
return 1
fi
fi
if [ -h /dev/net/tun ] && [ -c /dev/misc/net/tun ]; then
ebegin "Detected broken /dev/net/tun symlink, fixing"
rm -f /dev/net/tun
ln -s /dev/misc/net/tun /dev/net/tun
eend $?
fi
if yesno "$client_mode"; then
local f; for f in "$up_script" "$down_script"; do
[ -r "$f" ] || { eerror "'$f' is not readable"; return 1; }
done
# Warn about setting scripts as we override them
if cfgfile_has_option "(up|down)"; then
ewarn "WARNING: You have defined your own up/down scripts"
ewarn "As you're running as a client, we now force Alpine specific"
ewarn "scripts to be run for up and down events."
ewarn "These scripts will call /etc/openvpn/$RC_SVCNAME-{up,down}.sh"
ewarn "where you can put your own code."
fi
# Warn about the inability to change ip/route/dns information when
# dropping privs
if cfgfile_has_option "user"; then
ewarn "WARNING: You are dropping root privileges!"
ewarn "As such openvpn may not be able to change ip, routing"
ewarn "or DNS configuration."
fi
fi
}
start_pre() {
checkconfig || return 1
if yesno "$client_mode"; then
command_args="$command_args
--up-delay
--up-restart
--down-pre
--script-security 2
--up $up_script
--down $down_script"
start_inactive="yes"
else
# Run as openvpn unless otherwise specified.
cfgfile_has_option "user" || command_args="$command_args --user openvpn"
cfgfile_has_option "group" || command_args="$command_args --group openvpn"
fi
# If the config file does not specify the cd option, we do.
# But if we specify it, we override the config option which we do not want.
if cfgfile_has_option "cd"; then
command_args="$command_args --cd $cfgdir"
fi
}
start() {
# If we are re-called by the up.sh script, then we don't actually want
# to start OpenVPN. We do this so we can "start" ourselves from
# inactive (from the up.sh script) which then triggers other
# services to start which depend on us.
yesno "$IN_BACKGROUND" && return 0
default_start
}
stop() {
# If we are re-called by the down.sh script, then we don't actually
# want to stop OpenVPN.
if yesno "$IN_BACKGROUND"; then
mark_service_inactive "$RC_SVCNAME"
return 0
fi
default_stop
}
reload() {
ebegin "Reloading $name"
${supervisor} ${RC_SVCNAME} --signal HUP
eend $?
}
stats() {
ebegin "Dumping $name statistics to syslog"
start-stop-daemon --signal USR2 --pidfile "$pidfile"
eend $?
}
cfgfile_has_option() {
grep -Eq "^\s*$1\s" "$cfgfile"
}
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/13803Package request: strike2022-05-11T23:43:29ZAntoni Aloy TorrensPackage request: strikeStrike is a simple minimal IDE for the Linux phones. Code, build, and run from the phone.
Source code: https://invent.kde.org/maui/strikeStrike is a simple minimal IDE for the Linux phones. Code, build, and run from the phone.
Source code: https://invent.kde.org/maui/strikehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13802[Package request] kmonad2022-09-13T08:13:13ZTim[Package request] kmonadhttps://github.com/kmonad/kmonad
KMonad is an advanced tool that lets you infinitely customize and extend the functionalities of almost any keyboard.https://github.com/kmonad/kmonad
KMonad is an advanced tool that lets you infinitely customize and extend the functionalities of almost any keyboard.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13781Possible Bug: PyGObject misbehaving surfaced by GNOME Builder2022-05-06T13:15:13ZSaijin-NaibPossible Bug: PyGObject misbehaving surfaced by GNOME BuilderIn testing the latest build of GNOME Builder, it was revealed that one of the built-in Extensions (rstcheck) was not functioning properly, despite working properly in the flatpak builds.
It was suggested by the maintainer of Builder tha...In testing the latest build of GNOME Builder, it was revealed that one of the built-in Extensions (rstcheck) was not functioning properly, despite working properly in the flatpak builds.
It was suggested by the maintainer of Builder that this might be an issue happening in PyGObject for some reason.
https://gitlab.gnome.org/GNOME/gnome-builder/-/issues/1669Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/docs/user-handbook/-/issues/2"Getting a Graphical Environment" Instructs Installing Nonexistent Package2022-10-25T17:14:12ZJacenBoy"Getting a Graphical Environment" Instructs Installing Nonexistent PackageIn the ["Getting a Graphical Environment" section of the "Post Installation Recommendations" page](https://docs.alpinelinux.org/user-handbook/0.1a/Working/post-install.html#_getting_a_graphical_environment) users are instructed to instal...In the ["Getting a Graphical Environment" section of the "Post Installation Recommendations" page](https://docs.alpinelinux.org/user-handbook/0.1a/Working/post-install.html#_getting_a_graphical_environment) users are instructed to install the `alpine-desktop` package. Trying to install thing with apk gives a "no such package" error. Should either remove this section or update it with more accurate/more clear instructions.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13776xscreensaver in 3.15 complains about being too old2022-05-05T23:22:44ZGray Wolfxscreensaver in 3.15 complains about being too oldWhen running xscreensaver in 3.15, it complains both on startup and on the lock screen that it is too old and should be updated.When running xscreensaver in 3.15, it complains both on startup and on the lock screen that it is too old and should be updated.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13774[Package Request] Pronterface2022-05-04T20:05:42ZWeston Miller[Package Request] PronterfaceThis is simple host software for 3D printing.
https://github.com/kliment/PrintrunThis is simple host software for 3D printing.
https://github.com/kliment/Printrunhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13766main/zsh: no -dev package with headers2022-05-01T05:42:20ZPatrycja Rosaalpine@ptrcnull.memain/zsh: no -dev package with headerszsh allows loading dynamic modules with `zmodload`; unfortunately, even though there are [some modules in aports](https://pkgs.alpinelinux.org/contents?file=*.so&path=%2Fusr%2Flib%2Fzsh%2F5.8.1%2Fzsh&name=&branch=edge), they're only buil...zsh allows loading dynamic modules with `zmodload`; unfortunately, even though there are [some modules in aports](https://pkgs.alpinelinux.org/contents?file=*.so&path=%2Fusr%2Flib%2Fzsh%2F5.8.1%2Fzsh&name=&branch=edge), they're only built within the zsh aport as subpackages and the headers are not being packaged at allJakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13763Package request: k0s2022-05-08T23:12:00ZHoang NguyenPackage request: k0sA lightweight Kubernetes distribution.
Homepage: https://k0sproject.io/
Preferably built with Kubernetes components bundled in the binary.A lightweight Kubernetes distribution.
Homepage: https://k0sproject.io/
Preferably built with Kubernetes components bundled in the binary.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13754zabbix - we must hit refresh several times from screen elements2022-05-02T17:19:00ZPICCORO Lenz McKAYzabbix - we must hit refresh several times from screen elementsthe current alpine stable release (until 2023 it has LTS), has zabbix pacakge with some problems into the map desinger
we must hit several times f5 when there's lot of elements in screen, cos an alert said that width are invalid
![imag...the current alpine stable release (until 2023 it has LTS), has zabbix pacakge with some problems into the map desinger
we must hit several times f5 when there's lot of elements in screen, cos an alert said that width are invalid
![imagen](/uploads/91a62cef7f1f499d049e3928d8ddd3b4/imagen.png)https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/24https urls for apkovl= and alpine_repo= broken in 3.152022-04-27T06:54:00Zsbrudenellhttps urls for apkovl= and alpine_repo= broken in 3.15I'm trying to use the current netboot images. Using an ipxe config like this:
```
kernel http://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86_64/netboot/vmlinuz-virt modules=loop,squashfs nomodeset apkovl=https://f004.backblazeb2.com/...I'm trying to use the current netboot images. Using an ipxe config like this:
```
kernel http://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86_64/netboot/vmlinuz-virt modules=loop,squashfs nomodeset apkovl=https://f004.backblazeb2.com/file/sbrudenell-netboot/test.apkovl.tar.gz alpine_repo=https://dl-cdn.alpinelinux.org/alpine/v3.15/main modloop=https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86_64/netboot/modloop-virt
initrd http://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86_64/netboot/initramfs-virt
```
The initramfs contains mkinitfs v3.6.0:
```
Alpine Init 3.6.0-r0
```
After !89 it seems like the https urls should work, but I get errors:
```
Connecting to f004.backblazeb2.com (149.137.128.16:443)
ssl_client: f004.backblazeb2.com: certificate verification failed: unable to get local issuer certificate
wget: error getting response: Connection reset by peer
...
* Installing packages to root filesystem: fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/main/x86_64/APKINDEX.tar.gz
140234374155080:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1914:
ERROR: https://dl-cdn.alpinelinux.org/alpine/v3.15/main: Permission denied
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.15/main: No such file or directory
```
The ca bundle is present at `/etc/ssl`, but libcrypto is looking in `/etc/ssl1.1`:
```
/ # strace -f wget https://google.com 2>&1 | grep /etc/ssl
[pid 689] open("/etc/ssl1.1/cert.pem", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 689] stat("/etc/ssl1.1/certs/c06d5c68.0", 0x7ffd1fc12c60) = -1 ENOENT (No such file or directory)
[pid 689] stat("/etc/ssl1.1/certs/1001acf7.0", 0x7ffd1fc12c60) = -1 ENOENT (No such file or directory)
[pid 689] stat("/etc/ssl1.1/certs/5ad8a5d6.0", 0x7ffd1fc12c60) = -1 ENOENT (No such file or directory)
[pid 689] stat("/etc/ssl1.1/certs/5ad8a5d6.0", 0x7ffd1fc12c60) = -1 ENOENT (No such file or directory)
```
It looks like ssl dependencies and files are in flux in recent versions.
In 3.15:
* `ssl_client` depends on `libretls`, which depends on `libcrypto1.1` and `ca-certificates-bundle`
* `ca-certificates-bundle` provides `/etc/ssl/certs`
* `libcrypto1.1` provides `/etc/ssl1.1/certs` which symlinks to `/etc/ssl/certs`
* `libcrypto1.1` defaults to `/etc/ssl1.1` for the ssl dir
In edge:
* Dependencies are actively changing. I saw that `ssl_client` switched from depending on `libretls` to `libcrypto1.1` directly, between the time I did `docker run -it alpine:edge` and `apk upgrade` within the container :smile:
* `libcrypto1.1` doesn't provide `/etc/ssl1.1`, but does provide files (not certificates) in `/etc/ssl`
* `libcrypto3` provides `/etc/ssl3`. `/etc/ssl3/certs` symlinks to `/etc/ssl/certs`. No packages depend on `libcrypto3`/`openssl3` currently.
So it seems like `/etc/ssl` is the "canonical" ssl dir, but a default install uses indirection through `/etc/ssl1.1`, *only* in 3.15.
Seems like it would be consistent to change `libcrypto1.1` to load certificates from `/etc/ssl` in 3.15 like it does in other branches, but this seems like a dangerous change.
I can imagine two fixes to the `init` issue:
1. Change the ssl includes in the network feature to wildcards, something like `/etc/ssl*/certs.pem` and `/etc/ssl*/certs`
2. Add `export SSL_CERT_DIR=/etc/ssl/certs; export SSL_CERT_FILE=/etc/ssl/certs.pem` to `init`, as a workaround for 3.15.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13746ERROR: librbd-16.2.7-r5: trying to overwrite usr/lib/librbd.so.1 owned by lib...2022-04-25T10:31:40ZBart RibbersERROR: librbd-16.2.7-r5: trying to overwrite usr/lib/librbd.so.1 owned by librbd17-17.1.0-r0.This happened on several machines nowThis happened on several machines nowhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13735main/fortify-headers does not seem to be a big fan of LTO2023-04-30T15:07:44ZGhost Usermain/fortify-headers does not seem to be a big fan of LTOwhen compiling quite a few c++ programs with -flto, some part of the build process will usually fail with something along the lines of:
```
/usr/include/fortify/stdio.h:70:28: error: inlining failed in call to 'always_inline' 'vsnprin...when compiling quite a few c++ programs with -flto, some part of the build process will usually fail with something along the lines of:
```
/usr/include/fortify/stdio.h:70:28: error: inlining failed in call to 'always_inline' 'vsnprintf': function body can be overwritten at link time
```
some things mistakenly don't actually use lto when trying to currently, then fail with the above. for instance, in community/alembic:
```
CXXFLAGS="$CXXFLAGS -flto -fno-ipa-cp"
cmake -B build -G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE=Release \
-DUSE_HDF5=ON
cmake --build build
```
however, this doesn't actually enable lto. to enable it with cmake you would usually do something along the lines of `-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON`, and then when you do that, you get the above error.
some other aports that fail in the exact same way:
testing/gnuradio (the -U_FORTIFY_SOURCE is there because it implicitly sets lto in cmake, and without disabling either lto or fortify, it fails in the same way)
community/rocksdb (with the -DCMAKE flag above..)
really, most things i try that are c++ fail in this same way.https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10511lbu: support backups of multiple hosts on one device2022-05-13T06:04:11ZRoland Pabellbu: support backups of multiple hosts on one deviceI have two computers running apline and would like to use the same usb stick to save their lbu backup files. But lbu complains when there are two apkovl files present:
~~~
two:/mnt# lbu ci
The following apkovl file(s) were found:
/media...I have two computers running apline and would like to use the same usb stick to save their lbu backup files. But lbu complains when there are two apkovl files present:
~~~
two:/mnt# lbu ci
The following apkovl file(s) were found:
/media/usb/one.apkovl.tar.gz
/media/usb/two.apkovl.tar.gz
Please use -d to replace.
~~~
I understand that apkovl is the active file, since backup_apkovl() in lbu replaces "apkovl" with the date.
But I think the functionality could easily be enabled if lbu would only consider files starting with the hostname, which is true almost everywhere except in these 3 occasions in function cmd_commit():
~~~
line 453: local rmfiles=$(ls "$mnt/"*.apkovl.tar.gz* 2>/dev/null)
line 460: [ -z "$DRYRUN" ] && rm "$mnt/"*.apkovl.tar.gz*
line 463: lines=$(ls -1 "$mnt"/*.apkovl.tar.gz* 2>/dev/null)
~~~
I changed these locally to `${hostname}.*.apkovl.tar.gz` and that works as expected.
What I don't know is: Is this by design? Should there ever only be one apkovl file on any given device?https://gitlab.alpinelinux.org/alpine/aports/-/issues/13732QUESTION: Automatic/Unattended installation2023-12-02T23:35:57ZCarlo CorradiniQUESTION: Automatic/Unattended installation_Sorry for posting a question, but I've searched for a possible solution without success._
I've created a custom ISO following [How to make a custom ISO image with mkimage](https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_imag..._Sorry for posting a question, but I've searched for a possible solution without success._
I've created a custom ISO following [How to make a custom ISO image with mkimage](https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage) and I'd like to completely automate the installation when the system boots up.
I've tried creating a custom `genapkovl` (following [genapkovl-dhcp.sh](https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/genapkovl-dhcp.sh) example and [this tutorial](https://wejn.org/2022/04/alpinelinux-unattended-install/)) that creates a file under _/etc/local.d_ and executes it on boot (added via `rc_add local boot`).
The script in _/etc/local.d_ runs `setup-alpine` with a preconfigured answerfile.
Unfortunately, the overall procedure does not work 😥
I've tried everything without success.
Any help is greatly appreciated 🥳
Thanks! 🤗https://gitlab.alpinelinux.org/alpine/aports/-/issues/13731community/dnscrypt-proxy: run as 'dnscrypt' interferes with dnscrypt-proxy op...2022-04-19T23:11:42ZDannycommunity/dnscrypt-proxy: run as 'dnscrypt' interferes with dnscrypt-proxy opening port 53Context: this is an issue in installing _dnscrypt-proxy_ on PostmarketOS. AFAICT it uses this repository.
See https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/dnscrypt-proxy/dnscrypt-proxy.initd#L8
_dnscrypt-proxy_,...Context: this is an issue in installing _dnscrypt-proxy_ on PostmarketOS. AFAICT it uses this repository.
See https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/dnscrypt-proxy/dnscrypt-proxy.initd#L8
_dnscrypt-proxy_, by default, opens port `53` for TCP and UDP. The openrc-init procedure runs dnscrypt-proxy as user `dnscrypt` causing it to fail initialization due to missing privileges. _dnscrypt-proxy_ can be configured to perform privilege lowering to a specified username in the configuration, but not commandline.
Errors become visible with `command_background="no"`. (And there is probably an easier way.)https://gitlab.alpinelinux.org/alpine/aports/-/issues/13730community/hyphen: support more languages2022-04-19T17:57:43ZJohannes Arnoldcommunity/hyphen: support more languagesCurrently, [hyphen](/community/hyphen/APKBUILD) only has a [hyphen-en](https://pkgs.alpinelinux.org/package/edge/community/x86_64/hyphen-en) subpackage, which appears to link all language dictionaries to `hyph_en_US.dic`.
Would it be po...Currently, [hyphen](/community/hyphen/APKBUILD) only has a [hyphen-en](https://pkgs.alpinelinux.org/package/edge/community/x86_64/hyphen-en) subpackage, which appears to link all language dictionaries to `hyph_en_US.dic`.
Would it be possible to have subpackages which link a specific language to its dictionary? I question the efficacy of "faking" over 20 other languages' hyphenation to US-American.Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13709setup-disk with sys mode on Raspberry 4 using 3.15.4-aarch64 fails2022-04-15T23:57:34Zcmonty14setup-disk with sys mode on Raspberry 4 using 3.15.4-aarch64 failsHello,
I have prepared a SSD for RPi 4 based on the instructions [Classic install or sys mode on Raspberry Pi](https://wiki.alpinelinux.org/wiki/Classic_install_or_sys_mode_on_Raspberry_Pi), however this workaround
```
mount /dev/sda2 /...Hello,
I have prepared a SSD for RPi 4 based on the instructions [Classic install or sys mode on Raspberry Pi](https://wiki.alpinelinux.org/wiki/Classic_install_or_sys_mode_on_Raspberry_Pi), however this workaround
```
mount /dev/sda2 /mnt # The second partition, in ext4 format, where Alpine Linux is installing in sys mode
export FORCE_BOOTFS=1 # work around for issue 12353
setup-disk -m sys /mnt
```
fails with the well known error:
"Ext4 is not supported. Only supported are: VFAT"
Then I tried to install Alpine using `setup-alpine`, but this fails with an error that no disk is identified.
Only the boot partition mounted on _/media/sda1_ is identified, although I can mount /dev/sda2 to any mountpoint.
Please advise how to fix this.
THXhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13706GNOME on Xorg either crashing or working very very slowly2024-03-09T18:49:33ZlinuxuserGNOME on Xorg either crashing or working very very slowlyGNOME, when started via startx, behaves like a powerpoint slide. It renders frame by frame _ONLY_ when I'm switching between TTY's (e.g. CTRL + ALT + F2). <br><br>
**This is the content of my .xinitrc: <br>**
`export XDG_SESSION_TYPE=x1...GNOME, when started via startx, behaves like a powerpoint slide. It renders frame by frame _ONLY_ when I'm switching between TTY's (e.g. CTRL + ALT + F2). <br><br>
**This is the content of my .xinitrc: <br>**
`export XDG_SESSION_TYPE=x11` <br>
`export GDK_BACKEND=x11` <br>
`exec gnome-session` <br><br>
Whereas when I try to start it via GDM, it just kicks me back to the login-screen. <br>
I am using an AMD RX 6800 XT and a Ryzen 5 3600, with kernel version 5.15 LTS, so there shouldn't be any hardware problems. <br><br>
This is my latest Xorg.log file: [Xorg.0.log](/uploads/91f834de3f469870c1f0c368e5c0862f/Xorg.0.log)Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.dev