QEMU/KVM: Wirtualny router z wykorzystaniem OpenWRT

Cześć!

Od kilku dni zastanawiałem się, czy jest możliwość połączenia kilku maszyn wirtualnych w jedną sieć 'bez sieci' (czyli stricte bez kabla i mostu na hoście). Docelowo zależało mi na działaniu bez uprawień root'a i bez ingerencji w konfigurację hosta.

Możliwości są dwie. Natywnie qemu/kvm umożliwia nam zestawienie wirtualnego połączenia dwóch maszyn (stream, mcast, socket itd) i tym dzisiaj nie będziemy się zajmować. Nas interesuje wirtualna sieć z wykorzystaniem vde_switch.

Na hoście (Debian) instalujemy:

apt install vdeplug vdens vde2-cryptcab vde2 vde-wirefilter vde-switch

Uruchamiamy przełącznik:

vde_switch

Domyślnym katalogiem "gniazd" jest /tmp/vde.ctl/ (można zmienić, zapraszam do manuala).

Do VMki dodajemy:

-netdev user,id=wan -device e1000,netdev=wan,mac=52:54:00:00:00:01 \

-netdev vde,id=lan,sock=/tmp/vde.ctl/ -device e1000,netdev=lan,mac=52:54:00:00:00:02

Koniecznie w takiej kolejności, żeby zachować kolejność nazewnictwa. wan powinien zostać nazwany jako eth0 a lan jako eth1.

OpenWRT ma bardzo małe wymagania sprzętowe, więc na obecnych komputerach nie powinniśmy odczuć jego działania. Jak ogarniemy sobie obraz (u mnie zadziałał obraz generic combined) to wystarczy uruchomić VMkę, wejść do konsoli enterem (domyślnie ustawione jest puste hasło) i wykonać następne polecenia:

uci set network.wan=interface

uci set network.wan.device='eth0'

uci set network.wan.proto='dhcp'

uci set network.lan=interface

uci set network.lan.device='eth1'

uci set network.lan.proto='static'

uci set network.lan.ipaddr='192.168.10.1'

uci set network.lan.netmask='255.255.255.0'

uci commit network

/etc/init.d/network restart

uci set dhcp.lan=dhcp

uci set dhcp.lan.interface='lan'

uci set dhcp.lan.start='100'

uci set dhcp.lan.limit='150'

uci set dhcp.lan.leasetime='12h'

uci commit dhcp

/etc/init.d/dnsmasq restart

uci commit

reboot

I tyle. Kolejne VMki należy odpalać z poniższą linijką:

-netdev vde,id=lan,sock=/tmp/vde.ctl/ -device e1000,netdev=lan,mac=52:54:00:00:00:xx

Należy tylko pamiętać o zmianach mac (xx) i ruszy z marszu.

QEMU/KVM: Instalacja Windowsa bez TPM

Cześć!

Ostatnio "walczyłem" z emulacją TPM dla VM'ek qemu/kvm. Teraz pokażę 2 sposoby, jak zainstalować Windowsa bez emulacji TPMa.

Pierwszym z nich jest edycja rejestru w "locie", tzn w trakcie instalacji systemu. Na pierwszym ekranie korzystamy ze skrótu:

Shift + F10

W ten sposób uruchomimy cmd.exe (wiersz poleceń). Wpisujemy:

regedit

Przechodzimy do:

HKEY_LOCAL_MACHINE\SYSTEM\Setup

Tworzymy nowy klucz o następującej nazwie:

LabConfig

I tworzymy nowe wpisy DWORD 32.

BypassTPMCheck

BypassSecureBootCheck

BypassRAMCheck

Każdy kolejny wpis musi mieć wartość 1. I to wszystko.

Drugim sposobem jest edycja obrazu iso. Najpierw dociągamy (w Debianie) następujące paczki:

apt install wimtools chntpw xorriso

Obraz iso teoretycznie możemy zamontować z opcją loop, ale domyślnie zamontuje się w trybie tylko do odczytu. Ja, zamiast montowania, traktuję iso po prostu jak archiwum i rozpakowuję jakimkolwiek archiwerem (np 7zip).

