Allmän hälsokontroll

[Lao Tzu]

Eftersom jag inte vet huruvida mina problem har samma orsak eller ej, lägger jag här en tråd om en allmän hälsogenomgång av min dator.

Anledningen till att jag vill kolla hårdvaran är att datorn är gammal och sliten. Dessutom är problemen (enligt mig) ytterst märkliga. Dessa kan man hitta här: http://www.ubuntu-se.org/phpBB3/viewtop ... 19#p475119


Hårdvarukontroll
Hårddisk
Hårddisken knackar till och från när den arbetar (vet inte om det enbart är när den läser eller skriver eller om det kan vara både och). Dock har jag kört ett test som man hittar under Inställninngar --> Diskar --> More actions (har ett kugghjul som symbol). Såvitt jag kan se ger det inga indikationer på att något är galet. Är det samma test som görs automatiskt med jämna mellanrum när man startar upp datorn?

Jag tänkte också passa på att kontrollera min externa hårddisk för att se hur den mår. Är det här kommandot lämpligt: sudo fsck /dev/sdb1 (under förutsättning att den är inkopplad som sdb1)?

RAM
Jag har också kört memtest utan att hitta några fel på ram-minnena. Det fick köra i 3,5 timmar en av dessa varma sommarkvällar och jag brukar inte pressa datorn särskilt hårt, varpå eventuella fel som händer vid användning också borde ha noterats vid testet.

Mjukvara
Det kan också vara klokt att försöka felsöka mjukvaran eftersom det är där felen märks men jag har ingen aning om hur man gör det på ett smidigt sätt.

Jag har inte testat om det blir samma fel när jag kör Live-USB men om jag har tålamod ska jag prova. Saken är bara den att jag inte direkt har kunnat se något samband med när felen inträffar.

Firefox
Det enda möjliga sambandet att Firefox har varit igång länge innan det kraschar först, sen kan det krascha kort efter igen om jag startar om läsaren direkt, men eftersom det ibland kan gå veckor mellan krascherna och ibland tätt inpå är det hopplöst att felsöka genom att inaktivera ett tillägg eller en plugin i taget.

Musiken
En snabb genomgång av musiken på hårddisken ger endast vid handen att några låtar ser ut att vara över 10 minuter. Dock är de trots att de bara är cirka 4 minuter "hela" men det går inte att spola. Dock är det likadant i min äldsta kvarvarande backup så de kan "alltid ha varit så". Därmed verkar det som att musikproblemet uppstod på usb-minnet (vilket dock är sprillans nytt).

Den flygande filen
Här har jag intet nytt att rapportera

Sen vet jag inte om det är en bugg eller om det bara hos mig felet finns men när jag skulle göra en skärmdump på testresultaten för hårddisken fungerade inte maximeringsknappen på fönstret.

[johanre]

Vad gäller hårddisken skulle jag kört smartmontools, men det har du uppenbarligen redan gjort och i stora drag ser det OK ut. Sen är det ingen garanti i sig, varför backup alltid är bra. Men - kör även SMART på din externa hårddisk.

fsck kollar så att filsystemet är ok, SMART kollar så att den fysiska hårddisken mår som den skall så det är alltid bra att köra båda varianter med jämna mellanrum. Men för att köra fsck måste filsystemet vara avmonterat under tiden man kör (sudo umount /dev/sdb1). fsck och SMART tester *kan* köras per automatik fast med lite olika förutsättningar; fsck körs i vanliga fall vid uppstart beroende på filsystem och optioner angivna i /etc/fstab. Att SMART tester numera ingick i Ubuntus / Gnomes diskhanteringsverktyg hade jag missat men tittar lite snabbt och det ser ut som det även där är förberett för automatiska tester. Alltså, kör både SMART och fsck på din externa hårddisk men se till att den är avmonterad innan du gör det (inte nödvändigt för SMART tester).

[johanre]

Förresten; hur mycket RAM minne har du, hur mycket swap och vilka program brukar du ha igång, och hur länge? Kör du Firefox med många plugins, många flikar igång samtidigt, etc. De problem du berättar om kan också uppstå när det börjar bli riktigt ont om minne, men det händer inte så ofta numera.

[Lao Tzu]

Tack för att du ställer upp så mycket!

Först och främst kan jag inte gå samma väg som jag gjorde med den interna hårddisken när jag ska kolla den externa. Möjligheten att testa den är alltså oklickbar. Likaså om jag avmonterar den. Jag provade därför fsck. Såhär blev resultatet:

Kod: Markera allt

