Onko Ubuntun kaatuminen harvinaista?

[Stazzy]

Tämä HP pavilion -vanhus, 7-vee ja jotain, jumiutuu tasaisin väliajoin kokonaan, kaatua ei ole tainnut varsinaisesti kuin pari kertaa. 10.04 oli liikaa, olisi pitänyt olla päivittämättä, tuntuu olevan liian raskas.

[Hajakenttä]

@Hajakenttä:

(EDIT: Hajakenttä: boot.log näyttää tältä:)
============
fsck kohteesta util-linux-ng 2.17.2
/dev/sda1: puhdas, 125961/246512 tiedostoa, 657942/984576 lohkoa
fsck kohteesta util-linux-ng 2.17.2
/dev/sdb5: Superblock last mount time (Sat Oct  9 10:36:12 2010,
    now = Tue Jan  1 02:02:12 2002) is in the future.


/dev/sdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
    (i.e., without -a or -p options)
mountall: fsck /home [380] päättyi tilakoodilla 4
mountall: Tiedostojärjestelmässä on virheitä: /home
Jätetään virheet huomiotta (/home) käyttäjän pyynnöstä
 * Starting AppArmor profiles        Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox

[ OK ]
=========================
(EDIT: Hajakenttä: Yritin ensin katsoa virheitä annetulla vaihtoehdolla f, mutta se ei johtanut mihinkään tulokseen, joten valitsin vaihtoehdon i = jätetään huomiotta, jolloin Ubuntu käynnistyi normaalisti.)

Ajoitko koskaan fsck:ta uudelleen?

/dev/sdb5: Superblock last mount time (Sat Oct  9 10:36:12 2010,
    now = Tue Jan  1 02:02:12 2002) is in the future.

Koneen kello on tainnut nollaantua. Tämä on ilmeisesti johtanut ongelmiin levyn tarkistuksessa.

Minulla aikoinaan tuli vastaava kellon nollautuminen ,joka korjaantui fsck:lla, oletan, että väärä päiväys ja kellonaika ei ole ongelman perussyy vaan:

mountall: Tiedostojärjestelmässä on virheitä: /home

tilakoodi 4 tarkoittaa, että virheet on jätetty korjaamatta (käyttäjän pyynnöstä, kuten kerroit)
dev/sdb5 pitäisi tarkastaa ja korjata virheet tiedostojärjestelmässä. Olettaisin, että -fy-optiolla korjaantuisi. Katso ohje: http://linux.fi/wiki/Fsck

Luin nuo läksyt ja ajoin sitten tuon pitemmän -fyc kaavan mukaan testin. Luullakseni se korjaa myös sen minkä voi samalla tavalla kuin -fy. Tikun kautta siirsin tänne sen päätteen näkymät. Se oli nimittäin ajattava asennus-sd-kortilla kun ei saanut umountattua /dev/sdb5, joka on "kiireinen".

Koodia: [Valitse]

ubuntu@ubuntu:~$ sudo fsck.ext4 -fyc /dev/sdb5
e2fsck 1.41.11 (14-Mar-2010)
Checking for bad blocks (read-only test): done                               
/dev/sdb5: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sdb5: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb5: 2204/972944 files (1.4% non-contiguous), 178000/3890944 blocks
ubuntu@ubuntu:~$
Mitähän tuo meinaa...***** FILE SYSTEM WAS MODIFIED *****? Onko jotain vakavaa, vai asiaan kuuluvaa? Ja mitäs tuo...2204/972944 files (1.4% non-contiguous), 178000/3890944 blocks...kuuluko asiaan?

Ainakin tuntuisi kaikki toimivan. Tällainen on nyt levytilanne:

Koodia: [Valitse]

:~$ df -h
Tiedostojärj.            Koko  Käyt Vapaa Käy% Liitospiste
/dev/sda1             3,7G  2,6G 1004M  73% /
none                  490M  284K  490M   1% /dev
none                  497M  112K  497M   1% /dev/shm
none                  497M   84K  497M   1% /var/run
none                  497M     0  497M   0% /var/lock
none                  497M     0  497M   0% /lib/init/rw
/dev/sdb5              15G  456M   14G   4% /home
/dev/sdc              7,5G  1,9G  5,7G  25% /media/USB 8GT
Samanlainen kuin ennenkin. (Unohtui tuo sdc tikku vaan reikäänsä). 16G sen sdb5.n pitäisi olla. Ja sda1.n pitäisi olla 4G. Mitä varten ne näkyy aina noin vajaana?