Tworzymy dwa foldery:

mkdir obraz wim

Do folderu obraz należy wypakować iso. Do katalogu wim montujemy boot.wim:

wimlib-imagex mountrw obraz/sources/boot.wim 2 wim

"2" oznacza Microsoft Windows Setup. Zapraszam do manuala wimlib-imagex.

Następnie wykonujemy polecenie:

chntpw -e /dev/shm/win11vm.wim/Windows/System32/config/SYSTEM

Teraz kolejno wpisujemy poniższe polecenia (każde kolejne zatwierdzamy enterem):

cd Setup

nk LabConfig

cd LabConfig

nv 4 BypassTPMCheck

nv 4 BypassSecureBootCheck

nv 4 BypassRAMCheck

ed BypassTPMCheck

1

ed BypassSecureBootCheck

1

ed BypassRAMCheck

1

q

y

Zapisujemy zmiany:

wimlib-imagex unmount wim --commit

W celu utworzeniu obrazu wykonujemy:

xorriso \

 -as mkisofs \

 -iso-level 3 \

 -o obraz.bez.tpm.iso \

 -full-iso9660-filenames \

 -volid "obraz.bez.tpm" \

 -eltorito-boot boot/etfsboot.com \

 -no-emul-boot \

 -boot-load-size 8 \

 -boot-info-table \

 -eltorito-alt-boot \

 -e efi/microsoft/boot/efisys.bin \

 -no-emul-boot \

 -isohybrid-gpt-basdat obraz

I to wszystko.

Windows Server 2025 na dzień 2 kwietnia 2026 nie wymaga TPMa do działania (o ile nie potrzebujemy szyfrowania itd).

QEMU/KVM: Karta dźwiękowa AC97 pod Windows 11 / Server 2025 (31.03.2026)

Cześć!
W poprzednim wpisie przygotowałem działającą maszynę wirtualną z Windows 11 oraz Server 2025. VMki działały bez dźwięku, bo standardowe intel-hda powodowały zawieszanie się qemu/kvm i finalnie kompletnie "mroziły" hosta (pomagał tylko twardy reset).
Z pomocą przyszedł użytkownik wowo89, który udostępnił działające sterowniki dla ac97. Finalnie:

qemu-system-x86_64 \
-cpu host -m 16G -smp 4 -enable-kvm \
-machine q35 \
-drive media=disk,format=raw,file=srv2025.img \
-drive if=pflash,format=raw,readonly=on,file=srv2025.code.fd \
-drive if=pflash,format=raw,file=srv2025.vars.fd \
-usb -device usb-tablet \
-audiodev alsa,id=snd0 -device ac97,audiodev=snd0 \
-vga std \
-display gtk,gl=on \
-device VGA,vgamem_mb=2048 \
-nic user

Sterowniki: LINK

Autor sterowników: wowo89

QEMU/KVM: Windows 11 / Windows Server (uefi, secure boot, tpm)

Cześć!

Po kilku latach korzystania z Virtualbox'a przeniosłem się na "natywne" rozwiązanie w świecie Linuksa, czyli tytułowe Qemu/KVM. Rozwiązanie te jest szeroko stosowane w różnych serwerowniach (nie zawsze, są również inne rozwiązania). W zastosowania bardziej "konsumenckich" używany np w Proxmoxie.

Z upływem czasu będę publikował kolejne notki dotyczące domowej wirtualizacji z wykorzystaniem Qemu, a dziś zacznę od... przygotowania maszyny wirtualnej (VM) Windowsa 11 (preferuję wersje serwerowe, ale podstawowe wymagania co do sprzętu mają względnie zbliżone).

Domyślnie qemu/kvm emuluje bios starszego typu. Windows 11 do poprawnego działania wymaga uefi, tpm oraz secure boot.

W Debianie instalujemy następujące pakiety:

aptitude install ovmf swtpm swtpm-libs swtpm-tools

