Linux-kysymyksiä & yleistä keskustelua Linuxista

[meridian]

Päätinpä sitten eilen illalla päivittää Debianin komennoilla apt update ja apt full-upgrade.

Alkuun vaikutti toimivan hyvin ja versioksi muuttui uusin 12.5, mutta sitten tapahtui jotain mystistä. Kun yritin normaalisti päivittää apt upgradella, niin tuhatkunta pakettia jäi "odottamaan päivitystä".

Noh, kone toimi normaalisti, joten jatkoin puuhastelua ja lopulta sammutin koneen. Kun seuraavan kerran yritin käynnistää, tuli eteen vain musta ruutu. Ilmeisesti joku/jotkut näistä paketeista olisi ollut tarpeen päivittää vaikka väkisin... Ei auttaneet mitkään näppäinkomennot, että olisi päässyt pelkälle komentoriville ilman graafista käyttöliittymää.

Kertaalleen sain bootattua grubin kautta valitsemalla vanhan kernelin, mutta kun siellä sit päivittelin systeemiä, lakkasi sekin toimimasta...

Sain kuitenkin oleelliset tiedostot talteen toiselle osiolle, joten kikkailun välttämiseksi vedin sileäksi koko käyttöjärjestelmäosion ja asensin tikulta uuden version. Nyt toimii taas.

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

 

[Barbarossa]

Kiitos avusta. Näissä on vaan se ongelma, että pitäisi ensiksi keksiä kaikki mahdolliset konffit noihin tiedostoihin jostain. Mulla on 2015 asti päivitetty Kubuntu ja Pipewire tuli ehkä pari päivitystä sitten. /etc/pipewire/media-session.d/ :ssä ei ole yhtikäs mitään. Eli joutuu lukemaan manuaaleja, että mitä niihin pitää tunkea jos ei ole valmiita pohjia missään, niin menee vaan rutosti aikaa.

Tuo mainitsemasi hakemisto viittaa vanhaan pipewire-media-sessioniin, joka oli PW:n aikaisempi sessionhallinta ja jonka kehitys loppui jokunen vuosi sitten kun WirePlumber korvasi sen. Ennen enempää perehtymistä kannattanee varmistaa että kyseessä ei ole jäännös vanhasta versiosta ja että Ubuntukin on jo siirtynyt WirePlumberin käyttöön.

Suspendin disabloimiseen löytyy pari eri tapaa PipeWire FAQista Troubleshooting · Wiki · PipeWire / pipewire · GitLab ja WirePlumberille lyhyt opas Disable Pipewire Suspend on Idle to avoid audio pops, delays, and white noise

 

[SamCer]

Päätinpä sitten eilen illalla päivittää Debianin komennoilla apt update ja apt full-upgrade.

Alkuun vaikutti toimivan hyvin ja versioksi muuttui uusin 12.5, mutta sitten tapahtui jotain mystistä. Kun yritin normaalisti päivittää apt upgradella, niin tuhatkunta pakettia jäi "odottamaan päivitystä".

Noh, kone toimi normaalisti, joten jatkoin puuhastelua ja lopulta sammutin koneen. Kun seuraavan kerran yritin käynnistää, tuli eteen vain musta ruutu. Ilmeisesti joku/jotkut näistä paketeista olisi ollut tarpeen päivittää vaikka väkisin... Ei auttaneet mitkään näppäinkomennot, että olisi päässyt pelkälle komentoriville ilman graafista käyttöliittymää.

Kertaalleen sain bootattua grubin kautta valitsemalla vanhan kernelin, mutta kun siellä sit päivittelin systeemiä, lakkasi sekin toimimasta...

Sain kuitenkin oleelliset tiedostot talteen toiselle osiolle, joten kikkailun välttämiseksi vedin sileäksi koko käyttöjärjestelmäosion ja asensin tikulta uuden version. Nyt toimii taas.

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

GRUB kun on käytössä, niin voit lisätä numeron 3 kernelin boot parametreihin editoimalla GRUB-bootmenussa, niin kone käynnistyy suoraan komentoriville ilman grafiikkaa. Sen jälkeen vaan logeja kattelemaan missä vika.