[mrl586]

Samanlainen kuin ennenkin. (Unohtui tuo sdc tikku vaan reikäänsä). 16G sen sdb5.n pitäisi olla. Ja sda1.n pitäisi olla 4G. Mitä varten ne näkyy aina noin vajaana?

Selitys tälle löytyy Wikipediasta:

Levyn tallennuskapasiteetti ilmoitetaan gigatavuina  (lyhenne Gt tai GB, 1 000 000 000 tavua) tai joskus megatavuina (lyhenne Mt tai MB, 1 000 000). On syytä huomata, että käyttöjärjestelmät esittävät levyn kapasiteetin yleensä gibitavuina, kahden potensseina, eli gigatavu on 2^30 eli 1 073 741 824 tavua.

Lähde: http://fi.wikipedia.org/wiki/Kiintolevy#Toimintaperiaate

[peran]

Tässä on myös toinen huomioitava seikka:
Osioidessa määrittelet osion kokoa, joka sisältää osoitteet tiedostoihin.
Tiedostojärjestelmän teon jälkeen tiedostojärjestelmä haukkaa siitä osansa, ja se ei ole ihan pieni. Tosin roikkuu tiedostojärjestelmästä. Ext-järjestelmät eivät ole siinä suhteessa parhaita.

[Hajakenttä]

Samanlainen kuin ennenkin. (Unohtui tuo sdc tikku vaan reikäänsä). 16G sen sdb5.n pitäisi olla. Ja sda1.n pitäisi olla 4G. Mitä varten ne näkyy aina noin vajaana?

Selitys tälle löytyy Wikipediasta:

Levyn tallennuskapasiteetti ilmoitetaan gigatavuina  (lyhenne Gt tai GB, 1 000 000 000 tavua) tai joskus megatavuina (lyhenne Mt tai MB, 1 000 000). On syytä huomata, että käyttöjärjestelmät esittävät levyn kapasiteetin yleensä gibitavuina, kahden potensseina, eli gigatavu on 2^30 eli 1 073 741 824 tavua.

Lähde: http://fi.wikipedia.org/wiki/Kiintolevy#Toimintaperiaate

En ollut ennen huomannutkaan, että tässä on tuollainen juttu. Siis ihan esitystavasta johtuva poikkeama. Olen paljon ollut tekniikan kanssa tekemisissä, oikeastaan koko ikäni, ja mittayksiköt aina tarkoittavat juuri yhtä asiaa... tai niin olisi tarkoitus. Uusi asia on, että sama mittayksikön merkintätapa voi siis tarkoittaa kahta erilaista mittaa. Onkohan tässä standardisointi jäänyt tekemättä? Vai onko oikeasti olemassa kaksi mittayksikön merkintätapaa, kummallekin oma? Emme vaan ole oppineet niitä käyttämään. Olihan ennen Porvoon torillakin kauppiaalla ja kruununvoudilla erisuuruinen perunakappa.

EDIT:
Wikipediassa http://fi.wikipedia.org/wiki/Gigatavu on asia esitetty niin, että gibitavu merkitään GiB. Tosin siinä ei ollut lähteitä. Korjasin sen myös tuohon edellä mainittuun wikiin: http://fi.wikipedia.org/wiki/Kiintolevy#Toimintaperiaate. Jos se on nyt väärin niin korjatkaa kiireesti, etten taas joudu kulkemaan paperipussi päässä.

Näin sitä opitaan taas vanhoilla päivillä.

[ajaaskel]

Onkohan tässä standardisointi jäänyt tekemättä?

Jos sille tehtäisiin standardi niin se olisi juuri tuollainen. Perustavaa laatua olevista syistä johtuen tietotekniikan "määrät" ovat kakkosen potenssiin perustuvia. Muualla ne ovat kymmenpohjaisia tasalukuja.
No, meni hieman off-topic: in puolelle mutta asia näytti kiinnostavan.

[peran]

En ollut ennen huomannutkaan, että tässä on tuollainen juttu. Siis ihan esitystavasta johtuva poikkeama. Olen paljon ollut tekniikan kanssa tekemisissä, oikeastaan koko ikäni, ja mittayksiköt aina tarkoittavat juuri yhtä asiaa... tai niin olisi tarkoitus. Uusi asia on, että sama mittayksikön merkintätapa voi siis tarkoittaa kahta erilaista mittaa. Onkohan tässä standardisointi jäänyt tekemättä? Vai onko oikeasti olemassa kaksi mittayksikön merkintätapaa, kummallekin oma? Emme vaan ole oppineet niitä käyttämään. Olihan ennen Porvoon torillakin kauppiaalla ja kruununvoudilla erisuuruinen perunakappa.