Tworzenie dysku o rozmiarze 80GB:

qemu-img create -f raw win11.img 80G

Emulujemy moduł tpm:

swtpm socket \

--tpm2 \

--tpmstate dir=/dev/shm/ \

--ctrl type=unixio,path=/dev/shm/win11.tpm \

--daemon;

ovmf ma pliki z uefi. Możemy korzystać z oryginalnych ścieżek lub skopiować dwa potrzebne pliki do folderu z VM'ką:

cp /usr/share/OVMF/OVMF_CODE_4M.secboot.fd win11.code.fd

cp /usr/share/OVMF/OVMF_VARS_4M.fd win11.vars.fd

Odpalamy naszą VM'kę:

qemu-system-x86_64 \

-cpu host -m 16G -smp 4 -enable-kvm \

-machine q35 -usb -device usb-tablet \

-device VGA,vgamem_mb=2048 \

-drive media=disk,format=raw,file=win11.img \

-drive if=pflash,format=raw,readonly=on,file=win11.code.fd \

-drive if=pflash,format=raw,file=win11.vars.fd \

-chardev socket,id=chrtpm,path=/dev/shm/win11.tpm \

-tpmdev emulator,id=tpm0,chardev=chrtpm \

-device tpm-tis,tpmdev=tpm0 \

-nic user \

-drive media=cdrom,file=/sciezka/do/obrazu.iso

Gdyby z jakiegoś powodu nie dało się zainstalować z użyciem konta lokalnego, wówczas:

- na ekranie tworzenia użytkownika odpalamy konsolę za pomocą Shift + F10

- wpisujemy oobe\bypassnro

- VM'ka zacznie się restartować, musimy wychwycić odpowiedni moment żeby Escapem wejść w menu bootowania VM'ki i na ekranie wyboru nośnika po prostu ją wyłączyć

- teraz wystarczy uruchomić VM'kę z opcją -nic none zamiast -nic user

- uruchamiamy, gdzieś po drodze będzie okienko umożliwiające instalację bez dostępu do internetu (dosłownie)

- jak przejdziemy resztę etapów to przed następnym uruchomieniem możemy przywrócić -nic user

Efekt finalny z TPM (+ wcześniej odpalamy swtpm):

qemu-system-x86_64 \

-cpu host -m 16G -smp 4 -enable-kvm \

-machine q35 -usb -device usb-tablet \

-device VGA,vgamem_mb=2048 \

-drive media=disk,format=raw,file=win11.img \

-drive if=pflash,format=raw,readonly=on,file=win11.code.fd \

-drive if=pflash,format=raw,file=win11.vars.fd \

-chardev socket,id=chrtpm,path=/dev/shm/win11.tpm \

-tpmdev emulator,id=tpm0,chardev=chrtpm \

-device tpm-tis,tpmdev=tpm0 \

-nic user

Dla Windows Server 2025 TPM nie jest potrzebny do działania po instalacji.

Możemy więc omijać kroki z swtpm. Wystarczy:

qemu-system-x86_64 \

-cpu host -m 16G -smp 4 -enable-kvm \

-machine q35 \

-drive media=disk,format=raw,file=srv2025.img \

-drive if=pflash,format=raw,readonly=on,file=srv2025.code.fd \

-drive if=pflash,format=raw,file=srv2025.vars.fd \

-usb -device usb-tablet \

-device VGA,vgamem_mb=2048 \

-nic user

Powyższe kroki celowo pomijają kwestię konfiguracji dźwięku. Domyślne ac97 docelowo nie działa w nowszych Windowsach, a karty intelowskie powodują u mnie małe problemy.

SWAP w pliku na Linuksie

Obszar wymiany danych (czy to poprawne określenie?) to takie "miejsce" na dysku, które rozszerza pamięć RAM o dodatkową pojemność na dysku twardym. W Windowsie jest to pagerfile, w Linuksie (i pochodnych) odpowiednikiem jest swap, a w Androidzie podobną funkcję oferuje RAM Boost.