[edit] Toi on tosin vain arvailua näillä tiedoilla. Pitäis saada enemmän dataa tapahtuneesta logien kautta. Toi, et jätetään päivityksiä odottamaan, johtuu ainakin Ubuntulla siitä, että kyseiseinen päivitys, kyseisellä käyttisversiolla on johtanyt ongelmiin X-prosentilla päivityksen asentajista, jonka vuoksi sen jakelu on keskeytetty kyseiselle käyttisversiolle.

Toi tuhatkunta on kyllä niin julmeton määrä, et kyse ei taida olla tuosta...

 

[jkaart]

Semmonen huomio, että noi ritinät ja poksahdukset ei tallennu Pipewire FAQ:ssa neuvottuun audio data dumpiin. Koneella kuunellessa tietenkin kuuluu noita (ja joka kerta eri kohassa), mutta kun tuo siirti puhelimeen ja sillä kuunteli niin äänessä ei ollu mitään ylimäärästä häiriötä.
Edit: niin eikä niitä kuulu samaisen Ubuntun asenustikulta löytyvästä puhtaasta asennuksesta.

 

[JiiPee]

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

Vastausta en osaa antaa mutta ittellä on jo yli 10v takaa aika samanlainen kokemus debianin kanssa. Se sitten jäikin viimeiseksi kokeiluksi kyseisen distron kanssa.

 

[Cor3]

Päätinpä sitten eilen illalla päivittää Debianin komennoilla apt update ja apt full-upgrade.

Alkuun vaikutti toimivan hyvin ja versioksi muuttui uusin 12.5, mutta sitten tapahtui jotain mystistä. Kun yritin normaalisti päivittää apt upgradella, niin tuhatkunta pakettia jäi "odottamaan päivitystä".

Noh, kone toimi normaalisti, joten jatkoin puuhastelua ja lopulta sammutin koneen. Kun seuraavan kerran yritin käynnistää, tuli eteen vain musta ruutu. Ilmeisesti joku/jotkut näistä paketeista olisi ollut tarpeen päivittää vaikka väkisin... Ei auttaneet mitkään näppäinkomennot, että olisi päässyt pelkälle komentoriville ilman graafista käyttöliittymää.

Kertaalleen sain bootattua grubin kautta valitsemalla vanhan kernelin, mutta kun siellä sit päivittelin systeemiä, lakkasi sekin toimimasta...

Sain kuitenkin oleelliset tiedostot talteen toiselle osiolle, joten kikkailun välttämiseksi vedin sileäksi koko käyttöjärjestelmäosion ja asensin tikulta uuden version. Nyt toimii taas.

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

Debian on yksi eniten vakaimmista distroista, näin melkein 30-vuoden kokemuksella sanottuna. Stable releasin pitäisi päivittyä aina ongelmitta. Mutta suosittelen ottamaan niitä varmuuskopioita levystä ja tiedostoista. Suosittelen varmuuskopiomaan käyttöjärjestelmän esim. Clonezillalla aina silloin tällöin niin välttyy isommilta asennus ruljansseilta.

 

[Lammas]

Mistä johtuu, että Ubuntu 24.04:ssä "dmesg --ctime" näyttää kellonaikoja, jotka on noin 11,5 tuntia edellä verrattuna oikeaan aikaan (jonka mm. "date" näyttää)?

Joskus kauan sitten dmesg:n näyttämät kellonajat oli ihan pielessä, mutta se johtui ilmeisesti siitä, että se kello pysähtyi aina kun koneen laittoi lepotilaan tms., mutta tuo bugi korjattin jo aikoja sitten ja esim. Ubuntu 20.04:ssä ajat oli aina oikein.

 

[jkaart]

Mistä johtuu, että Ubuntu 24.04:ssä "dmesg --ctime" näyttää kellonaikoja, jotka on noin 11,5 tuntia edellä verrattuna oikeaan aikaan (jonka mm. "date" näyttää)?