Joo... Eli Kiintolevyn kyljessä olevat tavut ovat GB (1000^3) Suomennettuna Gt.
Nautilus ja Windows ilmoittaa jäljellä olevan tilan GiB (1024^3) Suomennettuna Gt.
Samaten tiedostojen koot ilmoitetaan MiB:einä.

Eli tässä on vähän sama tapa kuin Porvoon torillakin - kauppias myy GB:tä ja tiedostot syövät GiB:tä.

Alunperin syynä tähän oli lienee 1024:n laskemisen nopeampi suoritus (50-60 luvulla), kun riitti pelkkä bittien siirtely. Nykyään sillä nopeusedulla ei enää ole merkitystä.

Muistia sentään myydään GiB:einä.

[Hajakenttä]

Onkohan tässä standardisointi jäänyt tekemättä?

Jos sille tehtäisiin standardi niin se olisi juuri tuollainen. Perustavaa laatua olevista syistä johtuen tietotekniikan "määrät" ovat kakkosen potenssiin perustuvia. Muualla ne ovat kymmenpohjaisia tasalukuja.
No, meni hieman off-topic: in puolelle mutta asia näytti kiinnostavan.

Olkoon off tai on, kyllä asia on tärkeä. Tällainen lähde löytyy sieltä wikin katso myös viitteistä:

http://physics.nist.gov/cuu/Units/binary.html

Lieneekö miten luotettava kun puhuukin SI standardista, eikös sen pitäisi olla ISO nykyään?

[ajaaskel]

Alunperin syynä tähän oli lienee 1024:n laskemisen nopeampi suoritus

Ei se ole nopeusasia vaan rakenteellinen asia, tietokoneet toimivat biteillä. Jos ajatellaan muistipaikojen osoitusta niin siellä emolevyllä on aivan fyysisiä linjoja tai johtimia (muistin osoiteväylä) joilla kerrotaan mitä muistipaikkaa luetaan tai kirjoitetaan. Valinta tehdään kytkemällä linjaan joko looginen "1" tai looginen "0". Eli kaksi mahdollista tilaa, jännite päällä / jännite pois.  Jos sinulla on esimerkiksi kaksi johdinta niin niillä on olemassa yhteensä neljä erilaista mahdollista tilaa: 00, 10, 01, 11  eli voidaan osoittaa 4 eri muistipaikkaa eli 2 potenssiin kaksi. Jos linjoja onkin 32 niin voidaan osoittaa 2 potensiin 32 eri paikaaa, jne.  Jokaisella muistipaikalla on osoite joka voidaan näin valita.
Samantyyppinen asia liittyy myös dataan jota käsitellään, 8 bitillä on 2 potenssiin 8 = 256 erilaista yhdistelmää eli voidaan esittää 256 erilaista asiaa / tilaa. Taskulaskimella näet helposti paljonko on sitten 2 potensiin 32 (32 bittinen) tai 2 potenssiin 64 (64 bittinen) luku.
Tämän voisi kirjoittaa tarkemminkin mutta menee vähän pitkäksi...


Edit (Hajakentälle):  No löytyihän sieltä IEC standardikin näille biteille.

[Hajakenttä]

Nyt ei ole pitkiin aikoihin tullut tuota virheilmoitusta ja bootin katkeamista. Toivotaan, että korjauskomento tosiaan jotain korjasi. Eikö tosiaan kellään ole käsitystä: mitä nämä tulosteet meinaa?

Koodia: [Valitse]

/dev/sdb5: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb5: 2204/972944 files (1.4% non-contiguous), 178000/3890944 blocks
Voisiko liittyä siihen kun on ssd muisti? Vai yrittääkö se sanoa, että tosiaan jotain modifioitiin? Siellähän oli vikaa todistettavasti koska testi sellaista sanoi ja käski ajaa käsipelillä tuon fsck komennon. Miten näillä on tapana toimia?

[Ganymedes]

Nyt ei ole pitkiin aikoihin tullut tuota virheilmoitusta ja bootin katkeamista. Toivotaan, että korjauskomento tosiaan jotain korjasi. Eikö tosiaan kellään ole käsitystä: mitä nämä tulosteet meinaa?

