Inlägg

Som vogonerna från liftarens guide till galaxen.

"There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now"

Både vogoner och nvidia vet att det är omöjligt att läsa alla avtal så när det uppstår kontrovers kan de bara peka på avtalet och säga att folk får skylla sig själva.

"Online privacy policies are so cumbersome and onerous that it would take the average person about 250 working hours every year — about 30 full working days — to actually read the privacy policies of the websites they visit in a year,"
http://www.npr.org/sections/alltechconsidered/2012/04/19/1509...

Om företagen gör något med den insamlade datan som inte står i avtalet så kan det uppstå problem så alla företag skriver sitt avtal så att det är så tillåtande som möjligt bara för att vara på den säkra sidan. Det intressanta för en vanlig användare är vad för data som samlas inte, inte vad som får samlas in enligt avtalet. Nvidia borde därför informerat användarna om insamlingen på ett tydligt ställe (ej i avtalet).

Hur vet du det? Om de samlar in kraschdumpar så inkluderas troligen delar gpu minnet. Där kan de finna framebuffers och pixmaps för gamla program som användaren inte använt på flera timmar. Det är mycket känslig information.

Utskriften kommer från glibc och glibc gillar att öppna terminalen direkt från /dev/tty och skriva felmeddelande till den. Jag vet inte om ditt meddelande skrivs så men du kan prova att sätta LIBC_FATAL_STDERR_=1 för att få glibc felmeddelanden till stderr.

Jag vet att glibc envvars inte funkar för setuid binärer och det finns nog andra regler för hur och var de används. Du får googla för detaljerna.

Om den tar lång tid att starta när den är kall men startar snabbt när den är varm så låter det som om den har kassa kondensatorer. Jag har själv en gammal LG skärm som tar runt en minut att starta. Jag har bytt 2 trasiga kondensatorer i den reda för den gav ingen bild alls innan. Om du har garanti så lämna tillbaka den. Om inte så går det byta själv om du har ork och tid. Googla på "capacitor monitor repair"

Jag fick själv en riktigt käftsmäll av postnord i veckan. Mitt postombud som ligger 700m bort ska bytas till en som ligger 3km bort i ett industriområde.

http://www.corren.se/nyheter/linkoping/stor-ilska-efter-postn...

Jag har inte bil eller ens cykel. Lokaltrafikbussarna har jag så dålig erfarenhet av att jag bara använder dom i krisfall. Det blir att bära hem paket 3km eller sluta handla på nätet.

Code 43 är ett generellt fel som inträffar om en drivrutin inte kan laddas. Det kan bero på massa olika saker. Drivrutiner för grafikkort kan ge code 43 om den extra strömsladden till grafikkortet inte är inkopplad. Kolla så att den inte glappar. Eftersom du redan debuggat mjukvaran ganska mycket gissar jag att det är ett hårdvaruproblem.

Kingston brukar ljuga ganska frisk när de anger storlek.
Jag har en Kingston DTSE9 på "8GB" som innehåller 15248832 sektorer (7,807,401,984 bytes)
en annan DTSE9 på "16GB" som innehåller 30712320 sektorer (15,724,707,840 bytes)
och en datatraveler 100 G3 på "16GB" som innehåller 30736384 sektorer (15,737,028,608 bytes)

Enligt någon faq på Kingstons hemsida används det saknade utrymmet till firmware och overprovisioning.

Så du startar datorn, ser någon grafisk greeter (display manager), när du försöker logga in ser du i stället framebuffern för ett ögonblick och sen startar greeter igen? Symtomen är typiska då X servern kraschar eller stänger av sig av någon anledning. Anledningen kan vara allt möjligt, som att display manager kraschar eller har felaktig konfig eller att desktopen inte startar av någon anledning. Det meddelandet du ser är det sista som skrevs till framebuffern innan X servern startade och det har inget att göra med felet.

För att hitta felet blir det till att felsöka. Kolla kernelns log, Xorg.0.log och loggar för display manager om det finns någon. Kolla också konfigurationen för dessa. Att guida den felsökningen över internet är inte så kul så jag säger som Red Foreman: I'd like to help, but not as much as I'd like not to.

Min gut feeling säger att du dragit in nya grafikdrivrutiner som kraschar X servern vid start. Om du behöver komma åt filerna snabbt så använd en livecd.

Om du bestämt dig för zfs så tjänar det inte mycket till att jag svarar egentligen men eftersom du verkar rädd att använda snapraid med fyllda diskar gissar jag att du inte vet fullt ut hur det funkar. Snapraid använder dina filer som de är utan någon konvertering. Snapraid skriver aldrig till dina lagrade filer om du inte gör recovery. Vid vanlig användning behövs inte ens skrivrättighet till dina filer och utan skrivrättighet är det ingen risk att din redan existerande filer skadas.

