FF Blog

MinID som alternativ til BankID

Fredrik Sætereng Fyksen — Fri, 10 Apr 2026 08:08:26 +0000

Jeg ønsker å gjøre meg så fri fra proprietære løsninger som mulig. Og i den forbindelse prøver jeg å kvitte meg med alle apper på telefonen min som krever Google Play services. På sikt hadde det vært moro å bruke PostmarketOS på telefonen til daglig.

Hva er forskjellen på BankID og MinID

Begge tjenestene brukes til å logge inn på offentlige tjenester.

Eiere og driftes

BankID eies av Vipps, som igjen eies av banker. DNB er største eier, og Sparebanken på en god andreplass.
MinID er et produkt utviklet og forvaltet av Digitaliseringsdirektoratet.

Ulikt sikkerhetsnivå

BankID støtter «høyt sikkerhetsnivå»
MinID støtter bare «betydelig sikkerhetsnivå»

Du kan lese litt mer om sikkerhetsnivåene på norge.no sine sider.

BankID støtter flere nettsider

BankID støtter ID Porten, banktjenester, betalingstjenester og mange selskap bruker BankID som elektronisk signering av dokumenter etc.
MinID støter kun ID Porten.

ID Porten er portalen man kan velge hvilken innloggingsmetode man ønsker å bruke for offentlige tjenester.

Hvorfor vil jeg ha MinID

MinID støtter standard 2fa innlogging. Som betyr at jeg kan bruke mine foretrukne 2fa applikasjon Aegis Authenticator. Mulighet for å ta lokal backup av authentiseringsnøklene til et format som støttes i flere applikasjoner, og bruke tjenesten på enheter som ikke er Android og Apple telefoner er viktig for meg.

Hvordan opprette MinID

Bestill aktiveringskoder i posten fra minid.no
Registrer koden du får på brev i posten på registrer.minid.no
- Registrer telefonnummer, epost og fødselsnummer.
Logg inn på profil.minid.no
- Scroll ned til «To-faktor metoder», og velg «engangskode fra autentiserings-app». Herfra kan du legge til 2fa som hvilken som helst annen nettside.

Skjermbilde fra profil.minid.no

Dessverre finner jeg ikke noen måte og deaktivere SMS-koder som reserveløsning for tofaktor. Så man er ikke trygg fra SIM angrep.

Takk for at du kom til min TED talk, hade bra!

Vi må rigge oss for alternativer

Fredrik Sætereng Fyksen — Fri, 06 Mar 2026 12:14:30 +0000

Android operativsystemet kjører på nesten alle smarttelefoner som ikke bruker Apples iOS. Android er åpen kildekode. Dessverre blir telefoner som kjører Android mer låst ned for hver dag som går. Utfordringene er mange, men de viktigste mener jeg er:

Mobilprodusentene låser ned telefonen så man kan ikke installere alternative versjoner av Android på mobilene. (Hederlige unntak er Googles egen Pixel-serie, og Fairphone).
Applikasjonsmakerne bruker tjenester som bare er tilgjengelig via Google Play services.

Denne posten handler om sistnevnte. Google play services, og spesifikt hvilke tjenester jeg kunne ønske norske leverandører stoppet å bruke.

Pushvarsel

De fleste av oss har et forhold til pushvarsel. Her er allikevel et kjapt forsøk på å forklare. La oss ta Vipps sin applikasjon som et eksempel. En venn sender deg penger, og du får et varsel på telefonen. Varselet ble sendt fra Vipps, via Google, og så til telefonen din.

Grunnen til at varselet ikke går direkte fra Vipps sine servere og til din telefon, er for å spare prosessorkraft (og dermed også batteri). Ved å samle alle varselsendinger via en strøm, blir det færre oppkoblinger for telefonen.

Det er to store problemer med at applikasjoner bruker Google Play Services for pushvarsler: Metadata og lock-in.

Google mottar masse data

Google får mye data om din data fra pushvarsler.

Hvilken applikasjon som mottar pushvarselet.
Når pushvarselet var sendt fra Vipps sine servere og mottatt på enheten.
Hvilken google brukerkontor varselet ble sendt til.
Innholdet i varselet (bare om applikasjonen ikke har satt opp kryptering).

I tillegg har det vist seg å være vanskelig for applikasjonsutviklere og holde tunga rett i munnen når de skal sende pushvarseler. I studien «The Medium is the Message: How Secure Messaging Apps Leak Sensitive Data to Push Notification Services», kan man lese at av de 20 krypterte meldingsapplikasjoner som ble analysert, sendte 11 av de informasjon som kan brukes til å identifisere deg til Google.

Om man ønsker å bruke en alternativ versjon av Android uten Google sine tjenester, fungerer ikke pushvarseler. I praksis betyr det at du ikke får varselet fra Vipps før du åpner appen.

Google Play Store

Android kan installere applikasjoner fra mange steder. Man kan laste ned installasjonsfiler fra Internett, eller bruke alternative applikasjonsbutikker.

Dessverre er Google Play Store det eneste stedet Vipps publiserer applikasjonen sin. For å bruke Google Play Store må man ha Google bruker, og en telefon med Google Play Services. Entusiaster kan laste ned applikasjonen fra alternative nettsider som republiserer applikasjoner fra Play Store. Men her er det vanskelig og vite om installasjonsfilene er tuklet med.

Play Integrity API

For mange er første gangen de hørte om Play integrity i kode 24. Her kunne man lese om hvordan «Ikke mulig å bruke Vipps og samtidig være fri fra amerikansk Big Tech», samt «Dette svarer Vipps til kommentaren fra Robin Heggelund Hansen». I praksis leverer Play integrity en tjeneste for utviklere til å sjekke om Google mener telefonen er trygg, og ikke tuklet med. Dette er uten tvil den største hindringer for entusiaster å komme seg rundt. Man kan lese side opp og side ned om brukere som lurer på om Play integrity fungerer på deres alternative versjon av Android.

Alternativene finnes

For pushvarsel bør applikasjoner bruke Unifiedpush. Unifiedpush er et desentralisert pushvarsel system som lar brukeren velge pushvarsel-leverandør. Det er utviklet for å være sikkert, fleksibelt og åpent. Noen og tredve applikasjoner støtter allerede Unifiedpush. Om man installerer en applikasjon som støtter Unifiedpush på en telefon med kun Google Play Services, så vil push-varselet sendes via Google som vanlig. Dermed vil ikke den jevne brukeren merke at applikasjonen støtter Unifiedpush, og man ødelegger ingen brukeropplevelser.

Et godt Google Play store alternativ er F-Droid. F-Droid er en applikasjonsbutikk som ut av boksen bare inneholder applikasjoner med åpen kildekode. Heldigvis støtter F-Droid alternative pakkearkiver. Vipps kunne publisert apk-ene sine i et slik pakkearkiv. F-Droid har god dokumentasjon på hvordan Vipps selv kan ta kontroll på hele publikasjonskjeden. Det er ikke så vanskelig og se for seg en fremtid hvor Google sperrer Vipps ut av Google Play Service, om de blir en for stor konkurrent til Google egen «Google Wallet», eller om de bryter med en av Google Play Services diffuse regler. Selvfølgelig burde Vipps fortsette å publisere til Google Play butikken, samtidig som de publiserer til et F-Droid pakkearkiv.

Så er vi på Play integrity, som Vipps selv mente var vanskelig og bytte ut. Her er jeg til dels enig. Vipps sier til kode24 at de ikke må bruke Play integrity, men «løsningen dekker en stor del av det vi må ivareta rundt integritet av både enhet og app. ... Jeg vil si at det som gjør det vanskelig å gjøre endringer her er vel så mye det rundt avtaler, dokumentasjonskrav og revisjoner, som det er den tekniske løsningen.». Siden jeg ikke har innsikt i hvilke forpliktelser Vipps har med betalingsleverandørene, så er det vanskelig og komme med et teknisk alternativ. GrapheneOS (en distribusjon av Android med særlig fokus på sikkerhet) peker på «standard Android hardware attestation API». Men skulle være papirmøllene til betalingsleverandørene som stopper bruk av alternative åpen Android, vil jeg oppfordre Vipps til å dele det offentlig, så man har mulighet til å legge press mot riktig instans.

