Jeśli domyślna konfiguracja wydaje się nam zbyt spuchnięta, to z pewnością mamy rację. W kernelu znajduje się domyślnie cała masa zbędnych ustawień, które można usunąć. W tym celu najczęściej edytujemy pliki konfiguracyjne. Jest to metoda skuteczna, ale czasochłonna i żmudna. Możemy jednak znacząco ułatwić sobie taki zabieg. Aby to zrobić, musimy posłużyć się pewną sztuczką.
Metoda dla leniwych - korzystanie z xconfig oraz gconfigEdytujemy PKGBUILD i odszukujemy w nim poniższą frazę:
cd ${_srcname}
msg "Running make bzImage and modules"
make ${MAKEFLAGS} LOCALVERSION= bzImage modules
}
Aby skorzystać z graficznego narzędzia dla optymalizacji kernela, wystarczy dodać odpowiedni zapis:
A. Dla osób preferujących Qtcd ${_srcname}
make xconfig
msg "Running make bzImage and modules"
make ${MAKEFLAGS} LOCALVERSION= bzImage modules
}
B. Dla osób preferujących GTKcd ${_srcname}
make gconfig
msg "Running make bzImage and modules"
make ${MAKEFLAGS} LOCALVERSION= bzImage modules
}
Uruchomimy w ten sposób graficzny edytor, w którym będziemy mogli odznaczyć wpisy, które nas nie interesują. Możemy także wybrać model procesora, pod jaki zostanie skompilowany kernel. Po zakończeniu prac, zapisujemy zmiany i zamykamy edytor. Kompilowanie kernela ruszy a czas niezbędny do wykonania tej operacji znacząco się skróci.
Zdecydowanie bardziej polecam edytor oparty o bibliotekę Qt, gdyż dysponuje poręczną wyszukiwarką.
Metoda zalecana - korzystanie z nconfigJeśli preferujemy metody bez GUI, nic straconego. Odszukujemy odpowiednie fragmenty:
# Tweak kernel options prior to a build via nconfig
_makenconfig=
lub
# Set these variables to ANYTHING (yes or no or 1 or 0 or "I like icecream") to enable them
_makenconfig= # tweak kernel options prior to a build via nconfig
oraz wprowadzamy niewielką modyfikację:
# Tweak kernel options prior to a build via nconfig
_makenconfig=y
lub
# Set these variables to ANYTHING (yes or no or 1 or 0 or "I like icecream") to enable them
_makenconfig=1 # tweak kernel options prior to a build via nconfig
Opis oraz przebieg kompilowania kernela z AUR opisany został w
TYM temacie.
Alternatywna oraz uproszczona metoda kompilowania jądra pod procesor została szerzej opisana w
TYM wątku.
Jeśli nie dysponujesz odpowiednią wiedzą, nie wykonuj żadnych zmian. Za wszelkie awarie winę ponosi tylko i wyłącznie użytkownik. Aktualizacja poradnika:Dostosowałem kernele znajdujące się pod moją opieką w AUR do poradnika. Zastosowałem w nich następujący zapis:
build() {
cd ${_srcname}
# Tweak kernel options prior to a build via gconfig
#make gconfig
# Tweak kernel options prior to a build via xconfig
#make xconfig
# Tweak kernel options prior to a build via nconfig
#make nconfig
msg "Running make bzImage and modules"
make ${MAKEFLAGS} LOCALVERSION= bzImage modules
}
Pierwsze dwie opcje (gconfig oraz xconfig) odpowiadają metodą przedstawionym w podpunktach
A oraz
B, ostatnia zaś opcji przedstawionej jako zalecana. Jeśli chcemy skorzystać z poszczególnej opcji, usuwamy
# sprzed wpisu i gotowe.
Aktualizacja poradnika nr 2:Ciekawą opcję podczas kompilowania kernela stanowi
localmodcfg. Aby z niej skorzystać odszukujemy:
_localmodcfg= # compile ONLY probed modules
lub
# More at this wiki page ---> https://wiki.archlinux.org/index.php/Modprobed_db
_localmodcfg=
Zmieniamy na coś takiego
_localmodcfg=y # compile ONLY probed modules
lub
# More at this wiki page ---> https://wiki.archlinux.org/index.php/Modprobed_db
_localmodcfg=y
Oczywiście, skorzystanie z punktu 3. Poradnika nie jest przeszkodą, do wykonania czynności opisanej w punkcie 1. Najlepiej jest w pierwszej kolejności wykonać punkt 3. Poradnika by następnie jeszcze bardziej okroić konfigurację korzystając z punktu 1. Przykładowo, w swojej konfiguracji wyciąłem pozostałe schedulery (deadline oraz cfq), korzystając z bfq.
[ 0.325029] io scheduler noop registered
[ 0.325036] io scheduler bfq registered (default)
[ 0.325037] BFQ I/O-scheduler version: v7r4
Aktualizacja poradnika nr 3:
Bardzo pomocnym narzędziem przy korzystaniu z
localmodcfg jest
modprobed-dbInstalujemy je za pomocą:
yaourt -S modprobed-db
Następnie wykonujemy polecenie:
modprobed-db store
Od tej pory podczas kompilowania kerneli udostępnianych przez OpenLinux.pl,
linux-ck oraz
linux-uksm za pomocą
localmodcfg baza wczytanych modułów zostanie zaktualizowana automatycznie za pomocą polecenia:
modprobed-db recall
Nie musimy wykonywać tego osoboście. Odpowiada za to poniższy wpis w PKGBUILD:
### Optionally load needed modules for the make localmodconfig
# See http://aur.archlinux.org/packages.php?ID=41689
if [ -n "$_localmodcfg" ]; then
msg "If you have modprobe_db installed, running it in recall mode now"
if [ -e /usr/bin/modprobed_db ]; then
[[ ! -x /usr/bin/sudo ]] && echo "Cannot call modprobe with sudo. Install via pacman -S sudo and configure to work with this user." && exit 1
sudo /usr/bin/modprobed_db recall
fi
msg "Running Steven Rostedt's make localmodconfig now"
make localmodconfig
fi
}
Listę modułów można zobaczyć za pomocą polecenia:
modprobed-db list
Aktualizacja poradnika nr 4:Opcja _use_current spowoduje użycie pliku config aktualnie załadowanego kernela. W ten sposób, jeśli budujemy kernel używając w danej sesji wcześniej zbudowanego kernela, to użyje on jego opcji konfiguracyjnych. Równocześnie możemy zbudować nowy kernel w oparciu o config innego kernela, który z jakichś powodów jest dla nas atrakcyjny. Po prostu _use_current wczyta jego config zamiast domyślnie dostarczonego z tarballem
# Use the current kernel's .config file
# Enabling this option will use the .config of the RUNNING kernel rather than
# the ARCH defaults. Useful when the package gets updated and you already went
# through the trouble of customizing your config options. NOT recommended when
# a new kernel is released, but again, convenient for package bumps.
_use_current=
bądź
_use_current= # use the current kernel's .config file
oraz wprowadzamy w zapisach odpowiednie zmiany:
# Use the current kernel's .config file
# Enabling this option will use the .config of the RUNNING kernel rather than
# the ARCH defaults. Useful when the package gets updated and you already went
# through the trouble of customizing your config options. NOT recommended when
# a new kernel is released, but again, convenient for package bumps.
_use_current=y
bądź
_use_current=yes # use the current kernel's .config file