Linux-kysymyksiä & yleistä keskustelua Linuxista

Se asennusohjelma kysyy melko alkuvaiheessa haluatko antaa asennusohjelman tehdä homman automaattisesti vai haluatko itse määritellä mille levylle asennetaan ja minkälaiset partitiot tehdään. Tarkoitatko että tällaista valintaa ei ollut vaiko että manuaalinen levyjen ja partitioitten määrittely ei toiminut?
Siellä oli sellainen toiminto, mutta mistään ei voinut valia sitä 1T:n m.2:sta.
 
Se manuaalinen levyn valinta voi näyttää hiukan mystiseltä kun se käyttää hiukan kummallisia merkintöjä levyistä että ehkä sitä voisi katsoa uudestaan ja pidempään että josko se silti siellä olisi.

Tai sitten linux ei ole jotenkin löytänyt tätä levyä jolloin ongelma on vaikeampi.

Jos tämä on pöytäkone niin ehkä sen 4t kovalevyn voi napata irti asennuksen ajaksi jolloin se automaaginen asennus pitäisi mennä sille toiselle ainoalle kiinniolevalle levylle.
 
Asensin tänään Linux Mintin. Asennusohjelma osasi asentaa myös Nvidian ajurit. Asennusohjelma ei kuitenkaan antanut valita tallennusmediaa. Laitto 4T kiintolevylle vaikka 1T m.2 olisi ollut käytettävissä.
Aika erikoinen automatiikka. Asennusohjelman olisi kyllä järkevä suosia aina nvme-levyä. Oletan nyt että m.2 oli nvme. Muutenhan ne voivat näkyä sata-levyinä molemmat ja tuo lopputulema mahdollinen.
 
Se manuaalinen levyn valinta voi näyttää hiukan mystiseltä kun se käyttää hiukan kummallisia merkintöjä levyistä että ehkä sitä voisi katsoa uudestaan ja pidempään että josko se silti siellä olisi.

Tai sitten linux ei ole jotenkin löytänyt tätä levyä jolloin ongelma on vaikeampi.

Jos tämä on pöytäkone niin ehkä sen 4t kovalevyn voi napata irti asennuksen ajaksi jolloin se automaaginen asennus pitäisi mennä sille toiselle ainoalle kiinniolevalle levylle.
En katsonut Linuxin levyille antamia koodeja. Ainoastaan kokoa.

Sinun idealla koneeseen saadaan yksi Windows ja kaksi Linuxia. Dual/tripla käynnistysvalikko saattaisi mennä solmuun. Jatketaan nykyisellä asennuksella.
 
Aika erikoinen automatiikka. Asennusohjelman olisi kyllä järkevä suosia aina nvme-levyä. Oletan nyt että m.2 oli nvme. Muutenhan ne voivat näkyä sata-levyinä molemmat ja tuo lopputulema mahdollinen.
Samsung 1TB 970 EVO Plus SSD-levy, M.2 2280, PCIe 3.0 x4, NVMe, 3500/3300 MB/s.
 
Jotenkin kuulostaa että edelleen on ongelma olemassa että sille m.2 levylle ei ole onnistuttu asentamaan linuxia ja se ei näy linuxin asennusohjelman manuaalisessa partitiovalinnassa.

Tuo minun vihje yrittää ottaa 4t kovalevy irti oli yritys selvittää miksi näin on ja erityisesti että onko rauta siten että linux ylipäätään osaa nähdä sen m.2 levyn. Jos 4t kovalevyn irtiottamisen jälkeen asennus ei onnistu koska m.2 levyä ei näy niin tällätavoin pääsee nopeasti oikean ongelman juurisyyn selvittelyn alkuun. Jos taas asennus onnistuu niin sehän kait oli just se mitä sinä halusit.

Se mitä 4t levyllä tällähetkellä on on vähän epäselvää mutta oletan että siellä on kenties turha linux asennuspartitio mutta senhän voi sieltä poistaa. Ihan samallatavalla sen kait sieltä haluat ja joudut poistamaan jos vaikka onnistutkin asentamaan linuxin myös sille m.2 levylle tällä taktiikalla millä näytät etenevän.

Se oikea ongelma joka tuosta minun 4t levyn irtiottoideasta seuraa että jos asennat linuxin m2. levylle näin ja jos windows asennus on sillä 4t levyllä niin asennuksen jälkeen systeemi on linux singleboot tilassa mutta sen saaminen dualboottaamaan sen jälkeen kun 4t levy laitetaan uudestaan kiinni ei ole vaikeaa vaan ihanvaan grub configuraattorilla menee helposti sen jälkeen kun muutat koneen buuttausjärjestyksen että se buuttaa m.2 levyltä ensin.

Jos taas windows on m.2 levyllä ja kone siis jo ennestään buuttaa ensin m.2 levyltä niin silloinhan dualboot tulee kerralla kuntoon ja sun tarttee vain deletoida se 4t levyn linux osio ettei siitä ole harmia tulevaisuudessa mutta senhän haluat tehdä joka tapauksessa?

Triplakäynnistysvalikko tai vaikka monimutkaisempikaan ei sinällään ole mitenkään ihmeellistä vaan sellaisia on monella ihmisellä ihan halun vuoksi jos vaikka haluavat testata 12 erilaista käyttöjärjestelmää eri partitioilla ja heillä on siis dozenboot valikko.

Mutta ihan miten vaan haluat.
 
En katsonut Linuxin levyille antamia koodeja. Ainoastaan kokoa.

Sinun idealla koneeseen saadaan yksi Windows ja kaksi Linuxia. Dual/tripla käynnistysvalikko saattaisi mennä solmuun. Jatketaan nykyisellä asennuksella.
Ei selvinnyt alkuperäisestä viestistä: oliko tarkoituksenasi asentaa Linux Mint olemassaolevan Windows-asennuksen rinnalle dualboottiin, vai ainoaksi käyttikseksi tyhjälle tietokoneelle jolla on sekä (täysin tyhjät) SSD että HDD levyt (ja ymmärrettävästi haluat Linuxin nopeammalle levylle)?

Jos siellä on jo Windows, millä levyllä se on? SSD?

Molemmissa ylläolevissa tapauksissa herra57 ajatus olisi se mitä itsekin yrittäisin, jotta voisi todentaa eikö Linux Mintin asennusmedia jostain syystä näe SSD-levyä ollenkaan. Jos taas nykyinen Windows on asennettu hitaalle HDD:lle ja Linuxin haluat rinnalle tyhjälle SSD:lle, sitten tuo idea ei toimi.

Mahdollisia lisäkommerverkkeja:

1. Onko SecureBoot päällä? Sinänsä Linux Mint pitäisi osata hanskata se mutta aloitteleva voi mennä vikaan kun SecureBoot alkaa pyytää jotain MOK-avaimia uudelleenkäynnistyessään eikä ole varma miten edetä; io-techin aiemmin ketjussa ollut Linux-testi taisi törmätä juuri tähän kun ottivat NVidian proprietary-ajurit käyttöön, valitsivat kai väärän option eivätkä saaneet Linuxia toimimaan ennenkuin SecureBoot laitettiin kokonaan pois päältä.

Tosin en tiedä aiheuttaisiko SecureBoot tuollaista ettei toinen levy (SSD) näy Linuxille asennuksessa, mutta mistä näitä tietää varmasti.

2. Joku toinen oli mielessä mutta meni jo.
 
Näin useamman viikon ubuntun ja freenassin parissa lopulta asrockin biosiksi paljastuneen ongelmapesän kanssa tapelleena. Mitä valmistajaa ensisijaisesti kannattaa katella hw puolelta ja mitä distroa lähteä koittaman samba-nas-plex kotipalvelimena?
 
Näin useamman viikon ubuntun ja freenassin parissa lopulta asrockin biosiksi paljastuneen ongelmapesän kanssa tapelleena. Mitä valmistajaa ensisijaisesti kannattaa katella hw puolelta ja mitä distroa lähteä koittaman samba-nas-plex kotipalvelimena?
Varmaan auttaisi avata hieman mistä on kiikastanut ja mikä AssRockin BIOSissa hiertää? Yleisesti ottaen toki myös koneen speksit. Aika hankala lähteä mitään perusteltua vastausta näiltä pohjin antamaan..
 
En katsonut Linuxin levyille antamia koodeja. Ainoastaan kokoa.

Sinun idealla koneeseen saadaan yksi Windows ja kaksi Linuxia. Dual/tripla käynnistysvalikko saattaisi mennä solmuun. Jatketaan nykyisellä asennuksella.
Nykyään kun koneissa on UEFI (olettaen että kone on luokkaa 10-15v vanha korkeintaan), niin eka boottivalikko on kyllä siellä UEFIn rommilla. Sinne voi säätää eka Windowsin ja Linuxin. Systemd-boot tai grub on sitten Linuxin osiolla ketjuladattuna. Ennen vanhaan olikin eri juttu kun sekä Windows että Linux käyttivät samaa MBR:ää ja kaikki sähellys boottailun ympärillä rikkoi kaiken.
 
Ei selvinnyt alkuperäisestä viestistä: oliko tarkoituksenasi asentaa Linux Mint olemassaolevan Windows-asennuksen rinnalle dualboottiin, vai ainoaksi käyttikseksi tyhjälle tietokoneelle jolla on sekä (täysin tyhjät) SSD että HDD levyt (ja ymmärrettävästi haluat Linuxin nopeammalle levylle)?

Jos siellä on jo Windows, millä levyllä se on? SSD?

Molemmissa ylläolevissa tapauksissa herra57 ajatus olisi se mitä itsekin yrittäisin, jotta voisi todentaa eikö Linux Mintin asennusmedia jostain syystä näe SSD-levyä ollenkaan. Jos taas nykyinen Windows on asennettu hitaalle HDD:lle ja Linuxin haluat rinnalle tyhjälle SSD:lle, sitten tuo idea ei toimi.

Mahdollisia lisäkommerverkkeja:

1. Onko SecureBoot päällä? Sinänsä Linux Mint pitäisi osata hanskata se mutta aloitteleva voi mennä vikaan kun SecureBoot alkaa pyytää jotain MOK-avaimia uudelleenkäynnistyessään eikä ole varma miten edetä; io-techin aiemmin ketjussa ollut Linux-testi taisi törmätä juuri tähän kun ottivat NVidian proprietary-ajurit käyttöön, valitsivat kai väärän option eivätkä saaneet Linuxia toimimaan ennenkuin SecureBoot laitettiin kokonaan pois päältä.

Tosin en tiedä aiheuttaisiko SecureBoot tuollaista ettei toinen levy (SSD) näy Linuxille asennuksessa, mutta mistä näitä tietää varmasti.

2. Joku toinen oli mielessä mutta meni jo.
Samsung 970 EVO Plus SSD 500 Gt M.2 -SSD-kovalevy Windows
Samsung 1TB 970 EVO Plus SSD-levy, M.2 2280, PCIe 3.0 x4, NVMe, 3500/3300 MB/s Tyhjä
Seagate Barracuda 4 Tt 256 Mt 5900 RPM 3.5" SATA III (6 Gb/s) kovalevy Alunperin pekästään tiedostoja. Nyt Myös Linux Mint. Mint näkee kaikki alkuperäiset tiedostot.
AMD Ryzen 9 5900X
Asus ROG Strix RTX 3090
Corsair 32GB (2 x 16GB) Vengeance LPX, DDR4 3200MHz, CL16,
Tarkoitus oli asentaa dualboot, joka tulikin.
Linuxin asennusmedia näki vain 4T kiintolevyn.
1. En tiedä mitään SecureBootista. Ei kysellyt MOKkeja. Nvidian ajurit toimivat asennuksen jäkeen. Kokeilin Homeword 3:sta.
 
Samsung 970 EVO Plus SSD 500 Gt M.2 -SSD-kovalevy Windows
Samsung 1TB 970 EVO Plus SSD-levy, M.2 2280, PCIe 3.0 x4, NVMe, 3500/3300 MB/s Tyhjä
Seagate Barracuda 4 Tt 256 Mt 5900 RPM 3.5" SATA III (6 Gb/s) kovalevy Alunperin pekästään tiedostoja. Nyt Myös Linux Mint. Mint näkee kaikki alkuperäiset tiedostot.
AMD Ryzen 9 5900X
Asus ROG Strix RTX 3090
Corsair 32GB (2 x 16GB) Vengeance LPX, DDR4 3200MHz, CL16,
Tarkoitus oli asentaa dualboot, joka tulikin.
Linuxin asennusmedia näki vain 4T kiintolevyn.
1. En tiedä mitään SecureBootista. Ei kysellyt MOKkeja. Nvidian ajurit toimivat asennuksen jäkeen. Kokeilin Homeword 3:sta.
Ok nyt on vähän selkeämpää.

Vaikea sanoa mistä johtuu mutta paras arvaus, sinunkin tuossa sanomanasi, oli että jostain syystä se ei nähnyt noita SSD-levyjä... mutta osasi silti tehdä toimivan dual-bootin toisella "näkymättömällä" SSD:llä majailevan Windowsin kanssa?

Sitä myös mietin miten se osasi asentaa itsensä HDD:lle jos siellä oli jo esim. NTFS-formatoitu datapartitio? Vai oliko siellä käyttämätöntä tilaa jota ei oltu vielä partitioitu, ja Mint partitioi sen itselleen (ext4)?

Jos kokeilisin itse uudestaan Mint-asennusta, varmaan just kokeilisin että HDD irti siksi aikaa, ja näkeekö Mint mitään mille asentaa itseään (eli niitä kahta SSD:tä, tai lähinnä sitä tyhjää). Joku viisaampi osaa ehkä sanoa miten olemassaolevasta Mint-asennuksesta pääsisi helpoiten eroon että lähtee grubitkin kne mäkeen etkä vahingossa poista sitä datapartitiotasikin...

Yksi mitä myös tarkistaisin olisi mennä BIOS/UEFI asetuksiin ja katsoa sieltä miten nuo kolme levyä siellä näkyvät, ja onko niille erilliset boot optiot ja mikä on nyt valittu aktiiviseksi jolta buutataan (joka sitten osannee antaa sinulle buutissa valikon että mennäänkö Windowsiin vai Linuxiin). Samalla ehkä näkee onko SecureBoot päällä, toki sitä ei kannattane tässä vaiheessa muuttaa.

Muistelen myös että joillakin koneilla minun piti vaihtaa UEFI-asetuksista joku "SATA Operation" defaultiista "Raid On" => "ACHI" ennenkuin sain asennettua Linuxin rinnalle ja alkoi toimia. En tiedä liittyykö tämä ollenkaan sinun tapaukseesi.