Utfordringer, oppfordringer og drømmer

Det er få som har blitt rike av å støtte åpne standarder. Det er dårlig butikk å bruke penger på å utvikle tjenester den gemene hop ikke bruker. I disse ulvetider mener jeg det allikevel er hensiktsmessig at applikasjoner fra det offentlige (og selskaper med særlig samfunnsansvar) støtter åpne standarder. Ikke bare kan innbyggere velge om de vil ha big tech i lomma, men vi gjør det også mulig for nye konkurrenter og innovere, uten å spille ball med Google og Apple. Og skulle det i fremtiden bli enda vanskeligere og samarbeide med USA, er det veldig kjekt og ha klar selvstendig infrastruktur.

Så kjære mellomledere og utviklere av applikasjonene til Vipps, BankID, Ruter, Posten, MinID, Entur, Vy også videre. Prøv å ta grep for å gjøre det enklere å velge bort selskapene som logrer for monopol og diktatur. Kanskje applikasjonene deres til og med kan bli publisert som åpen kildekode? Bevegelsen Public Money, Public Code begynner å bli store i Europe.

En av tingene som er vanskelig med et føderert Internett

Fredrik Sætereng Fyksen — Mon, 26 Jan 2026 10:43:37 +0000

Vi som jobber for et åpent Internet med klienter som snakker med hverandre på tvers av servere (føderert som epost, ikke som Signal eller facebook), opplever ofte at teknologien vår er upraktisk hva gjelder og finne gamle kjente, og verifisere at brukeren er den hen gir ser ut for å være.

Et av ankerpunktene ved å bruke Matrix chat (eller Mastodon, ActivityPub), er at man ikke har den samme sentrale databasen med metadata om brukerne som f.eks Facebook eller Signal har.

Verifisering til besvær

Når du åpner Signal for første gang, får du spørsmål om du vil dele kontaktene dine med appen, for å se om noen av dine venner allerede er medlemmer. Signal kan være helt sikker på at tlf-nummeret mitt er 81549300, fordi jeg har bevist til Signal at jeg kan motta koden de sendte til nummeret. Men om Signal var satt sammen av tusenvis av servere (som Matrix er), så måtte hver enkel server sende en sms til meg med en enganskode. Det funker jo ikke i praksis. Det samme gjelder e-post.

Om vi hardnakket vil fortsette å bruke tlf-nummer som identitet må vi ha felles identitetsservere vi stoler på. For eksempel kunne vi hatt matrix-identiteter.no som en felles Norsk Sydent server, hvor alle som vil kan spørre tjeneren om verifisering og oppslag. Dette har dessverre noen ulemper. De største er:

Hvordan forsvarer man seg mot at en server ikke skraper kontaktdataene og sender spam?
Hvordan får man folk til å villig dele ut kontaktdataene sine?

Et bedre alternativ?

Personlig tror jeg telefonnummerets tid er talte. Jeg liker godt hvordan Mastodon har løst det hvor man kan verifisere at man eier en nettside ved å lenke til brukeren sin fra domenet. På min Mastodon profil, kan alle se at jeg har skrivetilgang til domenene fyksen.me og norge.chat. Og alle Mastodon servere kan sjekke dette, uten at vi trenger og stole på en felles database. Den store ulempen er selvfølgelig at ikke alle har domener eller websider, og at domenet ikke funker godt som oppslag. En venn har jo (dessverre) ikke lagret meg i kontaktlista med et eget notat som sier "eier fyksen.me", som igjen kan brukes som reversert oppslag til min Mastodon konto.

Dette er altså grunnen til at jeg ikke (enda?) har satt opp en felles Norsk Sydent server.

Energigel i Norge

Fredrik Sætereng Fyksen — Thu, 02 Oct 2025 08:14:17 +0000