Koodia: [Valitse]

/dev/sdb5: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb5: 2204/972944 files (1.4% non-contiguous), 178000/3890944 blocks
Voisiko liittyä siihen kun on ssd muisti? Vai yrittääkö se sanoa, että tosiaan jotain modifioitiin? Siellähän oli vikaa todistettavasti koska testi sellaista sanoi ja käski ajaa käsipelillä tuon fsck komennon. Miten näillä on tapana toimia?

No parempia vastauksia odotellessa:

Bootti varmastikin keskeytyy jos /home partitiossa, mistä tässä on kyse tulosteesi mukaan, on jotakin vikaa.

Bad block tarkoittaa sitä, että levyllä oikeasti on vikaa - rakenteellinen vika, joka estää levylle kirjoituksen johonkin tiettyyn paikkaan. Tällöin pitää ajaa levyn tarkistus ja korjaus, joka merkitsee virheelliset blockit muistiin, jolloin näille kohdille ei yritetä enää kirjoittaa. Kun tämä on tehty, niin levy toimii jälleen. Tällaista voi tapahtua tavallisillakin levyilla, mutta monesti levyn tuho on lopullista kun joku luku/kirjoituspää on tehnyt levylle jo paljon isommankin tuhon tai tekee hyvin nopeasti.

Yleensä tavallisilla levyilla bad blockien lukumäärä on pyöreät nolla.

Kyse ei siis periaatteessa ole käyttöjärjestelmän viasta vaan fyysisen levyn viasta, jonka käyttöjärjestelmä osaa sivuuttaa.

Non-contiguous tarkoittaa sitä, että tiedostoista 4% ei ole yhtenäisesti kirjoitettu, vaan paikkoihin levyllä, jotka ovat kaukana toisistaan. Tällainen hidastaa levyä kun luku/kirjoitusoperaatiot joutuvat haeskelemaan tiedostoja monesta eri paikasta eivätkä voi lukea/kirjoittaa yhteen menoon. 4% ei kuitenkaan ole paljon, esim. XP:n NTFS on lähes välittömästi pahemmassa tilassa ja siellä de-fragmentoinnin ajaminen on suositeltavaa viikottain. Linuxin ext2/3/4 järjestelmissä vastaavaa tarvetta ei ole. Silloin kun levy tulee erittäin täysi, esim. alle 10 % on vapaana, on kuitenkin väistämätöntä että tällainen frakmentoituminen aina tapahtuu, koska muutoinhan levylle ei voisi enää kirjoittaa mitenkään - tämän voi helposti päätellä itsekin.

Ehkä tämä selventää jotakin?

[Hajakenttä]

No nyt se taas tuli, se virheilmoitus ja bootin katkeaminen. Tämä ilmoitus on muuten sama kuin ennenkin, mutta eri numero: ennen oli 296. Ja se levyn tarkastus ja badplokkien ohitus, fsck, on ajettu tässä välissä.

[quote"(Process: 286): GLib-WARNINGS: getparid_r (). failed due to unknown userid (0)"][/quote]

Tällainen ilmoitus juuri siinä kohdassa kun pitäisi tulla se Ubuntun logo, jossa on ne juoksevat pisteet ja siihen katkeaa bootti. Kun napsauttaa virtanappia vilkkuu hetken se logo ja jotain sekamelskaa ja sitten sammuu kone. Uusi käynnistys onnistui.

Tietääkö kukaan mikä on tuo 286 ? Tai mistä sellaisen voi opetella selvittämään?

[Ganymedes]

No nyt se taas tuli, se virheilmoitus ja bootin katkeaminen. Tämä ilmoitus on muuten sama kuin ennenkin, mutta eri numero: ennen oli 296. Ja se levyn tarkastus ja badplokkien ohitus, fsck, on ajettu tässä välissä.

[quote"(Process: 286): GLib-WARNINGS: getparid_r (). failed due to unknown userid (0)"]

Tällainen ilmoitus juuri siinä kohdassa kun pitäisi tulla se Ubuntun logo, jossa on ne juoksevat pisteet ja siihen katkeaa bootti. Kun napsauttaa virtanappia vilkkuu hetken se logo ja jotain sekamelskaa ja sitten sammuu kone. Uusi käynnistys onnistui.