Valitettavasti minullakin tämä oppi dualbootin toimintaan saamiseksi on tullut lähinnä kantapään kautta yritys&erehdys-menetelmällä ja kovalla googlailulla. Toki yleensä se on mennyt heti maaliin mutta eniten joskus jouduin ihmettelemään juuri tuota yllämainittua "SATA Operation"-modea, ja joskus tuli io-tech Linux videon tapaan tapeltua niiden MOK-avainten kanssa ennenkuin sain SecureBootin toimimaan (ei siinä muusta ollut kyse kuin että buutin jälkeisessä "MOK-ruudussa" tein väärän valinnan kun en ymmärtänyt mihin ko. valinta edes liittyi; io-tech taisi tehdä saman mokan mutta pääsi sen yli disabloimalla koko SecureBootin; minä tarvitsin SecureBootin päälle koska työnantaja niin vaati ja Windowsissa oli BitLocker käytössä joka muistaakseni taitaa vaatia SecureBootin päälläoloa, -kö?
 
Windowsin Fast Startup myös lukitsee asemia vain lukutilaan, se tulisi itselle ensiksi mieleen.
Hyvä pointti, tuohan tulisi kai ensimmäiseksi disabloida Windowsista ennenkuin alkaa asennella Linuxia rinnalle?

En ehkä itse törmää tuohon koska aina käyn Windowsin asennuksen jälkeen poistamassa tuon asetuksen. Tykkään vaan että shutdown oikeasti tarkoittaa shutdown eikä jotain hybridihibernatetilaa josta ei voi olla varma. Kyllä minä jaksan odottaa sen 5-10 s kauemmin konetta käynnistettäessä.
 
On moni näemma ainakin ryhtynyt kokeilemaan linuxia statcouterin mukaan.
Noussut viimme aikoina 18%, toivottavasti myös usea on tyytyväinen vaihtoon.
Tietysti vaihto vaatii paljon uuden opettelua.
statcounter
StatCounter-os_combined-FI-monthly-202404-202504.png
 
Muistelen myös että joillakin koneilla minun piti vaihtaa UEFI-asetuksista joku "SATA Operation" defaultiista "Raid On" => "ACHI" ennenkuin sain asennettua Linuxin rinnalle ja alkoi toimia. En tiedä liittyykö tämä ollenkaan sinun tapaukseesi.
Tuo Raid kannattaa vaihtaa muissakin tapauksissa AHCI:ksi. AHCI on standarditapa ja raidien kanssa joutuu mahdollisesti ongelmiin, jos emolevy hajoaa. Linuxissa on omat softaraid-tekniikat.
 
Jos tulkitsen oikein hw kuvaustasi niin tämä 1t SSD jolle yritetään asentaa vaikuttaisi olevan pcie adapterikortilla ja tämä toinen 500g SSD on emolaudan m.2 liittimessä.

Linuxilla on ollut ongelmia buutata joittenkin pcie adapterikorttien takana olevalta m.2 SSD:ltä. Kannattaa googlata lisää yksityiskohtia.

Joku helppo kokeilu olisi vaihtaa nuo SSD asemat päikseen että 1T SSD jonne asennetaan linux tulisi emolaudan liittimeen ja tuo toinen Windows SSD sinne adapterikortille josko Windows osaisi buutata tältä adapterikortilta. Se voi osata buutata sieltä natiivisti mutta luultavasti ainakin siten että buuttaus tapahtuu 1T SSD linux dualboot konfiguraation kautta.

Sen linux partition tuhoaminen 4t HDDltä on paras tehdä windowssista antamalla sen laajentaa Windows partition sen päälle. Windows osaa varmaan tuhota sen linux buuttisektorin joka jää nyt käyttämättömäksi mutta jos ei niin ei se haittaa kun sä et halua määritellä tätä levyä biossissa levyksi jolta buukataan.

Linuxin asennusmedia ehkä valitsi olla näyttämättä tätä 500g levyä koska siellä oli Windows käyttämässä koko levytilan. Jos olisit ennakolta tehnyt sinne allokoimatonta tilaa niin ehkä asennusmedia olisi näyttänyt tämän levyn.
 
Viimeksi muokattu:
On moni näemma ainakin ryhtynyt kokeilemaan linuxia statcouterin mukaan.
Noussut viimme aikoina 18%, toivottavasti myös usea on tyytyväinen vaihtoon.
Tietysti vaihto vaatii paljon uuden opettelua.
statcounter
StatCounter-os_combined-FI-monthly-202404-202504.png
Tainu macciukot siirtyä Linux käyttäjiksi, kun OS X:n käyrä laskenu samassa suhteessa kuin mitä Linux noussu?! :smoke:
 
Tainu macciukot siirtyä Linux käyttäjiksi, kun OS X:n käyrä laskenu samassa suhteessa kuin mitä Linux noussu?! :smoke:
Itse en ole vain tiettyyn käyttöjärjestelmään uskova. Käytössä Windows, macOS, Linux, BSD ja tietty noi vanhojen muistamat C64 ja Amiga.

Mutta tuohon viimeiseen Intelillä valmistettuun MacBook Pro sarjaan tuli pari viikkoa sitten laitettua dual bootilla Arch Linux ja olen sen ajoon erittäin tyytyväinen. Hyvää rautaa, sekä parasta softaa nyt siinä. Varsinkin dev puolelta macOS on liian paljoa eristetty, että mitä pääsee tekemään.
 
Viimeksi muokattu:
Varmaan auttaisi avata hieman mistä on kiikastanut ja mikä AssRockin BIOSissa hiertää? Yleisesti ottaen toki myös koneen speksit. Aika hankala lähteä mitään perusteltua vastausta näiltä pohjin antamaan..
Acpi bios error tulee käynnistyksessä vanhalla z370 Extreme4 emolla ja 8700k intelillä ensimmäisen rebootin aikana ja menee pelastusmodiin uusimmalla lst ubuntulla. Windowsin kanssa ei ollut vuosiin mitään ongelmia tuon kanssa. Freenas ei edes suostunut asentamaan itseään tuohon.
Tuossa käytössä c-statet on hyvä olla käytössä kun suurimman osan ajasta idlenä sekä raidin selvitä bootista hävittämättä tietoja että mitään pointtia koko projektissa. 32gb ramia ja intelin 256gb ssd käyttiksellä. Jaetuksi oli tarkoitus pistää raid 1 4tb hdd pari ja laajentaa myöhemmin toisella raid 1 parilla mitä vanhoja levyjä kertynyt nurkkiin.
 
Viimeksi muokattu:
Acpi bios error tulee käynnistyksessä vanhalla z370 Extreme4 emolla ja 8700k intelillä ensimmäisen rebootin aikana ja menee pelastusmodiin uusimmalla lst ubuntulla. Windowsin kanssa ei ollut vuosiin mitään ongelmia tuon kanssa. Freenas ei edes suostunut asentamaan itseään tuohon.
Tuossa käytössä c-statet on hyvä olla käytössä kun suurimman osan ajasta idlenä sekä raidin selvitä bootista hävittämättä tietoja että mitään pointtia koko projektissa.
En tiedä onko tästä apua, mutta sama prossu ja joku MSI lankku ja ubuntu 22 versio jotain (bionic) kyllä toimi ja käynnistyi. Mutta asiat on muistin varassa kun kyseisenä vuonna tuo prossu oli varsin tuore. Oli työpaikan kone, jossa oli ollut 7700k prossu käytössä ja emo hajonnut. Tilalle oltiin ostettu uusi emo jossa tuo vanha 7700k ei sitten toiminutkaan ja sitten hankittiin 8700k.
 
Jos tulkitsen oikein hw kuvaustasi niin tämä 1t SSD jolle yritetään asentaa vaikuttaisi olevan pcie adapterikortilla ja tämä toinen 500g SSD on emolaudan m.2 liittimessä.

Linuxilla on ollut ongelmia buutata joittenkin pcie adapterikorttien takana olevalta m.2 SSD:ltä. Kannattaa googlata lisää yksityiskohtia.

Joku helppo kokeilu olisi vaihtaa nuo SSD asemat päikseen että 1T SSD jonne asennetaan linux tulisi emolaudan liittimeen ja tuo toinen Windows SSD sinne adapterikortille josko Windows osaisi buutata tältä adapterikortilta. Se voi osata buutata sieltä natiivisti mutta luultavasti ainakin siten että buuttaus tapahtuu 1T SSD linux dualboot konfiguraation kautta.

Sen linux partition tuhoaminen 4t HDDltä on paras tehdä windowssista antamalla sen laajentaa Windows partition sen päälle. Windows osaa varmaan tuhota sen linux buuttisektorin joka jää nyt käyttämättömäksi mutta jos ei niin ei se haittaa kun sä et halua määritellä tätä levyä biossissa levyksi jolta buukataan.

Linuxin asennusmedia ehkä valitsi olla näyttämättä tätä 500g levyä koska siellä oli Windows käyttämässä koko levytilan. Jos olisit ennakolta tehnyt sinne allokoimatonta tilaa niin ehkä asennusmedia olisi näyttänyt tämän levyn.
1T SSD ei ole adapterikortilla kiinni.
 
1T SSD ei ole adapterikortilla kiinni.
Jos emolla on kaksi m2-paikkaa niin toinen on yleensä kytketty suoraan ja toinen piirisarjan kautta. Jospa distrossa oli vanhat ajurit eikä piirisarjalle tukea? Ennen kuin syyttää Linuxia niin kannattaa katsoa jollain distrolla jossa on uudet ajurit. En Minttiä käytä, mutta esim. distrowatchin mukaan siinä tulisi nytkin 6.8-kerneli ja 6.14 on uusin. Eli tuo on reilun vuoden vanha (+ tietoturvapäivitykset). Aiemmissa julkaisuissa oli 6.1, 5.15, 5.10 ja 5.4. Voi olla että asennuksen jälkeen voi vaihtaa tuoreempaankin kerneliin, mutta linux-distrojen mittapuulla tuo tahti ei ole ihan älyttömän nopea. Jos on uudehkoa rautaa, niin rolling release -distrot on tuen puolesta paras valinta.
 
Onkohan vielä olemassa käyttökohteita 90-luvun raudalle? Avaruustekniikka voi olla missä tuon aikakauden arkkitehtuuria vielä käytetään, muuta on vaikea keksiä.
Teollisuudessa on paljon i486-arkkitehtuureja käytössä, mutta ei niitä kukaan päivitä.

T2 Linux tulee tukemaan noita edelleen. Tukeehan se myös Motorolan MIPS-prosessoria vuodelta 1977 eikä ole suunnitelmissa niiden pudottamista.
 
Mistä kiikastaaa ettei btrfs levyt mounttaannu automaattisesti vaan pitää käydä painaa Gpartista päälle mounttaus.

tossa rivit fstabista:
UID=9a1c344d-0918-4844-9eeb-4782ac656695 /mnt/ssdgames rw,user,noatime,nodiratime,compress=lzo 0 2
UUID=64871d34-f335-4e45-bda3-e674f22ecabf /mnt/data rw,user,noatime,nodiratime,compress=lzo0 2
UUID=dc595867-0a0d-4e3a-b2b2-c6e2dba42489 /mnt/backup rw,user,noatime,nodiratime,compress=lzo 0 2

oon noiden /mnt hakemistijojenkin oikeuksia muuttanut käyttäjälle mutten mikään auta
 
Mistä kiikastaaa ettei btrfs levyt mounttaannu automaattisesti vaan pitää käydä painaa Gpartista päälle mounttaus.

tossa rivit fstabista:
UID=9a1c344d-0918-4844-9eeb-4782ac656695 /mnt/ssdgames rw,user,noatime,nodiratime,compress=lzo 0 2
UUID=64871d34-f335-4e45-bda3-e674f22ecabf /mnt/data rw,user,noatime,nodiratime,compress=lzo0 2
UUID=dc595867-0a0d-4e3a-b2b2-c6e2dba42489 /mnt/backup rw,user,noatime,nodiratime,compress=lzo 0 2

oon noiden /mnt hakemistijojenkin oikeuksia muuttanut käyttäjälle mutten mikään auta
Puuttuuko ekasta rivistä eka U oikeasti, vai onko jäänyt vain pois copypastesta?
 
Mistä kiikastaaa ettei btrfs levyt mounttaannu automaattisesti vaan pitää käydä painaa Gpartista päälle mounttaus.

tossa rivit fstabista:
UID=9a1c344d-0918-4844-9eeb-4782ac656695 /mnt/ssdgames rw,user,noatime,nodiratime,compress=lzo 0 2
UUID=64871d34-f335-4e45-bda3-e674f22ecabf /mnt/data rw,user,noatime,nodiratime,compress=lzo0 2
UUID=dc595867-0a0d-4e3a-b2b2-c6e2dba42489 /mnt/backup rw,user,noatime,nodiratime,compress=lzo 0 2

oon noiden /mnt hakemistijojenkin oikeuksia muuttanut käyttäjälle mutten mikään auta

Koska et käytä defaults mount optiota (joka siis sisältäisi auto ja rw optiot) niin sun tarttee auto lisätä.

 
Puuttuu vaan copypasten takia. Ei auttanut ton auton lisäys. Ei toiminut vaikka pyyhki pois nuo muut ja lisäsi vain defaultsin ja 0 0
 
Jakelu on uusin linux mint cinnamon jos tolla nyt mitään väliä o
Ainakin omissa koneissa fstabissa on polun jälkeen vielä tiedostojärjestelmän tyyppi ennen noita optioita, esimerkiksi
UUID=c8db64cf-d51e-41f5-a169-efc333d73834 /boot ext4 defaults 0 2

Vaikuttaisikohan tuo tyypin puuttuminen tuohon?
 
Ainakin omissa koneissa fstabissa on polun jälkeen vielä tiedostojärjestelmän tyyppi ennen noita optioita, esimerkiksi
UUID=c8db64cf-d51e-41f5-a169-efc333d73834 /boot ext4 defaults 0 2

Vaikuttaisikohan tuo tyypin puuttuminen tuohon?
Kyllähän se vaikutti. Jotenkin miljoona kertaa tuon kattonut mutta jotenkin tullut jo asian suhteen sokeeksi. Kiitokset tuhannesti
 
Kyllähän se vaikutti. Jotenkin miljoona kertaa tuon kattonut mutta jotenkin tullut jo asian suhteen sokeeksi. Kiitokset tuhannesti

Juuri tuon takia suosittelen että opettelet noiden kolmen ekan tasauksen tabulaattorilla sinne fstabiin niin ovat huomattavasti selkeämpiä tulkittavia. Tyyliin:
Koodi:
UUID=4043d322-c0b8-4c3f-a7e8-28f0ae1ca47f       /               btrfs           defaults,noatime,x-systemd.device-timeout=0     0 0
UUID=873f4989-526c-4cf9-82d5-799b6703acd3       /boot           ext4            defaults,noatime                1 2
UUID=DDCA-C9A4                                  /boot/efi       vfat            defaults                        0 0
LABEL=raid1-swap                                swap            swap            defaults                        0 0
 
Kyllähän se vaikutti. Jotenkin miljoona kertaa tuon kattonut mutta jotenkin tullut jo asian suhteen sokeeksi. Kiitokset tuhannesti
Kun itselläni on ollut tarkoituksena testailla btrfs käyttöönottoa, mitkä asiat sinua motivoivat sen käyttöönottoon, eli miksi ei normi ext4 tai xfs?

Minua lähinnä kiinnostaisi muuntaa isoilla (esim. 5-18TB) USB-levyillä olevat tiedostoarkistoni btrfs:ään jotta niissä olisi sisäänrakennettu checksum-tarkistus, eli ilman lisäkommerverkkejä kuten md5 tai sha256-checksummien luomista kaikista tiedostoista, btrfs avulla voisin aina tarkistaa ovatko mitkään tiedostot korruptoituneet ajan saatossa, ja korvata ne toiselta backupilta korruptoimattomilla versioilla.

Erillisten checksummien kanssa pelleily teettää paljon lisätyötä jos siirtelee ja muuttelee arkistoitavia tiedostoja usein, joutuisi erikseen luomaan uudet checksummat ja mitä vielä. Käsittääkseni btrfs (ja ehkä ZFS) hoitaisi tuonkin asian itsenäisesti taustalla.

Onko sinulla sama tai jokin muu syy btrfs käyttöönottoon? Software RAID tms.?
 
Kun itselläni on ollut tarkoituksena testailla btrfs käyttöönottoa, mitkä asiat sinua motivoivat sen käyttöönottoon, eli miksi ei normi ext4 tai xfs?

Minua lähinnä kiinnostaisi muuntaa isoilla (esim. 5-18TB) USB-levyillä olevat tiedostoarkistoni btrfs:ään jotta niissä olisi sisäänrakennettu checksum-tarkistus, eli ilman lisäkommerverkkejä kuten md5 tai sha256-checksummien luomista kaikista tiedostoista, btrfs avulla voisin aina tarkistaa ovatko mitkään tiedostot korruptoituneet ajan saatossa, ja korvata ne toiselta backupilta korruptoimattomilla versioilla.

Erillisten checksummien kanssa pelleily teettää paljon lisätyötä jos siirtelee ja muuttelee arkistoitavia tiedostoja usein, joutuisi erikseen luomaan uudet checksummat ja mitä vielä. Käsittääkseni btrfs (ja ehkä ZFS) hoitaisi tuonkin asian itsenäisesti taustalla.

Onko sinulla sama tai jokin muu syy btrfs käyttöönottoon? Software RAID tms.?
Ei kai tossa mulla sen ihmeempää syytä ole. Lueskelin noista tiedosto järjestelmistä ja monessa paikkaa tuota tunnuttiin nykysin suositeltavan.
 
Erillisten checksummien kanssa pelleily teettää paljon lisätyötä jos siirtelee ja muuttelee arkistoitavia tiedostoja usein, joutuisi erikseen luomaan uudet checksummat ja mitä vielä. Käsittääkseni btrfs (ja ehkä ZFS) hoitaisi tuonkin asian itsenäisesti taustalla.
Se huomaa korruption automaattisesti kun käyttää kyseisiä tiedostoja, mutta jos haluat tarkistaa kaiken läpi virheiden varalta, niin sitä pitää komentaa erikseen. Metadatan osalta on hiukan eri.
 
Se huomaa korruption automaattisesti kun käyttää kyseisiä tiedostoja, mutta jos haluat tarkistaa kaiken läpi virheiden varalta, niin sitä pitää komentaa erikseen. Metadatan osalta on hiukan eri.
Juu, tuo kelpaa ja riittää.

Se on kuitenkin huomattava parannus nykytilanteeseen missä yritän ylläpitää jotain checksummia useasta terasta arkistoitua dataa jota välillä päivitän tai siirtelen eri paikkoihin arkiston sisällä. Koitan käyttää tähän esim. rhash ja dvdsig apuohjelmia. Pitäisi aina laskea checksummat uusiksi muutetuista tai jopa vain uudelleennimetyistä tiedostoista, tai jos poistaa tiedoston, poistaa myös sen checksumman, tai jos siirtää tiedoston, pitäisi sen checksumma joko laskea uusiksi tai ainakin päivittää uusi paikka checksummalistalle... aaargh, mahdoton savotta.

Kiva jos filesysteemi tekee tuon kaiken hallinnan taustalla, ja minun osaltani riittää että silloin tällöin tarkistan vaikka koko arkiston läpi. Jos jonkun tiedoston checksumma ei täsmää, otetaan se tarkempaan tarkasteluun ja jos on viallinen, korvataan se toiselta varmistukselta löytyvällä todennäköisesti edelleen toimivalla tiedostolla.
 
Onko tuo tiedostojen korruptoituminen oikeasti joku ongelma? Mietin vaan kun itselläni on ollut kaikenlaisia fat12/fat16/vfat/ext2/ext4/zfs ja ties mitä tiedostojärjestelmiä käytössä vuosien varrella ties millaisilla levyillä eikä tiedostot ole korruptoineet ellei levy ole oikeasti hajonnut jolloin esim SMART on kyllä kertonut että levy on rikki tai sitten levy on vaan totaalisen kuollut. Osa noista tiedostojärjestelmistä on ollut mountattuna vaikka millaisten viritysten kautta, kuten SMB/CIFS, SSHFS, NFS, WebDAV jne joissa tietty on ollut joskus jotain verkko-ongelmia mutta on kyllä saanut noista suoraan jonkinlaisen virheilmoituksen. Vai onko itselläni vaan ollut viimeiset parikymmentä vuotta ihan hiton hyvä tuuri?
 
Onko tuo tiedostojen korruptoituminen oikeasti joku ongelma? Mietin vaan kun itselläni on ollut kaikenlaisia fat12/fat16/vfat/ext2/ext4/zfs ja ties mitä tiedostojärjestelmiä käytössä vuosien varrella ties millaisilla levyillä eikä tiedostot ole korruptoineet ellei levy ole oikeasti hajonnut jolloin esim SMART on kyllä kertonut että levy on rikki tai sitten levy on vaan totaalisen kuollut. Osa noista tiedostojärjestelmistä on ollut mountattuna vaikka millaisten viritysten kautta, kuten SMB/CIFS, SSHFS, NFS, WebDAV jne joissa tietty on ollut joskus jotain verkko-ongelmia mutta on kyllä saanut noista suoraan jonkinlaisen virheilmoituksen. Vai onko itselläni vaan ollut viimeiset parikymmentä vuotta ihan hiton hyvä tuuri?
Samaa itsekin mietin, jos filut ovat tärkeitä, on niistä joka tapauksessa backupit olemassa. Ei ole korruptoitunut tiedostoja ainakaan 20 vuoteen omalla kohdalla, ongelma oli lähinnä diskettiaikaan ja johtunee puhkikalutuista korpuista ennemminkin, kuin tiedostojärjestelmästä.. :think:
 
Kyllähän toi bit rot on ihan olemassa oleva uhka, mutta kyllä se monen kohdalla menee vaan enempi foliopipo hommiksi kuin ihan oikeaksi ongelmaksi.

Mutta tuosta olen kyllä eri mieltä että jos sulla on bvackupit kunnossa niin ei ongelmaa. Sinähän ET voi tietää että milloin se bit rot iskee, eli voit vaikka tehdä backupin jo mädästä tiedostosta kun taas btrfs taikka jokin muu moderni filesystem olisi kertonut sulle siinä backupin teossa että hei nyt on tiedosto päässyt mädäntymään ja jos sulla oli peilattu taikka joku muu raid pooli käytössä niin se korjattaisiin siinä lennossa.
Single disk btrfs ei pysty kuin varoittamaan lahoamista mutta peilattu/parity tosiaan korjaa itsensä.
 
Jos datan korruptoitumista pelkää niin silloin ei riitä mitkään tiedostojärjestelmät ellei satu olemaan myös ECC muistia joka varmistaa että datassa ei bitit flippaile sinä aikana kun niitä siirrellään tai käsitellään. Edes varmuuskopioidaan. Sille kun on jonkinlainen mahdollisuus jopa täysin ehjällä muistilla.
 
Jos datan korruptoitumista pelkää niin silloin ei riitä mitkään tiedostojärjestelmät ellei satu olemaan myös ECC muistia joka varmistaa että datassa ei bitit flippaile sinä aikana kun niitä siirrellään tai käsitellään. Edes varmuuskopioidaan. Sille kun on jonkinlainen mahdollisuus jopa täysin ehjällä muistilla.
Kyllä se varmuutta esim. säilytyksen aikaista bitrottia vastaan lisää, vaikka jää edelleen teoreettisia mahdollisuuksia että joku bitti menee vinoon jossain muussa tilanteessa jota ei sitten jollain muulla tavalla pystyisi huomaamaan.

Esim. jos kopioi dataa medialta toiselle ja pelkää muistibitin menevän vinoon sinä aikana, Windowsille löytyy esim. Teracopy ja Linuxissa voi käyttää rsync sopivilla optioilla tarkistaakseen että kopioitu tiedosto vastaa täysin alkuperäistä.
 
Kyllähän toi bit rot on ihan olemassa oleva uhka, mutta kyllä se monen kohdalla menee vaan enempi foliopipo hommiksi kuin ihan oikeaksi ongelmaksi.
Riippuu siitä miten tärkeäksi katsoo varmistustensa ehyenä pysymisen. Jos se ei ole tärkeää, sitten ehkä ne varmistuksetkin ovat sinänsä turhia. Varsinkin jos sen integriteettitarkistuksen saisi toimimaan taustalla ilman että joutuu itse jatkuvasti tekemään lisätyötä sen eteen, esim. erillisten checksum-työkalujen avulla.

Mutta tuosta olen kyllä eri mieltä että jos sulla on bvackupit kunnossa niin ei ongelmaa. Sinähän ET voi tietää että milloin se bit rot iskee, eli voit vaikka tehdä backupin jo mädästä tiedostosta
Toki tiedosto voi olla vaikka alusta asti korruptoitunut. Tarkoituksena on kuitenkin tehdä lisävarmistus että jos laitat sen vaikka kahdelle eri USB-levylle kahdeksi vuodeksi kaappiin, miten tarkistat sen kahden vuoden kuluttua että edes jompikumpi niistä on edelleen ok, jos vaikka jälkikäteen tehtävällä checksum-tarkistuksella ne antavat eri tuloksen.

En ajattele niin mustavalkoisesti että jos jää mikään 0.000001% mahdollisuus että siitä huolimatta jokin menee vikaan, kaikki sen eteen tehtävä työ on turhaa. Jos teen vaikka lopputyön ja otan kaksi fyysistä varmistusta kahteen lokaation ja kolmannen vielä pilveen... toki on teoriassa edelleen mahdollista että molemmat fyysiset varmistukset palavat poroksi samanaikaisesti ja pilvipalvelu johon talletit on mennyt konkurssiin ja datasi kadonnut sieltäkin. Oliko useampi varmistus siis alunperinkin täysin turhaa työtä?

Ehkä tavoitteena ei ole saada 100% varmuutta, jos edes 98% varmuus riittää esim. 50% varmuuden sijaan.

Se onko varmistusten bitrot mikään todellinen vai ainoastaan teoreettinen ongelma... en tiedä. Eteeni tulee varmistuksilta silloin tällöin yksittäisiä tiedostoja joiden havaitsen olevan korruptoituneita, tai ainakin epäilen niin. Esim. zip tai rar tiedosto joka ei enää suostukaan purkautumaan, lienee aika selvä juttu että jotain on tapahtunut jossain vaiheessa. Tai jos sama tiedosto on kahdella eri medialla ja tulee kaksi eri checksummaa, siinä arpoo kumpi on mahdollisesti vielä kunnossa vai onko kumpikaan, kun ei ole alkuperäistä checksummaa kummastakaan olemassa.

Mitään vastausta sille ei tuossa vaiheessa enää saa että missä vaiheessa ja miksi tiedosto on vioittunut, eikä sen tietäminen välttämättä mitään auttaisikaan enää siinä vaiheessa. Tärkeintä olisi lisätä jonkinlainen tarkistus että edes tietää onko tiedosto vielä ok, vai ei. Erillisten checksummien teko arkistoinnin yhteydessä on yksi, mutta pidemmän päälle työläs, tapa.

kun taas btrfs taikka jokin muu moderni filesystem olisi kertonut sulle siinä backupin teossa että hei nyt on tiedosto päässyt mädäntymään ja jos sulla oli peilattu taikka joku muu raid pooli käytössä niin se korjattaisiin siinä lennossa.
Kysyin jollain foorumilla (SuperUser varmaan) joskus antaako btrfs mitään lisävarmuutta sille että jos vaikka kopioin tiedoston koneelta ulkoiselle USB-asemalle (molemmilla btrfs käytössä), vastaako kopioitu tiedosto bitilleen alkuperäistä. Silloin sain ainakin käsityksen ettei esim. btrfs ota tuohon mitään kantaa tai tuo mitään lisäturvaa, btrfs on kiinnostunut vain siitä ettei sen omassa lokaalissa tiedostosysteemissä tapahdu ikäviä.

En tiedä onko teoriassa kuinka mahdollista että kopiointi menee vikaan (joku virhe USB:ssa, tai sitten aiemmin mainittu muistivirhe juuri kopioinnin aikana?), mutta tätä vastaan kai on sitten omat keinonsa, kuten Windowsissa TeraCopy joka ajaa automaattisesti checksum-tarkistukset alkuperäisen ja kopioidun tiedoston välillä, tai Linuxissa rsync sopivilla optioilla (saattoi olla että rsyncin joutui ajamaan kahteen kertaan jotta sai täyden varmuuden tuolle, eli toisella kopiointikerralla käskee rsyncciä ylikirjoittamaan vain ne tiedostot joiden checksum ei vastaa alkuperäistä, siinä yhteydessä ne kaikki tulee tarkistettua).

Single disk btrfs ei pysty kuin varoittamaan lahoamista mutta peilattu/parity tosiaan korjaa itsensä.
Juu, mutta single disk btrfs auttaa kuitenkin jos haluaa tietää onko ulkoisella varmistuksella oleva tiedosto edelleen ehjä, jotta sen voi esim. korvata toisella varmistuksella olevalla tiedostolla (melko epätodennäköistä että molemmat toisistaan erillään olevat tiedostot olisivat vioittuneet suunnilleen samoihin aikoihin).

Lisäksi mirroroinnit ja parityt eivät suoraan auta siihen jos teet inhimillisen virheen ja rikot tai tuhoat tiedoston itse, silloin helpointa on että sinulla on se sama tiedosto toisaalla ja voit korvata rikkoutuneen sillä. Mirroroinnit ja parityt ovat ehkä enemmän live-käyttöä varten, eivät kaapissa vuosikausia pidettäviä arkistoja varten.
 
Onko tuo tiedostojen korruptoituminen oikeasti joku ongelma? Mietin vaan kun itselläni on ollut kaikenlaisia fat12/fat16/vfat/ext2/ext4/zfs ja ties mitä tiedostojärjestelmiä käytössä vuosien varrella ties millaisilla levyillä eikä tiedostot ole korruptoineet
Mistä tiedät etteivät ole korruptoituneet? Oletko käynyt jokaisen tiedoston läpi ja todennut jollain tapaa että vastaa bitilleen alkuperäistä? Luotat vain siihen että jos saat tiedoston jollain tapaa auki Notepadissa etkä ensivilkaisulla huomaa siinä mitään erikoista, sen täytyy olla täysin kunnossa?

Tuo on juuri se yksi perusongelma, miten edes huomata tai todistaa että arkistot ovat edelleen kunnossa. Normaalisti sitä varten käytetään checksummia, mutta niiden pykääminen ja tarkistelu käsin, varsinkin jos arkiston sisältö muuttuu silloin tällöin, voi olla erittäin vaivalloista, aikaavievää ja jopa mahdotonta.

Kompressoiduissa tiedostoissa tuon varmuuden saaminen on helpompaa, jos zip tai rar tai 7z purkautuu virheettömästi, siitä voinee päätellä että on se edelleen ok. Kompressoimattomissa tiedostoissa varmuuden saaminen voi olla vaikeampaa tai mahdotonta.

Kyllä, minulla on tullut eteeni vanhoilta kiintolevyiltä kopioituja tiedostoja jotka joko ovat olleet selvästi korruptoituneita, tai olen epäillyt niin mutta en ole voinut saada täyttä varmuutta onko näin todella, tai onko tiedosto ollut alunperinkin korruptoitunut kun se kyseiselle kiintolevylle päätyi.

EDIT: Eikä edes vanhoilta levyltä. Puolisen vuotta sitten minulla oli episodi missä 18TB USB-arkistointilevyyni tuli jonkin sortin tiedostojärjestelmävika, joten kopioin kaikki datat muille levyille, formatoin 18TB uusiksi ja datat takaisin. Jälkitarkistuksissa havaitsin checksum-tarkistuksilla että joitakin korruptoituneita tiedostoja oli, en osaa sanoa olivatko vioittuneet tuon episodin aikana vai olleet jo sitä ennen korruptoituneita, ja missä vaiheessa tarkaalleen olivat korruptoituneet. Se ja sama, tärkeintä minulle oli saada jotenkin varmuus että ko. tiedostot ovat viallisia joten pystyin korvaamaan ne korruptoitumattomilla.

Päällisinhän puolin olisin tuossakin tilanteessa voinut väittää että kaikki ok enkä ole havainnut mitään tiedostojen korruptoitumisia. Vasta jälkikäteen suoritettu tarkistus kaikille tiedostoille paljasti totuuden.

Jos taas ei koe tärkeäksi jos joku tiedosto silloin tällöin mahdollisesti korruptoituu, sellaisiahan tiedostoja lienee turha edes varmuuskopioida. Eivät ole tärkeitä.
 
Viimeksi muokattu:
Samaa itsekin mietin, jos filut ovat tärkeitä, on niistä joka tapauksessa backupit olemassa. Ei ole korruptoitunut tiedostoja ainakaan 20 vuoteen omalla kohdalla, ongelma oli lähinnä diskettiaikaan ja johtunee puhkikalutuista korpuista ennemminkin, kuin tiedostojärjestelmästä.. :think:
Entä jos juuri backupissa oleva tärkeä tiedosto on korruptoitunut sen muutaman vuoden aikana kun se on siellä majaillut virrattomana? HDD-levyt ovat magneettisia ja kyllä niillä olevat bitit ihan vain ajan kanssa voivat mennä ja menevätkin vinoon.

Mistä edes tiedät onko varmistuksilla, tai edes aktiivikäytössä olevassa tiedostosysteemissäsi, oleva tiedosto kunnossa? Avaatko ja testaatko jokaisen tiedoston erikseen?
 
Mistä tiedät etteivät ole korruptoituneet? Oletko käynyt jokaisen tiedoston läpi ja todennut jollain tapaa että vastaa bitilleen alkuperäistä? Luotat vain siihen että jos saat tiedoston jollain tapaa auki Notepadissa etkä ensivilkaisulla huomaa siinä mitään erikoista, sen täytyy olla täysin kunnossa?

Tuo on juuri se yksi perusongelma, miten edes huomata tai todistaa että arkistot ovat edelleen kunnossa. Normaalisti sitä varten käytetään checksummia, mutta niiden pykääminen ja tarkistelu käsin, varsinkin jos arkiston sisältö muuttuu silloin tällöin, voi olla erittäin vaivalloista, aikaavievää ja jopa mahdotonta.

Kompressoiduissa tiedostoissa tuon varmuuden saaminen on helpompaa, jos zip tai rar tai 7z purkautuu virheettömästi, siitä voinee päätellä että on se edelleen ok. Kompressoimattomissa tiedostoissa varmuuden saaminen voi olla vaikeampaa tai mahdotonta.
Jos levy on salattu, niin silloin yhden bitin kääntyminen tallennusmediassa kaiken järjen mukaan aiheuttaa dekryptatussa datassa isomman kuin yhden bitin suuruisen virheen. Eli tavallaan salaus lisännee korruptoitumisen havaittavuutta.
 

Statistiikka

Viestiketjuista
301 742
Viestejä
5 136 477
Jäsenet
82 037
Uusin jäsen
Nikkiv04

Hinta.fi

Back
Ylös Bottom