Det er ingen tvil om at det er mye markedsføring i gode gels. For produkter som i bestefall er sukker, fruktsukker, syltepulver og vann er det fryktelig mye «babl». For en liten stund siden begynte jeg å undersøke effekten av ernæring under trening, og det gikk opp for meg at det kanskje er litt og hente på å mer aggressivt fylle energilagrene underveis i treningen. Det var denne videoen av Göran Winblad som sparket i gang dette.

Jeg var klar over at tidlig påfylling av raske karbohydrater etter økter var gunstig for restitusjon. Det jeg ikke var klar over er at man i stor grad kan trene opp magen til å innta karbohydrat underveis i treningsøkter. Dette er viktig både for lange konkurranser, men ikke minst for å kunne restituere fortere fra-, og tåle mer trening.

En annen ting jeg ikke var klar over, var at magen klarer og ta opp mer karbohydrat om fyller på med både glukose og fruktose.

Bevæpnet med min nye kunnskap løp jeg virtuelt så fort som mulig til en internettbutikk nær meg. Og få oversikt over fruktose/glukose-forhold og pris skulle være mer jobb en først antatt. Mange gels inneholder bare glukose, så jeg måtte ofte sjekke næringsinnhold for å se forskjellen. I tillegg var forholdet Glukose:Fruktose sjeldent oppgitt, så jeg måtte i enkelte tilfeller kontakte produsenten.

Navn	Pris pr ml	Glukose:Fruktose	Gel størrelse (g)	Carbo per gel	Antall i pakke	Pris på pakke	Pris pr gel	Kroner pr karbo	Lenke
Enervit C2:1 Carbo	kr 0.69	2:1	60	40	24	kr 999.00	kr 41.63	kr 1.04	sykkelkomponenter
SIS Beta Fuel	kr 0.42	1,3:1	60	40	30	kr 749.00	kr 24.97	kr 0.62	sykkelkomponenter
Maurten Gel 160	kr 0.85	1,25:1	65	40	10	kr 550.00	kr 55.00	kr 1.38	sykkelkomponenter
Fuel of Norway original	kr 0.64	2:1	55	31	20	kr 699.00	kr 34.95	kr 1.13	bikeshop
Fuel of Norway loaded	kr 0.58	1,25:1	65	40	20	kr 749.00	kr 37.45	kr 0.94	sykkelkomponenter

Kjenner jeg meg selv rett, kommer ikke denne lista til å holdes oppdatert. Se på den som et øyeblikksbildet i tid da denne posten ble skrevet (2 oktober 2025).

Har du flere gels med fruktose og glukose, med god pris som burde komme på lista? Skyt meg en epost på fredrik@fyksen.me

Auto import from SD card to Immich

Fredrik Sætereng Fyksen — Fri, 18 Jul 2025 17:56:27 +0000

I recently bought a Fuji mirrorless camera, and want to make it as smooth as possible to upload photos to Immich. After I have imported, I delete the images I do not want.

Labeling the SD card and automount

Fuji does not set a UUID or a label on the SD card when you format it. This is a bit annoying, since it makes is harder to automate the process that all cards formatted with a Fuji camera should automatically mount to /mnt/fuji. The workaround I went for is to create a label on the SD card manually after each format.

First find the path to your memory card with fdisk -l. Mine was /dev/sdg1

Then I put a label (DCIM) on it with:

sudo exfatlabel /dev/sdg1 DCIM

We can now edit the file /etc/fstab
Add the line:

/dev/disk/by-label/DCIM  /mnt/fuji  exfat  noexec,nodev,nosuid,nofail  0 0

We also need to add a udev rule, to have it automount.

Edit the file /etc/udev/rules.d/99-dcim-mount.rules

With the content:

# Mount when the card appears
ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="DCIM", TAG+="systemd", \
  ENV{SYSTEMD_WANTS}+="mnt-fuji.mount"

# (Optional) cleanly unmount when it’s pulled
ACTION=="remove", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="DCIM", RUN+="/usr/bin/umount /mnt/fuji"

