Czy instalacja nowych kerneli na starej dystrybucji jest bezpieczna?

[Piotr_1988]

Laickie pytanie. Czy instalacja nowych kerneli na starej dystrybucji jest bezpieczna?

Przykład. Mam kernel 4.9.0-9-amd64 x86_64 domyślny ze Sparkiego 4. Chyba mogę skompilować kernel 5.1.9 za pomocą sparky-kernel-builder. Tylko, czy taki nowszy kernel nie pokłóci się ze starymi pakietami?

[PomPom]

Może się pokłócić ze sterownikami do GPU. Na Debianie stable przy aktualizacji jądra z backportów wypadało też zaktualizować stery Nvidii. To tajemna wiedza, której nie chciało zdradzić forum Minta. Inna sprawa, że to dział i wątek archowy, a tu starych pakietów nie ma.

[pavbaranov]

@Piotr_1988 - Wiem, że zeszliśmy w tym wątku na manowce, ale proponuję tego typu pytania zadawać oddzielnie, bo więcej osób skorzysta.
Niemniej jednak - pytanie do Pawła, ale zdaje się, że w Sparky 4 są też dostępne również inne wersje. Zanim jednak odpowiem Ci na pytanie, to zadam inne: po co Ci jest potrzebny inny, nowszy kernel. Kernel z linii 4.9 jest nadal wspierany, choć jego obecna wersja - upstreamowa - to 4.9.181, 4.9.0 to jakaś zamierzchła przeszłość i na pewno były jakieś aktualizacje tego kernela.
Teraz tak: wersje kerneli, kernele LTS itp.
Jeśli chodzi o wspierane przez upstream kernele nie mam powodów do obaw. Te kernele zachowują się mniej więcej tak:
1. Zawierają takie wsparcie sprzętowe, jakie miały w chwili wejścia; próżno zatem np. w 4.9 szukać wsparcia dla AMD Ryzen, czy AMD Vega. Jednak jeśli jakiś sprzęt był w tej wersji obsługiwany, nie uległ zmianie, to będzie on obsługiwany co najmniej na takim samym poziomie przez cały czas życia takiego kernela.
2. Otrzymuje wsparcie w zakresie wykrytych luk bezpieczeństwa, jak każda następna wersja. Trzeba jednak taki kernel z wersji "podstawowej" aktualizować do nowszej. To owe cyferki po drugiej kropce.
3. Zwykle otrzymuje też łatki w zakresie wykrytych błędów w fukcjonalności. Oczywiście tego, co jest dostarczane w ramach tej linii.
Mowa oczywiście o kernelu upstreamowym, a nie kernelu od Debiana, Ubuntu itp., albowiem te dystrybucje mają swoje pomysły na życie. Długo by rozmawiać, ale ich punkt widzenia jest po prostu wadliwy. Koniec, kropka.
Nowsze wersje kerneli oferują zwykle inną funkcjonalność. Może się ona przejawiać w obsłudze innego hardware'u. Może polepszać, czy zmieniać działanie dotychczasowego wsparcia.
Instalacja nowego kernela zawsze ma sens, jeśli dotyczy "trzeciej cyferki po drugiej kropce". Zawsze - wg mnie - gdy kernel traci wsparcie upstreamu (we wsparcie dystrybucyjne po prostu nie wierzę). Nowa wersja kernela jest natomiast zawsze konieczna, jeśli w ten sposób uzyskuje się wsparcie dla sprzętu, który do tej pory nie był właściwie obsługiwany.
Konsekwencje z nowego kernela? Żadne, jeśli żadne z dodatkowych sterowników (tych, których nie ma w kernelu) nie są w systemie używane bądź są one w wersji dkms. W przeciwnym przypadku wymagają również przebudowania. Klasycznym przykładem mogą być sterowniki własnościowe nvidia, które niekiedy z nowymi kernelami odmawiają współpracy.

PS: Budowa kernela samodzielnie ma sens niemal wyłącznie, gdy chcemy uzyskać cokolwiek innego niż to, co oferowane jest w dystrybucji.

[PomPom]

Co do kerneli dodam, że czasami backportowane jest też wsparcie sprzętu (albo kłamią). Takim sposodem 4.12 w OpenSUSE Leap obsłużyło elegancko mojego Ryzena 2200g i radeona rx570, i nadal niby jest łatane, mimo że 4.12 to zdechlak.

[pavbaranov]

@PomPom - Zgadza się, ale to wszystko zależy od dystrybucji i jakości kerneli, które dostarcza. Można w to wierzyć lub nie. Dla mnie jest dosłownie 5 dystrybucji na krzyż, którym w takim zakresie mógłbym zaufać.

[PomPom]

No ja sam wolę mieć jednak normalnie nowszy kernel, niż taki z backportami. 4.12 w OpenSUSE Leap siedzi, żeby nie oddalić się od komercyjnego SUSE.

[Piotr_1988]

Zanim jednak odpowiem Ci na pytanie, to zadam inne: po co Ci jest potrzebny inny, nowszy kernel.

Na Debianie 9 oraz obecnym Sparkim nie działa mi kamera mikroskopowa Delta Optical DLT-Cam Basic 2MP, która działa bezproblemowo na Debianie testing/buster oraz na Fedora 30.
Początkowo zwalałem to na starszą wersję Cheese. Teraz przypuszczam -ale to tylko przypuszczenie-, że to sprawa kernela. Nie chcę używać Debiana testing, bo są z nim nieustanne problemy różnego rodzaju - wolałbym np. backportować co trzeba [tak, wiem, jednen wątek, jeden problem].