W Linuksie obszar wymiany danych może być zarówno partycją (np na oddzielnym dysku nvme) jak i plikiem. Zajmiemy się utworzeniem ostatniej opcji (z roota):

dd if=/dev/zero of=/swap bs=1G count=64

Stworzy nam to plik swap o rozmiarze 64GB, znajdujący się na partycji systemowej. Zmieniamy uprawnienia:

chmod 0600 /swap

Tworzymy "ekosystem":

mkswap /swap

W /etc/fstab tworzymy wpis:

/swap none swap defaults 0 0

Wykonujemy:

systemctl daemon-reload

Następnie:

mount -a

Oraz włączamy swapa:

swapon -a

I to wszystko :D

Zdalne wywołanie poleceń w Linuxie (ssh / port knocking / fwknop / shell2http)

Szukałem ostatnio rozwiązania, które pozwoliłoby mi na zdalne wywołanie dowolnego polecenia na jednym z komputerów. 

Docelowy komputer czasami pracuje u mnie po *naście albo *dziesiąt godzin a że jest to ekonomicznie uzasadnione rozwiązanie smart tv to posiada pełnoprawny interfejs graficzny. A Xorg, jak to Xorg, swoje wady ma i często po kilkunastu godzinach pracy po prostu lubi się całkowicie sfreezować (zamrozić / zawiesić) i wówczas pomaga tylko twardy reset. Poszukiwane rozwiązanie problemu i docelowy zamysł był taki, żeby gui na czas wyjścia z domu wyłączyć (o ile nic się nie renderuje), a można to rozwiązać na cztery sposoby.

Pierwszy sposób to ssh. A zrobimy to w taki sposób:

ssh user@pc 'sudo systemctl stop lightdm.service; sudo chvt 1'

Powyższa komenda zatrzymuje nam menedżera logowania i jednocześnie przełącza tty z 7 (domyślne tty dla gui w Debianie) na 1. Gdybyśmy chcieli tylko podejrzeć, czy menedżer logowania się wyłączył to możemy włączyć sprawdzić np htopem:

ssh -t user@pc htop

Po zamknięciu htopa oczywiście zostaniemy rozłączeni.

Drugim sposobem jest tzw port knocking. Metoda - podobno - trochę przestarzała i mało bezpieczna. Polega na wysłaniu "sygnału" na określone przez nas porty, po czym wykonuje określone w konfiguracji komendy. Rozwiązanie dobre, ale tylko lokalnie.

Instalacja (w Debianie):

apt install knockd

Konfiguracja z sekwencjami portów znajduje się w /etc/knockd.conf, przykładowo:

[options]

UseSyslog

LogFile = /var/log/knockd.log

Interface = eno1

[echo]

        sequence    = 1,1,1

        seq_timeout = 1

        command     = echo

        tcpflags    = syn

W sekcji [options] warto uwzględnić nazwę interfejsu oraz gdzie ma być zapisywany log.

Plik "aktywacyjny" /etc/default/knockd:

# control if we start knockd at init or not

# 1 = start

# anything else = don't start

# PLEASE EDIT /etc/knockd.conf BEFORE ENABLING

START_KNOCKD=1

# command line options

KNOCKD_OPTS="-i eno1"

START_KNOCKD domyślnie jest na 0, nazwę sieci ustawiamy wedle potrzeb.

Z poziomu klienta, jeśli klientem również jest Debian instalujemy tę samą paczkę:

apt install knockd

I terminalu wystarczy wykonać:

knock -v host port1 port2 port3

Opcja -v powoduje wypisanie nam na ekranie poszczególnych działań.

Knocking działa również na interfejsach wifi. Po resztę informacji zapraszam do manuali.

Trzecim sposobem jest fwknop. W tym przypadku "logowanie" do serwera działa jak w przeglądarce internetowej. Tzn tworzymy klucz, który przesyłamy do serwera, prawie jak ciasteczko w przeglądarce. Jak serwer odbierze nasze dane to zaakceptuje nasze połączenie i wykorzysta według konfiguracji.

Przedstawię bardzo uproszczoną konfigurację. W przeciwieństwie do poprzedniego rozwiązania musimy zainstalować dwie różne paczki.

Na kliencie instalujemy:

apt install fwknop-client

A na serwerze:

apt install fwknop-server 

Na kliencie uruchamiamy:

fwknop -a ip.klienta -D ip.serwera --key-gen -C /sciezka/do/zdalnej/komendy --save-rc-stanza

--save-rc-stanza powoduje zapisanie konfiguracje w ~/.fwknoprc. W tym pliku mamy dwa klucze, KEY_BASE64 oraz HMAC_KEY_BASE64 które musimy przenieść na serwer (o tym niżej). Jak do jednego serwera chcemy wysłać kilka różnych komend (raz jedną, innym razem drugą) to przy generowaniu klucza możemy wykorzystać opcję -n nazwa. Dokładny opis w manualu.

Na serwerze włączamy usługę w /etc/default/fwknop-server z poniższymi argumentami:

START_DAEMON="yes"

DAEMON_ARGS="-f -U"

Dodatkowo mamy pliki /etc/fwknop/fwknopd.conf oraz /etc/fwknop/access.conf. Pierwszy zostawiamy z domyślną konfiguracją a do access.conf wrzucamy klucze z ~/.fwknoprc:

SOURCE              ip.klienta

KEY_BASE64          klucz1

HMAC_KEY_BASE64     klucz2

ENABLE_CMD_EXEC     Y

ENABLE_CMD_EXEC zezwala nam na uruchomienie zdalnej komendy. Z poziomu klienta:

fwknop -n docelowy.serwer -C /sciezka/do/komendy

I to wszystko :D fwknop docelowo służy do zdalnej modyfikacji reguł firewalla ale równie dobrze możemy wykorzystać go do zdalnego wykonania komend. W manualu widzimy również opcje CMD_CYCLE_OPEN, CMD_CYCLE_CLOSE oraz CMD_CYCLE_TIMER, których akurat nie testowałem. Mogłyby być alternatywą dla -C /sciezka/do/zdalnej/komendy (czy wystarczyłoby odpalić fwknop -n docelowy.serwer?).

W przeciwieństwie do knockd, za pomocą fwknop udało mi się uruchomić kilka komend jednocześnie (w skrypcie). knockd wykonywał tylko pierwszą komendę z docelowego skryptu.

Na Androida jest aplikacja fwknop. Nie testowałem.

Czwartym i ostatnim sposobem jest shell2http. To taka mała usługa, która pozwala na wykonanie poleceń z poziomu np przeglądarki internetowej (poprzez uprzednio skonfigurowany adress www). Jest to chyba najprostszy sposób jaki udało mi się znaleźć, teoretycznie najmniej problemowy i z tego co widzę to nie wymaga żadnych zależności. Póki co gotowej paczki nie ma w repozytoriach Debiana (stan na 19.01.2026) ale można znaleźć w sieci paczkę *.deb i na luzie ją zainstalować np z wykorzystaniem gdebi:

gdebi shell2http_1.17.0_linux_amd64.deb

Składnia polecenia jest prosta. Tworzymy usługę /etc/systemd/system/shell2http.service:

[Unit]

Description=shell2http

[Service]

Type=oneshot

ExecStart=/bin/shell2http  /polecenie1 "/sciezka/do/polecenia1" /polecenie2 "/sciezka/do/polecenia2"

[Install]

WantedBy=multi-user.target

W miejscu "/sciezka/do/polecenia1" możemy wpisać (między cudzysłowami) kilka poleceń oddzielonych znakiem ";". Następnie aktywujemy:

systemctl enable shell2http.service

Oraz uruchamiamy:

systemctl start shell2http.service

W przeglądarce internetowej odpalamy adres:

adres.ip.serwera:8080/polecenie1

Lub:

adres.ip.serwera:8080/polecenie2

