Linux-kysymyksiä & yleistä keskustelua Linuxista

Poistetaanko seuraavaksi vaikka netfilter ja seccomp niin saadaan pintaa vielä kapeammaksi? ;)
Kyllä noissakin on vielä varmasti bugeja, mutta hyödyt ajanee useimmiten riskien edelle. Netfilter voi olla tarpeeton mm., jos ulkoverkkoon tarjotaan vain tiettyä palvelua tai filtteröinnit on hoidettu jo ennen palvelinta.

Tuotantopalvelimen ja kotikäyttäjän tarpeet ovat erilaiset, ei siihen Pihtiputaan Mummon™ koneeseen tarvitse kaikkia mahdollisia suojauksia. Kun huolehtii varmuuskopioinnista, käyttöjärjestelmän voi asentaa aina uusiksi, jos kakka osuu tuulettimeen. Kun pitää päivitykset ajan tasalla ja web-selaimen asetukset järkevinä jne., ongelmiin törmääminen on erittäin harvinaista.
 
Millä perusteella? Aika omituinen valinta Canonicalilta, Novellilta ja Red Hatilta oletuksena sisällyttää täysin tarpeeton moduuli Ubuntuun, SUSE:en ja Fedoraan/RHEL:iin.

Ei se varmasti täysin turha ole, mutta tekee asioista monimutkaisempia "tavallisille" Linux-käyttäjille, joiden riski joutua onnistuneen tietoturvahyökkäyksen kohteeksi lienee sangen pieni. Tosin nyt kun mietin, niin sehän taitaa olla omassa Fedora-koneessani päällä eikä ole liikoja huudellut.

Hyökkäykselle alttiissa kohteessa kuten suosittua sivustoa pyörittävässä web-palvelimessa se voi ollakin hyvä valinta.
 
Viimeksi muokattu:
Toimiiko zfsonlinux jo sen verran vakaasti, että uskaltaa importata poolin Linuxiin? Tarkoitus tyhjentää molemmat nykyiset poolit ja siirtyä ext4+snapraid+mergerfs kombinaation FreeBSD:stä. Eli siis paljoa ei tuolta kuitenkaan vaadittaisi, kunhan luku vain toimii. ZFS flageistä ei sen kummempaa käryä oikeastaan. Distro tulee olemaan Debian.
 
Hep, mikähän mahtaisi olla ongelma, kun yritän vanhaan Asus X71SL -läppäriin asennella sekä Linux Mintiä että Ubuntua USB-tikulta. Mintissä tulee alussa "Automatic boot in 10 seconds.." rullaamaan ja kun se menee loppuun (tai painaa esim. enteriä, valitsen valikosta mitä vaan esim. Integrity check), tulee vain musta ruutu johon jää kursori vilkkumaan vasempaan yläkulmaan eikä mitään tapahdu (edes ctrl+alt+del ei toimi). Ubuntussa pääsen valitsemaan kielen ja esim. aloittaessani asennuksen niin täysin sama juttu. Kahdella eri tikulla kokeiltu. Uusimmalla Rufuksella tein noista ISO:ista asennustikun.
 
Hep, mikähän mahtaisi olla ongelma, kun yritän vanhaan Asus X71SL -läppäriin asennella sekä Linux Mintiä että Ubuntua USB-tikulta. Mintissä tulee alussa "Automatic boot in 10 seconds.." rullaamaan ja kun se menee loppuun (tai painaa esim. enteriä, valitsen valikosta mitä vaan esim. Integrity check), tulee vain musta ruutu johon jää kursori vilkkumaan vasempaan yläkulmaan eikä mitään tapahdu (edes ctrl+alt+del ei toimi). Ubuntussa pääsen valitsemaan kielen ja esim. aloittaessani asennuksen niin täysin sama juttu. Kahdella eri tikulla kokeiltu. Uusimmalla Rufuksella tein noista ISO:ista asennustikun.
oletko testannut vaikka ubuntulla sitä live ominaisuutta? eli voit kokeilla käyttöjärjestelmän käyttöä muistitikulta ennen kuin varsinaisesti asennat sitä. tuleeko siinä sama ongelma?


edit netistä bongattua:
kokeile muuttaa bios-asetuksia:
Bios > Security > I/O interface security > option New card interface —> mettre en statut LOCKED au lieu de UNLOCKED

eli vaihda unlocked -> locked

Installing 12.04 on a ASUS X71SL
 