Tietääkö kukaan mikä on tuo 286 ? Tai mistä sellaisen voi opetella selvittämään?

Tuo numero on prosessin numero eikä sinänsä tarkoita mitään. Nuo tekstit tarkoittavat, mutta en tiedä tarkalleen mitä.

Tarkoitat kenties tätä:
- on toiminut normaalisti jonkun aikaa
- nyt tuli bootissa levyntarkistus, mutta sen jälkeen ei kuitenkaan toimi

Tällöin herää tarkentavia kysymyksiä:
- kuinka monta kertaa tätä on bootattu onnistuneesti edellisen virheen jälkeen?
- tuleeko joka kerta kuitenkin levyntarkistus vai vasta nyt tuli?

On mahdollista, että bootin levyntarkistus ei osaa korjata virhettä, mutta kun ajat sen komentoriviltä Live-Bootin avulla - siis tällöin levylle joka ei ole käytössä ja eri parametreillä - niin korjaus voi onnistua.

Riippuen virheiden esiintymistiheydestä ja historiasta - eihän tuo tietysti hyvää lupaa levyn eliniälle...?

[Hajakenttä]

Tällöin herää tarkentavia kysymyksiä:
- kuinka monta kertaa tätä on bootattu onnistuneesti edellisen virheen jälkeen?
- tuleeko joka kerta kuitenkin levyntarkistus vai vasta nyt tuli?

Pitkiin aikoihin ei tullut mitään virheilmoituksia, varmaan toista kymmentä käynnistystä, mutta nyt tuo äskeinen ja tänä aamuna taas, eli neljästä kaksi boottia  tässä viimeisessä oli numero 273.

On mahdollista, että bootin levyntarkistus ei osaa korjata virhettä, mutta kun ajat sen komentoriviltä Live-Bootin avulla - siis tällöin levylle joka ei ole käytössä ja eri parametreillä - niin korjaus voi onnistua.

En tiedä tuleeko levyn tarkastus jokaisella bootilla, ainakaan se ei näy mitenkään, siis ei sitä tarkastusta, joka vilistää sekunteja näytössä vähän aikaa. Mikähän loki sen näyttäisi: onko siellä vakiona joku tarkastus joka bootilla? Ei ainakaan ole asetettu biosiin sitä nopeampaa boottia. Se muistaakseni jättäisi juuri jotain tarkastuksia tekemättä.

Levyn tarkastus ja korjaus tehtiin dev/sdb levylle ja bootti tietysti rassaa systeemin levyä dev/sda  tai näin kuvittelisin. Live-Bootin avulla? Ei se anna muuten sitä ajaakaan, siis tätä tarkastusta:

Koodia: [Valitse]

ubuntu@ubuntu:~$ sudo fsck.ext4 -fyc /dev/sdb5
Olisiko joku muukin korjauskomento? Tai eihän se mitään korjaa, heittää liiteriin vaan kelvottomat muistipaikat. Tosiaan se korjaus on ajamatta sda levylle. Kannattaisiko ajaa vai meneekö sitten asennus uusiksi? Ja entäs tuo -fyc? Onko oikea?

Pari vuotta on ollut käytössä tämä ssd. Ehkä siinä alkaa jo esiintyä noita kuolleita soluja. Nykyiset uudet ssd muistit ovat jo varmaan parempia sekä nopeudeltaan, että kestoltaan.

[Ganymedes]

On mahdollista, että bootin levyntarkistus ei osaa korjata virhettä, mutta kun ajat sen komentoriviltä Live-Bootin avulla - siis tällöin levylle joka ei ole käytössä ja eri parametreillä - niin korjaus voi onnistua.

En tiedä tuleeko levyn tarkastus jokaisella bootilla, ainakaan se ei näy mitenkään, siis ei sitä tarkastusta, joka vilistää sekunteja näytössä vähän aikaa. Mikähän loki sen näyttäisi: onko siellä vakiona joku tarkastus joka bootilla? Ei ainakaan ole asetettu biosiin sitä nopeampaa boottia. Se muistaakseni jättäisi juuri jotain tarkastuksia tekemättä.

Levyn tarkastus ja korjaus tehtiin dev/sdb levylle ja bootti tietysti rassaa systeemin levyä dev/sda  tai näin kuvittelisin. Live-Bootin avulla? Ei se anna muuten sitä ajaakaan, siis tätä tarkastusta:

Koodia: [Valitse]