Joskus kauan sitten dmesg:n näyttämät kellonajat oli ihan pielessä, mutta se johtui ilmeisesti siitä, että se kello pysähtyi aina kun koneen laittoi lepotilaan tms., mutta tuo bugi korjattin jo aikoja sitten ja esim. Ubuntu 20.04:ssä ajat oli aina oikein.

Kyllä tuo mulla ainakin näyttää ihan oikeata aikaa.

 

[jkaart]

Taisi löytyä viimein ratkasu tohon ääni ongelmaan ja näyttäs ratkeavan nostamalla pipewiren prosessin prioritettia.
Mutta kysymys kuuluu, miten tämän saa pysyvästi korkeammalle prioriteetille?
Kun esim. system monitorista tai vaikka topissa tota saa käsin muutettua kyllä, mutta miten ton sais pysyvästi isommalle, että ei tarviis joka buutissa ruuvata tota?

 

[Hyrava]

Taisi löytyä viimein ratkasu tohon ääni ongelmaan ja näyttäs ratkeavan nostamalla pipewiren prosessin prioritettia.
Mutta kysymys kuuluu, miten tämän saa pysyvästi korkeammalle prioriteetille?
Kun esim. system monitorista tai vaikka topissa tota saa käsin muutettua kyllä, mutta miten ton sais pysyvästi isommalle, että ei tarviis joka buutissa ruuvata tota?

En tiedä saisiko tuon prioriteettia heti prosessin käynnistyksessä säädettyä (varmaan onnistuisi jostain palvelun asetustiedostosta) mutta ainakin käynnissä olevan prosessin prioriteettia voi muokata renice-komennolla. Ja tuon renice-komennon sopivilla parametreilla saisi varmaan johonkin koneen startup-skriptiin laitettua.

Ilmeisesti pipewiren konffissa on joku "nice.level" -parametri jolla tuota voisi säätää mutta itsellä ei ole kokemusta.

 

[Barbarossa]

Taisi löytyä viimein ratkasu tohon ääni ongelmaan ja näyttäs ratkeavan nostamalla pipewiren prosessin prioritettia.
Mutta kysymys kuuluu, miten tämän saa pysyvästi korkeammalle prioriteetille?
Kun esim. system monitorista tai vaikka topissa tota saa käsin muutettua kyllä, mutta miten ton sais pysyvästi isommalle, että ei tarviis joka buutissa ruuvata tota?

Ei ole tullut Ubuntujen kanssa tolskattua Pipewire-aikakaudella, mutta tuon pitäisi toimia ilman että tarvitsee käsin härppiä. Pipewire asettaa itse prioritynsä korkeammalle jos tarvittavat oikeudet ovat kunnossa, tai vaihtoehtoisesti pyytää sitä RTKitiltä DBusin kautta. Jälkimmäisen tavan vaatimuksista ei tietoa, mutta ensiksi mainittu on ainakin muutamassa muussa distrossa sidottu pipewire groupiin. Eli käyttäjän jolla halutaan pipewireä käyttää tulee olla tuossa groupissa.

Kannattaa kurkistaa onko pipewiren paketissa mukana /etc/security/limits.d/ hakemistoon tulevaa confia, jos tulee niin siitä pitäisi selvitä group johon käyttäjä lisäämällä homman pitäisi suttaantua. Jos sitä ei tule niin kenties Ubuntulla on joku eri tapa tehdä tuo.

Esim Fedorasta pipewire-paketista löytyy /etc/security/limits.d/25-pw-rlimits.conf jossa:

@pipewire   - rtprio  70
@pipewire   - nice    -19
@pipewire   - memlock 4194304

 

[jkaart]

Eipä se tuo käsin prioritetin nosto auttanu sittenkään...kahta kauheempana rätisee.
Kokeilaan käyttäjän lisäämistä vielä tonne pipewire ryhmään....tosin minusta minä tämänkin koitin jo aikasemmin.
Semmosen huomion tein kans, kun ihmettelin tuota system monitoria, että kun ääni rätisee ja poksuu niin niin pipewire-pulse prosessi hyppii sleeping ja running väliä minusta jatkuvasti. Sillon kun audio toimii niin toi pysyy running tilassa koko ajan niin pitkään kuin ääntä soittaa.

 