Viimeksi muokattu:
edit netistä bongattua:
kokeile muuttaa bios-asetuksia:
Bios > Security > I/O interface security > option New card interface —> mettre en statut LOCKED au lieu de UNLOCKED

eli vaihda unlocked -> locked

Installing 12.04 on a ASUS X71SL
Jukopliut, tämä toimi! Kiitoksia :kippis: Nyt on Mintti asentumassa niin katsellaan mihin kompastun seuraavana ;) Linux-puolelta PC:istä käyttökokemuksia on reilun parinkymmenen vuoden ajalta yhteensä ehkä kaksi tuntia.
 
Nyt on muutama päivä käytetty windows 10 pro:ta. Toimihan tämä noin 3 vrk normaalisti. Nyt eilen alkoi ihme oireilu.
Tahmaa, välillä työpöytä käynnistyy uudelleen, nuc tuuletin huutaa ja tehtäväpalkki ei vastaa. Internet yhteys katkeilee.
Kuntoraportti ei ole käytössä? Ym outoa.. Windowssin laitoin lähinnä saadakseni plex serverin pyörimään koneessa ja
sekin toimi hyvin pari päivää.. Viruksia ei löytynyt malwarebytesillä scannasin sekä defenderillä.

Depian toimi todella hyvin tässä koneessa. Samoin fedora. Onko kokemuksia noista toimisko noissa plex serveri ok?
 
Nyt on muutama päivä käytetty windows 10 pro:ta. Toimihan tämä noin 3 vrk normaalisti. Nyt eilen alkoi ihme oireilu.
Tahmaa, välillä työpöytä käynnistyy uudelleen, nuc tuuletin huutaa ja tehtäväpalkki ei vastaa. Internet yhteys katkeilee.
Kuntoraportti ei ole käytössä? Ym outoa.. Windowssin laitoin lähinnä saadakseni plex serverin pyörimään koneessa ja
sekin toimi hyvin pari päivää.. Viruksia ei löytynyt malwarebytesillä scannasin sekä defenderillä.

Depian toimi todella hyvin tässä koneessa. Samoin fedora. Onko kokemuksia noista toimisko noissa plex serveri ok?

Tästä kyse?
Plex (software) - Wikipedia

Toimii kyllä Linuxillakin.
 
Joo. Palattiin fedoraan takaisin. Joskus vuosia sitten kokemukset silloisesta pöytäkoneesta ja fedorasta olivat huonoja. Nyt tässä intel nuc toimii loistavasti.
Wifi ja bt löytyy suoraan jo live usb ajellessa. Xfce työpöydän sai mieleisekseen..

Plex;iä en tähän laita. Mulla on tuo chromebox ollut tv:ssä kiinni. Videoiden toistossa siinä on ongelmaa, jotkut nykivät ym. Teho kyllä pitäisi riittää kun on vanhempi i3 versio. Yritin tuota asennella;


3.1 OS- ja koodausasennus
Kodi voidaan asentaa ChromeBoxiin useilla eri tavoilla. Kaksi yleisintä on LibreELEC: n tai GalliumOS + Kodi: n kautta, joko itsenäisesti tai kahden käynnistyksen yhteydessä. Tämä toteutetaan ChromeBox Kodi EZ Setup Scriptin kautta, joka on ajettava (ainakin aluksi) ChromeOS: sta.

EZ-asetuskäsikirja helpottaa kaiken tarvittavan asentaa joko kaksoiskäynnistysasetukset tai asentaa mukautetun laiteohjelmiston, joka mahdollistaa minkä tahansa Linux-pohjaisen käyttöjärjestelmän asentamisen itsenäiseen tilaan.