Domyślny port to 8080, ale można to zmienić. Polecam zajrzeć do manuala. Odnoszę wrażenie, że shell2http reaguje najwolniej ze wszystkich opisanych rozwiązań.

I to wszystko :D

Najbezpieczniejszym rozwiązaniem wydaje się być fwknop z racji takiej że "sygnał" jest prawie nie do podrobienia (chyba, ze ktoś ma założony podsłuch) :D

Kilka sztuczek na SSH :) (wysłanie 1 komendy, gui, podniesienie uprawnień)

Mam u siebie kilka różnych komputerów z Debianem, które czasami chodzą po *-naście godzin. Kilka razy zdarzyło się, że się xorg losowo przywiesił (niezależnie od gpu i ogólnie sprzętu) i pomagał tylko twardy reset. Raczej kiepska sytuacja, tym bardziej że różne usługi chodzą w tle :D

Wpadłem na pomysł, że przecież gui zawsze można zdalnie wyłączyć, o ile nie jest w danej chwili potrzebne. Plus jest taki że prawdopodobnie dałoby radę zaprogramować to w automatyce domowej (wychodzisz, wyłączasz gui, wracasz, włączasz ponownie). No i jak zacząłem szukać różnych rozwiązań to zdałem sobie sprawę z tego, że przecież idealnie do tego nadaje się ssh.

1. Pierwsza 'testowa' komenda (odpala nam tylko htop, po zamknięciu sesja jest rozłączana):

ssh -t user@pc htop

2. Poniżej przykładowy sposób na wyłączenie np menedżera logowania (= gui) i przejście na tty1:

ssh user@pc 'sudo systemctl stop lightdm.service; sudo chvt 1'

3. A poniżej sposoby na odpalenie programu w gui z wykorzystaniem X11Forwarding:

ssh -X user@pc 'sudo -E polecenie'

Lub:

ssh -X user@pc 'su -p -c "PATH=/usr/sbin:/sbin:$PATH polecenie"'

sudo -E polecenie oraz su -p -c "PATH=/usr/sbin:/sbin:$PATH polecenie" są potrzebne tylko wtedy kiedy chcemy odpalić polecenie z podniesionymi uprawnieniami. W przypadku odpalenia np przeglądarki internetowej na zdalnym pc wystarczy:

ssh -X user@pc przeglądarka

Oczywiście są inne sposoby na zdalne wyłączenie gui (tudzież wysłanie dowolnej komendy) ale o tym w następnym wpisie :D

Zdalny dostęp do GUI w Debianie (rdp/ssh) (wersja 1min)

To tylko krótka notka.
Poza x11vnc mamy jeszcze dwie inne możliwości, wedle potrzeb.
Pierwsza z nich to 'stare', dobre Windowsowe rdp. Daje nam, tak jak przy vnc, dostęp do "całego" ekranu i środowiska użytkownika. W Debianie instalujemy:

apt install xorgxrdp xrdp

I tyle. Pliki konfiguracyjne mamy w /etc. Usługa systemowa 'tworzy' się w trakcie instalacji, więc każdy sobie musi sam "dopracować" poszczególne ustawienia.

Drugą z opcji, jeżeli korzystamy z ssh, jest tzw X11 Forwarding. W przeciwieństwie do rdp i vnc poniższa funkcja umożliwia nam uruchomienie jednego konkretnego programu z poziomu terminala klienckiego. Sprawdzamy co mamy w pliku konfiguracyjnym:

cat /etc/ssh/sshd_config | grep -e X11Forwarding -e PermitUserEnvironment -e X11UseLocalhost

U mnie jest ustawione na:

X11Forwarding 

PermitUserEnvironment yes 

X11UseLocalhost yes

I tyle. Restartujemy usługę:

systemctl restart ssh.service

I to wszystko.