emil@barbar:~$ sudo umount /dev/sdb1
[sudo] password for emil: 
emil@barbar:~$ sudo fsck /dev/sdb1
fsck från util-linux 2.20.1
dosfsck 3.0.16, 01 Mar 2013, FAT32, LFN
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? ?

Jag har inte gjort något val än utan inväntar rekommendation.

Kan man kolla den externa hårddisken med det som i mjukvarucentret kallas Gsmartcontrol (är väl ett GUI för Smartmontool)?

Gällande RAM har jag förvisso bara 2 GB men mig veterligen använder jag sällan eller aldrig så mycket. Nu blev jag osäker men jag tror att jag har kollat hur mycket jag använt precis efter en krasch nån gång. I så fall var det vara runt 1,5 då. Dock kan det också ha varit i ett annat sammanhang. Ska hålla utkik på det nästa gång. Jag kan ha upp emot ett 20-tal flikar men eftersom (nästan) all reklam är blockad går det ändå inte åt så mycket extra. Men som sagt, lösningen kan ändå vara såhär enkel, ska ha det i åtanke.

Jag har Adblock plus 2.6.4, Ecosia 3.0.4, Ghostery 5.3.2, Text-to-image 1.4.6 och Textarea Cache 0.9.3.2.

[Lao Tzu]

Liten uppdatering. Nu precis kraschade Firefox igen. Den här gången använde jag endast ungefär 1200 MB.

[johanre]

2 GB RAM kan vara i snålaste laget givet dagens minneshungriga applikationer, men du säger att du inte kör så mycket annat än just Firefox...Hhhhmm, får fundera.

Vad gäller hårddisken; kan du köra följande?

Kod: Markera allt

sudo fsck.vfat -a /dev/sdb1

[Lao Tzu]

Jo, 2 GB är snålt men jag använder som sagt inte mycket. Förutom Firefox kan jag ha Open Office, Audacious och någon mediespelare igång men då det är sällan har de flesta Firefoxkrascherna skett utan inblandning av andra program.

Som lite bonusinformation kan jag nämna att Firefox kraschade igen, nyss. Den här gången användes cirka 1060 MB efter kraschen och vid återuppstarten gick minnesanvändningen upp till cirka 1260. Jag hade då endast den här fliken igång.

Gällande hårddisken körde jag följande:

Kod: Markera allt

emil@barbar:~$ sudo umount /dev/sdb1
[sudo] password for emil: 
emil@barbar:~$ sudo fsck.vfat -a /dev/sdb1
dosfsck 3.0.16, 01 Mar 2013, FAT32, LFN
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automaticaly removing dirty bit.
FATs differ but appear to be intact. Using first FAT.
/Deja Dup Backup/duplicity-full.20130915T144435Z.vol94.difftar.gpg
  Contains a free cluster (6822784). Assuming EOF.
/Deja Dup Backup/duplicity-full.20130915T144435Z.vol94.difftar.gpg
  File size is 52464004 bytes, cluster chain length is 32145408 bytes.
  Truncating file to 32145408 bytes.
Reclaimed 54672 unused clusters (1791492096 bytes) in 118 chains.
Performing changes.
/dev/sdb1: 14239 files, 8498960/9765385 clusters

Jag antar att kommandot gjorde samma sak som att trycka 1 skulle ha gjort efter förra meddelandet?

Jag har tänkt och rannsakat mitt beteende en del och ett par saker kommer upp, som kan närma sig lösningen.
När jag har tagit back up de senaste två-tre gångerna (kanske när jag "återställde" /home i min nya installation också men det vill jag låta vara osagt) har jag fått några felmeddelanden om något jag inte begrep mig på men det stod att Deja dup ignorerade dessa och fortsatte ändå och eftersom jag inte har "märkt" något fel (det vill säga förutom att Firefox kraschar och nu då att det kan vara några fel på en del låtar) har jag inte brytt mig om det. Kan det vara så att OM det kom redan när jag återställde så är det något i /home som är knas, som en följd av felmeddelandena? Dessa är förmodligen knutna till ovannämnda "smutsiga bitar", eller?
Vad händer med filerna som har lagrats på de smutsiga bitarna?

Betyder det att det finns smutsiga bitar att hårddisken på ett eller annat sätt är på väg att ge upp och att jag bör söka mig om efter en ny back up-källa? Kan ett sådant fel dessutom uppstå på grund av att hårddisken tappar kontakt med datorn på grund av glapp i USB-sladden? Den glappar nämligen i anslutningen till själva hårddisken och jag har fått göra en patentare för att undvika att det händer igen. (Den är dessutom inköpt 2006 men används inte särskilt ofta då jag sällan lägger till (eller tar bort) saker från datorn).