Suorita ChromeBox EZ Setup -komentosarja seuraavasti:

  1. Käynnistä ja käynnistä ChromeOS. Älä kirjaudu sisään, mutta varmista, että verkkoyhteys on muodostettu.
  2. Avaa komentokehote ([CTRL] [ALT] [<-] ChromeOS-näppäimistöille painamalla [CTRL] [ALT] [F2]
  3. Kirjaudu käyttäjällä chronos (salasanaa ei vaadita)
  4. Lataa ja suorita ChromeBox Kodi EZ Setup Script -komentoa käyttämällä seuraavaa komentoa (paina enter jälkeenpäin):
    Curl -L -O https://mrchromebox.tech/setup-kodi.sh&& sudo bash setup-kodi.sh

    Tässä tulee ongelma kun tuota Script komentoa en osaa suomi näppiksellä kirjoittaa kun terminaalissa näppis tunnistuu US layotilla..

 
Fedora Xfce työpöytä;

Kuvakaappaus_2017-08-18_10-16-07.png
 
Kiitos vinkeistä! Täytyy kokeilla kun kerkeää..
Lisävinkkinä, siinä terminaalissakin toimii copy-paste. Eli voit sen komennon myös liittää komentoriville. Yleensä tapahtuu terminaalista riippuen joko suoraan hiiren oikeaa nappia painamalla tai sitten sieltä avautuvasta valikosta.
 
No joo tuo on tiedossa kyllä ja Linux puolella paljonkin ollut paljonkin mulla käytössä. Mutta mielestäni tuossa cromeos on käytössä 2 eri terminaali tilaa ja tuossa tilassa kone on muuten ikäänkuin pimeänä ja terminaali koko ruudun koossa.. ikäänkuin asentais arch Linuxia..
 
Lisävinkkinä, siinä terminaalissakin toimii copy-paste. Eli voit sen komennon myös liittää komentoriville. Yleensä tapahtuu terminaalista riippuen joko suoraan hiiren oikeaa nappia painamalla tai sitten sieltä avautuvasta valikosta.
Eikö se ole yleensä keskimmäinen nappi, joka liittää? Ja jos joku ei tiedä, niin pelkkä tekstin maalauskin kopioi sen leikepöydälle.
 
Hiirellä maalaus ja shift + insert lienee se vakio.
 
No nyt on LibreELEC dualboottiin asentumassa. Ja se oli tuo developer tila jossa ei saanut kun US layottia käytettyä. Googlaamalla sain sitten tuon Kodi EZ Setup Script:b hakattua..
 
Mulla on tuolla ASUS reitittimet, modeemit yms. verkkolaitteet viestistä #61 eteenpäin linuxjakeluun nimeltä OpenWRT liittyvä kysymys. Luulen että teen siinä jotakin yksinkertaista linuxiin liittyvää mokaa ja siksi tulin mainostamaan tuota ketjua tänne. Käyttökokemusta linuxeista mulla on 10 vuotta mutta sehän ei mitään tarkoita, meillä työpaikan mammoilla on windowsista 25 vuoden kokemus eikä silti osata refreshata selaimen sivua...

Jos tämä viesti oli turhaa spämmiä vika paikkaan niin pahoittelut.
 
Depianista kysymys. Elikkä mikä mahtaa olla syynä että jos kone jää auki ja kerkiää lukitusnäyttöön niin salasana
ei kelpaa vaan väittää vääräksi? Sisäänkirjautuessa bootin jälkeen taas kelpaa. Ja voin vannoa että tähän olen törmännyt aiemminkin.. Eikä kyse ole näppäinhäröstä.. Toistaiseksi laitoin asetuksista että näyttöä ei lukita koskaan..
Lepotilasta noustessa hyväksyy salasanan kyllä. Depian 9 testing siis.

Tullut jonkun verran testailtua tässä NUC:ssa eri distroja ja ubuntu sukuiset ei kyllä toimi oikein mitenkään. Fedora toimi
jonkin aikaa mutta sitten päivityksessä meni jotain rikki kun virransäästöltä noustessa jäi sellaiseen tilaan että hiiri liikkui muttei työpöytä reagoinut siihen mitenkään.. Eli pylpyrä vaan pyöri..
 
Depianista kysymys. Elikkä mikä mahtaa olla syynä että jos kone jää auki ja kerkiää lukitusnäyttöön niin salasana
ei kelpaa vaan väittää vääräksi? Sisäänkirjautuessa bootin jälkeen taas kelpaa. Ja voin vannoa että tähän olen törmännyt aiemminkin.. Eikä kyse ole näppäinhäröstä.. Toistaiseksi laitoin asetuksista että näyttöä ei lukita koskaan..
Lepotilasta noustessa hyväksyy salasanan kyllä. Depian 9 testing siis.

Tullut jonkun verran testailtua tässä NUC:ssa eri distroja ja ubuntu sukuiset ei kyllä toimi oikein mitenkään. Fedora toimi
jonkin aikaa mutta sitten päivityksessä meni jotain rikki kun virransäästöltä noustessa jäi sellaiseen tilaan että hiiri liikkui muttei työpöytä reagoinut siihen mitenkään.. Eli pylpyrä vaan pyöri..
Tarkistit siis ettei näppiskä muutu enkuksi välissä?
 
Depianista kysymys. Elikkä mikä mahtaa olla syynä että jos kone jää auki ja kerkiää lukitusnäyttöön niin salasana
ei kelpaa vaan väittää vääräksi? Sisäänkirjautuessa bootin jälkeen taas kelpaa. Ja voin vannoa että tähän olen törmännyt aiemminkin.. Eikä kyse ole näppäinhäröstä.. Toistaiseksi laitoin asetuksista että näyttöä ei lukita koskaan..
Lepotilasta noustessa hyväksyy salasanan kyllä. Depian 9 testing siis.

Debian 9 "stretch" muuttui testiversiosta stabiiliksi 17. kesäkuuta. Jos sinulla on jakeluvalinta edelleen asennossa "testing", olet nyt saamassa päivityksistä Debian 10:n ("buster") testiversion paketteja. Ja koska kymppiversio on nyt mitä suurimmassa määrin työn alla, se saattaa nyt olla toisinaan jossain määrin rikki.

Jos pakettirepositoriot on määritelty /etc/apt/sources.list-tiedostossa versiokohtaisella koodinimellä (stretch) eikä testing-avainsanalla, olet edelleen tukevasti 9-version puolella ja ongelma ei johdu kymppiversion paketeista. Silloin katso /var/log/auth.log tiedostosta (+ saman login vanhoista versioista) onko siellä epäonnistuneeseen salasanantarkistukseen liittyviä virheilmoituksia joista voisi selvitä mikä menee pieleen.

Toinen vaihtoehto on lukitusnäytön ollessa päällä joko ottaa koneeseen komentoyhteys verkon kautta (SSH, jos on sallittu) tai vaihtaa tekstikonsolin puolelle (Control-Alt-F1), kirjautua sitä kautta sisään ja tarkistaa onko graafisesti sisäänkirjautuneen käyttäjän kotihakemistossa piilotiedostoa .xsession-errors (= käyttäjäkohtainen graafisen istunnon virheloki; ylikirjoittuu kun samalla käyttäjällä avataan seuraava graafinen istunto) ja onko siellä jotain virheilmoitusta joka toisi lisävaloa asiaan. Tekstikonsolista pääsee takaisin graafiseen tilaan Control-Alt-F6 tai -F7 näppäinyhdistelmällä, mutta muista kirjautua tekstikonsolista ulos ensin: muuten jokainen paikalle osuva joka tietää Linuxin tekstikonsoleista pääsee jatkamaan koneen käyttöä tekstikonsolissa sinun tunnuksellasi.

(Joittenkin työpöytäympäristöjen lukitusnäytöt saa tarvittaessa estämään tekstikonsoliin vaihtamisen, mutta tämä ei ole välttämättä oletusarvo.)
 
Päivitykset näyttävät tulevan "buster" paketeista. Kyllä tuolla /var/log/auth.log on jotain tunnistautumisvirheitä.. Pitäis laittaa lukitus takaisin päälle ja katsoa mitä lokeihin tulee. Tosin pärjään nykyisellään näin..

Eikö depianin "testing" päivityksiä pidetä kumminkin suht vakaina? Ja vakaan version päivityksiä hyvin vakaina mutta vanhahtavina?
 
Viimeksi muokattu:
Eikö depianin "testing" päivityksiä pidetä kumminkin suht vakaina? Ja vakaan version päivityksiä hyvin vakaina mutta vanhahtavina?
Tässä vaiheessa Testing on vielä jokseenkin epävakaa. Sitä kehitetään kohti julkaisukelpoista vakaata versiota ja se muuttuu jatkuvasti vakaampaan suuntaan.

Tosin ite pärjäilin Sidillä siinä missä Testingilläkin kotikäytössä, ei ne nyt mitään Archeja sentään ole.
 
Tässä vaiheessa Testing on vielä jokseenkin epävakaa. Sitä kehitetään kohti julkaisukelpoista vakaata versiota ja se muuttuu jatkuvasti vakaampaan suuntaan.

Tosin ite pärjäilin Sidillä siinä missä Testingilläkin kotikäytössä, ei ne nyt mitään Archeja sentään ole.
Ja minä pärjään Archilla hienosti kotikäytössä :) Hyvällä tuurilla se Testing toimii siinä missä stablekin, huonolla tuurilla taas ei.
 
