Rolej 58 Zgłoś post Napisano Marzec 11, 2016 Cześć. W Proxmox 4.x usunięto OpenVZ i zastąpiono go LXC. LXC ja nie używam, jedynie korzystam z KVM. Chciałbym przekompilować jądro (gr+pax, onemand->performance i wyłączenie śmieci) - jądro Proxmoxa można rekompilować bez problemowo czy jednak coś może się stać z nim (nie wstanie albo inna historia). Ktoś próbował coś w tym temacie? Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Marzec 11, 2016 (edytowany) A to jądro ma jakieś nieoficjalne patche? Bo to w dużej mierze zależy od tego - reszta to config, a ten możesz ściągnąć z /proc/config.gz. LXC z tego co wiem jest natywnie w Linuxie, więc nie powinno tutaj być nic patchowane. Edytowano Marzec 11, 2016 przez Archi (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Rolej 58 Zgłoś post Napisano Marzec 13, 2016 Osobiście nie mam pojęcia czy coś jest patchowane - moim zdaniem nie powinno. W matce gdzieś znajdują się ewentualne informacje o patchach, które są zastosowane? Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Marzec 13, 2016 (edytowany) Nie znajdują się, to wszystko jest kompilowane do bzImage czy innego skompresowanego zImage. Jedyne co może wskazywać na custom patche to załadowanie /proc/config.gz (po uprzedniej dekompresji) jako .config do drzewa z tą samą wersją jądra na którą wskazuje i zrobienie make oldconfig. Jeśli nowo-wygenerowany .config będzie się różnić od zdekompresowanego /proc/config.gz to znaczy, że coś było patchowane. Najłatwiej to zrobić diffem. Przykładowo, jeśli zrobisz taki zabieg na kernelu grsec to od razu zauważysz, że twój nowy .config z make oldconfig nie posiada żadnych wpisów dot. grseca - a te znajdują się w /proc/config.gz. Jest to spowodowane tym, że twoje drzewo o tych wpisach nie wie, więc je usuwa z make oldconfig. To niestety jest tylko "wskazówka", bo jak ktoś zmienił kod jądra dyrektywami GCC czy samym kodem to i tak się do tego nie dokopiesz. IMHO, jeśli zabieg wyżej wskaże na jakieś braki, to najlepiej te braki zgooglować i poszukać skąd się biorą. Jeśli nie - wg. mnie można bezpiecznie założyć, że zrobienie własnego kernela na bazie oryginalnego configu będzie wystarczające. Edytowano Marzec 13, 2016 przez Archi (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach