Linux-kysymyksiä & yleistä keskustelua Linuxista

[EliEli]

Tiedä noista, välillä jotain voi mennä rikki vaikka ei pitäisi.

Aikoinaan tein release upgraden useammalle Ubuntu-virtuaalikoneelle. Muut menivät ok läpi, yhdessä meni grub rikki päivityksen yhteydessä eikä enää suostunut buuttamaan. Onneksi oli snapshot tilanteesta ennen päivitystä jonka palauttamalla lähti taas buuttaamaan, sitten pari tuntia googlailua ja löytyi joskus samasta ongelmasta kärsineitä ja ohjeet komennoista mitä pitää antaa ENNEN release upgradea jotta ongelma ei toistu. Sillä meni sekin release upgrade läpi.

Itsellä on nykyisin myös rolling distro (OpenSUSE Tumbleweed) käytössä. Pari kertaa on päivityksen yhteydessä tullut varoitus konflikteista riippuvuuksien kanssa. En ole koskaan tohtinut koittaa onneani vaan olen canceloinut päivityksen siltä kertaa, odottanut muutaman päivän tai yhden viikon ja yrittänyt uudestaan. Silloin yleensä ei ole varoitusta enää tullut ja olen uskaltanut päivittää läpi, kai joku puuttuva riippuvuus on silloin päivittynyt ajan tasalle että on kaikki taas synkassa. Onneksi varoittelee.

OpenSUSE TW väitettiin jossain distro-vertailussa omaavan maineen "stabiilein rolling distro", en ota kantaa onko oikeastii näin ja mitä se todellisuudessa tarkoittaa.

 

[TemeV]

Ei vaan aukea, miten pakettiriippuvuuksien rikkinäisyydestä päädytään bootloopiin. Archissa näkee ongelman pakettien päivittämisessä ennen kuin asentaa yhtään uutta ja poistaa vanhaa.

Muistelen itselläni olleen ongelma se, että jokin softa sai ison päivityksen ja vaati myös joltain riippuvuudelta uusista uusinta versiota. Siellä oli vain ne riippuvuuksien versionumerot pakettiin kirjoitettu väärin, ja se suostui asentumaan, vaikka siitä riippuvuudesta tarjoiltiin edelleen pykälän vanhempaa. Jos tuollainen osuu johonkin bootissa käynnistettävään serviceen, niin saattaa tosiaan estää bootin. Nykyään kaiketi Archilla on testaus paremmin hallussa, niin noita sattuu vähemmän.

 

[love_doctor]

Muistelen itselläni olleen ongelma se, että jokin softa sai ison päivityksen ja vaati myös joltain riippuvuudelta uusista uusinta versiota. Siellä oli vain ne riippuvuuksien versionumerot pakettiin kirjoitettu väärin, ja se suostui asentumaan, vaikka siitä riippuvuudesta tarjoiltiin edelleen pykälän vanhempaa. Jos tuollainen osuu johonkin bootissa käynnistettävään serviceen, niin saattaa tosiaan estää bootin. Nykyään kaiketi Archilla on testaus paremmin hallussa, niin noita sattuu vähemmän.

Joo siis Archilla on välillä isoja päivityksiä. Esim. firmware-paketit jaettiin jokin aika sitten ja vaati manuaalista poistoa ja asentamista. Libc-päivitys on isompi myös ja pätee muihinkin distroihin. Näissä vaan se, että jos pacman herjaa vähänkään jotain ongelmaa, onko pakko ajaa ne päivitykset? Se että paketeista tippuu uusia versioita pitkin päivää ei tarkoita että koko ajan pitää olla kaikki ajan tasalla.

Itsellä on kolmella koneella Arch ja samaa asennusta siirtänyt levyltä toisellekin kun tulee isompi
konepäivitys. Vanhin Arch-asennus oli ajalta ennen systemd:tä 2000-luvun lopulta. Jos vaikka vertaa Ubuntuun (ei LTS), Gentoohon, Debian unstableen, niin Arch ei ole erityisemmin erottunut bugiherkemmäksi. Testing-paketeissa on välillä rikkinäisiä riippuvuuksia, mutta niitä ei ole pakko käyttää. Joskus kehittäjien avaimet pitänyt hakea käsin uudestaan kun paketit eivät asennu. Archin kanssa on yllättävää, että 1-2 vuotta päivittämättäkin ollut distro vielä lähtenyt pacmanilla päivittymään, kun esim. Ubuntulla on tyypillistä, että teet 4-5 versiopäivitystä peräjälkeen eikä mitenkään voi hypätä aiempien yli ellei tee puhdasta asennusta.

 

[JiiPee]

Debianin kohdallahan on vitsailtu iät ja kaiket jotakuinkin: "Unstable means testing, Testing means stable and Stable means old".

Vähän noin sen ittekin olen mieltänyt.

Jos redhat puolelta ettii vastaavuutta niin RHEL 6.12 kerneli jota taitaa toi debian stable käyttää.
Fedora 43 vois vastata unstablee
Fedora rawhide taikka ELN sitten testing.

Kyllähän toi 6.12 kerneli jo aika hapan alkaa olla. Mutta yleensä se kerneli ei nyt niin suuri ongelma ole vaan noiden jäädytettyjen distrojen ongelma on ne muut kriittiset palikat kuten python ja php jotka niissä on monesti happamia jo siinä vaiheessa kun ne julkaistaan.

Joo siis Archilla on välillä isoja päivityksiä. Esim. firmware-paketit jaettiin jokin aika sitten ja vaati manuaalista poistoa ja asentamista. Libc-päivitys on isompi myös ja pätee muihinkin distroihin.

Mikä pätee? Ainakaan Fedoran kanssa ole tarttenu mitään manuaalisia poistoja tehdä enää vuosiin. 3rd party repoja kun on käytössä niin ne voi aiheuttaa välillä jotain että käsin joutuu poistamaan.

Ja jos vähänkin tuntee syvemmin distron toimintaa niin pystyy aika hyvin kyllä päättelemään että mitkä on ns. kriittisiä paketteja. Joskus on ollut tilanne että että ei riippuvuudet vaan resolvaa kun on joku muutos tehty ja vanha paketti vaatii jotakii riippuvuuksia ja uusi sitten toisia josta sitten jotenkin syntyy mahdoton tilanne. Ne on tullu juurikin ratkottua niin että miettiny onko se kriittinen, jos ei ole niin forcella vaan poistoon ja sitten kun muut on päivitelty niin asentaa takas.
Mutta ei ole tuommoistakaan tarttenu pitkään aikaan tehdä.

 

[Makis]

Töissä piti käyttää Bookwormia melkein vuoden loppuun kun yksi tietoturvakomponentti ei tukenut Trixietä. Voin sanoa että hiukan alkoi mm Pythonin kanssa olla jo tuskaa...

 

[Barbarossa]

Töissä piti käyttää Bookwormia melkein vuoden loppuun kun yksi tietoturvakomponentti ei tukenut Trixietä. Voin sanoa että hiukan alkoi mm Pythonin kanssa olla jo tuskaa...

Jotenkin tämä nostaa muistoja esiin.. käytössä joku maailman paras proprietary tieto"turva" sötöstys joka toimii ainoastaan jollakin vanhalla distrolla ja sen takia pitää koko firman laahata muun maailman perässä. Ja kuitenkin se kasa paskaa parhaimmillaankin ainoastaan syö resursseja, mutta toisinaan myös rikkoo asioita tai pahempaa.

Vaan kun IT management haluaa ostaa vastuuvapautuksen käyttämällä näitä, sitten kun tuotosta leviää pitkin tuulettimia niin voidaan levitellä käsiä että hommattiin markkinoiden paras tietoturvapökäle, katsokaa nyt näitä prosyyrejä. Antakee bonuksia.

 

[JiiPee]

Eihän noi jäädytetyt distrot oikeen sovellu mihinkään muuhun käyttöön kuin sellaiseen jossa tiedät että sulla on tää ohjelmakattaus ja muuta et tartte eikä myöskään uudet fyytsörit ala myöhemmin janottaa. Silloin on ihan ok käyttökohde. Jos taas et välttämättä tiedä että että mitä ohjelmia tulevaisuudessa tarttet niin aika huono valinta.

Muistan kun aikoinaan CentOS 7 yritin jotakin hommaa saada toimimaan ja ei siitä tullu mitään kun se vaati jonkun python palikan ja siitä palikasta ei niin vanhalle pythonille ollut versiota edes olemassa.

Noh kontitus toki tuo helpotusta tuohon tuskaan mutta toisaalta taas monimutkaistaa asioita ihan turhaan varsinkin jos sitä konttihärpäkettä ei tartte muuhun kuin siihen yhteen kikottimeen.

 

[SamCer]

Fyytsöreistä puheenollen, osaako kukaan sanoa, miksi esim. Ubuntun uusin "normi"/LTS ei tue kirjautumista passkeyllä FreeIPA/IdM domainissa? Fedora on tukenu sitä jo versiosta 39 lähtien ja Ubuntullakin kaikki palikat on tukevasti jo tuen puolella.

Oon koittanu googlettaa ja kysellä tekoälyltä, mutta mitään ei oikein irtoa...

 

[eurokeitai]

Eihän noi jäädytetyt distrot oikeen sovellu mihinkään muuhun käyttöön kuin sellaiseen jossa tiedät että sulla on tää ohjelmakattaus ja muuta et tartte eikä myöskään uudet fyytsörit ala myöhemmin janottaa. Silloin on ihan ok käyttökohde. Jos taas et välttämättä tiedä että että mitä ohjelmia tulevaisuudessa tarttet niin aika huono valinta.

Muistan kun aikoinaan CentOS 7 yritin jotakin hommaa saada toimimaan ja ei siitä tullu mitään kun se vaati jonkun python palikan ja siitä palikasta ei niin vanhalle pythonille ollut versiota edes olemassa.

Noh kontitus toki tuo helpotusta tuohon tuskaan mutta toisaalta taas monimutkaistaa asioita ihan turhaan varsinkin jos sitä konttihärpäkettä ei tartte muuhun kuin siihen yhteen kikottimeen.

Itse asiassa nykyään juurikin konttauksen, appimagen ja flatpakin vuoksi on jäädytetty distro toimii erinomaisesti.

Konffaat distron kerran kuntoon ja asennat sen jälkeen kaiken distron ulkopuolelta flatpakina tai konttina. Ei tarvitse jännittää että uutta softaa varten asentamasi python rikkoo distron mukana tulleen hp-toolboxin ja tulostus ei enää onnistu. Sitten kun työprojektien on vähän enemmän löysää voi ottaa aikaa LTS -> LTS päivitykseen.

Rolling distroon voisin siirtyä sitten kun tarjolla on täydellinen rollback regression sattuessa kohdalla. NixOS:saa ilmeisesti on, mutta sen käyttö vaatii toistaiseksi sen, että Nix:stä tekee oman elämäntavan. Mutta josko kohta NixOS:stä tulisi helppokäyttöisempi...

 

[love_doctor]

Mikä pätee? Ainakaan Fedoran kanssa ole tarttenu mitään manuaalisia poistoja tehdä enää vuosiin. 3rd party repoja kun on käytössä niin ne voi aiheuttaa välillä jotain että käsin joutuu poistamaan.

Siis muihinkin distroihin pätee, että libc on isompi päivitys ja sitä ei välttämättä huomaa edes jos ei ole rolling-release, kun ison päivityksen yhteydessä voi muutenkin kaikki muuttua.

 

[JiiPee]

Itse asiassa nykyään juurikin konttauksen, appimagen ja flatpakin vuoksi on jäädytetty distro toimii erinomaisesti.

Tuossahan se heti tuli miksi nää kontti sun muut härpättimet on ärsyttäviä. Joka isompi distro kun haluaa tehdä jutut omalla tavalla, sitten kehitellään käytännössä päällekkäisiä ratkaisuja joissa erona on ainoastaan jokin typerä ideologia.

Ja juu redhat syyllistyy tähän kanssa ihan huolella. Niille ei docker jostain syystä kelvannut niin piti viritellä oma räpellys podman sitten joka on ainakin melkein yhteensopiva mutta ei kuitenkaan aina ihan aina ja tarjoaa sitten dockeriin nähden jotain aivan käsittämättömiä kummallisuuksia.

Eli taas tullaan siihen linuxin perisyntiin että on monia hyviä ideoita mutta ne ideat on sitten liian fragmentoituneita kun jokainen haluaa tehä omansa.

 

[jokujossai]

Ainakaan Fedoran kanssa ole tarttenu mitään manuaalisia poistoja tehdä enää vuosiin. 3rd party repoja kun on käytössä niin ne voi aiheuttaa välillä jotain että käsin joutuu poistamaan.

Fedora 43 päivityksen yhteydessä jouduin poistamaan wine:n ennen päivitystä. En selvittänyt tarkemmin, mistä johtui, koska helppo asentaa uudestaan päivityksen jälkeen. Fedora 43 yhteydessä myös pam_lastlog päivittyi pam_lastlog2, jonka seurauksena kirjautuminen saattoi hajota päivityksessä.

Ja juu redhat syyllistyy tähän kanssa ihan huolella. Niille ei docker jostain syystä kelvannut niin piti viritellä oma räpellys podman sitten joka on ainakin melkein yhteensopiva mutta ei kuitenkaan aina ihan aina ja tarjoaa sitten dockeriin nähden jotain aivan käsittämättömiä kummallisuuksia.

Itse olen pidemmän aikaa käyttänyt podmania enkä ole huomannut käsittämättömiä kummallisuuksia dockeriin verrattuna. Jotain ominaisuuksia puuttuu dockerista, esimerkiksi `--mount=type=image` ja quadlet, mutta varmasti myös dockerissa omat etunsa podmaniin verrattuna.

 

[Makis]

Tuli muuten hassu bugi kun vaihdoin tässä koneessa X11 + XFCE:n Waylandiin ja KDE Plasmaan: kirjautumisruutuun tuli sellainen juttu, että kun kirjoitan salasanan niin eka yritys ei kelpaa ikinä. Se ei ole vääräkään (tai ainakaan en saa ilmoitusta), mutta enter ei tee mitään. Pitää tyhjentää kenttä ja kirjoittaa salasana uudestaan. Eipä tuo iso ongelma ole, onpahan vain erikoinen.

 

[Barbarossa]

Itse olen pidemmän aikaa käyttänyt podmania enkä ole huomannut käsittämättömiä kummallisuuksia dockeriin verrattuna. Jotain ominaisuuksia puuttuu dockerista, esimerkiksi `--mount=type=image` ja quadlet, mutta varmasti myös dockerissa omat etunsa podmaniin verrattuna.

Kyllä itselläkin tulee käytettyä podmania dockerin sijaan. Ei tarvitse mitään daemoneita pyörimässä ja rootless containerit toimivat tuosta vaan. Kaikki tähän mennessä tarvitsemani virallisesti dockerille tehdyt imaget ovat toimineet, muutamassa tapauksessa joutunut vähän komentorivinuppeja vääntelemään mutta yhtään ei ole jäänyt ajelematta sen takia etteivät olisi toimineet.

 

[Mukava]

Tuli muuten hassu bugi kun vaihdoin tässä koneessa X11 + XFCE:n Waylandiin ja KDE Plasmaan: kirjautumisruutuun tuli sellainen juttu, että kun kirjoitan salasanan niin eka yritys ei kelpaa ikinä. Se ei ole vääräkään (tai ainakaan en saa ilmoitusta), mutta enter ei tee mitään. Pitää tyhjentää kenttä ja kirjoittaa salasana uudestaan. Eipä tuo iso ongelma ole, onpahan vain erikoinen.

Itselle käy tätä välillä SDDMn kanssa. Ei jatkuvasti mutta aina välillä.

No onneksi SDDM:sitä päästään pian eroon kun Plasma 6.6 pitäisi alkaa käyttämään Plasma Login Manageria joka on 100% KDEn palikka ja integroitu Plasmaan.

 

[Barbarossa]

Itselle käy tätä välillä SDDMn kanssa. Ei jatkuvasti mutta aina välillä.

No onneksi SDDM:sitä päästään pian eroon kun Plasma 6.6 pitäisi alkaa käyttämään Plasma Login Manageria joka on 100% KDEn palikka ja integroitu Plasmaan.

greetd + tuigreet, karu mutta eipähän ole liikaa riippuvuuksia...

 

[TemeV]

greetd + tuigreet, karu mutta eipähän ole liikaa riippuvuuksia...

Boottaa tekstikonsoliin ja käynnistää DE:n sieltä. Vielä karumpi ja vähemmän riippuvuuksia

Tuo KDE:n uusi ratkaisuhan on apinoitu Gnomelta, missä se login-ruutu jo sisältää ison osan työpöytäympäristön riippuvuuksista. Toisaalta, sitä ei ole tarkoitettukaan itsenäiseksi palikaksi, vaan käytettäväksi plasman kanssa, niin kokonaisuutena riippuvuudet ei oikeastaan lisäänny.

 

[keskiverto]

Jos redhat puolelta ettii vastaavuutta niin RHEL 6.12 kerneli jota taitaa toi debian stable käyttää.

RHEL:iä on yhä (maksua vastaan) versiot 7, 8, 9 ja 10, joiden kerneleiden pohjana olivat 3.10.0, 4.18.0, 5.14.0 ja 6.12.0. Eikö 6.12:lla ole hiukan pidennetty tuki?
Lähinnä "Enterprise Linux":n idea on pistää palvelu pystyyn ja ajaa sitä sitten (vain tietoturvapäivitykset lisäten) vuosia (tai kymmen). Sillä tapaa "stable".

Ja juu redhat syyllistyy tähän kanssa ihan huolella. Niille ei docker jostain syystä kelvannut niin piti viritellä oma räpellys podman