@Paddanx: Det jag störde mig på var att du kritiserade snapraid för att det inte är traditionell raid. Som du märkt är det inte meningen och snapraid är överlägset traditionell raid för avsedd målgrupp. Snapraid innehåller troligen substringen raid för att det använder en redundant array of inexpensive disks. Vanlig backup är också redundant men utan att använda någon array of disks. Snapraid är inte heller full backup eller offsite backup. Det är därför jag uppmanade TS att läsa manualen så att det inte blir några missuppfattningar.

Jag har använt det i flera år och har hittills räddat datan på två havererade diskar.

Innan jag började använda snapraid kollade jag igenom all kod för att försäkra mig om att jag förstod hur det funkar. Koden är av hög kvalitet och utvecklaren är kompetent. Tyvärr är det fortfarande ett enmansprojekt men eftersom det är så få lines of code och det är lätt att läsa antog jag att jag kan fixa problem själv om utvecklaren skulle försvinna.

Om du vill använda snapraid så läs igenom hela manualen så att du inte har några missuppfattningar om hur det funkar och vad du kan förvänta dig av det.

Det är en av fördelarna med snapraid jämfört med traditionell raid. Eftersom raid uppdaterar paritetsdatan online skyddar det inte mot accidental delete som snapraid. Om man behöver high availability är snapraid inte lämpligt men om det är datasäkerhetsaspekten av raid man vill ha så är snapraid överlägset och det är troligen vad de flesta hemanvändarna är ute efter.

Drivrutinerna försöker gissa om full eller limited ska användas baserat på anslutningen, upplösningen och refresh raten. Ansluter man en datorskärm med vanliga upplösningar är det stor risk att den gissar fel och man får limited i stället för full. Att alltid köra full RGB blir också fel med vissa displayer så varje användare får själv välja vad som är rätt för sin egen display med xrandr.

Om det är en nyinstallation av windows 7 så är det troligen windows update som tuggar.
http://www.zdnet.com/article/sticking-with-windows-7-the-fore...
Symtomen är att en svchost process använder massa ram och 100% cpu på en kärna.

Om du laddar ner process explorer (procexp) så kan du se vad svchost kör om du vill bekräfta att windows update är problemet. För att lösa problemet måste man manuellt installera en bunt updates eller vänta några dygn tills windows update räknat färdigt.

Anledningen till att .so filer ibland byter namn med nya version är för att versionerna inte är kompatibla med varandra. Om man länkar en icke kompatibel version så att det ser ut som den är kompatibel så kan programmet ibland starta och se ut att fungera men kommer krascha eller bete sig skumt när det använder det icke kompatibla biblioteket. Installera rätt version av biblioteket i stället för att länka.

Hmm, troligen inte. Bios kör ibland kod i system management mode för att hantera hotplugging, emulering av legacy devices och ibland power management. Det är inte omöjligt att kod körs pga thermal throttling och den koden ändrar minne den inte borde. Det kan förklara varför det bara händer när alla kärnor är igång men det är en långsökt förklaring.

Har datorn några symptom av korrupt ram förutom memtest fel? Linux har en kernel parameter för att exkludera vissa minnessegment från användning men det är en sista utväg om problemet inte kan lösas på annat vis. Windows vet jag inte vad man kan göra med. Om det finns nyare bios så testa det.

Vanliga ram defekter bruka bara påverka en eller ett fåtal bitar och det brukar vara samma bitar hela tiden. "Err-Bits" raden brukar därför ha ett regelbundet utseende. Dina Err-Bits ser helt slumpmässiga ut så jag gissar att det inte är vanlig bitröta i ram. Uppstår alltid felen på samma del av minnet? Är adresserna alltid precis i början av fysiska ram? I så fall gissar jag att det är bios som korruptar den delen av minnet. Eftersom du redan testat med olika minnen och Err-Bits är slumpmässigt så är det ännu mer troligt att det inte är minnena det är fel på.

Linux kerneln har olika trick för att arbeta sig runt bios ram korruption. Det kanske inte är så lätt att testa om man inte använt det innan men här är några linux kernel options att googla på.