Druga opcja, umożliwia nam, zamiast instalacji całego środowiska graficznego, instalację np jednego konkretnego programu (do np księgowości, czy co tam potrzebujemy.

Programów graficznym pokroju gimpa czy innego blendera raczej bym nie uruchamiał, ale do mniej wymagających spraw dobre będą obydwie metody :D pozostała tylko kwestia przekierowania audio (w bliżej nieokreślonej przyszłości, mam już kilka pomysłów).

Stała częstotliwość pracy procesora CPU (poprawa pracy igpu)

Lata temu do zarządzania energią procesora korzystało się z cpufrequtils. Potem zaszły zmiany, wprowadzono intel_pstate i odpowiednik u AMD. Jest to rozwiązanie na pewno bardziej skuteczne w zarządzaniu energią procesora. U mnie wszystko było OK do czasu, aż podłączyłem pod TV starszego mini pc z Intelem. Jak się okazało, zintegrowana gpu bywa kapryśna bo w końcu jest w pełni zależna od cpu. U mnie w trakcie korzystania z serwisów streamingowych przeglądarka potrafiła znienacka zamknąć kartę i wywalić błąd :D (i to mimo wsparcia sprzętowego dla różnych kodeków)

Problem się objawiał tylko na starszych i trochę słabszych jednostkach jak i5-7500T, trochę mniej na i5-8500T a na zwykłym i5-11400 tego problemu nie zauważyłem.

Co ciekawe, kernel Liquorix na Debianie problemów nie sprawiał i w dodatku ma ustawioną stałą wartość częstotliwości pracy procesora. Z małą pomocą forumowego AI (jak na dzisiejsze standardy...) znalazłem sposób jak ustawić procesor na sztywno.

AI jak to AI, często się myli więc jeśli już musimy to trzeba korzystać bardzo ostrożnie i co najwyżej można się zasugerować ale nie można brać za pewnik.

Na tą chwilę (1.01.2026) rozwiązanie działa, ale jak długo tak będzie, nie wiadomo. Wygląda na to, że poniższa metoda działa również na linux-image-rt-amd64, czyli jednym z kerneli czasu rzeczywistego które zazwyczaj są odradzane w zastosowaniach "multimedialnych".

W Debianie instalujemy:

apt install linux-cpupower

Tworzymy plik z usługą systemową /etc/systemd/system/cpufreq.service:

[Unit]

Description=cpufreq max freq

[Service]

Type=oneshot

ExecStart=/bin/cpupower frequency-set --governor performance

[Install]

WantedBy=multi-user.target

Następnie:

systemctl enable cpufreq.service 

Zanim zrestartujemy system, musimy w pliku /etc/default/grub znaleźć i dopisać pogrubiony wpis:

GRUB_CMDLINE_LINUX_DEFAULT="quiet iwlwifi.power_save=0 pcie_aspm=off intel_pstate=disable"

Po czym:

update-grub2; reboot

Po restarcie sprawdzamy:

cpupower frequency-info

Wynik jak niżej:

analyzing CPU 3:

  driver: acpi-cpufreq

  CPUs which run at the same hardware frequency: 3

  CPUs which need to have their frequency coordinated by software: 3

  maximum transition latency: 10.0 us

  hardware limits: 800 MHz - 2.70 GHz

  available frequency steps:  2.70 GHz, 2.70 GHz, 2.60 GHz, 2.40 GHz, 2.30 GHz, 2.20 GHz, 2.00 GHz, 1.90 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 900 MHz, 800 MHz

  available cpufreq governors: performance schedutil

  current policy: frequency should be within 800 MHz and 2.70 GHz.

                  The governor "performance" may decide which speed to use

                  within this range.

  current CPU frequency: 2.70 GHz (asserted by call to hardware)

  boost state support:

    Supported: yes

    Active: yes

Oraz cat /proc/cpuinfo | grep MHz:

cpu MHz         : 2700.001

cpu MHz         : 2700.000

cpu MHz         : 2700.119

cpu MHz         : 2700.277

Odchyły mogą wystąpić, procesor czasami zejdzie poniżej 1000MHz ale generalnie trzyma się wysoko. Taktowanie, temperatury itd najwygodniej sprawdza mi się programem htop.