Rozumiem, że kernel, którego dostarcza Debian, to nie taki sam kernel, jakiego dostarcza kernel.org  :o Nie, nie rozumiem tego.

Lenovo ThinkPad E480
Intel Core i5-8250U (4 rdzenie, od 1.6 GHz do 3.4 GHz, 6MB cache)
RAM 16 GB (SO-DIMM DDR4, 2400MHz)
Intel UHD Graphics 620
SSD M.2 PCIe 256 GB & HDD SATA 5400 obr. 1000 GB

[TataPingu]

Początkowo zwalałem to na starszą wersję Cheese

Zamiast Cheese spróbuj guvcview...
- tylko nie wiem, czy jest dostępny pod Sparky...

[Piotr_1988]

Początkowo zwalałem to na starszą wersję Cheese

Zamiast Cheese spróbuj guvcview...
- tylko nie wiem, czy jest dostępny pod Sparky...

Dzięki. Zainstalowałem, sprawdziłem, nie działa. Po podłączeniu kamery mikroskopowej guvcview się w przeciwieństwie do cheese chociaż uruchamia (w cheese trzeba kończyć proces), ale kamery zdaje się nie zauważać. Tymczasem w Debian testing problem nie występuje.

Edit
Za miesiąc będzie nowy Debian 10 i problem sam się rozwiąże..., bo w testing działa bezproblemowo. Lub sprawdzę najpierw, czy zadziała z innym kernelem. Póki co mam Fedorę live do obsługi kamery.

[TataPingu]

Dzięki. Zainstalowałem, sprawdziłem, nie działa. Po podłączeniu kamery mikroskopowej guvcview się w przeciwieństwie do cheese chociaż uruchamia (w cheese trzeba kończyć proces)

W takim razie załóż nowy wątek w odpowiedim miejscu i może coś na to poradzimy

[pavbaranov]

Zanim jednak odpowiem Ci na pytanie, to zadam inne: po co Ci jest potrzebny inny, nowszy kernel.

Na Debianie 9 oraz obecnym Sparkim nie działa mi kamera mikroskopowa Delta Optical DLT-Cam Basic 2MP, która działa bezproblemowo na Debianie testing/buster oraz na Fedora 30.

Trzeba byłoby przeglądnąć changelog kerneli, ale od czasów 4.9 do obecnych było bodaj 12 wydań nowych wersji. Całkiem możliwe, że jakieś rozwiązanie w nich zastosowane umożliwiło współpracę z Twoją kamerą, albowiem istnieje absolutnie małe prawdopodobieństwo, by brak jej obsługi był związany z oprogramowaniem. Początek linii 4.9 sięga przełomu roku 2016/17. Toż to 3 i pół roku temu. Dla oprogramowania to wieczność. Zawsze mówię - chcesz Debiana - musisz być świadom dlaczego, albo mieć przedpotopowy sprzęt. I nic nowego kupić nie wolno :)

Rozumiem, że kernel, którego dostarcza Debian, to nie taki sam kernel, jakiego dostarcza kernel.org  :o Nie, nie rozumiem tego.

To i tak i nie tak :) Każdy, dowolny kernel, dowolnej dystrybucji jest kompilowany ze źródeł. Podstawowe źródła, podstawowego wydania są udostępniane przez kernel.org. Każdy opiekun, dowolnej dystrybucji, taki kernel może skompilować na dziesiątki sposobów, które są - w skrócie - przekazywane budowanemu kernelowi przez plik config. Ów config może być różny, w różnych dystrybucjach. Wszystko zależy od wyboru opiekunów takiego kernela. Dodatkowo dochodzi też sposób jego budowania przez kompilator. Tu również mogą być różnice. W efekcie może się zdarzyć tak, że kernel w dystrybucji X będzie oparty na tych samych źródlach co w dystrybucji Y, ale binarki na nich zbudowane będą się różnić (także w zakresie funkcjonalności).
Dodatkowo można na takie źródła z kernel.org nałożyć jakieś patche, które nie są udostępniane przez upstream, albo nawet i są, ale pochodzą z następnych wersji.
W przypadku Debiana jest jak jest. Zasadniczo ich kernel nie ma jakichś dodatkowych patchy (np. w przeciwieństwie do kerneli z OpenMandriva), które nie pochodzą od upstream. Jeśli trafili z wersją w swoim wydaniu na wersję kernela LTS, to zwykle nowe wydania takiego kernela są zgodne ze źródłami z kernel.org. Jeśli nie trafili, to - zwykle - nadal utrzymują wersję kernela, która jest już EOL, ale próbują na to nałożyć patche z nowszych wersji.
Mam nadzieję, że jakoś to wyjaśniłem.

[Piotr_1988]

W SparkyLinux 4.10 podmieniłem domyślny kernel 4.9.0-9-amd64 na 5.1.0-9.4-liquorix-amd64.

Na chwilę obecną nie widzę, by coś niewspółgrało... Także odpowiadam sobie na pytanie, że nie jest to bardzo niebezpieczne. Kamera jednak wciąż nie działa, więc nie była to sprawa kernela.

[pavbaranov]

Na chwilę obecną nie widzę, by coś niewspółgrało... Także odpowiadam sobie na pytanie, że nie jest to bardzo niebezpieczne.

W ogóle nie jest "niebezpieczne" :)

Kamera jednak wciąż nie działa, więc nie była to sprawa kernela.

Załóż zatem odpowiedni wątek, przedstaw w nim jak jest ona widziana przez system, przez co podłączona i jaki program ma ją obsługiwać.