Amount of low memory, in kilobytes, to reserve for the BIOS (X86_RESERVE_LOW)
Specify the amount of low memory to reserve for the BIOS.
The first page contains BIOS data structures that the kernel
must not use, so that page must always be reserved.
By default we reserve the first 64K of physical RAM, as a
number of BIOSes are known to corrupt that memory range
during events such as suspend/resume or monitor cable
insertion, so it must not be used by the kernel.
You can set this to 4 if you are absolutely sure that you
trust the BIOS to get all its memory reservations and usages
right. If you know your BIOS have problems beyond the
default 64K area, you can set this to 640 to avoid using the
entire low memory range.
If you have doubts about the BIOS (e.g. suspend/resume does
not work or there's kernel crashes after certain hardware
hotplug events) then you might want to enable
X86_CHECK_BIOS_CORRUPTION=y to allow the kernel to check
typical corruption patterns.

Check for low memory corruption (X86_CHECK_BIOS_CORRUPTION)

Periodically check for memory corruption in low memory, which
is suspected to be caused by BIOS. Even when enabled in the
configuration, it is disabled at runtime. Enable it by
setting "memory_corruption_check=1" on the kernel command
line. By default it scans the low 64k of memory every 60
seconds; see the memory_corruption_check_size and
memory_corruption_check_period parameters in
Documentation/kernel-parameters.txt to adjust this.
When enabled with the default parameters, this option has
almost no overhead, as it reserves a relatively small amount
of memory and scans it infrequently. It both detects corruption
and prevents it from affecting the running system.
It is, however, intended as a diagnostic tool; if repeatable
BIOS-originated corruption always affects the same memory,
you can use memmap= to prevent the kernel from using that
memory.

Med tanke på hur klen PS4 var när den släpptes så är det inte konstigt att den inte skulle räcka hela generationen ut. PS3 hade en produktionskostnad på $840 och såldes för $600. PS4 hade produktionskostnad på $381 och såldes för $400. Även utan inflation är det under halva hårdvarukostnaden för PS4 jämfört med PS3.

Nu ska jag se om jag hänger med. Du har en filserver med en disk som använder rsnapshot för att backupa två andra datorer? På filservern ser katalogstrukturen ut som:

/mnt/backup/weekly.0/backup/zarkov/
/mnt/backup/weekly.0/backup/frugan/
/mnt/backup/weekly.1/backup/zarkov/
/mnt/backup/weekly.1/backup/frugan/
...

Sen har du en offsite raspberry som också gör inkrementell backup med rsnapshot av hela filserver disken? Nu är disken i filservern full så du vill skaffa en till disk och ändra filstrukturen så den blir såhär?

/mnt/zarkovbackup/weekly.0/
/mnt/zarkovbackup/weekly.1/
/mnt/frugansbackup/weekly.0/
/mnt/frugansbackup/weekly.1/

där /mnt/zarkovbackup är den nya mountpointen för den gamla disken /mnt/backup och /mnt/frugansbackup är den nya disken? Eftersom rsnapshot bara stöder en "snapshot_root" i konfig filen antar jag att du ska skapa två rsnapshot konfig filer, en med /mnt/zarkovbackup som snapshot_root och en annan med /mnt/frugansbackup som snapshot_root och använda -c flaggan för att välja vilken konfig fil som ska användas?

Det borde gå att splittra backupen så du vill för det borde inte finnas några hårdlänkar mellan din och frugans kataloger. Även om samma filer finns i din och frugans kataloger så är rsnapshot inte smart nog att deduplikera dom med hårdlänkar. Kopiera alla kataloger /mnt/backup/weekly.*/backup/frugan/ till nya disken /mnt/frugansbackup/weekly.*/ med ett program som bevarar hårdlänkar. Rsync med följande argument duger rsync -v --stats -P -a --numeric-ids -H -A -X source dest.

Jag använder många olika backups beroende på vad det är för data jag backupar.

För den viktigaste datan som dokument, bilder och konfigfiler anväder jag incremental backup med rsnapshot. Jag sparar 15 daily och 12 monthly kopior. Jag använder rsnapshot för att det är enkelt att återställa från backup när man klantat till det.
För backup av långtidslagring använder jag snapraid. Jag backar upp 12TB data på 7 datadiskar mha 2 parity diskar.
Den viktigaste datan är även synkad till min laptop mha unison.

För offsite backup har jag konto hos rsync.net och använder min egna lösning för att backa upp den viktigaste datan med kryptering. Det finns många off the shelf lösningar som duplicity, attic, obnam, osv men alla har brister jag inte gillar så jag kör min egna lösning.

Alla gör sina egna beslut och får stå för konsekvenserna men när det gäller DNA sekvensering fattar man även beslut för sina släktingar. Det är därför jag tycker att det är god sed att fråga släktingarna om tillåtelse först.