Create the dir, reload systemd, and test mount:

mkdir /mnt/fuji
udevadm control --reload
systemctl daemon-reload
mount -a

Creating systemd file to start bash script

Create the systemd service file for running the script:

/etc/systemd/system/auto-upload-immich.service

With the content:

[Unit]
Description=Archive .raf  and import jpeg to Immich
BindsTo=dev-disk-by\x2dlabel-DCIM.device     # die when the device goes away
After=dev-disk-by\x2dlabel-DCIM.device
RequiresMountsFor=/mnt/fuji                  # systemd mounts it for us
ConditionPathIsMountPoint=/mnt/fuji

[Service]
Type=oneshot
Environment="IMMICH_API_KEY=<yourAPIkey"
Environment="IMMICH_INSTANCE_URL=https://<yourdomain.immich.domain>"
Environment="MOUNT_DIR=/mnt/fuji/DCIM/100_FUJI/"
Environment="RAW_DIR=/mnt/appdata/rawfiles/"
Environment="WEBHOOK_ENDPOINT=<endpoint if you want to ping a webhook>"
Environment="SD_CARD_MOUNT=/mnt/fuji"
Environment="HA_URL=https://homeassistant.yourdomain.com/api/webhook/-webhookID"
ExecStart=/usr/local/bin/auto-upload-immich.sh --when=inserted --mount-point=/mnt/fuji

[Install]
WantedBy=dev-disk-by\x2dlabel-DCIM.device

Please make sure to edit the environment variables for your environment. Take note that I have set the variable MOUNT_DIR to DCIM/100_FUJI, so Immich doesn't need to scan the whole SD card for the media files.

The environment variable $RAW_DIR is for moving the .raf files to a separate directory before running the Immich import. This way I can store my .raf files independently, if I have a banger of a photo that the jpeg did not end up looking nice.

The env $WEBHOOK_ENDPOINT is for sending a POST to a webhook. I have another service that checks my geolocation from Home Assistant, and ads that data to the images on Immich. This way, I get geolocation on the photos without draining my battery with BLE connecting to the camera when I shoot.

The env HA_URL is for sending a http PUT request to a Home Assistant automation. (I have a automation that says on my speakers in the kitchen that the import is finished, so I remember to put the SD card back in the camera).

The bash script

So finally it is the script. Create and edit the file:

/usr/local/bin/auto-upload-immich.sh

With the content:

#!/bin/bash

# set immich_cli variable
IMMICH_CLI="docker run --rm  --pull=always \
-v $MOUNT_DIR:/import:ro \
-e IMMICH_INSTANCE_URL=$IMMICH_INSTANCE_URL \
-e IMMICH_API_KEY=$IMMICH_API_KEY \
ghcr.io/immich-app/immich-cli:latest upload -r /import"

echo "script started"
echo "Moving raw files"
shopt -s nullglob
for file in "$MOUNT_DIR"*.RAF; do
  # the -- protects against filenames starting with “-”
  mv -- "$file" "$RAW_DIR"/
done
echo "Starting Immich import"
$IMMICH_CLI

#echo "unmounting sd card"
#umount $SD_CARD_MOUNT
echo "Sending curl"
curl --silent --show-error --fail -X POST $WEBHOOK_ENDPOINT
curl --silent --show-error --fail -X PUT $HA_URL
echo "Done, exiting"

You need docker (or podman) to run this.
We also pull=always, so we do not end up with a stale immich cli image.
We do not delete the files from the SD card, and mount it as read only inside the container.

fin

Finally we need to reaload systemd.

systemctl daemon-reload
systemctl enable /etc/systemd/system/auto-upload-immich.service

You can check your services with:

journalctl -u /etc/systemd/system/auto-upload-immich.service -f

Fixing suspend with Linux on TUXEDO InfinityBook Pro 15

Fredrik Sætereng Fyksen — Wed, 26 Feb 2025 19:37:55 +0000

I'm running Fedora Rawhide Cosmic. But this will be the same for all Fedora (and most other Linux distroes).

Add acpi.ec_no_wakeup=1 to the line that starts with: GRUB_CMDLINE_LINUX= in the file /etc/default/grub. Then run grub2-mkconfig -o /boot/grub2/grub.cfg then reboot.

Then new file should look like this:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet acpi.ec_no_wakeup=1"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

Reboot your system, and the problem should be fixed.

ICS Kalender for Ski VM Trondheim

Fredrik Sætereng Fyksen — Wed, 26 Feb 2025 10:00:13 +0000

ICS FIL: https://user.fm/calendar/v1-b9b3f3145aa7dd028de49c8a08a1d8f0/ski-vm.ics

Det er ville tilstander at man klarer å hoste opp chat AI, men ikke en kalender folk kan importere til kalenderne sine. Symptomatisk for websider i dizze tider.

Fosdemfylt helg

Fredrik Sætereng Fyksen — Sun, 02 Feb 2025 16:03:32 +0000

Dette er første gang jeg har vært på Fosdem. Merksnodig som jeg er, så har det vært et mål i livet og jobbe for en arbeidsgiver som betaler kost og losji til Fosdem. Fosdem er jo ikke som andre konferanser. Det er ikke mulig for bedrifter og sponse Fosdem, for så å få holde foredrag. Dette bidrar til at konferansen er fylt med folk ideologisk opptatt av åpen kildekode, og som er interessert i å finne ut hvordan ting (gjerne tekniske dupeditter) fungerer.

Folk.

Jeg er jo ganske opptatt av folk. Og det er ikke så vanskelig å definere en gjennomsnittlig Fosdemdeltaker. Hvit mann, middelklasse, sekk fra tech-arbeidsgiver, og praktiske klær. Men det slo meg at det er langt høyere andel personer som er trans eller ikke-binære blant Fosdem deltakere, enn det er i gjennomsnittet av befolkningne. Jeg synes dette er spennende. Jeg tror noe av grunnen til dette er at fri programvare gjør det mulig for personer utsatt for hetsing på det «vanlige nettet» lage sine egne trygge havner, hvor de selv får bestemme hva som er akseptabel oppførsel. Dette gjør meg både trist og glad. Trist fordi det ikke skulle være nødvendig, men glad fordi jeg er endel av et miljø som gir en trygg havn til de som trenger det. Muligheten til å være seg selv er jo en menneskerett.

Jeg fikk besøke bodene og hørte på foredragene til prosjekter jeg bruker og følger. Høydepunktene for meg var

Mastodon
Matrix
Immich
Pine64
Forgejo

Et knippe bilder fra helga

🏃 Løping

Jo, også ble det en løpetur da. Intervaller i Parc du Cinquantenaire AKA Jubelparken. Helt på det jevne både på følelse og fart, men fikk iallefall klemt ut en god økt, til tross for en helg fylt med alt annet enn løping. Hadde egentlig tenkt til å løpe inni parken, men de slo ikke på lyset før godt utti intervallen, så det ble rundt istedenfor.

Distanse	Fart	Puls	Tid
9.9 km	3:41	128 bpm	36:28
2.3 km	3:44	124 bpm	8:36
2.3 km	3:39	123 bpm	8:26
1.8 km	3:39	124 bpm	6:26
1.8 km	3:40	134 bpm	6:30
1.8 km	3:41	134 bpm	6:30

Gpu lxc podman jellyfin passtrough

Fredrik Sætereng Fyksen — Sun, 27 Aug 2023 22:00:00 +0000

Why LXC, and not a VM?

A couple of reasons:

Disks on Proxmox perform better with Container mounts then with huge VM disks. I want to passtrough my video library as a separate zfs dataset to multiple LXC containers.
If you passtrough a GPU to a VM, only that VM can use it. I want to make us of the GPU.

How to notes:

I used a Fedora LXC container for this, but it should work pretty simular for Debian or Ubuntu as well.
I use Proxmox 8.
I have a AMD APU (Ryzen 5650GE)
I have a intel arc A 380 GPU.
Have a look at Jellyfin doc about ARC GPU.

Proxmox setup:

Create a privileged container.
Go to Options -> Features -> Tick Nesting, FUSE and Create Device Nodes.
ssh into the proxmox host for the next few steps.
We need to establish what the path to our GPU is. Run lscpi | grep Arc.
Take note off the PCI number. In my case, this is 12:00.0:

root@rack:~# lspci | grep Arc
12:00.0 VGA compatible controller: Intel Corporation DG2 [Arc A380] (rev 05)

Now ne need to check where this PCI device is mounted. run ls -la /dev/dri/by-path/ | grep 12:00

root@rack:~# ls -la /dev/dri/by-path/ | grep 12:00
lrwxrwxrwx 1 root root   8 Aug 28 10:07 pci-0000:12:00.0-card -> ../card1
lrwxrwxrwx 1 root root  13 Aug 28 10:07 pci-0000:12:00.0-render -> ../renderD128

My card is mounted as /dev/dri/card1, and /dev/dri/renderD128.
We also need to check what group owns the /dev/dri files. run ls -la /dev/dri

root@rack:~# ls -la /dev/dri/
total 0
drwxr-xr-x  3 root root        160 Aug 28 10:07 .
drwxr-xr-x 18 root root       5040 Aug 28 10:07 ..
drwxr-xr-x  2 root root        140 Aug 28 10:07 by-path
crw-rw----  1 root video  226,   0 Aug 28 10:07 card0
crw-rw----  1 root video  226,   1 Aug 28 10:07 card1
crw-rw----  1 root video  226,   2 Aug 28 10:07 card2
crw-rw----  1 root render 226, 128 Aug 28 10:07 renderD128
crw-rw----  1 root render 226, 129 Aug 28 10:07 renderD129

In my setup, 226 is the group that owns the cards.
Now we need to map this into our container. My container have the ID 100, so my container config file is: /etc/pve/lxc/100.conf.
Add the following at the end of the file. Please make sure to insert your owner, instead of 226:

# Allow C group:
lxc.cgroup2.devices.allow: c 226:* rwm

# Pass trough the files for the device:
lxc.mount.entry: /dev/dri/card1 dev/dri/card0 none bind,optional,create=file
lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file

note that I passed trough host: /dev/dri/card1 to container: dev/dri/card0. This is to make it easier for the container. Most software expects the gpu to be on /dev/dri/card0. This way I do not have to specify this in Jellyfin settings later.
Save the file, and start your container.

LXC setup:

Install packages:

dnf install intel-gpu-tools podman

Run intel_gpu_top, to check that you can access the GPU device.
Run podman with passtrough of the gpu:

podman run  --name jellyfin-test -p 8096:8096 --device /dev/dri/card0:/dev/dri/card0 --device /dev/dri/renderD128:/dev/dri/renderD128 -v /root/jellyfin/config:/config -v /root/jellyfin/media/:/media/movies docker.io/jellyfin/jellyfin:latest

Check the QSV and VA-API codecs inside container with: podman exec -it jellyfin-test /usr/lib/jellyfin-ffmpeg/vainfo
Check OpenCL runtime status inside container: podman exec -it jellyfin-test /usr/lib/jellyfin-ffmpeg/ffmpeg -v verbose -init_hw_device vaapi=va -init_hw_device opencl@va
Then login to your jellyfin admin settings -> playback. And tick the boxes ✅

I have not tested this for long, so this might not work as expected, we'll see.

Asrock Rack x470D4U Resizable bar

Fredrik Sætereng Fyksen — Wed, 16 Aug 2023 22:00:00 +0000

To my surprise they answered a day later with a BIOS update:

We add resized bar option in BIOS L4.27
Advanced -> PCI Subsystem Settings -> Re-Size BAR support.

The BIOS is not listed on Asrocks pages yet, so you should probably not use it yet. (Especially not since you got the file from a random guys blog).

But if somebody needs it, here's the file.

X47D4U427.ZIP (10 MB)

Other names for resizable bar:

CAM - Clever Access Memory
SAM - Smart Access Memory
Rebar - Resizable bar