En sak som slog mig när jag började skriva det här inlägget är också att det eventuellt kan vara så att krascherna oftast inträffar just när jag ska skriva i såna här rutor. Jag ska prova att påbörja inlägg och kommentarer intensivt under dagen och se ifall det blir fler krascher. I så fall kan det vara Textarea Cache som spökar. Särskilt ifall det visar sig att jag vid samma användning med det inaktiverat. Det är inte säkert men helt klart en rimlig sak att prova.

[johanre]

Jag börjar allt mer luta åt att en ren nyinstallation kan vara bästa lösningen för dig. Det är bara så, ibland kan felsökning kräva alldeles för mycket mer tid än vad det är värt - en nyinstallation kan i det läget vara långt mer meningsfull och resultatinriktad.

Vad gäller hårddisken så har fsck:en fixat alla problem. Den borde vara i fullt dugligt skick nu. Alla filer skall nu vara som de skall vara - oskadda! Sen är jag medvetet försiktig; naturligtvis finns det en avlägsen möjlighet att något på disken har tagit skada men jag tror verkligen inte det.

[Lao Tzu]

Jag börjar allt mer luta åt att en ren nyinstallation kan vara bästa lösningen för dig. Det är bara så, ibland kan felsökning kräva alldeles för mycket mer tid än vad det är värt - en nyinstallation kan i det läget vara långt mer meningsfull och resultatinriktad.

Ja, du har nog rätt. Det enda som har hindrat mig från detta är just ifall felet finns i den säkerhetskopierade /home. I så fall skulle en nyinstallation och tillbakasättandet av /home bara återskapa felen. Sen är det så att jag bara ha säkerhetskopierat hela /home, vilket i så fall innebär att jag ändå måste leta efter felet efter nyinstallationen.

Vad gäller hårddisken så har fsck:en fixat alla problem. Den borde vara i fullt dugligt skick nu. Alla filer skall nu vara som de skall vara - oskadda! Sen är jag medvetet försiktig; naturligtvis finns det en avlägsen möjlighet att något på disken har tagit skada men jag tror verkligen inte det.

Det låter tryggt. Det är åtminstone inte ett tecken på att den börjar ge upp.

Jag ska prova att krascha Firefox lite mer, lyckas inte det (ser mörkt ut) gör jag en nyinstallation och använder den nu reparerade, senaste back upen av /home. Gör det susen blir jag glad. Den här gången blir det dock Xubuntu.

[Lao Tzu]

Denna räddningsoperation har givit ett (för mig) oväntat resultat. Jag har nu, förutom det jag hade förut, 118 filer vid namn FSCKxxxx.REC från (alltså FSCK0000 - FSCK0117) i storleksordningen 32 KB - 36,1 MB. Alla daterade 1979-12-31 23:00. Vad gör jag med dem och hur påverkar de en återställning av /home? Jag menar, Själva återhämtningsfilerna torde ligga i mappen Deja Dup, där de alltid hamnar.

Kanske kan det vara idé att nämna att jag har krypterat återställningen i Deja Dup.

Dessutom har jag Under System Volume Information mappar med namn som exempelvis _restore{04B1F701-7C5F-4E88-A49B-7DD69D26E3E9} där den äldsta filen går tillbaka till 2006 och den nyaste till 2009.

[Lao Tzu]

Jag har googlat en del parallellt men blir inte mycket klokare. Som jag har förstått det är FSCKxxx.REC filer som har återskapats i den mån programmet har klarat av det. Vissa har bytt namn och fått fungerande filer. Betyder det att man kan prova att byta ut exempelvis FSCK0016.REC mot FSCK0016.mp3 som sedan kanske är spelbar ifall det nu är en mp3-fil?

En vidare fråga är alltså, ifall detta nu är borttaget från själva back upen: betyder det att dessa filer (eller vad det nu är) försvinner vid nästa återställande av /home?

[johanre]

Lite osäker; har du installerat om och tittar nu på återläsning från backup?

Kan ingenting om Deja Dup så har inget att bidra med i fråga om dina backuper...

[Lao Tzu]

Nej, jag har bara "fixat" den externa hårddisken och när jag skulle kolla en annan sak på den hittade jag dessa FSCKxxxx.REC-filerna. Jag tänkte ta reda på vad som försvinner innan jag gör en nyinstallation och så vill jag veta ifall det är filer jag kan ta bort eller om jag ska göra något med dem.

Min googling säger mig att FSCKxxxx.REC-filer uppkommer oberoende av vad det är som har kraschat men så långt är du förmodligen med. Det knepiga med kryptering i Deja dup är att det blir som olika kluster helt omöjliga att säga vad de innehåller då storleken på filerna inte stämmer med storleken på enskilda okrypterade filer. Dock är det här mer överkurs och nyfikenhet.