[Barbarossa]

Eipä se tuo käsin prioritetin nosto auttanu sittenkään...kahta kauheempana rätisee.
Kokeilaan käyttäjän lisäämistä vielä tonne pipewire ryhmään....tosin minusta minä tämänkin koitin jo aikasemmin.
Semmosen huomion tein kans, kun ihmettelin tuota system monitoria, että kun ääni rätisee ja poksuu niin niin pipewire-pulse prosessi hyppii sleeping ja running väliä minusta jatkuvasti. Sillon kun audio toimii niin toi pysyy running tilassa koko ajan niin pitkään kuin ääntä soittaa.

Erikoinen tapaus kyllä. Jotenkin kai pitäisi pystyä haarukoimaan että mitä tuossa on eri tavalla silloin kun se toimii ongelmitta verrattuna rätinään. Onko jokin tietty softa jonka äänet rätisevät? Ja onko se joka kerta sama softa? Tai onko useampi aktiivinen ääntä tuottava softa käynnissä?

Jotakin vinkkiä voisi saada myös jos vertaa esim. pw-top tai pw-dump työkalujen ulosantia äänten toimiessa ja rätistessä. Jälkimmäinen tosin tuuttaa pitkän JSONin jonka vertaaminen voi vaatia toisenkin kupillisen kahvia.


Hämärä flashback tuli miten vuosia sitten painiskelin vastaavan ongelman kanssa, satunnaisesti äänentoistossa oli epämääräisiä napsumisia ilman että mikään ilmiselvä olisi muuttunut välissä. Parin spirtismisession jälkeen hoksasin että äänilaitteen sample rate oli eri tapausten välillä.

Ongelman ilmetessä oli käynnissä useampi ääntä tuottava softa (en muista mitkä), ja riippuen missä järjestyksessä softat avasivat streamin ongelma joko tuli tai ei tullut. Toiston sample rate asetettiin ensimmäisen streamin mukaan, jos softa X oli ekana, niin sample rateksi tuli 48kHz ja toisen softan toisto poksui. Jos softa Y kerkesi ensin, sample rate oli 44.1kHz ja äänet toimivat täydellisesti.

En muista enää löytyikö tähän oikeakin ratkaisu vai päädyinkö johonkin workaroundiin, mutta ei tuota ole tapahtunutkaan vuosikausiin. Saattoi jopa olla kun vielä käytin PulseAudiota, joten ei välttämättä edes liity juuri sinun ongelmaasi.

 

[Ryzkis40]

Mint Cinnamonin jälkeen kokeilin Matea ja mikäs sen tehtäväpalkkia mahtaa vaivata kun välillä ei voi klikata toista tehtäväpalkissa auki olevaa ikkunaa/ohjelmaa esille, vaan se alkaa vilkuttamaan sillä hetkellä esillä olevaa ikkunaa/ohjelmaa tehtäväpalkissa. Kun klikkaan sitä niin se esillä oleva ikkuna minimoituu ja vasta sen jälkeen voin klikkailla muita luukkuja tehtäväpalkissa. Tilanne missä tämän saa varmasti ainakin itsellä aina toistettua on pitää ohjelma A esillä ja klikata starttivalikko auki, minkä jälkeen en voi sen jälkeen suoraan klikata ohjelmaa B tehtäväpalkissa esille vaan pitää klikata ohjelmaa A ensin jolloin se minimoituu. Hivenen kankealta ja epäloogiselta tuntuu.

Edit: Jahas, nähtävästi johtui Window managerin vaihdosta oletuksen Marco + compositing -> Marco + compton minkä yksi tuninkisivu neuvoi vaihtamaan. Typerä tuunausneuvo kun huonontaa käytettävyyttä.

 

[Marquette]

Mikähän on vika? Kone on vanha 4770K ja siinä Debian (uusin, päivitetty) ja Virtualbox ja siellä Windows 11, missä ajoin sitä Microsoftin virustorjunnan full scannia. Sain kolme kertaa koneen buuttaamaan hallitsemattomasti, eli jotenkin rasitukseen tämä