Arch on tehty käytettäväksi distroksi. Jotkut sanovat, että Debian Testing/Unstable on tehty vain testaamiseen joten niiden kanssa ongelmien todennäköisyys olisi suurempi.

Debian Testingissä bugien todennäköisyys voi olla pienempi kuin Unstablessa, mutta se myös päivittyy hitaammin kuin Unstable.
 
Ennen kuin Debian testing-versiosta tulee uusi vakaa versio, testiversiolla on portaittainen "jäädytyskausi" jonka aikana sinne otetaan vastaan vain bugikorjauksia. Tällöin testing-versio on bugien suhteen erittäin laadukkaassa kunnossa ja paranee koko ajan: se on niin lähellä vakaata versiota kuin se yhden versiokierron aikana voi olla.

Kun uusi vakaa versio julkaistaan, testing-versio vapautuu jäädytyksestä ja sinne alkaa virrata taas uutta tavaraa unstable-versiosta, automaattisesti, kaksi kertaa vuorokaudessa.

Nyt kun uusi versio on juuri kesäkuussa tullut ulos, testing-versioon voidaan ottaa unstablesta isojakin rakennemuutoksia jos ne katsotaan tarpeellisiksi seuraavaa vakaata versiota varten (kunhan seuraavan vakaan version tavoitteet saadaan lyötyä lukkoon). Eli juuri nyt testing-versio on niin lähellä unstable-versiota kuin se vain voi olla.

Jos testing-versiota aikoo käyttää johonkin tärkeään, on syytä tiedostaa tämän kiertokulun olemassaolo ja vakaan version julkaisun lähestyessä päättää haluaako jäädä pian vakaaksi muuttuvalle versiotasolle (= laittaa /etc/apt/sources.list-riveille halutun version koodinimi, kuten kesäkuussa vakiintunut "stretch" tai tuleva "buster") vai onko syytä valmistautua versiohyppäykseen ja mahdollisiin ongelmiin kun testing päivittyy julkaisujäädytyksen päättyessä unstablen tasolle.
 
Löin debianin tulille ja siihen virt-managerilla windowsin virtuaalikoneelle. Syötin winukalle gtx1070 -näyttiksen passthroughilla ja se toimii niinkuin pitäisikin. Virtuaalikoneen sain nettiin säätämällä bridgen virtuaalikoneesta hostille. Ainut ongelma nyt on äänet. Koneessa on Asuksen Xonar DGX, jolta pitäisi äänet ja mikki saada kuuluviin. En ole ehtinyt vielä kovinkaan paljoa googlailla, mutta se vähä mitä ehdein ei ollut kovinkaan hyödyllistä. Onko kellään vinkkejä miten saisin tuon äänikortin passthrougilla tuohon virtuaalikoneeseen? Tarvitseeko se blacklistata jotenkin? virt isolta ei löydy ääniajureita vaikka lähes kaikille muille laitteille löytyi.
 
Jutun juoni on että virtualisoinnin pitäisi tarjota (jos niin käsketään) virtuaalikoneelle virtuaalinen äänikortti, joka emuloi sellaista fyysistä äänikorttia jolle Windowsista löytyy ajurit valmiina. Vaihtoehtoja on käsittääkseni Intelin ICH6-piirisarjan äänipiiri (HD Audio/AC97 yhteensopiva) tai sitten es1370.

Alustakoneen fyysistä äänikorttia ei siis tarvitse välttämättä näyttää passthroughilla virtuaalikoneelle... mutta jos haluat niin tehdä, haluat estää ääniajurien latauksen alustakoneessa ja kerrot passthrough-systeemille tuon äänikortin PCI-laitetunnuksen (näkyy lspci-komennolla). Silloin virtuaalikone pääsee käyttämään äänikorttia "suoraan" ja yksinoikeudella, millä saattaa olla merkitystä jos äänentoiston pitää olla tarkasti synkassa siihen mitä kuvassa tapahtuu.

Äänikortin Linux-ajurien latauksen estäminen tarkoittaa yleensä että blacklistataan se snd_* moduuli joka viime kädessä vastaa äänikortin ohjauksesta. Jos tuo äänikortti on HD Audio-yhteensopiva, blacklistattava moduuli on snd_hda_intel.

Virtualisointi ei ilmeisesti oletuksena järjestä tuota virtuaaliäänikorttia ilman käskyä, kenties siksi että jos koneessa ajetaan isoa kasaa virtuaalikoneita ja kaikissa on äänet päällä, voisi syntyä melkoinen kakofonia etenkin sopivissa virhetilanteissa.
 
Jutun juoni on että virtualisoinnin pitäisi tarjota (jos niin käsketään) virtuaalikoneelle virtuaalinen äänikortti, joka emuloi sellaista fyysistä äänikorttia jolle Windowsista löytyy ajurit valmiina. Vaihtoehtoja on käsittääkseni Intelin ICH6-piirisarjan äänipiiri (HD Audio/AC97 yhteensopiva) tai sitten es1370.

Alustakoneen fyysistä äänikorttia ei siis tarvitse välttämättä näyttää passthroughilla virtuaalikoneelle... mutta jos haluat niin tehdä, haluat estää ääniajurien latauksen alustakoneessa ja kerrot passthrough-systeemille tuon äänikortin PCI-laitetunnuksen (näkyy lspci-komennolla). Silloin virtuaalikone pääsee käyttämään äänikorttia "suoraan" ja yksinoikeudella, millä saattaa olla merkitystä jos äänentoiston pitää olla tarkasti synkassa siihen mitä kuvassa tapahtuu.

Äänikortin Linux-ajurien latauksen estäminen tarkoittaa yleensä että blacklistataan se snd_* moduuli joka viime kädessä vastaa äänikortin ohjauksesta. Jos tuo äänikortti on HD Audio-yhteensopiva, blacklistattava moduuli on snd_hda_intel.

Virtualisointi ei ilmeisesti oletuksena järjestä tuota virtuaaliäänikorttia ilman käskyä, kenties siksi että jos koneessa ajetaan isoa kasaa virtuaalikoneita ja kaikissa on äänet päällä, voisi syntyä melkoinen kakofonia etenkin sopivissa virhetilanteissa.
Asiantuntija ei halua virtuaaliäänikorttia vaan erillisen pci äänikortin passthroughna windowsille.
 
Onko tuo kortti PCI vai PCIe liitännällä varustettu? Voi olla ettei vanhempaa PCI väylää pysty rauta avusteisesti virtualisoimaan.
 
Onko tuo kortti PCI vai PCIe liitännällä varustettu? Voi olla ettei vanhempaa PCI väylää pysty rauta avusteisesti virtualisoimaan.
PCI-e kortti kyseessä. Koitin myös säätää virtuaalista äänikorttia laittamalla virt-managerista ICH6 sekä ICH9, mutta ei auttanut. Hosti tunnistaa integroidun äänikortin ja tuon Asuksen kortin. Hostin äänet kuuluu integroidusta, jossa toiset kuulokkeet kiinni. Tosiaan muuten toimii tuo virtuaali windows hyvin, näyttö toimii 144hz ja muutenkin suorituskyky lähes natiivia vastaava. Ainut huono puoli tuossa on se, että tarvitsee olla kaksi hiirtä ja näppäimistöä. Ostamalla Syngergyn saisi yhden hiiren ja näppäimistön toimimaan monen koneen välillä.
 
Mitenkä saisi helpoiten korruptoituneen tiedoston kopioitua kovolta talteen? Kyseessä 50GB win7 Vbox image. Osui vissiin jokunen bad sektori tuon kohdalle ja IO virhettä antaa puolivälissä kopiointia, mutta windows kuitenkin vielä toimii.
"dd" vois auttaa tässä tilanteessa:

Koodi:
dd if=[polku hajonneeseen tiedostoon] of=[polku uuteen tiedostoon] conv=noerror,sync

Eli tuon pitäisi kopsata raaka datana ja kirjoittaa nollaa jos ei pysty jotain lukemaan niin tilalle.
Kannattaa sitten olla varovainen tuon dd kanssa, sillä pystyy pistää helposti datat sekasi, eli tarkkana pitää olla!

ddrescue on enempi tarkoitettu tuohon hommaan ja oletettavasti sekin tukee ihan tiedoston kopiointia, mutta tästä minulla ei ole henk. kohtaista kokemusta, mutta ajattelin mainita, jos haluaa kokeilla. Josko se saisi vähän paremmin asian hoidettua...

Mutta jos kyseessä on tärkeää dataa, niin itse ottaisin ddrescue koko levystä imagen ja sitten sieltä kaivelisin talteen tiedostoja jotka tärkeitä. Koska tiedä millo levy sanoo sopparin lopullisesti irti ja sit onkin vaikeempi työ saada dataa talteen...
 
Viimeksi muokattu:
Jep dd on vaarallinen työkalu. t: piti tehdä tikusta image, kopioin sitten 4gb tikun 500 gb kovon päälle, osiotasolla.
 
Päivitykset näyttävät tulevan "buster" paketeista. Kyllä tuolla /var/log/auth.log on jotain tunnistautumisvirheitä.. Pitäis laittaa lukitus takaisin päälle ja katsoa mitä lokeihin tulee. Tosin pärjään nykyisellään näin..

Eikö depianin "testing" päivityksiä pidetä kumminkin suht vakaina? Ja vakaan version päivityksiä hyvin vakaina mutta vanhahtavina?


Sep 4 09:14:59 debian lightdm: pam_unix(lightdm:auth): check pass; user unknown
Sep 4 09:14:59 debian lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
Sep 4 09:15:10 debian lightdm: pam_unix(lightdm:auth): check pass; user unknown
Sep 4 09:15:10 debian lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
Sep 4 09:15:24 debian lightdm: pam_unix(lightdm:auth): check pass; user unknown
Sep 4 09:15:24 debian lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
modify_inline.gif


tuossa lokitiedostoa..
 
Joo no nyt päästiin tämmöseen kun hetken aikaa oli purppura ubuntun ruutu. Exit pistää tässä ytimen paniikin

Jatketaan täällä.

150576032231768493418-jpg.42601



Tiedostojärjestelmäsi on korruptoitunut. USB-tikku on rikki.

Miten olet rakentanut tämän linux-tikun ja onko mahdollista koettaa toista tikkua?
 
Jatketaan täällä.

150576032231768493418-jpg.42601



Tiedostojärjestelmäsi on korruptoitunut. USB-tikku on rikki.

Miten olet rakentanut tämän linux-tikun ja onko mahdollista koettaa toista tikkua?
Sain toimimaan kun käytin toista tikkua. Käytin rufusta tikun tekemiseen. Jännä kyllä että yli 7 vuotta vanha tikku toimii ja 4 vuotta vanha on mukamas rikki. Pitää tässä katsoa vielä kuitenkin onko siinä vielä paljon elämää jäljellä. Kiitos kuitenkin avusta.
 
Sain toimimaan kun käytin toista tikkua. Käytin rufusta tikun tekemiseen. Jännä kyllä että yli 7 vuotta vanha tikku toimii ja 4 vuotta vanha on mukamas rikki. Pitää tässä katsoa vielä kuitenkin onko siinä vielä paljon elämää jäljellä. Kiitos kuitenkin avusta.
Sekin on jännä, miten upouusi puhelin voi olla rikki, mutta sitä sattuu. Eipä tuo sinänsä ikää katso, vaikka vanhemmalla laitteella lieneekin suurempi riski hajota.
 
Eipä tuo sinänsä ikää katso, vaikka vanhemmalla laitteella lieneekin suurempi riski hajota.
Tekniikan kannalta vanhemmat isommalla viivanleveydellä valmistetut piirit ovat kestävämpiä.

USB tikkujen piirit eivät taida koskaan tulla parhailta tuotantolinjoilta joten niiden varaan ei kannata laittaa mitään elintärkeää, voivat hajota koska tahansa iästä riippumatta.
 
Sarjassa uskomattoman hyviä ideoita:
KDE:n virransäästösovellus powerdevil. Powerdevil ei sammuta näyttöä (eikä tee muutakaan virransäästöön liittyvää) jos sovellus sitä pyytää. Yleisesti ottaen ihan hyvä idea, mutta kun tuota toimintoa ei tietääkseni voi poistaa käytöstä mitenkään (pl. sorsia muokaamalla, dokumentaatiosta en ainakaan löytänyt mitään) tai white/blacklistata sovelluksia. Ongelma tulee siinä vaiheessa kun sovellus käyttäytyy huonosti: "Google chrome is currently suppressing power management", eli mikä tahansa webbisivu voi kääntää virransäästön pois päältä. Esimerkki tällaisesta sivusta on foreca.fi, joka käyttää webrtc:tä, ja jos on aktiivisia webrtc-yhteyksiä, chrome estää näytön sammumisen. :facepalm:
 
@hsalonen Osaatko sanoa miksi tää skripti ei lähde pyörimään? Tän verran tulee tekstiä ja sitten ei tapahdu mitään. Tuossa mainitaan että buildloop.sh ei ole olemassa mutta kyllä se on siellä muiden tiedostojen kanssa.
 

Liitteet

  • DSC_0240.JPG
    DSC_0240.JPG
    3,7 MB · Luettu: 76
@Frezeh Kokeile antaa siinä hakemistossa missä ko. tiedosto on, niin antaa komento chmod +x buildloop.sh .. Jos vaikka jostain syystä execute permission puuttuu ko. skriptiltä.
 
@hsalonen Osaatko sanoa miksi tää skripti ei lähde pyörimään? Tän verran tulee tekstiä ja sitten ei tapahdu mitään. Tuossa mainitaan että buildloop.sh ei ole olemassa mutta kyllä se on siellä muiden tiedostojen kanssa.
Taitaa olla tämä skripti?

Kun komento pushd suoritetaan, se tulostaa nykyisen ja aiemman hakemiston, jossa oltiin. Eli suoritit kill-ryzen.sh-skriptin kotihakemistosta tuon mukaan. Mene ensiksi hakemistoon, jossa skriptit ovat ja suorita skripti sieltä.
 
Sarjassa uskomattoman hyviä ideoita:
KDE:n virransäästösovellus powerdevil. Powerdevil ei sammuta näyttöä (eikä tee muutakaan virransäästöön liittyvää) jos sovellus sitä pyytää. Yleisesti ottaen ihan hyvä idea, mutta kun tuota toimintoa ei tietääkseni voi poistaa käytöstä mitenkään (pl. sorsia muokaamalla, dokumentaatiosta en ainakaan löytänyt mitään) tai white/blacklistata sovelluksia. Ongelma tulee siinä vaiheessa kun sovellus käyttäytyy huonosti: "Google chrome is currently suppressing power management", eli mikä tahansa webbisivu voi kääntää virransäästön pois päältä. Esimerkki tällaisesta sivusta on foreca.fi, joka käyttää webrtc:tä, ja jos on aktiivisia webrtc-yhteyksiä, chrome estää näytön sammumisen. :facepalm:

Tuo virransäästön estopyyntö menee varmaan dbus-väylän kautta, ja List of Chromium Command Line Switches « Peter Beverloo listaa Chromelle option --dbus-stub, joka saattaisi käskeä Chromea olemaan käyttämättä dbus-väylää ollenkaan. Kokeilemalla sitten selviää estääkö tuo samalla jotain muita hyödyllisempiä toimintoja...

Suunnitelma B:
GitHub - jnerin/dbus-listen-inhibit: Tool to check for dbus messages inhibiting sleep in power management
Tuossa on näköjään skripti jolla voisi seurata dbus-väylällä meneviä estopyyntöviestejä. Jos saat kiinni Chromen lähettämän viestin, voisi katsoa millaiset lähettäjätiedot siinä on ja sitten tutkia voisiko dbus-väylälle tehdä politiikkamäärityksen joka estää Chromea juttelemasta virransäästöjärjestelmän kanssa (katso "man dbus-daemon").
 
Tuo virransäästön estopyyntö menee varmaan dbus-väylän kautta, ja List of Chromium Command Line Switches « Peter Beverloo listaa Chromelle option --dbus-stub, joka saattaisi käskeä Chromea olemaan käyttämättä dbus-väylää ollenkaan. Kokeilemalla sitten selviää estääkö tuo samalla jotain muita hyödyllisempiä toimintoja...

Suunnitelma B:
GitHub - jnerin/dbus-listen-inhibit: Tool to check for dbus messages inhibiting sleep in power management
Tuossa on näköjään skripti jolla voisi seurata dbus-väylällä meneviä estopyyntöviestejä. Jos saat kiinni Chromen lähettämän viestin, voisi katsoa millaiset lähettäjätiedot siinä on ja sitten tutkia voisiko dbus-väylälle tehdä politiikkamäärityksen joka estää Chromea juttelemasta virransäästöjärjestelmän kanssa (katso "man dbus-daemon").

Kiitos erittäin hyödyllisestä vastauksesta. Tuo "--dbus-stub" ei vaikuttanut mitenkään, mutta ei tullut mieleeni tarkistaa dbus-väylän estoviestejä. Sain Chromen lähettämät pyynnöt näkyviin, pitänee tutkia voiko niille tehdä jotain.
 

Statistiikka

Viestiketjuista
258 390
Viestejä
4 489 665
Jäsenet
74 151
Uusin jäsen
Malik

Hinta.fi

Back
Ylös Bottom