Om vi istället tar oss upp en nivå och inte bryr oss om ifall det rör sig om kluster eller ej, så kvar står frågan mer teoretiskt. Är FSCKxxxx.REC-filer försök att återskapa förstörda delar? Det verkar så. Jag har hittat det här programmet, vilket verkar intressant om man vill se vad det är: http://mark0.net/soft-trid-e.html.

[johanre]

https://wiki.gnome.org/Apps/DejaDup/HowItWorks

Déjà Dup uses an opaque format for files stored in your backup location. You must use Déjà Dup or another duplicity-based tool to restore your files. This is opposed to a native format where you can browse and examine your files using any normal file tool.

This naturally is a bummer. But it is necessary to support Déjà Dup's feature set:

Encryption
Compression
Incremental backups
Assuming little about location (allowing cloud backups)
Supporting file permissions, even when backing up to locations that don't

Because of all the above, it is impossible to allow a version of your files that is accessible without duplicity. Note that there is a way to get your data back by hand, but it's not fun or easy.

[Lao Tzu]

https://wiki.gnome.org/Apps/DejaDup/HowItWorks

Déjà Dup uses an opaque format for files stored in your backup location. You must use Déjà Dup or another duplicity-based tool to restore your files. This is opposed to a native format where you can browse and examine your files using any normal file tool.

This naturally is a bummer. But it is necessary to support Déjà Dup's feature set:

Encryption
Compression
Incremental backups
Assuming little about location (allowing cloud backups)
Supporting file permissions, even when backing up to locations that don't

Because of all the above, it is impossible to allow a version of your files that is accessible without duplicity. Note that there is a way to get your data back by hand, but it's not fun or easy.

Attans... betyder detta att mitt tidigare räddningsförsök kan ha varit en björntjänst? Oh well. Tack för informationen i alla fall. Förhoppningsvis har jag blivit lite klokare till nästa gång.

Jag måste säga att själva programmet Deja Dup, inte skyltar särskilt väl med hur man återskapar trasiga filer. Det tycks hur som helst bli till att skaffa ytterligare en back up hårddisk som jag kan använda för att lagra nästa försök att återskapa det som är trasigt. Kanske är det inte helt kört. Det finns en guide jag ska försöka följa och se vad som händer. Värre bör det i alla fall inte bli.

Gällande TrID har jag precis försökt använda det genom att köra sudo file /media/emil/IOMEGA_HDD/kraschfiler/FSCKxxxx.REC på alltihop. Dock vet jag inte om det var rätt och resultatet blev magert. De flesta ger informationen "data" medan några sa "DOS executable (COM)". En sa "Dyalog APL component file version 58 .100", en annan "SysEx File – AKG" och en tredje "MIPSEL-BE MIPS-III ECOFF executable not stripped - version 192.55".

Edit: Kommandot jag körde är en gissning utifrån en kommentar till det här inlägget: http://www.makeuseof.com/tag/identify-u ... dowslinux/

[Lao Tzu]

Ytterligare ett par frågor har dykt upp. Nedan är resultatet av fsck och det har slagit mig att det endast är en fil som nämns (/Deja Dup Backup/duplicity-full.20130915T144435Z.vol94.difftar.gpg). Betyder det att det endast är den filen som är skadad? Om jag har räknat rätt är den cirka 52 MB.

Sen har FSCK gjort en hel del andra beräkningar och räddningsfilerna (FSCKxxxx.REC) är på totalt 1,7 GB. Hur kommer det sig, om nu felet endast fanns/finns i ovannämnda fil?

FSCK-resultatet:

Kod: Markera allt

emil@barbar:~$ sudo umount /dev/sdb1
[sudo] password for emil: 
emil@barbar:~$ sudo fsck.vfat -a /dev/sdb1
dosfsck 3.0.16, 01 Mar 2013, FAT32, LFN
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automaticaly removing dirty bit.
FATs differ but appear to be intact. Using first FAT.
/Deja Dup Backup/duplicity-full.20130915T144435Z.vol94.difftar.gpg
  Contains a free cluster (6822784). Assuming EOF.
/Deja Dup Backup/duplicity-full.20130915T144435Z.vol94.difftar.gpg
  File size is 52464004 bytes, cluster chain length is 32145408 bytes.
  Truncating file to 32145408 bytes.
Reclaimed 54672 unused clusters (1791492096 bytes) in 118 chains.
Performing changes.
/dev/sdb1: 14239 files, 8498960/9765385 clusters