.. tämä jo ratkesi

 

[SamCer]

Mikähän on vika? Kone on vanha 4770K ja siinä Debian (uusin, päivitetty) ja Virtualbox ja siellä Windows 11, missä ajoin sitä Microsoftin virustorjunnan full scannia. Sain kolme kertaa koneen buuttaamaan hallitsemattomasti, eli jotenkin rasitukseen tämä

.. tämä jo ratkesi

Mikä se ratkaisu oli?

 

[jkaart]

Erikoinen tapaus kyllä. Jotenkin kai pitäisi pystyä haarukoimaan että mitä tuossa on eri tavalla silloin kun se toimii ongelmitta verrattuna rätinään. Onko jokin tietty softa jonka äänet rätisevät? Ja onko se joka kerta sama softa? Tai onko useampi aktiivinen ääntä tuottava softa käynnissä?

Jotakin vinkkiä voisi saada myös jos vertaa esim. pw-top tai pw-dump työkalujen ulosantia äänten toimiessa ja rätistessä. Jälkimmäinen tosin tuuttaa pitkän JSONin jonka vertaaminen voi vaatia toisenkin kupillisen kahvia.


Hämärä flashback tuli miten vuosia sitten painiskelin vastaavan ongelman kanssa, satunnaisesti äänentoistossa oli epämääräisiä napsumisia ilman että mikään ilmiselvä olisi muuttunut välissä. Parin spirtismisession jälkeen hoksasin että äänilaitteen sample rate oli eri tapausten välillä.

Ongelman ilmetessä oli käynnissä useampi ääntä tuottava softa (en muista mitkä), ja riippuen missä järjestyksessä softat avasivat streamin ongelma joko tuli tai ei tullut. Toiston sample rate asetettiin ensimmäisen streamin mukaan, jos softa X oli ekana, niin sample rateksi tuli 48kHz ja toisen softan toisto poksui. Jos softa Y kerkesi ensin, sample rate oli 44.1kHz ja äänet toimivat täydellisesti.

En muista enää löytyikö tähän oikeakin ratkaisu vai päädyinkö johonkin workaroundiin, mutta ei tuota ole tapahtunutkaan vuosikausiin. Saattoi jopa olla kun vielä käytin PulseAudiota, joten ei välttämättä edes liity juuri sinun ongelmaasi.

Hmm...
Ulostulon sample rate näyttäs olevan mulla kait väärä?

Eikös tuon pitäs olla sama 44.1kHz kuin tolla lähteellä eli VLC:lla?
Tosin rätinään toi ei vaikuta, kun Firefox ja esim. Youtube videot ovat 48kHz ja silloin toi lähde on myös 48000 mutta silti rätisee. Sitähän en tosin tiiä onko Youtube videooiden audio raidat sitten 48kHz oikeasti...

 

[Marquette]

Mikä se ratkaisu oli?

Ne core multiplierit oli sittenkin liian suuret 44,43,42,41 eli joku oli niitä säätänyt joskus, kun tuonhan piti olla 3,5 GHz ja "turbo" 3,9 GHz. Pienensin kaikkia yhdellä niin sitten sain ajeltua virustarkistukset (yms. näennäispuuhat) läpi. Ajoin myös memtest:iä 20 minuuttia. Muistista ei löytynyt mitään vikaa tuolla ajalla, joten en tiedä lopulta mihin kaatui, muuta kuin "liian korkeaan multiplieriin".

 

[Barbarossa]

Hmm...
Ulostulon sample rate näyttäs olevan mulla kait väärä?

Eikös tuon pitäs olla sama 44.1kHz kuin tolla lähteellä eli VLC:lla?
Tosin rätinään toi ei vaikuta, kun Firefox ja esim. Youtube videot ovat 48kHz ja silloin toi lähde on myös 48000 mutta silti rätisee. Sitähän en tosin tiiä onko Youtube videooiden audio raidat sitten 48kHz oikeasti...

Ei tuolla pitäisi normaalisti olla merkitystä, vaikka olisi yhtä aikaa useampi lähde eri sample ratea puskemassa.

Tähän tapaan:

Spoileri