Yes something like that in conjunction with UEFI.
But how to overcome it?
Issue new UEFI keys?
Yes something like that in conjunction with UEFI.
But how to overcome it?
Issue new UEFI keys?
Why did apparmor not cause problems with the previous kernel but it does with this kernel?
apparmor has a module enabled in the proxmox kernel. Maybe the 6.1 kernel does not? I don't have a system with it installed to look at the kernel config.
aaron@omv7dev:~$ grep -i apparmor /boot/config-6.5.*
/boot/config-6.5.0-0.deb12.4-amd64:CONFIG_SECURITY_APPARMOR=y
/boot/config-6.5.0-0.deb12.4-amd64:# CONFIG_SECURITY_APPARMOR_DEBUG is not set
/boot/config-6.5.0-0.deb12.4-amd64:CONFIG_SECURITY_APPARMOR_INTROSPECT_POLICY=y
/boot/config-6.5.0-0.deb12.4-amd64:CONFIG_SECURITY_APPARMOR_HASH=y
/boot/config-6.5.0-0.deb12.4-amd64:CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
/boot/config-6.5.0-0.deb12.4-amd64:CONFIG_SECURITY_APPARMOR_EXPORT_BINARY=y
/boot/config-6.5.0-0.deb12.4-amd64:CONFIG_SECURITY_APPARMOR_PARANOID_LOAD=y
/boot/config-6.5.0-0.deb12.4-amd64:CONFIG_DEFAULT_SECURITY_APPARMOR=y
/boot/config-6.5.0-0.deb12.4-amd64:CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf"
/boot/config-6.5.11-8-pve:CONFIG_SECURITY_APPARMOR=y
/boot/config-6.5.11-8-pve:# CONFIG_SECURITY_APPARMOR_DEBUG is not set
/boot/config-6.5.11-8-pve:CONFIG_SECURITY_APPARMOR_INTROSPECT_POLICY=y
/boot/config-6.5.11-8-pve:CONFIG_SECURITY_APPARMOR_HASH=y
/boot/config-6.5.11-8-pve:CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
/boot/config-6.5.11-8-pve:CONFIG_SECURITY_APPARMOR_EXPORT_BINARY=y
/boot/config-6.5.11-8-pve:CONFIG_SECURITY_APPARMOR_PARANOID_LOAD=y
/boot/config-6.5.11-8-pve:# CONFIG_SECURITY_APPARMOR_RESTRICT_USERNS is not set
/boot/config-6.5.11-8-pve:CONFIG_DEFAULT_SECURITY_APPARMOR=y
/boot/config-6.5.11-8-pve:CONFIG_LSM="lockdown,yama,integrity,apparmor"
Alles anzeigen
root@debnas:/var/log# grep -i apparmor /boot/config-6.1.*
/boot/config-6.1.0-0.deb11.11-amd64:CONFIG_SECURITY_APPARMOR=y
/boot/config-6.1.0-0.deb11.11-amd64:# CONFIG_SECURITY_APPARMOR_DEBUG is not set
/boot/config-6.1.0-0.deb11.11-amd64:CONFIG_SECURITY_APPARMOR_INTROSPECT_POLICY=y
/boot/config-6.1.0-0.deb11.11-amd64:CONFIG_SECURITY_APPARMOR_HASH=y
/boot/config-6.1.0-0.deb11.11-amd64:CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
/boot/config-6.1.0-0.deb11.11-amd64:CONFIG_SECURITY_APPARMOR_EXPORT_BINARY=y
/boot/config-6.1.0-0.deb11.11-amd64:CONFIG_SECURITY_APPARMOR_PARANOID_LOAD=y
/boot/config-6.1.0-0.deb11.11-amd64:CONFIG_DEFAULT_SECURITY_APPARMOR=y
/boot/config-6.1.0-0.deb11.11-amd64:CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf"
/boot/config-6.1.0-0.deb11.13-amd64:CONFIG_SECURITY_APPARMOR=y
/boot/config-6.1.0-0.deb11.13-amd64:# CONFIG_SECURITY_APPARMOR_DEBUG is not set
/boot/config-6.1.0-0.deb11.13-amd64:CONFIG_SECURITY_APPARMOR_INTROSPECT_POLICY=y
/boot/config-6.1.0-0.deb11.13-amd64:CONFIG_SECURITY_APPARMOR_HASH=y
/boot/config-6.1.0-0.deb11.13-amd64:CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
/boot/config-6.1.0-0.deb11.13-amd64:CONFIG_SECURITY_APPARMOR_EXPORT_BINARY=y
/boot/config-6.1.0-0.deb11.13-amd64:CONFIG_SECURITY_APPARMOR_PARANOID_LOAD=y
/boot/config-6.1.0-0.deb11.13-amd64:CONFIG_DEFAULT_SECURITY_APPARMOR=y
/boot/config-6.1.0-0.deb11.13-amd64:CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf"
Alles anzeigen
I don't see any difference but there might be a difference in the code. The proxmox kernel is an Ubuntu kernel and Ubuntu systems always have apparmor installed. Debian lets apparmor be optional. So, there is evidently a difference somewhere.
chente: what did you do to get the iGPU available in Jellyfin?
My Jellyfin works but whenever i select transcoding videos do not playback anymore (file not compatible..).
I have these env variables in my docker YML:
And this config in Jellyfin
Alder Lake does not support VP8. https://es.wikipedia.org/wiki/Intel_Quick_Sync_Video
I have it like this:
In docker only this:
And the user "appuser" added in the render and video groups.
Are you running the official Jellyfin docker or the linuxserver.io one?
Because i got my env variables from the official documentation and they are correct.
Will cross of VP8 but that is not gonna solve it.
It seems my Jellyfin does not have access to the iGPU for rendering:
Alder Lake does not support VP8. https://es.wikipedia.org/wiki/Intel_Quick_Sync_Video
I have it like this:
In docker only this:
I thought VA-API is recommended for this hardware? You are running QSV
If you're using a Firestick 4k or Shield then you should uncheck everything but VP8 and VC1.
---
version: "2.1"
services:
jellyfin:
image: lscr.io/linuxserver/jellyfin:latest
container_name: jellyfin
environment:
- PUID=${PUID}
- PGID=${PGID}
- TZ=${TZ}
volumes:
- ./config:/config
- ./cache:/cache
- /DATOS_DESV/multimedia:/DATOS_DESV/multimedia:ro # SKIP_BACKUP
- /DATOS_DESV/multimedia2:/DATOS_DESV/multimedia2:ro # SKIP_BACKUP
- /DATOS_AITI/multimedia:/DATOS_AITI/multimedia # SKIP_BACKUP
devices:
- /dev/dri:/dev/dri
ports:
- 8096:8096
restart: unless-stopped
Alles anzeigen
I thought VA-API is recommended for this hardware? You are running QSV
VA-API is not required. The drivers are integrated into the kernel starting with kernel 6.2
Oh yeah that seemed to have changed since then ok. Will try with QSV.
My yaml file is fine. It is identical except for the device driver part.
As i said above:
Official Jellyfin documentation says to use --device /dev/dri/renderD128:/dev/dri/renderD128
linuxserver.io says to use /dev/dri:/dev/dri
I am using the offical jellyfin/jellyfin
As i said above:
Official Jellyfin documentation says to use --device /dev/dri/renderD128:/dev/dri/renderD128
linuxserver.io says to use /dev/dri:/dev/dri
If you do this:
/dev/dri:/dev/dri
you are passing the entire /dev/dri folder to the container, including /dev/dri/renderD128 and everything in it.
Ah ok makes sense. I wasnt aware...but now looking at it i understand
And the user "appuser" added in the render and video groups.
Is the user who runs the container in those two groups?
It's weird. No matter what i do, the /dev/dri folder doesnt show up in the container.
I set up PUID and PGID and also added the user to the video and render group. Still doesnt work.
(just also remarked i am actually also running the linuxserver image )
version: "3.6"
services:
jellyfin:
container_name: "jellyfin"
environment:
- "TZ=Europe/Berlin"
- "PUID=1006"
- "PGID=100"
# - "DEVICE=/dev/dri/renderD128:/dev/dri/renderD128"
# - "DEVICE=/dev/dri/card0:/dev/dri/card0"
- "DEVICE=/dev/dri:/dev/dri"
image: "lscr.io/linuxserver/jellyfin:nightly"
network_mode: "bridge"
ports:
- "8096:8096/tcp"
restart: "always"
volumes:
- "/srv/9379aef8-4c1e-43c1-ab84-31fd2aa5b875/FTP_usenet/Moviez:/data/movies" # SKIP_BACKUP
- "/srv/9379aef8-4c1e-43c1-ab84-31fd2aa5b875/FTP_usenet/Moviez Kinder:/data/movies kinder" # SKIP_BACKUP
- "/srv/9379aef8-4c1e-43c1-ab84-31fd2aa5b875/FTP_usenet/neueMucke:/data/music" # SKIP_BACKUP
- "/srv/9379aef8-4c1e-43c1-ab84-31fd2aa5b875/FTP_usenet/Serien:/data/tvshows" # SKIP_BACKUP
- "/srv/dev-disk-by-label-SSD_Data/appdata/jellyfinDocker:/config"
- "/srv/9379aef8-4c1e-43c1-ab84-31fd2aa5b875/JulyPaddy/Fotos:/data/fotos" # SKIP_BACKUP
networks:
default:
name: bridge
external: true
enable_ipv6: true
Alles anzeigen
id 1006 gives me:
uid=1006(dockeruser) gid=100(users) Gruppen=100(users),27(sudo),44(video),1001(ftpadmin),1002(ftpuser),117(render)
Also did a:
Checking the folder inside the container:
What is going on here?
image: "lscr.io/linuxserver/jellyfin:nightly"
Do you run the nightly version for any special reason?
Checking the folder inside the container:
What do you have on the host in /dev/dri?
ls -al /dev/dri
Do you run the nightly version for any special reason?
What do you have on the host in /dev/dri?
ls -al /dev/dri
Yes there was a reason why i switched to it. Dont ask me, i forgot
Yes there was a reason why i switched to it. Dont ask me, i forgot
If it has been a long time since then, the solution you needed will probably have been adopted in the standard version, so I would eliminate the nightly version. It could cause other unexpected problems for you.
Everything seems correct, I can't think of why the container doesn't see that folder...
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!