Linux-kysymyksiä & yleistä keskustelua Linuxista

Dokumentaatio löytyy vaikka linux-doc-nimisestä paketista, ainakin Ubuntussa, tiedostosta /usr/share/doc/linux-doc/sysctl/net.txt.gz.
Samoin kun uutisista keskustellessa ei riitä vain linkin heittäminen ilman omaa inputtia, ei tietotekniikasta keskustella riitä heittää satunnaisia komentoja avaamatta niiden tarkoitusta.

Niitäkin tapauksia löytyy ihan riittävästi, kun komennot antanut käyttäjä ei itse ymmärrä, mitä hänen antamansa komennot tekevät, jolloin ainakin sivustaseuraajat osaisivat tulla kertomaan, että oikeastaan tuolla tavalla vain paskoo koneensa ennemmin kuin korjaa ongelmia.

Buffereiden käpistely on oppikirjaesimerkki tällaisesta tilanteesta. Ulkopuolinen ei voi millään tietää, ovatko annetut arvot järjellisiä tai kenties typotettuja tai että onko kirjoittaja vain ravistanut ne hihastaan, koska ne kai toimivat joskus vuosia aiemmin täysin eri ongelmaan.
 
Viimeksi muokattu:
Mistähän kannattaisi lähteä etsimään vikaa kun Linuxilla ftp/sftp siirrot ovat vain murto-osan nopeuden osalta kuin Windowsilla?

Windowsilla kun saa koko kaistan täydeltä (100Mbit download) mutta linuxilla jäädään sinne 3-4megaan siirtonopeudessa. Tämä siis Wifin kautta. Wifi-korttina läppärissä on Intelin 7360 kortti

En nyt ihan ensiksi lähtisi säätämään kernelin buffereita. Tyypillisesti sellaiselle ei pitäisi olla mitään tarvetta.
Onko sulla siis sama kone, jossa vaihdat dual-bootilla Windowsin ja Linuxin välillä? Vai onko kyseessä eri koneet?
WLAN-kortin ajurissa voi olla jotain pielessä Linuxin puolella.

Mikä on läppärisi malli ja mikä Linux-jakelu on kyseessä?
 
Viimeksi muokattu:
En nyt ihan ensiksi lähtisi säätämään kernelin buffereita. Tyypillisesti sellaiselle ei pitäisi olla mitään tarvetta.
Onko sulla siis sama kone, jossa vaihdat dual-bootilla Windowsin ja Linuxin välillä? Vai onko kyseessä eri koneet?
WLAN-kortin ajurissa voi olla jotain pielessä Linuxin puolella.

Mikä on läppärisi malli ja mikä Linux-jakelu on kyseessä?
Juu dualbootti kyseessä Win10 ja Fedora 30 (sama ongelma tosin oli jo Fedora 29:lla sekä Manjarolla). KYseessä siis Thinkpad T480.

EDIT: Mitä nyt nopealla googlailulla sain selville niin syy vaikuttaisi olevan Intelin surkeissa linux-ajureissa, tai ainakin vähän tälläinen kuva jäi mieleen.
 
Viimeksi muokattu:
Samoin kun uutisista keskustellessa ei riitä vain linkin heittäminen ilman omaa inputtia, ei tietotekniikasta keskustella riitä heittää satunnaisia komentoja avaamatta niiden tarkoitusta.

Niitäkin tapauksia löytyy ihan riittävästi, kun komennot antanut käyttäjä ei itse ymmärrä, mitä hänen antamansa komennot tekevät, jolloin ainakin sivustaseuraajat osaisivat tulla kertomaan, että oikeastaan tuolla tavalla vain paskoo koneensa ennemmin kuin korjaa ongelmia.

Buffereiden käpistely on oppikirjaesimerkki tällaisesta tilanteesta. Ulkopuolinen ei voi millään tietää, ovatko annetut arvot järjellisiä tai kenties typotettuja tai että onko kirjoittaja vain ravistanut ne hihastaan, koska ne kai toimivat joskus vuosia aiemmin täysin eri ongelmaan.
Se että postaan mistä paketista löytyy dokumentaatiota, ja toisin kuin @Leo_Greta väittää, en usko kaikkien tietävän tuosta, ei tarkoita, ettei asiasta keskustelua voida enää jatkaa. En itsekään tiennyt mitä nuo tekevät, niin en viitsinyt sitä yrittää alkaa selittämään.
 
Mistähän kannattaisi lähteä etsimään vikaa kun Linuxilla ftp/sftp siirrot ovat vain murto-osan nopeuden osalta kuin Windowsilla?

Windowsilla kun saa koko kaistan täydeltä (100Mbit download) mutta linuxilla jäädään sinne 3-4megaan siirtonopeudessa. Tämä siis Wifin kautta. Wifi-korttina läppärissä on Intelin 7360 kortti

Miltä yhteyden statistiikka näyttää kun olet siirtänyt tavaraa hetken aikaa? Esim. cat /proc/net/wireless tai iwconfig <kortti>.

Oletkos muuten varma tuosta kortin mallista? Tuo näyttäisi Intelin katalogissa olevan LTE modeemi.

En nyt ihan ensiksi lähtisi säätämään kernelin buffereita. Tyypillisesti sellaiselle ei pitäisi olla mitään tarvetta.
Onko sulla siis sama kone, jossa vaihdat dual-bootilla Windowsin ja Linuxin välillä? Vai onko kyseessä eri koneet?
WLAN-kortin ajurissa voi olla jotain pielessä Linuxin puolella.

Mikä on läppärisi malli ja mikä Linux-jakelu on kyseessä?

Vähän samoilla linjoilla, en välttämättä ensimmäisenä lähtisi ihan sokkona (vastaanotto)buffereita härppimään...
 
Miltä yhteyden statistiikka näyttää kun olet siirtänyt tavaraa hetken aikaa? Esim. cat /proc/net/wireless tai iwconfig <kortti>.

Oletkos muuten varma tuosta kortin mallista? Tuo näyttäisi Intelin katalogissa olevan LTE modeemi.
cat /proc/net/wireless näyttää seuraavaa

Inter-| sta-| Quality | Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlp3s0: 0000 59. -51. -256 0 0 0 0 56 0

ja iwconfig:

wlp3s0 IEEE 802.11 ESSID:"Kotiverkko"
Mode:Managed Frequency:5.18 GHz Access Point: 8C:3B:AD:B3:14:F2
Bit Rate=650 Mb/s Tx-Power=22 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=59/70 Signal level=-51 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:60 Missed beacon:0

Katsoin tosiaan kortin väärin, oikea kortti lspci:n mukaan on Intel Corporation Wireless 8265 / 8275 (rev 78)
 
cat /proc/net/wireless näyttää seuraavaa

Inter-| sta-| Quality | Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlp3s0: 0000 59. -51. -256 0 0 0 0 56 0

ja iwconfig:

wlp3s0 IEEE 802.11 ESSID:"Kotiverkko"
Mode:Managed Frequency:5.18 GHz Access Point: 8C:3B:AD:B3:14:F2
Bit Rate=650 Mb/s Tx-Power=22 dBm
Retry short limit:7 RTS thr:eek:ff Fragment thr:eek:ff
Power Management:eek:n
Link Quality=59/70 Signal level=-51 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:60 Missed beacon:0

Katsoin tosiaan kortin väärin, oikea kortti lspci:n mukaan on Intel Corporation Wireless 8265 / 8275 (rev 78)

Ei nuo kovin ongelmallisilta näytä. Minulla joskus Intelin wifikortti (Ultimate-N 6300) takkusi pahasti myöskin joillakin siirtoprotokollilla, mutta tässä tapauksessa hyvästä signaalista huolimatta tuli valtavasti virheitäkin. Lienee siis erilainen ongelma.
 
Jahas, taas ollaan tutun ongelman ääressä, onko Linuxissa mitenkään mahdollista pakkotappaa prosessia?
Tulin läppärin kanssa reissusta, löin LAN -piuhan kiinni katkaisematta ensin WLANia, pistin verkkolevyllä olevat videot enkoodaukseen ja myöhemmin huomasin, että Dolphin oli vetänyt itsensä jojoon. Ei vastaa mihinkään, ajoittain kysyy odotetaanko vai tapetaanko prosessi ja vaikka tappaisi sen, ei se kuole. Ei auta edes rootilla suoritettu SIGKILL. F12:lla aukeavaan terminaaliin syötin df -h katsoakseni verkkolevyn tilanteen ja nyt sekin terminaali on löysässä hirressä eikä suostu kuolemaan. Muuten kyllä verkkolevy toimii kuten pitää, toisella tiedostoselaimella ei ole mitään ongelmaa ja em. videoenkoodauskin toimii, mutta se on myös syy, miksi ei huvittaisi lähteä reboottaamaankaan ihan hetkeen.
 
Täällä ihan samanlaista nopeuden katoamista verkkosiirrossa. Huomaan sen kahdella eri tavalla:

1) kiinteälläkin kaapeliyhteydellä nopeutta häviää esim. tiedostoja siirtäessä samba-jakoihin

2) Intelin wifi-ajurien kanssa nopeutta katoaa "johonkin" vaikka signaali tukiasemaan on ihan ok.

Mitään kunnon ratkaisua en ole löytänyt näihin, mutta eri tapoja testata ja sorkkia asetuksia kyllä. Verkon kapasiteettia olen testannut iperf -komennolla ja ihan speedtest.netillä. Jos iperfillä näyttää tulevan verkon maksimikapasiteetilla bittiä läpi, samba-siirroissa siitä on hukkaantunut johonkin puolet. Ehkä ftp/sftp:n kanssa vastaava ongelma, mutta mitään pikaratkaisua tähän ei ole. ethtool -K <interface> -komennolla voi räplätä verkkokortin optioita. "tso off" ja "gso off" -optioita kokeilin itse ja ehkä joku pieni apu oli niistä.

Intelin wifi on sitten oma juttunsa, ja luulen että ajurit ovat yksinkertaisesti paskemmat kuin windowsilla. Vieressä on Win10-läppäri suunnilleen samalla Intelin piirisarjalla ja se siirtää ulkomaailmaan 190 Mb/s kun linux-kone sai alussa läpi 80 Mb/s ja säätämisen jälkeen 130 Mb/s. Johonkin katoaa kymmeniä prosentteja kapasiteetista vaikka signaalin laatu on ihan OK.

Tälläistä säätöä olen yrittänyt Intelin wifin kanssa:

- /etc/modprobe.d/iwlwifi.confiin optiot "options iwlwifi bt_coex_active=0 11n_disable=8"

- tukiasemasta 802.11n radio pois päältä ja pakotetaan kaikki yhteydet 802.11ac:lle

- iwconfig <interface> power off (ei vaikutusta)

Netissä on aika lailla sivuja näistä verkon siirto-ongelmista ja aika paskoja ohjeita on useimmissa, täyttä hakuammuntaa kuten itselläkin ollut. Sen verran edistystä Intelin wifi-ajureiden kanssa on ollut, että aikaisemmin mulla myös pätki AC-tason yhteydet jatkuvasti mutta nykyään ne sentään pysyvät ongelmitta ylhäällä. Tohon tosin vaikuttaa kernelin versio, firmware-versiot, wpa-supplicantin versio jne. Ihan toivoton soppa siis.
 
Intelin wifi on sitten oma juttunsa, ja luulen että ajurit ovat yksinkertaisesti paskemmat kuin windowsilla.

Tähän tulokseen olen tullut minäkin. Siihen lienee syynsä minkä takia ei ole mitenkään harvinaista että astetta kovemmat Thinkpad-harrastajat näkevät BIOSin whitelistojen poistamisen vaivan saadakseen Intelin wifit korvattua vastaavalla Atheroksella.
 
/etc/modprobe.d/iwlwifi.conf

options iwlwifi bt_coex_active=0 swcrypto=1 11n_disable=8

Tolla joskus sain Manjaron norminopeuteen. Ei kylläkään ollut Intelin wlan-kortti.
 
Intel wifistä sen verran vielä että koneen ja tukiaseman optioita räpläämällä sain bitraten nousemaan pysyvästi n.300-400 Mb/s:tä 500-800 Mb/s:ään.

iwlwifi.confin optioista
swcrypto: ei vaikutusta tai huonompi siirtonopeus
11n_disable: optio 1 näytti toimivan ensin, sitten ei, sitten optio 8 näytti auttavan. WTF?
bt_coex_active: saattoi auttaa, ja koneesta bluetoothin poiskytkeminen saattoi auttaa

Tukiasemasta 802.11n:n poiskytkeminen saattoi auttaa. Oon vissiin myös jossain vaiheessa vääntänyt sieltä TX poweria ylöspäin joka varmaan on auttanut.
 
Jahas, taas ollaan tutun ongelman ääressä, onko Linuxissa mitenkään mahdollista pakkotappaa prosessia?
Tulin läppärin kanssa reissusta, löin LAN -piuhan kiinni katkaisematta ensin WLANia, pistin verkkolevyllä olevat videot enkoodaukseen ja myöhemmin huomasin, että Dolphin oli vetänyt itsensä jojoon. Ei vastaa mihinkään, ajoittain kysyy odotetaanko vai tapetaanko prosessi ja vaikka tappaisi sen, ei se kuole. Ei auta edes rootilla suoritettu SIGKILL. F12:lla aukeavaan terminaaliin syötin df -h katsoakseni verkkolevyn tilanteen ja nyt sekin terminaali on löysässä hirressä eikä suostu kuolemaan. Muuten kyllä verkkolevy toimii kuten pitää, toisella tiedostoselaimella ei ole mitään ongelmaa ja em. videoenkoodauskin toimii, mutta se on myös syy, miksi ei huvittaisi lähteä reboottaamaankaan ihan hetkeen.

Vahva veikkaus että nuo prosessit ovat jääneet odottamaan IO:ta joka ei enää vastaa johtuen tuosta WLAN -> LAN vaihdoksesta, eli ovat uninterruptible sleep (D) tilassa. Näitä prosesseja ei tietääkseni pysty tappamaan muuten kuin boottaamalla. Ellei syscall sitten palaa kernelistä.

Esim Magic SysRq + w yhdistelmällä kernel tulostaa logiin listan D tilassa olevista prosessista. Tai (roottina):
Koodi:
# echo w > /proc/sysrq-trigger
olettaen toki että tuo SysRq on päällä kernelissä.

Tai esim.
Koodi:
# ps -eo stat,wchan:20,comm:20|grep ^D
listaa kaikkien prosessien tilan, wait channelin ja komennon nimen, grepaten ainoastaan D tilassa olevat. Tuo wait channel on sitten jumittunut syscall.

Ehkä vaihtamalla vähäksi aikaa takaisin LAN -> WLAN nuo syscallit päättyvät. Tai sitten ei ja kone on vielä pahemmassa solmussa :dead:
 
löin LAN -piuhan kiinni katkaisematta ensin WLANia, pistin verkkolevyllä olevat videot enkoodaukseen ja myöhemmin huomasin, että Dolphin oli vetänyt itsensä jojoon.
Onko tämä ihan yleistä linuxin kanssa? Että pitäisi laittaa WLAN kiinni ennen LAN piuhan kytkemistä?
 
Vahva veikkaus että nuo prosessit ovat jääneet odottamaan IO:ta joka ei enää vastaa johtuen tuosta WLAN -> LAN vaihdoksesta, eli ovat uninterruptible sleep (D) tilassa. Näitä prosesseja ei tietääkseni pysty tappamaan muuten kuin boottaamalla. Ellei syscall sitten palaa kernelistä.

Esim Magic SysRq + w yhdistelmällä kernel tulostaa logiin listan D tilassa olevista prosessista. Tai (roottina):
Koodi:
# echo w > /proc/sysrq-trigger
olettaen toki että tuo SysRq on päällä kernelissä.

Tai esim.
Koodi:
# ps -eo stat,wchan:20,comm:20|grep ^D
listaa kaikkien prosessien tilan, wait channelin ja komennon nimen, grepaten ainoastaan D tilassa olevat. Tuo wait channel on sitten jumittunut syscall.

Ehkä vaihtamalla vähäksi aikaa takaisin LAN -> WLAN nuo syscallit päättyvät. Tai sitten ei ja kone on vielä pahemmassa solmussa :dead:
Juu, D -tilassa näyttäisi olevan. LAN -> WLAN vaihto, tai ihan umount saattaisi korjata ongelman, mutta molemmat mitä todennäköisimmin katkaisee samalla tuon enkoodauksen. Ei oikein lämmitä Linuxin tehokkuus prosessien tapossa tällaisessa tilanteessa. Ilmeisesti ei siis voi kuin odottaa videon valmistumista ja rebootata. Tuossa lueskelin, että mounttioptioihin lisätty "soft" voisi korjata tulevaisuudessa nämä ongelmat, pitää kokeilla.

Onko tämä ihan yleistä linuxin kanssa? Että pitäisi laittaa WLAN kiinni ennen LAN piuhan kytkemistä?
En tiedä kuinka yleistä tai oikeaoppista tuo on, päivittäin tulee kuitenkin käytettyä läppäriä piuhan päässä ja ehkä kerran kuukaudessa joku ohjelma lopettaa yhteistyön sen seurauksena. Tottunut kytkemään WLANin etukäteen pois päältä sen estääkseni, kun se on muutenkin sammutettava, että taustalla pyörivät ohjelmat vaihtavat yhteyden langalliseen. Yhtälailla Windowsissa joutuu kytkemään WLANin pois piuhaan siirryttäessä.
 
se on muutenkin sammutettava, että taustalla pyörivät ohjelmat vaihtavat yhteyden langalliseen. Yhtälailla Windowsissa joutuu kytkemään WLANin pois piuhaan siirryttäessä.
Aijaa, uutta tietoa oli tämä windowsista että pitäisi laittaa pois päältä. Nopeasti googlaamalla windows ohje priorisoinnista. Eikö noita sitten pysty priorisoimaan linuxissakin? Että jos kaksi eri tapaa on päällä, niin joku niistä on ykkösvaihtoehto?
 
Aijaa, uutta tietoa oli tämä windowsista että pitäisi laittaa pois päältä. Nopeasti googlaamalla windows ohje priorisoinnista. Eikö noita sitten pysty priorisoimaan linuxissakin? Että jos kaksi eri tapaa on päällä, niin joku niistä on ykkösvaihtoehto?
Kyllä sekä Windows että Linux priorisoi verkon automaattisesti LANiin (ainakin omalla kohdalla, muilla voi priorisoida muualle), mutta jo muodostetut yhteydet ei siirry verkosta toiseen saumattomasti itsekseen.
 
Aha, nykyiset systeemit eivät sitten ole kauhean sofistikoituneita. En kyllä vieläkään ymmärrä miksi sulla dolphin meni jumiin. Tulit himaan, wlan päällä, dolphin otti yhteyden sen kautta verkkojakoon, sitten löit lanipiuhan kiinni ja sen jälkeen dolphin hirtti kiinni? En kyllä ymmärrä miksi järjestelmä ei osaa/osaisi tuollaista tilannetta handlata oikein. Kuulostaa suunnitteluvirheeltä.
 
Itse vaihtelen duunissa linux-läppäriä eri wlanien välillä ja välillä eri kiinteiden lanienkin välillä aikalailla randomisti eikä nyt ainakaan tämän vuoden puolelta tule mieleen yhtään ongelmaa. Ainoa ongelma on että joskus OpenVPN ei osaa automaattisesti yhdistää uudestaan kun vaihtaa langattoman ja langallisen välillä, kahden langallisen välillä tai kahden langattoman välillä se osaa tuonkin. Tosin, tuossa koneessa ei taida olla Intelin verkkorautaa, joten olisikohan Intel-spesifinen ongelma?
 
Tähän tulokseen olen tullut minäkin. Siihen lienee syynsä minkä takia ei ole mitenkään harvinaista että astetta kovemmat Thinkpad-harrastajat näkevät BIOSin whitelistojen poistamisen vaivan saadakseen Intelin wifit korvattua vastaavalla Atheroksella.
Luulen kyllä, että olet nyt sekoittanut merkit keskenään, sillä Atheros on sitä roskislaatuista paskaa ja Intel on ainoa merkki, joka oikeasti toimii.

Nimimerkillä Intel-piirisen läppärin Atherosiin äskettäin vaihtanut....

Erityisen vittumaisia / pelottavia ovat ne hetket, kun Atherosin firmis alkaa ylikuumentaa piiriä ja läppärin tuuletin huutaa täysillä vaikka htop näyttää prossun kuormitusasteen olevan < 10 %. Aluksi luulin, että läppärini oli menossa rikki, kun verkko hyytyi ja tuulettimet ujelsivat, mutta vika olikin siinä, että heikon kuuluvuuden takia wifi-piiri menee sekaisin. Uusimmalla firmiksellä ja kernelillä wifi-piiri kaatuilee itsestään noin puolen tunnin välein ja silloin kun se ei osaa palautua siitä, niin kone tilttaa reboottia tehdessä ja pahimmillaan joutuu boottailemaan useita kertoja saadakseen yhteyden takaisin. (Päivitin manuaalisesti vanhempaan firmikseen.)

Kahden ja viiden gigahertsin verkkojen välillä vaihtaminen ei onnistu, koska piiri kaatuu taas ja Linuxin NetworkManager yrittää sen palautuessa yhdistää taas siihen ensimmäiseen verkkoon, jonka yhteyden se tuntee. (Eli ainoa tapa vaihtaa eri taajuutta käyttävään verkkoon on poistaa toinen verkko kokonaan NetworkManagerista.)

Aha, nykyiset systeemit eivät sitten ole kauhean sofistikoituneita. En kyllä vieläkään ymmärrä miksi sulla dolphin meni jumiin. Tulit himaan, wlan päällä, dolphin otti yhteyden sen kautta verkkojakoon, sitten löit lanipiuhan kiinni ja sen jälkeen dolphin hirtti kiinni? En kyllä ymmärrä miksi järjestelmä ei osaa/osaisi tuollaista tilannetta handlata oikein. Kuulostaa suunnitteluvirheeltä.
Verkkoyhteyksien virheiden käsittely on Linuxin yksi suurimmista ongelmista vuonna 2019. Monta muuta asiaa on saatu korjattua mutta jumittavat verkkojaot ja joskus jopa jumittava nettiyhteys laittaa koneen polvilleen.

Esimerkiksi Firefox kaatuu edelleen taustalle, jos netti pykii ja selaimen sulkee. Luulen, että taustalla pyörivä Firefox Sync -workeri ei suostu kuolemaan ja siksi koko selain jää zombiksi.

VirtualBoxin nettiyhteydet menevät sekaisin wlan-yhteyttä vaihtaessa ja koneen suspendatessa, jolloin taas kerran prosessit jäävät taustalle jumiin vaikka virtuaalikoneen sulkisi onnistuneesti. Konetta bootatessa jumittava nfs-mountti estää koneen sulkemisen, koska Systemd jumittaa pollaamassa mountpointtia.
 
Viimeksi muokattu:
Itse vaihtelen duunissa linux-läppäriä eri wlanien välillä ja välillä eri kiinteiden lanienkin välillä aikalailla randomisti eikä nyt ainakaan tämän vuoden puolelta tule mieleen yhtään ongelmaa. Ainoa ongelma on että joskus OpenVPN ei osaa automaattisesti yhdistää uudestaan kun vaihtaa langattoman ja langallisen välillä, kahden langallisen välillä tai kahden langattoman välillä se osaa tuonkin. Tosin, tuossa koneessa ei taida olla Intelin verkkorautaa, joten olisikohan Intel-spesifinen ongelma?

Vähän epäilen että tuo on enemmän verkkotiedostojärjestelmiin liittyvä ongelma. Tai ainakin CIFS/SMB:hen.

Omassa läppärissä on verkkolevy mountattuna CIFS:nä ja se aiheuttaa jumituksia jos sattuu fifi yskähtämään väärällä hetkellä. Tyyliin terminaalissa verkkolevyhakemistossa juuri ajamassa komentoa joka yrittää käynnistyessään päästä käsiksi johonkin tiedostoon tai lukea nykyisen hakemiston sisällön ja fifi on juuri korkannut. Tuloksena koko terminaali on jökissä, usein toipuu kunhan yhteys tokenee.

Yhteen väliin jossakin 4.x sarjan kernelissä oleva huippulaadukas Intelin wifi-ajuri kaatui vähintään pari kertaa viikossa. Jos tällöin oli verkkolevyn kautta tiedostoja auki niin tuloksena oli noita D tilaisia prosesseja jotka jäi pysyviksi koska verkkoa ei saanut enää hereille.

Luulen kyllä, että olet nyt sekoittanut merkit keskenään, sillä Atheros on sitä roskislaatuista paskaa ja Intel on ainoa merkki, joka oikeasti toimii.

Nimimerkillä Intel-piirisen läppärin Atherosiin äskettäin vaihtanut....

Olen kyllä pitänyt minäkin Qualcommia C-tier pajana jolla määrä korvaa laadun mutta en usko että olen sekoittanut niitä. Tiedän esim. AR9380:n olevan suosittu 3x3 Thinkpadeissa.

Siis vaihdoit läppäreitä? Muuten samanlainen mutta eri wifi?

Konetta bootatessa jumittava nfs-mountti estää koneen sulkemisen, koska Systemd jumittaa pollaamassa mountpointtia.

Oman läppärin cifs-mountti tekee tätä myös. Eikä minkään timeoutin asettaminen tunnu vaikuttavan tässä, systemd odottelee jumineen cifsin unmountin onnistumista joskus minuuttitolkulla. Muutakaan toimivaa ratkaisua löytämättä kiersin aikoinaan ongelman poistamalla automaagisen verkkolevyn mounttauksen, teen sen käsin ainoastaan tarvittaessa ja unmounttaan samantien. Ja suosin scp:tä aina kun mahdollista.
 
Miten voi palauttaa nmtuin eli NetworkManagerin Raspbianissa, jos se katoaa kuin pieru saharaan? Onko jotain näppärää backup-juttua tälläiseen?
Meinaan vaikea saada wifiä takaisin päälle, jos ei pääse edes noihin asetuksiin.
Muutamia kertoja käynyt näin ja muuten Raspbian vaikuttanut olleen ihan ok kunnossa.

Myöskin raspi-config kohdassa wifi jutut katoavat näissä tapauksissa.
 
Luulen kyllä, että olet nyt sekoittanut merkit keskenään, sillä Atheros on sitä roskislaatuista paskaa ja Intel on ainoa merkki, joka oikeasti toimii.

Nimimerkillä Intel-piirisen läppärin Atherosiin äskettäin vaihtanut....

Omaankin Linux läppäriin vaihdoin aikoinaan Atheroksen tilalle Intelin AC7260, tosin syynä ainoastaan nopeammat yhteydet. Viime viikkoon asti toimi ilman mitään ongelmia, mutta Kubuntun päivitys 18.10->19.04 versioon rikkoi jotain. Noin 5-15 min WLANin käytön jälkeen verkko katkes ja verkkoyhteyksissä ei näkynyt yhtään verkkoa. Dmesg näytti kasan virheitä mm:
Koodi:
iwlwifi 0000:02:00.0: Queue 5 is active on fifo 2 and stuck for 10000 ms. SW [15, 16] HW [90, 90] FH TRB=0x05a5a5a5a
iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd
iwlwifi 0000:02:00.0: Error sending SCAN_OFFLOAD_REQUEST_CMD: enqueue_hcmd failed: -5
iwlwifi 0000:02:00.0: Scan failed! ret -5
iwlwifi 0000:02:00.0: Failed to wake NIC for hcmd

Netti näytti olevan turvoksissa vastaavia ongelmia ja korjauksia löytyi vaikka kuinka. No itselle asiaan näytti auttavan kun lisäsin /etc/modprobe.d/iwlwifi.conf tiedostoon:
Koodi:
options iwlwifi bt_coex_active=0
Nähtävästi ajuri/kernel sekoilee jotain jos WLAN-BT häiriöiden väistely on päällä ja lopulta koko ajuri kaatuu. Nyt on pelannut muutaman päivän ilman ongelmaa.
 
Tänään huomasin, että päivitettyäni Xubuntun 19.04 versioon bluetooth ei pelaa ollenkaan. Harvoin käytän tuota, lähinnä bt-kuulokkeiden kanssa satunnaisesti niin en heti huomannut, mutta nyt ostin uuden donglettoman bt-hiiren, jota olisin mielelläni alkanut tuossa käyttää. Blueman ei vaan hae bt-laitteita. Netistä löysin jonkun vastaavan ongelmakuvauksen, johon ei vastauksia sadellut joten se veti asennuksen uusiksi ja sitten pelasi taas. No nyt en jaksa alkaa uudelleen asennukseen joten otin sen käyttöön toisessa läppärissä (Xubuntu 18.04).

Muokkaus: Ai niin, tuo läppäri, missä ei toimi, on Lenovo e320 Edge. Sandy Bridge aikakautta.
 
Mulla taas tuli Kubuntun päivityksessä 18.10:stä 19.04:n lievä äänihäiriö. Aina kun ääni alkaa ja loppuu, kuuluu lyhyt rasahdus.

Sain sen nyt pois ArchWikin ohjeella.

Tiedostoon ~/.config/pulse/default.pa seuraavat rivit.
Koodi:
.include /etc/pulse/default.pa
unload-module module-suspend-on-idle
Pulseaudiolle restarttia: pulseaudio -k
 
Joku viisaampi jos voisi ratkaista seuraavan ongelman.

Eli Orange Pi:n wlan lakkasi toimimasta "ubuntun" 16.04-->18.04 päivityksen yhteydessä. Kikkakolmosella lähtee käyntiin, mutta ei tämä oikein ole pysyväisratkaisu (iface wlan0 inet dhcp "/etc/network/interfacesista" #pois buutin ajaksi ja buutin jälkeen takaisin ja komento: sudo ifup wlan0 ja taas rokkaa seuraavaan buuttiin saakka).

Olisi kiva, ettei joka kerta tarvitsisi tehdä edellistä, vaan että netti toimisi automaattisesti heti käynnistyksen jälkeen. Jos jätän tuon iface wlan0 inet dhcp:n kommentoimatta, niin buuttaus kestää ~15min, minkä jälkeen mitkään taikomiset ei saa nettiä toimimaan. Kohtalaisen ärsyttävää. Pitääkö tässä joku skriptitaika keksiä, kun ei muuten osaa?
 
Viimeksi muokattu:
Joku viisaampi jos voisi ratkaista seuraavan ongelman.

Eli Orange Pi:n wlan lakkasi toimimasta "ubuntun" 16.04-->18.04 päivityksen yhteydessä. Kikkakolmosella lähtee käyntiin, mutta ei tämä oikein ole pysyväisratkaisu (iface wlan0 inet dhcp "/etc/network/interfacesista" #pois buutin ajaksi ja buutin jälkeen takaisin ja komento: sudo ifup wlan0 ja taas rokkaa seuraavaan buuttiin saakka).

Olisi kiva, ettei joka kerta tarvitsisi tehdä edellistä, vaan että netti toimisi automaattisesti heti käynnistyksen jälkeen. Jos jätän tuon iface wlan0 inet dhcp:n kommentoimatta, niin buuttaus kestää ~15min, minkä jälkeen mitkään taikomiset ei saa nettiä toimimaan. Kohtalaisen ärsyttävää. Pitääkö tässä joku skriptitaika keksiä, kun ei muuten osaa?

Mikä Orange Pi se oikein on? Jos se on se Zero malli niin siinähän on onneton wlan ja putoilee pois vähän väliä.
 
Mikä Orange Pi se oikein on? Jos se on se Zero malli niin siinähän on onneton wlan ja putoilee pois vähän väliä.
OP Zerohan tuo. Hyvin tuo tuntuu verkossa pysyvän, mutta yhdistämisen kanssa oli uudemman Ubuntun kanssa ongelmia. Asensin sitten tuon vanhemman 16.04 lts:n tai mikä lie, kun sen kanssa yhdistyy ongelmitta. Ajaa asiansa Spotify-serverinä oikein hyvin. Piti alun perin tulla langallisen laserin kaveriksi (-->langaton), mutta halpa TP-linkin wifi-toistin sopi siihen hommaan paremmin kuin hyvin. Voi kyllä sanoa, että iloa koko rahalla (13e). :)
 
OP Zerohan tuo. Hyvin tuo tuntuu verkossa pysyvän, mutta yhdistämisen kanssa oli uudemman Ubuntun kanssa ongelmia. Asensin sitten tuon vanhemman 16.04 lts:n tai mikä lie, kun sen kanssa yhdistyy ongelmitta. Ajaa asiansa Spotify-serverinä oikein hyvin. Piti alun perin tulla langallisen laserin kaveriksi (-->langaton), mutta halpa TP-linkin wifi-toistin sopi siihen hommaan paremmin kuin hyvin. Voi kyllä sanoa, että iloa koko rahalla (13e). :)

Itsellä löytyy myös tuo Zero ja kyllähän se kituen pysyy verkossa kiinni potkien välillä terminaali tilasta pois, että saa taas uusiksi kirjautua. Laitoin sitten erillisen Asuksen Nano wifi usb-donglen tuohon niin pysyy vakaasti terminaalissa niin kuin normaalisti pitääkin pysyä.

OP Litessa wifi toimi aina hyvin ja OP PC+:ssa oli ollut tuollaista samankaltaista vikaa, että hukkasi wifinsä buutin jälkeen, mutta siihen tuli sitten sellainen päivitys, että wifi pysyy pystyssä buutinkin jälkeen.
 
Pitäisi purkaa.img tiedosto Linuxilla, jossa on sisäkkäisiä .img -tiedostoja, muokata tiettyjä tiedostoja ja pakata paketti muilta osiltaan samanlaiseksi .img -tiedostoksi (boottaava). .iso varmaan käy myös tiedostomuotona. Ohjeiden mukaan pitäisi olla ihan peruskauraa, mutta en osaa. Jossain vaiheessa puuttuu tiedostoja tai uusi pakkaus ei onnistu. Onko tähän hommaan jotain hyvää graafista aputyökalua Linuxille?
 
.img ei ole niin yksikäsitteinen tiedostopääte kuin vaikka .zip tai .iso, mutta usein se tarkoittaa joko partitiosta tai kokonaisesta levystä tehtyä image-tiedostoa. Mitä ohjeita yrität seurata?

Jos kysymyksessä on kokonaisesta kiintolevystä (tai USB-tikusta, tai vastaavasta) tehty image-tiedosto, silloin sitä voi yleensä käsitellä suoraan varsinaisesti purkamatta sitä. Tällaiseen vapaamuotoiseen image-tiedostojen käyttöön tarvitaan roottivoimaa, eli seuraavat komennot annetaan joko roottina tai sitten niiden eteen pitää laittaa sudo-komento.

Kokolevyn image kannattaa ensin kytkeä ns. looppilaitteeksi:
Koodi:
# losetup -P /dev/loop0 /jossain/tiedosto.img

Tämän jälkeen image-tiedoston osiotaulua voi vilkaista esim. komennolla
Koodi:
# fdisk -l /dev/loop0

Image-tiedoston osiotaulun määrittelemiä "levyosioita" pääsee looppilaitteeksi kytkennän jälkeen käyttämään suoraan siten, että ensimmäinen osio on /dev/loop0p1 ja niin edespäin. Levyosion voi esimerkiksi mountata:
Koodi:
# mkdir /mnt/osio1
# mount /dev/loop0p1 /mnt/osio1

Tämän jälkeen image-tiedoston ensimmäisen osion sisältö on käsiteltävissä /mnt/osio1-hakemistohaaran alla.
Osion tiedostojärjestelmätyypistä sitten riippuu voiko sisältöä muokata suoraan, vai onko vain lukuoperaatiot sallittu (iso9660, squashfs).

Jos sieltä löytyy toinen .img-tiedosto, sen voi vastaavasti kytkeä /dev/loop1:een ja näin kaivautua niin syvälle kuin tarvitaan. Kun tarvittavat muutokset on tehty, mountit ja looppilaite-kytkennät pitää muistaa purkaa vastakkaisessa järjestyksessä kuin ne on tehty:
Koodi:
# umount /mnt/osio1
# rmdir /mnt/osio1 #ei pakollinen, mutta siistimpää näin
# losetup -d /dev/loop0

Jos kysymyksessä on yksittäisestä levyosiosta/tiedostojärjestelmästä tehty image-tiedosto, silloin sen saa käsiteltäväksi helpommin:
Koodi:
# mkdir /mnt/image-tiedosto
# mount -o loop /jossain/tiedosto.img /mnt/image-tiedosto

### ja purkuun riittää vastaavasti...

# umount /mnt/image-tiedosto
# rmdir /mnt/image-tiedosto

Jaa miksi annoin komentorivikomentoja? No, niiden voi olettaa toimivan samalla tavalla suunnilleen kaikissa suht tuoreissa Linux-jakeluissa. GUI-työkalujen kanssa pitäisi tietää mitä jakelua käytät (esim. Ubuntu, Fedora, Arch tms.), tai vähintään mitä työpöytäympäristöä käytät (Gnome, KDE, muu, mikä?).

Boottaavuus voi olla sitten vähän kimurantimpi juttu, etenkin perinteisen BIOS/MBR-tyylin levyissä ja niistä tehdyissä image-tiedostoissa. Niiden kanssa on nimittäin sellainen juttu, että boottitiedot ovat varsinaisten levyosioiden ulkopuolella, eikä niitä voi käsitellä tiedostoina. Tämä tekee boottaavuudesta "näkymättömän" ominaisuuden, jos ei tiedä miten asia pitää tarkistaa (tästä voisi kirjoittaa oman pitkän postauksen tai pari). Tästä seuraa myös se, että pelkästään kopioimalla tiedostot yhdestä levyimagesta toiseen boottaavuus ei tule mukana, vaan se pitää tehdä uuteen imageen erikseen.

UEFI-boottityyli helpottaa tässä aika lailla: sen kanssa on yksiselitteisesti niin, että jos siirrettävällä levyllä tai levyimagella on FAT32-tyyppinen osio josta löytyy tiedosto \EFI\BOOT\BOOTX64.EFI, ko. siirrettävä levy tai levyimage on UEFI:n kannalta boottikelpoinen, ja muuta ei tarvita.

.iso-tiedostoilla on sitten aivan omat kuvionsa boottikelpoisuuden suhteen, ja jos .iso-tiedosto halutaan sellaiseksi että sen voi kirjoittaa USB-tikulle ja bootata sieltäkin, matkaan tulee vielä yksi mutka lisää (ns. isohybrid-tekniikka).
 
Kiitos, tiedän mihin suuntaan keskittyä ja unohtaa tuo haave .iso -muodosta. Boottikelpoisuus siis pitää säilyttää ennallaan.
 
Iltaa. Pöytäkoneessa on Solus 4 SSD:llä jota olen nyt tweekannut mieleisekseni, olisi kiva jatkaa läppärillä hommia jossa m.2 levy. Ovat samankokoisia. Home-kansiot eivät tietenkään ole eri osoilla. Saisko kovot jotenkin kätevästi synkattua toisiinsa, onko siinä ylipäätään mitään järkeä? Vai jos samanlaista aattelee niin sitten mennä jollain .dot -file asennusskipti -tyylillä jolla saa omat asetukset, juutubissa tuntuvat jotkut sellaista käyttävän?

Edit: No jos vaan rupeisi käyttämään sitä Läppäriä. Eli näyttö kiinni kotona ja muuten muualla.
 
Viimeksi muokattu:
Onko linuxilla mahdollista alivoltittaa Nvidian näytönohjaimia?
Distroa ei ole vielä lyöty lukkoon, mutta tulee todennäköisesti olemaan akselilla mint, manjaro tai arch.

Suunnittelen komponenttivalintoja uuteen ITX buildiin ilmajäähdytettynä tai 240+92 radeilla. (Ncase M1)
Kotelon koon takia täytyisi pyrkiä minimoimaan lämpökuorma, mutta tavoitteena olisi kuitenkin "maksimaalinen suorituskyky". Kortiksi olen alustavasti ajatellut 2080 tai 2080 ti mallia.

Prosessorin voi varmaankin alivoltittaa biosin kautta?
Prosessoriksi kaavaillut 9900k tai jokin tulevista ryzen malleista. (mikä ylipäätään mielipide intel vs amd linuxilla?)
 
Onko linuxilla mahdollista alivoltittaa Nvidian näytönohjaimia?
Distroa ei ole vielä lyöty lukkoon, mutta tulee todennäköisesti olemaan akselilla mint, manjaro tai arch.

Suunnittelen komponenttivalintoja uuteen ITX buildiin ilmajäähdytettynä tai 240+92 radeilla. (Ncase M1)
Kotelon koon takia täytyisi pyrkiä minimoimaan lämpökuorma, mutta tavoitteena olisi kuitenkin "maksimaalinen suorituskyky". Kortiksi olen alustavasti ajatellut 2080 tai 2080 ti mallia.

Prosessorin voi varmaankin alivoltittaa biosin kautta?
Prosessoriksi kaavaillut 9900k tai jokin tulevista ryzen malleista. (mikä ylipäätään mielipide intel vs amd linuxilla?)
Intel ja AMD toiminut ihan yhtä hyvin. Intelin integroidut näytönohjaimet toimivat parhaiten, tai siis paremmin(varmemmin) kuin AMD, mutta AMD näyttisajurit on toimivat kanssa. Välillä ollut jotain ongelmaa, kuten nyt kun päivitin fedora 28:n ensin 29:iin ja siitä fedora 30:eem. 29:ssä AMD radeon hd6850 kuvassa oli häiröitä. 28:ssa ei, ja 30 versiossa häiriöt oli korjattu.

Itse näen 9900K järkevänä vain jos pelaa framerateja vaativia pelejä ja käyttää windowsia. Windows käyttiksellä pelien framerated on jo heti paremmat linuxiin verrattuna. Siis jos haluaa sen parhaan PC pelikoneen, niin sitten se on windows + 9900k yhdistelmä tällä hetkellä. Muutoin sitten linuxia varten miettii sitten sitä omaa käyttöä ja tarvittavien corejen määrää ja hinta/suorituskyky suhdetta. Joka tapauksessa odottaisin tuon uuden Ryzen prossan julkaisua. Voi käydä niin että kuukauden päästä tuo 9900K lähtis satkun halvemmalla.
 
Saako Linux Mintissä (19.1) jotenkin säädettyä puhallinta, ettei se huuda 100% koko aika? Windowsille löytyy kannettavan valmistajan sotfa, joka tiputtaa välillä puhaltimen päältä eli ns hiljaisena käy.
 
Saako Linux Mintissä (19.1) jotenkin säädettyä puhallinta, ettei se huuda 100% koko aika? Windowsille löytyy kannettavan valmistajan sotfa, joka tiputtaa välillä puhaltimen päältä eli ns hiljaisena käy.

Mites tuota suoraan läppärin biossista säädöt? Kannattaisi ehkä myös harkita paineilmapullon hommaamista niin sillä saa villakoiria pois läppärin sisuksista niin jäähtyisi paremmin.
 
Viimeksi muokattu:
Saako Linux Mintissä (19.1) jotenkin säädettyä puhallinta, ettei se huuda 100% koko aika? Windowsille löytyy kannettavan valmistajan sotfa, joka tiputtaa välillä puhaltimen päältä eli ns hiljaisena käy.

Riippuu läppäristä. Useimmilla Thinkpadeilla ja joillakin Asuksen malleilla onnistuu ainakin, kernelistä löytyy ajuri näille.
 
Saako Linux Mintissä (19.1) jotenkin säädettyä puhallinta, ettei se huuda 100% koko aika? Windowsille löytyy kannettavan valmistajan sotfa, joka tiputtaa välillä puhaltimen päältä eli ns hiljaisena käy.
Eiköhän tuo kuule toimi ihan biosin ohjastamana ja koneesi vain käy liian kuumana. Luultavasti sinun pitäisi tutkia, kuinka korjaat näytönohjaimesi virransäästötilaan. Tämä oli ihan villi veikkaus, mutta jos koneessasi on Nvidian kortti, niin luultavasti oikein.
 
Gentoossa mulla piti ottaa käyttöön lm_sensors-paketin fancontol-skripti, kun asensin koneeseen kotelotuulettimen. Se huusi täysillä jatkuvasti muuten. Fancontrol otettiin käyttöön komentamalla

sudo systemctl enable fancontrol

joka siis lisää sen koneen mukana käynnistettäviin palveluihin.
 
Mites tuota suoraan läppärin biossista säädöt? Kannattaisi ehkä myös harkita paineilmapullon hommaamista niin sillä saa villakoiria pois läppärin sisuksista niin jäähtyisi paremmin.

No eipä sieltä löydy kun ainoastaan Intel SpeedStep valinta ja eikä muita valintoja tai säätöjä puhaltimelle. Mitä tuossa puhalsin pölyjä, niin eipä sieltä oikein tahtunut tulla paineilmapullolla mitään pois eli en tiiä, pitäskö avata.

Kyllä tuossa käy puhallin, mutta pienemmällä äänentasolla nyt. CPU:n lämmöt 50 asteessa.

Vaihdettu kerran emo kannettavaan, en tiiä pudistivatko siitä kohden sitten fyysisesti siilin.

Eiköhän tuo kuule toimi ihan biosin ohjastamana ja koneesi vain käy liian kuumana. Luultavasti sinun pitäisi tutkia, kuinka korjaat näytönohjaimesi virransäästötilaan. Tämä oli ihan villi veikkaus, mutta jos koneessasi on Nvidian kortti, niin luultavasti oikein.

No jos mulla on läppärissä Intel HD 4000 + AMD Radeon HD 7670m.
 
Gentoossa mulla piti ottaa käyttöön lm_sensors-paketin fancontol-skripti, kun asensin koneeseen kotelotuulettimen. Se huusi täysillä jatkuvasti muuten. Fancontrol otettiin käyttöön komentamalla

sudo systemctl enable fancontrol

joka siis lisää sen koneen mukana käynnistettäviin palveluihin.
Tuossa on mukana myös näppärä pwmconfig skripti, jolla pääsee käsiksi PWM-säätöihin. Mitään tarkkoja käyriä ei voi tehdä, mutta minimin ja maksimin ainakin voi määrittää.
 
Onko linuxilla mahdollista alivoltittaa Nvidian näytönohjaimia?
Distroa ei ole vielä lyöty lukkoon, mutta tulee todennäköisesti olemaan akselilla mint, manjaro tai arch.

Suunnittelen komponenttivalintoja uuteen ITX buildiin ilmajäähdytettynä tai 240+92 radeilla. (Ncase M1)
Kotelon koon takia täytyisi pyrkiä minimoimaan lämpökuorma, mutta tavoitteena olisi kuitenkin "maksimaalinen suorituskyky". Kortiksi olen alustavasti ajatellut 2080 tai 2080 ti mallia.

Prosessorin voi varmaankin alivoltittaa biosin kautta?
Prosessoriksi kaavaillut 9900k tai jokin tulevista ryzen malleista. (mikä ylipäätään mielipide intel vs amd linuxilla?)


On mahdollista alivoltittaa, googlettamalla kryptomainaukseen liittyviä guideja ainakin löytyy ohjeita noihin. Itse testasin pari vuotta sitten 1060:llä ja hyvin toimi.
 
Onko kukaan huomannu, että OpenSuse Tubleweedin iso-tiedostojen mounttaus ois muuttunu jotenki?

Itsellä on virtuaalinen labraverkko, johon oon pystyttäny OpenSusella-servun jossa on kaikki tarvittava, että virtuaalikoneet voivat asentaa Xubuntun ja W10:n PXEn/verkon kautta. Ja siihen liittyen olen mountannut W10-asennus ISO-tiedoston aikaisemmin komennolla:
Koodi:
sudo mount -o loop /mnt/vbox/Windows_10_x64_1809_October_2018_Update_30.4.2019.iso /srv/tftpboot/windows_10/
Ja homma on toiminut ongelmitta, sekä muistaakseni omistaja ja ryhmä on aina ollu "root" tuolle windows_10 -kansiolle.

Mutta nytten jossain vaiheessa se on muuttunut, niin ettei mountti anna tarpeeksi oikeuksia windows_10-kansioon sekä omistaja ja ryhmä on nykyisin "nobody", joiden vuoksi tulee errori "Access denied" kun yritän aloittaa W10 asennuksen tuolta windows_10 -kansiosta joka on myös jaettu samballa.

Homma korjaantuu kun antaa lisää vipuja mountille:
Koodi:
sudo mount -o loop,mode=755 /mnt/vbox/Windows_10_x64_1809_October_2018_Update_30.4.2019.iso /srv/tftpboot/windows_10/

Oli taas iloinen asia etsiä vikaa kun lähdin väärästä päästä purkamaan ongelmaa, niin ajattelin että samba ois saanu päivityksen, minkä vuoksi ne oikeudet kusee. Ja kaikkea muuta kuin tuota...
 

Statistiikka

Viestiketjuista
259 231
Viestejä
4 505 679
Jäsenet
74 340
Uusin jäsen
spacevector

Hinta.fi

Back
Ylös Bottom