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?
Linux-kysymyksiä & yleistä keskustelua Linuxista
Alensia
Custom-titteli
- Liittynyt
- 17.10.2016
- Viestejä
- 4 096
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ä..
- Liittynyt
- 21.06.2017
- Viestejä
- 7 378
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ä.
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ä.
- Liittynyt
- 17.10.2016
- Viestejä
- 1 380
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ä.
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.
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.
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).
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.
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:
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.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ä..
Mistä edes tiedät onko varmistuksilla, tai edes aktiivikäytössä olevassa tiedostosysteemissäsi, oleva tiedosto kunnossa? Avaatko ja testaatko jokaisen tiedoston erikseen?
- Liittynyt
- 14.10.2017
- Viestejä
- 799
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.
Luulisin että aika monella jolla on 18TB arkistoja niin ne on sellaisia joista ei yhdellä tiedostolla ole mitään merkitystä mutta se onko niitä fileksiä arkistossa 17TB vai 0TB on iso merkitys ja silloin yhden fileksen korruptoituminen ole mikään ongelma vaan peikko on että kaikki menee kerralla puuf. Siksi jonkinlainen backup tai vaikka 2 on hyvä mutta esim koko levyn salakirjoittaminen ei ole.
Siitäkään 18TB alkuperäisestä määrästä ei koskaan lueta oikeaan käyttöön puoliakaan vaan hoardataan lisää ja ensi vuonna sitä arkistokamaa on 32TB.
Siitäkään 18TB alkuperäisestä määrästä ei koskaan lueta oikeaan käyttöön puoliakaan vaan hoardataan lisää ja ensi vuonna sitä arkistokamaa on 32TB.
Viimeksi muokattu:
Suurin osa tuolla levyllä olevasta datasta ei ole niin tärkeää etten voisi sitä menettää, ainakaan tässä vaiheessa. Se kun olisi ladattavissa uudestaan netistä ainakin toistaiseksi, veisi vaan päiviä ellei viikkoja ladata se kaikki uudestaan. Siksi kopioin ko. datat toisille levyille ennen levyn formatointa, jotta säästyisi aikaa. Ja kyllä se on rahanarvoista tavaraa, olen maksanut vuosien aikana niistä n. 16000 euroa.
Toki ymmärrän että monille "data" ei tarkoita nykypäivänä muuta kuin someen otettuja selfieitä tms., olen samaa mieltä että ehkä ne voi hyvinkin kaikki menettää sitten kun Whatsapp tai Facebook tai Tiktok sulkee palvelunsa, data on katoavaista ja tuskin itseäkään kiinnostaa vanha kuva millaisen pizzan söi Tampereella 1.5.2022. (en itse harrasta itsestäni kuvien ottamista kännykälläni jatkuvalla syötöllä ja niiden julkaisemista nettiin, se ei tuo elämääni mitään sisältöä).
Toisaalta, jos mietin säästämiäni digitaalisia videoita häistäni tai lapsieni elämän alkutaipaleesta, ne haluan tunnesyistä säilyttää useana kopiona ja korruptoitumattomina, ja lapseni ovat ilmaisseet samaa tahtoa. Veikkaan että katsovat niitä vielä 60 vuoden kuluttua, mahdollisesti myös heidän omat lapsensa haluavat nähdä ja ehkä jopa säilyttää niitä. Minusta ainakin olisi ollut kiehtovaa nähdä videoita esim. oman isäni ja äitini lapsuudesta.
Sinänsä keskustelu siitä onko minulla toisten mielestä lupa tai järkevää arkistoida haluamaani dataa ei ole tässä keskustelussa oleellista, vaan se millä eri tavoin datansa eheyttä voi ylläpitää ja tarkistaa mahdollisimman pienellä vaivalla.
Viimeksi muokattu:
- Liittynyt
- 10.03.2017
- Viestejä
- 1 337
Ei Gnomeen liittyvää, mutta tuoreimmat Proton GE 10:t (ja Proton-CachyOS) tukee nyt Waylandia Steamissa (Wine-Wayland vs. normaalisti XWayland), kun pistää launchiin pari uutta parametria. HDR-tuki tuli samalla.
PROTON_ENABLE_WAYLAND=1 PROTON_ENABLE_HDR=1 %command%
Itsellä tuli Warframeen ihme hiirihäröä (katos hiiri pariksi sekunniksi haxatessa) ton kanssa, joten pistin takas pois päältä. Muuten pyöri ok sen kanssa.
Itse pyöritellyt Nobara+KDE-comboa Waylandilla nyt varmaan 6kk+, kun sain ainoan oikuttelevan softan vaihdettua, eli Synergy/InputLeap vaihtui Deskflowiin.
- Liittynyt
- 08.12.2017
- Viestejä
- 1 764
Toki kirjoituksen jälkeen voidaan lukea ja toistaa kirjoitus tarvittaessa. Todennäköisyys sille että kirjoitus ja luku epäonnistuvat samalla tavalla on aika pieni. DDR5:ssä on jo sisäänrakennettuna yhden bitin suojaus, ns. built-in data checking.
Ainakin jos valokuvaa ja käyttää usb-laitteita johdolla niin fat-kopioiden epäsynkka on melkoisen yleistä. Minulla myös on pari kertaa kamera korruptoinut muistikortin kun akku loppunut kuvaa kirjoittaessa. Vaikka kortin saa koneella auki, niin kamera on ilmoittanut että korruptoitunut kortti, joka pitää formatoida tyhjäksi. Näissähän on sekin, että ei joku Windows tai Mac ala selittämään käyttäjälle jostain matalan tason anomaliasta vaan aika binäärisesti joko korjataan automaattisesti ilman että sanotaan mitään tai kieltäytydään avaamasta edes levyä/tiedostoa.
Journaloivilla systeemeillä näkee sitä että jos kone tilttaa niin seuraavassa bootissa kelataan journalia auki. Tietenkin jos siinä on joku graafinen goatse näkyvissä, niin ei tuollaisia "pelottavia" ilmoituksia näytetä käyttäjälle.
Ei verkkolevyjärjestelmä käytä suoraan sitä levyä. Tai iSCSI ja NBD ovat ehkä lähinnä. Noissa muissa on ihan erillään verkkolevyjärjestelmän abstraktiot varsinaisesta levyjärjestelmästä.
Läppärille oli entisestään Windows 11 Pro, secureboot ja bitlocker päällä.
Saman levyn toiselle osiolle asensin OpenSUSE Tumbleweed, kiltisti meni paikalleen ja Windows toimii edelleen.
Nyt on pari kertaa tapahtunut että Linuxissa käynnin jälkeen, Windowsiin buutatessa, Bitlocker on ottanut herneet nenäänsä ja vaatii Bitlocker-avainta. Sen kun on jaksanut syöttää, homma jatkuu taas.
Olen yrittänyt googlailla mikä tuon aiheuttaa. Joku jolla samaa ilmeni joko OpenSUSE tai Mint kanssa, väitti että hän joutuu syöttämään bitlocker-avaimen Windowsille aina Linuxissa käynnin jälkeen. Minulla ongelma ei onneksi ole noin paha, minusta vaikuttaisi että BL laukeaa JOS grub2 on jotenkin muuttunut.
Esim. eilen tämä tapahtui kun SUSE:ssa muutin Yast-työkalulla buuttia siten että Windows on se oletusarvoinen joka ladataan, sitä ennen oli SUSE. Tämä muutos triggeröi BL:n, mutta avaimen syötön jälkeen taas toimii ok vaikka buuttailisi edestakaisin.
Jos syynä on tuo grub-muuttuminen:
1. Millaisissa tilanteissa sen voi olettaa muuttuvan? Jos esim. Linuxin kernel päivittyy, silloin myös grub päivitetään ja pitää syöttää taas bitlocker-avain Windowsille? Kuinka usein tuollaisia kernel-muutoksia tai muita grubiin automaattisesti tulevia muutoksia olisi odotettavissa Tumbleweedillä, joka viikko, muutaman kuukauden välein tms.?
2. Jossain ehdotettiin että jos menee Windowsiin, ei mene grub kautta ollenkaan vaan buutin yhteydessä painelee F12 tms. jossa pitäisi tulla valinta mihin buutataan, ja sitä kautta päättää buutataanko suoraan Windowsiin (ilman grubin kautta läpimenoa), vai mennnääkö grubiin (eli Linuxiin).
En vielä saanut testattua mutta pitäisikö tuon toimia? Varmaan laittaisin sitten BIOS/UEFI-asetuksissa että defaulttina mennään suoraan Windowsiin, ja jos haluan buutata Linuxiin, sitten F12-painelua buutissa ja valitsen Linux/grub-buutin, jos siellä sellainen näkyy.
3. Jossain myös mainittiin että olisi ehkä mahdollista lisätä Windowsin buuttivalikkoon mahdollisuus mennä Linuxiin eikä Windowsiin? Tiedän ettei tämä ole Windows-keskustelu, mutta onko kellään tietoa pitäisikö tuollaisenkin olla mahdollista? bcdedit ilmeisesti?
Eihän tuon pitkän bitlocker-avaimen kirjoittamiseen minuuttia kauempaa mene mutta ei sitä mielellään edes viikoittain viitsisi tehdä, varsinkin jos on kiire just silloin päästä Windowsiin kiinni.
Bitlockerin ja/tai Securebootin sammutus eivät ole se oikea ratkaisuehdotus tässä tapauksessa. Läppärillä on aika sensitiivistä kamaa, ydinaseiden laukaisukoodeja yms. jotka eivät saa päätyä venäläisten tai kiinalaisten käsiin. Linux-asennuksenkin ajattelin vielä LUKS-kryptata, jos helposti onnistuu jälkikäteen.
Saman levyn toiselle osiolle asensin OpenSUSE Tumbleweed, kiltisti meni paikalleen ja Windows toimii edelleen.
Nyt on pari kertaa tapahtunut että Linuxissa käynnin jälkeen, Windowsiin buutatessa, Bitlocker on ottanut herneet nenäänsä ja vaatii Bitlocker-avainta. Sen kun on jaksanut syöttää, homma jatkuu taas.
Olen yrittänyt googlailla mikä tuon aiheuttaa. Joku jolla samaa ilmeni joko OpenSUSE tai Mint kanssa, väitti että hän joutuu syöttämään bitlocker-avaimen Windowsille aina Linuxissa käynnin jälkeen. Minulla ongelma ei onneksi ole noin paha, minusta vaikuttaisi että BL laukeaa JOS grub2 on jotenkin muuttunut.
Esim. eilen tämä tapahtui kun SUSE:ssa muutin Yast-työkalulla buuttia siten että Windows on se oletusarvoinen joka ladataan, sitä ennen oli SUSE. Tämä muutos triggeröi BL:n, mutta avaimen syötön jälkeen taas toimii ok vaikka buuttailisi edestakaisin.
Jos syynä on tuo grub-muuttuminen:
1. Millaisissa tilanteissa sen voi olettaa muuttuvan? Jos esim. Linuxin kernel päivittyy, silloin myös grub päivitetään ja pitää syöttää taas bitlocker-avain Windowsille? Kuinka usein tuollaisia kernel-muutoksia tai muita grubiin automaattisesti tulevia muutoksia olisi odotettavissa Tumbleweedillä, joka viikko, muutaman kuukauden välein tms.?
2. Jossain ehdotettiin että jos menee Windowsiin, ei mene grub kautta ollenkaan vaan buutin yhteydessä painelee F12 tms. jossa pitäisi tulla valinta mihin buutataan, ja sitä kautta päättää buutataanko suoraan Windowsiin (ilman grubin kautta läpimenoa), vai mennnääkö grubiin (eli Linuxiin).
En vielä saanut testattua mutta pitäisikö tuon toimia? Varmaan laittaisin sitten BIOS/UEFI-asetuksissa että defaulttina mennään suoraan Windowsiin, ja jos haluan buutata Linuxiin, sitten F12-painelua buutissa ja valitsen Linux/grub-buutin, jos siellä sellainen näkyy.
3. Jossain myös mainittiin että olisi ehkä mahdollista lisätä Windowsin buuttivalikkoon mahdollisuus mennä Linuxiin eikä Windowsiin? Tiedän ettei tämä ole Windows-keskustelu, mutta onko kellään tietoa pitäisikö tuollaisenkin olla mahdollista? bcdedit ilmeisesti?
Eihän tuon pitkän bitlocker-avaimen kirjoittamiseen minuuttia kauempaa mene mutta ei sitä mielellään edes viikoittain viitsisi tehdä, varsinkin jos on kiire just silloin päästä Windowsiin kiinni.
Bitlockerin ja/tai Securebootin sammutus eivät ole se oikea ratkaisuehdotus tässä tapauksessa. Läppärillä on aika sensitiivistä kamaa, ydinaseiden laukaisukoodeja yms. jotka eivät saa päätyä venäläisten tai kiinalaisten käsiin. Linux-asennuksenkin ajattelin vielä LUKS-kryptata, jos helposti onnistuu jälkikäteen.
Viimeksi muokattu:
F12 biosin valinta valitsee sen levyn jolta buutataan ja jos haluaa tällaisen toiminnan niin windows ja linux pitää olla asennettuna eri levyille jolloin toisella levyllä voi olla windowsin natiivi buuttisektori ja grub buuttisektorin pitää olla jollakin toisella levyllä jotta biosista voisi valita kummasta buutataan.
Sinulla kun on molemmat samalla levyllä niin tämän ainoan levyn buuttisektori menee grubiin ja windowssin natiivia buuttisektoria ei ole enää olemassa jonka voisi biosista valita.
Jos käyttö on hyvin paljon Windows painotteista niin sellaistakin vaihtoehtoa voisi harkita että ajaa linuxia virtuaalikoneessa windowssin alla eikä ollenkaan dualboottaa.
Googlailin tätä bcdedit juttua jolla voisi buutata linuxiin windowssin boot managerista ja vaikutti hyvin harvinaiselta jutulta josta näkyi monenlaista mielipidettä toimiiko se vai ei. Saattaa toimia mutta minä en uskaltaisi lähteä tärkeällä työkoneella tällaista kokeilemaan. Näkyi myös ehdotuksia korvata grub rEFInd boot managerilla joka olisi enemmän käyttöjärjestelmäneutraali tapa valita käyttis mikä bootataan mutta tästä minulla ei ole kokemusta.
Viimeksi muokattu:
Itseasiassa ei tunnu olevan noin. Tarkistin BIOS/UEFI asetuksista ja siellä on (enemmän kuin) kaksi erillistä buuttivalintaa tässä prioriteettijärjestyksessä:
1. opensuse-secureboot
2. Windows Boot Manager
Noiden jälkeen oli vielä ehkä jotain verkkobuutteja yms. jotka eivät liity tähän.
Testasin painelemalla F12 buutin aikana ja se antoi valita kummalta noista kahdesta buutataan. Valitsin Windows Boot Manager jolloin se tosiaan meni samantien Windowsiin kulkematta grub-ruudun kautta.
Näissä toki pitää olla tarkkana kun testailee ja että se bitlocker-avain on saatavilla. Tälläkin kertaa Windows päätti että jotain on taas muuttunut (kuten olikin koska valitsin tuollaisen epätavallisen tavan buutata Windows) ja vaati taas BL avainta. Ja sen jälkeen vaikka buuttasi Windowsiin, admin-käyttäjälle asetettu PIN-koodi ei myöskään enää kelvannut, ei kuulemma ollut enää saatavilla. Sain sen onneksi resetoitua, käytössä MFA joten kysyi puhelimen autentikaattorissa MFA koodia ja antoi sen jälkeen asettaa uuden eli saman PIN-koodin.
Pitänee asettaa Windows Boot Manager ykköseksi UEFI-asetuksissa ja testailla ettei se ala kysellä BL-avainta enää vaikka välillä buuttaisi Linuxiin ja välillä Windowsiin. Ja varmistaa ettei epähuomiossa buuttaa enää grubista Windowsiin, varmasti BL sekoaisi silloinkin uudestaan, voi sen Windows-option kai grubista poistaakin.
Haluan ajaa Linuxia rautaa vasten, enkä halua asennella Windowsiin ainakaan mitään ylimääräisiä hypervisoreita. Pidän sen mahdollisimman askeettisena, taustakuvakin pois ja spartalainen harmaanvihreä tausta tilalle. Joskus vuosia sitten ajoin testi-Linuxia työläppärin VirtualBoxilla, omia testailuja missä kokeilin eri Linux-distroja ja myös FreeBSD mielenkiinnosta, ei liittynyt ainakaan suoraan työhön. Oracle tuli linjaa pitkin että alas poika maksaa VirtualBoxin käytöstä. Pois lähti ja pysyy poissa.
Joo en lähde tuohon, jostain ohjeista sain kuvan että enää tuo ei onnistuisi, Microsoft on ilmeisesti estänyt muiden kuin Windowsien buuttaamisen boot manageristaan. Joskus aiemmin on ilmeisesti toiminut Linuxin tai MS-DOSin lisääminen siihen.
Jos tuo F12 painelu buutissa toimii ja valitsee Linuxin jos sinne haluaa eikä Bitlocker/Windowsin PIN enää triggeröidy missään tilanteissa, se on minulle paras vaihtoehto koska sillä buuttikaan ei mainosta että rinnakkain on useampia asennettuja käyttöjärjestelmiä. Antaa Linukan olla uteliailta silmiltä piilossa, toki näkyy Windowsin Diskmanagementissä joku outo partitio joka ei ole Windowsin käytössä mutta elämä on.
Viimeksi muokattu:
- Liittynyt
- 17.10.2016
- Viestejä
- 1 380
Ei nyt sentäs enää armon vuonna 2025 kun UEFI on ollut vakiokauraa jo toista kymmentä vuotta toistella enää vanhoja BIOSin ja MBR levyjen aikaisia meemejä.
Ei niissä mitään boottisektoreita ole enää. Levyillä on ESP-partitiot joille voi käyttöjärjestelmät (ja käyttäjät) laittaa tarpeidensa mukaan ajettavia EFI-binaareja, jotka voivat olla bootloadereita (bootmgr, systemd-boot etc), työkaluja (memtest86 tms), käyttöjärjestelmän kerneleitä (linux EFISTUBilla) tai paska minikäyttöjärjestelmä jota antiikin aikoina käytettiin boottaamaan oikeita käyttöjärjestelmiä (Grub).
Mitään Grubin kaltaisia kötöstyksiä ei UEFIn kanssa tarvita, riittää kun käyttöjärjestelmä osaa sinne ESP:lle sijoittaa oman bootloaderin tai kernelin ja kirjoittaa EFI:n nvramille tiedon siitä. Windows tämän osaa, systemd-boot osaa myös mutta jostakin syystä monet distrot ovat edelleen naimisissa Grubin kanssa ja tunkevat sitä oletuksena. Mutta esim. Fedora on tukenut sitä jo useamman version ajan, joutuu vaan itse laittamaan käyttöön. Sen jälkeen se kyllä toimii omalla painollaan, päivittelee kernelit ja tarvittaessa systemd-bootin ESP:lle ym.
Tuo yllä mainittu F12n takaa löytyvä valikko on juuri se UEFIn boottivalikko mistä voi valita mitä sieltä ESP:ltä ajellaan, ja Grubin sijaan voisi hyvin bootata suoraan OpenSUSEn jos se ei olisi jumissa menneisyydessä. Mutta vaikka se dinosaurus siellä vielä mönkiikin niin kyllähän tuo toimii ongelmitta.
Pienoisena riskinä on että Windows joskus päättää että ESP tai EFIn nvram on korruptoitunut, ja saattaa "korjata" sen kirjottamalla sinne omat törkynsä uudestaan ja samalla poistaa nvramilta viittaukset kaikkeen muuhun. Sen jälkeen ne Linux-kamatkin saattavat vielä löytyä osiolta mutta valikossa ei näy, pitäisi päästä UEFI shelliin ja sieltä käynnistää käsin. Ja näin voi käydä vaikka olisi täysin erilliset levyt Windowsille ja Linuxille, ja molemmilla levyillä omat ESPinsä.
Ja itseasiassa bcdeditillä manipuloidaan bootmgrin lisäksi myös ESPiä ja EFImuuttujia, toki Microsoftin tyyliin. Linuxin puolelta vastaavaa pystyy tekemään esim. efibootmgr:lla.
Ei niissä mitään boottisektoreita ole enää. Levyillä on ESP-partitiot joille voi käyttöjärjestelmät (ja käyttäjät) laittaa tarpeidensa mukaan ajettavia EFI-binaareja, jotka voivat olla bootloadereita (bootmgr, systemd-boot etc), työkaluja (memtest86 tms), käyttöjärjestelmän kerneleitä (linux EFISTUBilla) tai paska minikäyttöjärjestelmä jota antiikin aikoina käytettiin boottaamaan oikeita käyttöjärjestelmiä (Grub).
Mitään Grubin kaltaisia kötöstyksiä ei UEFIn kanssa tarvita, riittää kun käyttöjärjestelmä osaa sinne ESP:lle sijoittaa oman bootloaderin tai kernelin ja kirjoittaa EFI:n nvramille tiedon siitä. Windows tämän osaa, systemd-boot osaa myös mutta jostakin syystä monet distrot ovat edelleen naimisissa Grubin kanssa ja tunkevat sitä oletuksena. Mutta esim. Fedora on tukenut sitä jo useamman version ajan, joutuu vaan itse laittamaan käyttöön. Sen jälkeen se kyllä toimii omalla painollaan, päivittelee kernelit ja tarvittaessa systemd-bootin ESP:lle ym.
Tuo yllä mainittu F12n takaa löytyvä valikko on juuri se UEFIn boottivalikko mistä voi valita mitä sieltä ESP:ltä ajellaan, ja Grubin sijaan voisi hyvin bootata suoraan OpenSUSEn jos se ei olisi jumissa menneisyydessä. Mutta vaikka se dinosaurus siellä vielä mönkiikin niin kyllähän tuo toimii ongelmitta.
Pienoisena riskinä on että Windows joskus päättää että ESP tai EFIn nvram on korruptoitunut, ja saattaa "korjata" sen kirjottamalla sinne omat törkynsä uudestaan ja samalla poistaa nvramilta viittaukset kaikkeen muuhun. Sen jälkeen ne Linux-kamatkin saattavat vielä löytyä osiolta mutta valikossa ei näy, pitäisi päästä UEFI shelliin ja sieltä käynnistää käsin. Ja näin voi käydä vaikka olisi täysin erilliset levyt Windowsille ja Linuxille, ja molemmilla levyillä omat ESPinsä.
Ja itseasiassa bcdeditillä manipuloidaan bootmgrin lisäksi myös ESPiä ja EFImuuttujia, toki Microsoftin tyyliin. Linuxin puolelta vastaavaa pystyy tekemään esim. efibootmgr:lla.
- Liittynyt
- 21.01.2017
- Viestejä
- 253
Toi on niin legacy. BIOS osasi ladata (suorittaa) ainoastaan levyn sektorissa 0 olevaa koodia, joka latasi loput bootloadersita muualta. Siitä "yksi bootloader per levy".
EFI etsii EFI System Partition (ESP) FAT-osion ja lataa bootloaderin sieltä. Tosin ESP:ääkään ei kannata olla enempää kuin yksi per levy, mutta jokainen OS-toimittaja voi tehdä sinne oman alihakemiston, jonne tunkee bootloaderinsa (tai jonkun muun *.efi -binäärin). Emon flashille saa tallennetua polun tiedostoon, joten "F12" (näppäin riippuu EFI-versiosta -- Asrock:lla on "F11") näyttää vaihtoehdot.
`efibootmgr -v` näyttänee, jos Linux on käynnistynyt EFI-moodilla.
Windows ei näytä ESP:tä. Linux mountannee sen, esim. /boot/efi alle.
En ole varma onko se grub mutta sellainen graafinen valikko siihen tulee mikä buutti valitaan, ja mielestäni ehkä näin jossain vilahtavan sanan "grub2". En muokannut mitään grubin configgia suoraan vaan käytin Yast-työkalua OpenSUSE:ssa.
Sinänsä Windowsin viereen asennus sujui erityisen helposti, vaikka oli SecureBootit ja bitlockerit Windowsin puolella käytössä, asiat jotka monille Linux-distroille ovat liikaa ja niissä neuvotaan vain laittamaan ne pois päältä vaikka ei millään haluaisi. Asennuksen aikana ei erityisemmin tarjottu vaihtoehtoja mitäs käytetään bootissa yms. jne., en tiedä minkä expert moden taakse olisi pitänyt kurkata. Menin aika defaulttina ja hienosti asentui levyllä vielä vapaana olevalle partitioimattomalle osiolle, oli se sitten grubilla tai millä.
Ainoa mikä hieman harmittaa, miksi tämäkin väkipakolla väkää jotain erillistä swap-partitiota. Pitäisin swapin mieluummin tiedostona, paljon helpompi siirrellä tai muokata kokoa. No voi sen jälkikäteenkin korjata jos jaksaa... En jaksanut asennuksen aikana säädellä yrittäen poistaa swap-partitio mutta jättäen kaikki muut samoiksi.
En tiedä onko OpenSUSE Tumbleweed menneisyyteen jämähtänyt distro, käsitin että rolling release distrona kaikki pitäisi olla viimeisintä shiittiä, tiedostojärjestelmäksikin tarjoaa oletusarvoisesti btrfs eikä mitään isoisäni aikaista ext4 tai xfs-käpylehmää.
Toivotaan ettei Windows päätä paskoa buuttia jossain vaiheessa. Kovin ikävää jos se niin tekisi, voisi pistää vihaksi. Uskaltaneeko SUSE:n levyjä sitten edes kryptata jotta saisi niiltä varmasti datat ulos jälkikäteen jos Windows salamurhaa Linuxin sen nukkuessa.
Hyvältä näyttää toistaiseksi. Olen nyt buuttaillut sekä Windowsiin että Linuxiin (Linuxiin painamalla F12 buutin aikana ja siitä valitsee OpenSUSE:n; jos ei tee mitään niin menee suoraan Windowsiin), ei ole Bitlocker tai Windows ainakaan vielä pillastunut.
OpenSUSE:n Yast-administrointityäkalusta löytyy kyllä mahdollisuus vaihtaa boot loader:
GRUB2 for EFI (nyt käytössä)
GRUB2
GRUB2 with BLS
Systemd Boot
Not Managed
Ei hajuakaan mikä noista olisi minulle sopivin tässä tilanteessa, mutta ei viitsi vaihdella jos taas rikkoo jotain. Nykyinen tuntuu toimivan tarkoituksiini ja hyvä näin.
Seuraava projekti on katsoa saisiko LUKS-kryptauksen koko Linuxille päälle. Olisin toivonut että olisi saanut jo asennusvaiheessa mutta en äkkiseltään nähnyt asennuksessa sille optiota. Saas nähdä saanko systeemin sillä rikki, no toivottavasti ei ainakaan Windowsin puolelle vaikuta.
OpenSUSE:n Yast-administrointityäkalusta löytyy kyllä mahdollisuus vaihtaa boot loader:
GRUB2 for EFI (nyt käytössä)
GRUB2
GRUB2 with BLS
Systemd Boot
Not Managed
Ei hajuakaan mikä noista olisi minulle sopivin tässä tilanteessa, mutta ei viitsi vaihdella jos taas rikkoo jotain. Nykyinen tuntuu toimivan tarkoituksiini ja hyvä näin.
Seuraava projekti on katsoa saisiko LUKS-kryptauksen koko Linuxille päälle. Olisin toivonut että olisi saanut jo asennusvaiheessa mutta en äkkiseltään nähnyt asennuksessa sille optiota. Saas nähdä saanko systeemin sillä rikki, no toivottavasti ei ainakaan Windowsin puolelle vaikuta.
- Liittynyt
- 17.10.2016
- Viestejä
- 1 380
Yleisestiottaen jos ei tiedä tarvitsevansa Grubia, niin varsin suurella todennäköisyydellä ei tarvitse. Systemd-boot riittää kaikkiin tavanomaisiin käyttötapauksiin. Mutta jos harrastaa SERriä, tai muuten vaan haluaa tehdä asioita vaikeasti niin sitten voi joutua purkkaamaan Grubia ynnä muuta mukavaa.
Asia erikseen onko sen vaihtamisesta tässä vaiheessa isompaa iloa kun bootin suoraviivaistaminen.
Ei sillä kyllä käyttäjälle ole juurikaan mitään merkitystä, että onko siellä se grub vai systemd-boot käytössä. Säätämisen ilo on oikeastaan ainoa syy vaihtaa suuntaan tai toiseen. Distron ylläpidettävyyshän tuossa on isompi juttu. Vapautuu ylläpitäjiltä aikaa muihin hommiin, kun grubin voi päästää eläkkeelle.
Kyllä varmaankin jokaisen distron asennustyökalu tuota tarjoaa. Yleensä se on rasti ruutuun -tyyppinen valinta osioinnin yhteydessä. Ja se kannattaa kyllä siinä asennuksen aikana laittaa päälle. Jälkikäteen se on hankalaa ja riskialtista (jos ei sitten ihan viimeaikoina ole tullut jotain näppärää työkalua joka hoitaa homman).
- Liittynyt
- 10.03.2017
- Viestejä
- 1 337
"Consistent with AMD’s commitment to Open Source software, we will be making the following changes
to the composition of the Radeon Software for Linux releases, starting with 25.20: The Mesa Vulkan driver
will be officially supported, along with Mesa OpenGL and Multimedia support.
The AMD proprietary OpenGL and Vulkan drivers will no longer be included in the release."
LUKS oli jossain Rocky Linux 9 asennuksessa rasti ruutuun, mutta jostain syystä ei osunut silmään OpenSUSE-asennuksessa vaikka mielestäni näin aiemmin keskustelua että pitäisi olla mahdollista LUKS-kryptata koko tiedostosysteemi OpenSUSE asennuksessa. Oletan että btrfs käyttö tiedostojärjestelmänä ei vaikuta tuohon...?
Sama tuon grub/systemd boot-valinnan kanssa. Ei se mielestäni missään kohtaa kysellyt mitäs laitetaan mutta toisaalta en mennyt kovin syvälle expert-moodiin vaan koitin mennä sillä mitä asennusohjelma tarjoaa. Ajattelin että kyllä se tietää paremmin miten kannattaa asentaa, vaikka jo ajattelin että erillisen swap-partition olisi voinut kyllä jättää tekemättä.
Jostain syystä OpenSUSE TW sitä tarjosi oletusarvoisesti, ei edes kysynyt mitä laitetaan. No näillä mennään ellen päätä koittaa vielä uudelleenasennusta.
- Liittynyt
- 08.12.2017
- Viestejä
- 1 764
Serrin kanssa voi käyttää syslinuxiakin. Minusta grub 2.x ei selkeytä mitään ikinä.
- Liittynyt
- 08.12.2017
- Viestejä
- 1 764
Jos on vähänkään nykyaikainen kone eikä muistin tarve ole kriittinen jossain työssä, niin zram on vaihtoehto swap-osiolle. Olen kuullut monenlaisista säädöistä, mutta oletuksena moni laittaa 50% muistista zramiksi ja lz4 pakkaa noin 2x. Eli esim. 16 gigan muistista saa 8 + 2 x 8 = 24 gb käyttöön. Ei tarvi swap-osiota.
Ehkä sitten, oli jonkun polun takana jota en tullut tarkistaneeksi, liekö sitten Guided installation vai expert mode vai mikä lie.
Ensin kyllä menin johonkin expert-modeen koska halusin swap-osion pois (ja olisin tehnyt itse swap-tiedoston) mutta en siihen hätään keksinyt miten olisin päässyt muuttelemaan aluksi ehdotettua levykonfiguraatiota josta olisin vain ottanut swap-osion pois, mutta joko päädyin ruutuun missä minun olisi itse pitänyt päättää kaikki osiot itse tyhjältä pöydältä (/boot ja /boot/efi ja mitä lie, ei jaksa miettiä ja muistaa), tai sitten se jossain vaiheessa ehdotti että poistetaan levyltä kaikki Windows-partitiota myöten jolloin päätin että joo mennään mieluummin default-asennuksella, joka asensikin itsensä kiltisti Windowsin rinnalle käyttäen kaiken vapaana olevan partitioimattoman tilan, kuten halusinkin.
Voisihan tuota kokeilla vielä uusiksi, jos nykysen Linux-asennuksesta pois päästäkseni riittää että tuhoan kaikki Linuxin tekemät osiot ja poistan opensuse-option UEFI boot optioista. Ei ehkä enää ole yhtä vaikeaa kuin MBR-aikoina kun piti buuttailla Windows-asennuslevyllä ja ajaa joku fixmbr että pääsi grub-valikosta eroon jne...
32GB on RAM jonka luulisin riittävän. Ainoa syy miksi swap-tiedoston sinne edelleen tekisin on että muistan lukeneeni ettei swapin poistaminen kokonaan ole hyvä idea, vaikka omasta mielestä fyysistä RAMia olisi enemmän kuin tarpeeksi. Kai Linuxikin tai sen ohjelmat sitten odottavat aina että edes joku pieni 2GB swap siellä on, vaikka muistia olisi tuhat gigaa.
Tekoaälykin äsken luetteli useita syitä miksi swapin poisto Linuxissa ei ole hyvä idea, vaikka muistia olisikin paljon.
Niin en tiedä tai muista mitä zram on, pitää kai googletella. Kuvauksestasi päättelen sen olevan swap... fyysisessä RAM-muistissa?
Ilmeisesti juuri näin, kompressoitu blokki muistissa swappia varten. Menee vähän kikkailuksi kun swapia käytän vain koska ilmeisesti se on hyvien käytöstapojen mukaista.
Viimeksi muokattu:
Varmasti riippuen mitä koneella tekee mutta ite oon jättäny pois swapin jo sillon ku oli 16GB muistia ja nyt on 32GB ja swappi edelleen poissa eikä ikinä ole ongelmia ollut.
Mulla on 16G muistia ilman swappia, kun muisti loppuu kone ensin hidastuu sitten tilttaa jos ei kerkeä vapauttamaan lisää. En tiedä auttaisiko swap?
Muistin loppumisen syy kaksi selainta ja ikkunoita öö..... aika monta
Uutiset
-
Motorola julkaisi edullisemman pään moto g86- ja g56 -älypuhelimensa
30.5.2025 15:30
-
AMD julkaisi AMD Software 25.5.2 -ajurit näytönohjaimilleen ja prosessoreilleen
30.5.2025 14:55
-
DeepCoolin Computex-uutuuksiin kuului coolereita ja kaksi koteloa integroidulla nestejäähdytyksellä
30.5.2025 14:25
-
Live: io-techin Tekniikkapodcast (21-22/2025)
30.5.2025 14:20
-
Uusi artikkeli: Testissä NVIDIA GeForce RTX 5060
29.5.2025 19:20