ubuntu@ubuntu:~$ sudo fsck.ext4 -fyc /dev/sdb5
Olisiko joku muukin korjauskomento? Tai eihän se mitään korjaa, heittää liiteriin vaan kelvottomat muistipaikat. Tosiaan se korjaus on ajamatta sda levylle. Kannattaisiko ajaa vai meneekö sitten asennus uusiksi? Ja entäs tuo -fyc? Onko oikea?

Pari vuotta on ollut käytössä tämä ssd. Ehkä siinä alkaa jo esiintyä noita kuolleita soluja. Nykyiset uudet ssd muistit ovat jo varmaan parempia sekä nopeudeltaan, että kestoltaan.

Tuohon tarkennuksia:

Bioksen tarkistukset ovat keskusmuistin tarkennuksia - eivät liity tähän mitenkään, eikä mikään muukaan bios-asetus.

Levytarkistus kestää jopa 15 min isolla levyllä. Se tapahtuu "ubuntu-ikkunassa" - tällaistako näkyy, voihan se olla verrattain nopea pienellä SSD-levyllä?

Ainahan ennen levyn tarkistusta pitää olla backup-kunnossa - voihan niissä tapahtua mitä hyvänsä jos pahoja virheitä löytyy ...

Se, että tarkistetaanko levyä bootissa vai ei, on määrätty /etc/fstab -tiedoston mount-optioissa - ne nollat ja ykköset perässä. En osaa sanoa mitä on oletus tuossa järjestelyssä, jossa /home on erikseen. Näillä hallitaan sitä, että tehdäänkö automaattiset tarkistukset määrävälein vai ei. Se, että miten usein ne tehdään, hallitaan erikseen ja sitä voi muuttaa - oletus on muistaakseni noin suunnilleen: joka 30. kerta tai 180 vrk:n välein, kumpi tuleekaan ensin. Joten näin usein nämä normaalisti ajetaan "koko Ubuntu järjestelmälle" - ilman, että se hajoaa.

Käsintehtävien tarkistusten parametrejä en hallitse sen paremmin - joskus on antanut itse ne kehotuksena ja olen käyttänyt niitä. Niistä lienee ohjeita netissä riittämiin - tai joku muu antaa täällä. Muistaakseni -f oli se oleellinen, mutta tarkista vielä. Se mitä kirjoitit live-CD:n käytöstä on se mitä juuri tarkoitin.

[Hajakenttä]

Kiitos uskonvahvistuksesta.

Laittelen backupit kuntoon ja ajelen tuon korjauksen. Wiki kyllä kertoo sen oleellisen. Sen korjauksen ajo kestää vain silmänräpäyksen jos jättää pois sen tarkastuslistauksen. 16 Gt levyllä se tarkastuslistaus kesti pari minuuttia.

Palaillaan asialle.

[Hajakenttä]

Ajoin sen testin. En tiedä korjasiko mitään, mutta tämmösen tulosti:

Koodia: [Valitse]