Dockerilla kontin käynnistäminen tavallisena käyttäjänä oli mahdoton yhtälö. Jotain oli pakko räpeltää.

Siis muihinkin distroihin pätee, että libc on isompi päivitys ja sitä ei välttämättä huomaa edes jos ei ole rolling-release, kun ison päivityksen yhteydessä voi muutenkin kaikki muuttua.

Esim. RHEL listaa libc:n ja pari muuta pakettia, joiden päivitetyn version saa käyttöön helpoiten uudelleen käynnistyksellä: Identify packages that will require a system reboot after an update - Red Hat Customer Portal
Siksi heillä on työkalu helpottamaan huomaamista.

 

[TemeV]

Eikö 6.12:lla ole hiukan pidennetty tuki?

Ei taida olla siinäkään kuin pari vuotta. Sen jälkeen mm. distrojen ylläpitäjät niitä paikkailee.

 

[Barbarossa]

Ei taida olla siinäkään kuin pari vuotta. Sen jälkeen mm. distrojen ylläpitäjät niitä paikkailee.

6.12 tuki jatkuu CIP projektin kautta 10 vuotta "virallisen" tuen loppumisen päättymisestä.

 

[JiiPee]

Kyllä itselläkin tulee käytettyä podmania dockerin sijaan. Ei tarvitse mitään daemoneita pyörimässä ja rootless containerit toimivat tuosta vaan. Kaikki tähän mennessä tarvitsemani virallisesti dockerille tehdyt imaget ovat toimineet, muutamassa tapauksessa joutunut vähän komentorivinuppeja vääntelemään mutta yhtään ei ole jäänyt ajelematta sen takia etteivät olisi toimineet.

Kyllä itteäni ainakin nyppii tuon podmanin kanssa se että koneen kun boottaat niin pitää käsinee kontteja alkaa käynnistellä. Dockerin kanssa asennat kontin ja sen jälkeen se vaan toimii. Boottaat koneen niin kontti käynnistyy dockerin käynnistymisen mukana.
Ja juu tiedän että saa ne bootissa käynnistymään mutta vaatii kohtuuttoman paljon värkkäämistä. Se nyt vielä jotenkin menis jos

Ja ei ole ittellä ollu myöskään mitenkään ruusuista noiden konttien toimiminen jotka on dockerille tehty alkujaan. Lähes asina on vähintään pitäny conffista jotakii muuttaa ja ei yks eika kaks kertaa kun on kontti lopettanu toimintanta kun bootin jälkeen on koittanu sitä ajella ylös.

Varmaan ihan kiva lelu jos sen kanssa jaksaa leikkiä mutta miksi kuluttaa moiseen aikaa kun on sellainenkin kontti ympäristö olemassa jossa homma vaan toimii?

 

[Lammas]

Kyllä itteäni ainakin nyppii tuon podmanin kanssa se että koneen kun boottaat niin pitää käsinee kontteja alkaa käynnistellä. Dockerin kanssa asennat kontin ja sen jälkeen se vaan toimii. Boottaat koneen niin kontti käynnistyy dockerin käynnistymisen mukana.
Ja juu tiedän että saa ne bootissa käynnistymään mutta vaatii kohtuuttoman paljon värkkäämistä. Se nyt vielä jotenkin menis jos

Ja ei ole ittellä ollu myöskään mitenkään ruusuista noiden konttien toimiminen jotka on dockerille tehty alkujaan. Lähes asina on vähintään pitäny conffista jotakii muuttaa ja ei yks eika kaks kertaa kun on kontti lopettanu toimintanta kun bootin jälkeen on koittanu sitä ajella ylös.

Varmaan ihan kiva lelu jos sen kanssa jaksaa leikkiä mutta miksi kuluttaa moiseen aikaa kun on sellainenkin kontti ympäristö olemassa jossa homma vaan toimii?

Eihän dockerkaan defaulttina käynnistä kontteja bootin jälkeen? Näyttäisi siltä, että vipu automaattisen käynnistyksen enablointiin on täsmälleen sama dockerissa ja podmanissa, eli en näe mitään eroa tässä suhteessa, tosin en ole kyseistä ominaisuutta ikinä halunnut tai tarvinnut niin en tiedä.

Mä siirryin dockerista podmaniin joskus vuosi sitten, enkä muista kohdanneeni yhtään ongelmatilannetta, joka olisi ollut vältettävissä dockeria käyttämällä. Nvidian GPU:n enablointi tosin vaati hieman dokumentaation lukemista, koska se tapahtui vähän eri tavalla podmanilla.