ubuntu@ubuntu:~$ sudo fsck.ext4 -fy /dev/sda1
e2fsck 1.41.11 (14-Mar-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 126161/246512 files (0.2% non-contiguous), 661162/984576 blocks
ubuntu@ubuntu:~$
Eli 0,2% kai oli sitten jotain huomautettavaa. Tässä ei ole nyt sitä MODIFIED huomautusta, joka tuli sdb testissä /home osiosta. Kaikki tuntuisi toimivan ja nyt vaan odotellaan: vieläkö niitä bootin katkeamisia tulee?

fstab näyttää tältä:

# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
/dev/sda1       /               ext4    errors=remount-ro 0       1
# /home was on /dev/sdb5 during installation
UUID=4289322f-cf04-4372-9219-851da567d55a /home           ext4    defaults        0       2
/dev/sdb1       none            swap    sw              0       0

En osaa tuosta päätellä kuinka usein levyä testataan, mutta luulisin, että 20 käynnistyksen välein. Muistelen joskus lukeneeni sitä nopeasti vilahtavasta rivistä niin.

Ehkä se bootin katkeaminen ei liity siihen levyn testaamiseen. Eikä sda levyn testissä ole virheilmoitusta tullut. Vai testataanko sda:ta lainkaan? Sillä kun on käyttöjärjestelmän / osio. Olisiko voinut olla joku levyn viallinen solu siellä piilossa osassa, jota ei normaalisti päästä tutkimaan?

[Ganymedes]

Se millä säädetään tutkimisten intervallia on komento "tunefs".

fstabin optioista löysin tällaisen dokumentaation:

Fsck order is to tell fsck what order to check the file systems, if set to "0" file system is ignored.

Often a source of confusion, there are only 3 options :

    * 0 == do not check.
    * 1 == check this partition first.
    * 2 == check this partition(s) next

In practice, use "1" for your root partition, / and 2 for the rest. All partitions marked with a "2" are checked in sequence and you do not need to specify an order.

Use "0" to disable checking the file system at boot or for network shares.

Tämä koskee siis listauksesi viimeistä lukua. Periaatteessa sinulla on fstabissa oikein - eli myös root " / " tutkitaan.

Tarkistuksessasi ei löytynyt nyt virheitä. Tuota framentoitumista kommentoin jo aiemmin ja tuo 0.2 % ei ole mitään.

Ilmeisesti sinulla nämä virhetilanteet eivät tule säädetyn määräajan mukaisissa tarkistuksissa, vaan silloin kun bootti epäonnistuu ja järjestelmää alkaa testaamaan levyä oma-aloitteisesti.

[madmax75]

Windows kaatuili minulla sanotaan kerran viikossa tai kerran kahdessa viikossa.

Ubuntua olen käyttänyt nyt kaksi ja puoli vuotta (about), ja tänä aikana on ollut ehkä 3-4 jumiutumista (Hiiri ja näppäimistö eivät toimi, ruutu jäätyy yms.). Tosin läppärissäni oli aikanaan viallinen tuuletin, joka saattoi aiheuttaa ongelmia 

[Hajakenttä]

Se millä säädetään tutkimisten intervallia on komento "tunefs".

fstabin optioista löysin tällaisen dokumentaation:

Fsck order is to tell fsck what order to check the file systems, if set to "0" file system is ignored.

Often a source of confusion, there are only 3 options :

    * 0 == do not check.
    * 1 == check this partition first.
    * 2 == check this partition(s) next

In practice, use "1" for your root partition, / and 2 for the rest. All partitions marked with a "2" are checked in sequence and you do not need to specify an order.

Use "0" to disable checking the file system at boot or for network shares.

Tämä koskee siis listauksesi viimeistä lukua. Periaatteessa sinulla on fstabissa oikein - eli myös root " / " tutkitaan.

Tarkistuksessasi ei löytynyt nyt virheitä. Tuota framentoitumista kommentoin jo aiemmin ja tuo 0.2 % ei ole mitään.

Ilmeisesti sinulla nämä virhetilanteet eivät tule säädetyn määräajan mukaisissa tarkistuksissa, vaan silloin kun bootti epäonnistuu ja järjestelmää alkaa testaamaan levyä oma-aloitteisesti.

Kiitos selvennyksestä Ehkäpä tässä sitten ei ole muuta tehtävissä. Levynkirjoitusta voi kyllä vähentää vastaisen varalle, mutta se ei liity näihin vikoihin.

Itse aiheeseen palatakseni: Ubuntu 10.04 on kestänyt kunnossa aivan moitteettomasti, eikä tässä koneessa ole ollut yhtään jumia, joka olisi selvästi Ubuntun syytä. Tämäkin bootin katkeaminen on kyseenalainen juttu, josta ei voi suoraan käyttöjärjestelmää syyttää. Saattaa olla rautojenkin vika. Rautoja syyttäisin myös toisen koneemme (Asus A6R) taannoisesta, oikeastaan ainoasta kunnon jumiutumisesta. Siinä on yhteensopimaton näytönohjain (ATI radeon Xpress 200M) ja se on keljuillut muutenkin: Ei herää keskeytystilasta, eikä aja kunnolla 3d ajoa. Sille olisi ehkä avoimen koodin ajureita, mutta en ole rohjennut koittaa. Firefox on joitakin kertoja jumittunut, mutta aivan suoraan en siitäkään Ubuntua syyttäisi, koska se ilmenee useimmiten tietyllä Firefoxin tehtävällä, ja se korjautuu pelkän Firefoxin uudelleenkäynnistyksellä. Samaa sanoisin edellisistä jakeluista JJ ja KK. Hyvin ovat pelanneet. Windowsiin en vertaisi, koska sekin pelaa aivan hienosti niin kauan kun siihen ei asenna mitään sille vierasta ohjelmaa. Alkuperäisosillahan autotkin parhaiten toimivat, eikä erimerkkisillä ristiin.