Изпечатай

[mikis]

Ситуацията е следната:

На компютъра ми имам инсталирани Уиндоус ХП и Дебиан Линукс инсталиран от Кнопикс. Системата е малко архаична защото отдавна нямам Интернет. Ядрото е компилирано самостоятелно, версията е 2.4.29.

Работата е там, че Линукса си работеше много добре и стабилно докато по здравословни причини се наложи да изляза от вкъщи за повече от месец. През това време компютърът не е пипан от никой (1 парола на БИОС, 1 на Ун ХП и 1 на Линукс-а). Когато се върнах и пуснах компютъра за първи път след едномесечната пауза, реших да освободя малко мсто като кодирам едно останало ДВД. Оставих го да мачка през нощта, на сутринта се събуждам и го виждам забил. Тотално. Нито можех да мърдам мишката, нито да отворя някоя виртуална конзола, нищо. Светодиода на кутията за твърдит дискове светеше постоянно.

От начало мислех, че е от dvdrip - програмата с която мачкам дисковете. Самата тя е графичен интерфейс на цял набор програми за работа с мултимедия - mplayer, mencoder, transcode и др.
Да ама не, както се казва. На следващия ден реших да организирам малко файловите системи и започнах да копирам-трия-местя разни работи от едно място на друго. Понеже Конкуерор (файловият мениджър) вади доста подробна информация за това какво копира-мести от къде за къде и с каква скорост ми направи впечатление, че по едно време скоростта на копиране падна на нула, а едва бе стигнало трийсетина процента. В този момент превключих на първата виртуална конзола (Ctrl+Alt+F1) и видях как едно съобщение за грешка много бързо се повтаря (на вируалната конзола нямаше влязъл потребител).

Съобщението гласеше горе-долу следното:

"Canot copy file! Disc not fount! или not available или нещо такова
Error #нещо си"

Не го записах защото си мислех, че ще го има някъде във /var/log или dmesg. Е да, ама не! Няма го.
Всички дялове са правилно описани във fstab и са монтирани правилно.
Сега е почти невъзможно да пусна Линукс-а защото изкарва едва няколко минути преди да забие.

Гледайки горното съобщение си мисля, че проблемът е хардуерен. Може би "лош" сектор някъде по линукските дялове. Някакви идеи от какво друго може да е?

В самата инсталация на Линукс нищо не е променяно, нито нещо е инсталирано, нито деинсталирано. Нов хардуер не е добавян, стар не е махан.

Реших да намеря нещо с което да тествам хардуера и попаднах на това. "Жива" дистрибуция с инструменти за тестване на различни компоненти на системата - памет, процесор, дискове и т.н.
Искам да попитам някой има ли опит с нея и нейните инструменти, особено при тестване на твърди дискове? Ако има хора, които са работили с нея моля да споделят опита си, защото няма как да направя резервно копие на 120 ГБ данни.

Това е в общи линии проблемът. Ако на някой му трябват повече данни, например съдържанието на някой .лог файл, да каже.

Отворен съм за всякакви предложения.  

[gotha]

Аз не че разбирам много, но виж какво бих направил. Първо тествай харда - аз лично съм имал най-много проблеми със скапани сектори и разни такива. Второто нещо е стандатното преинсталиране. Напоследък машината ми започна да забива доста често заради горещината, така че не бих я пропускал като фактор. Моята БОЗА се размаза вече от постоянно рестартиране, а пък AmaroK вече не иска да пуска по повече от една песен  '> .
За дистрибуцията, която си избрал нищо не мога да ти кажа, помня само, че някъде из сайта бяха писали за нея.
Нека оставя по-компетентните да си кажат мнението.

[vstoykov]

Пробвай оперативната памет. Може да го направиш с някоя жива дистрибуция (напр. VS Live, Knoppix).
Ако си с VS Live напиши memtest там, където се пишат параметри на ядрото (вж. http://vstoykov.hit.bg/vslive/img/start_10.png).

http://www.memtest.org/
http://www.memtest86.com/

Преди време и аз се чудих защо ядрото забива твърде често (а Windows-a изобщо не иска да зареди). Тази програма ми помогна да разбера причината.

[mikis]

Цитат (gotha @ Юли 25 2006,17:52)

Аз не че разбирам много, но виж какво бих направил. Първо тествай харда - аз лично съм имал най-много проблеми със скапани сектори и разни такива. Второто нещо е стандатното преинсталиране. Напоследък машината ми започна да забива доста често заради горещината, така че не бих я пропускал като фактор. Моята БОЗА се размаза вече от постоянно рестартиране, а пък AmaroK вече не иска да пуска по повече от една песен  '> . За дистрибуцията, която си избрал нищо не мога да ти кажа, помня само, че някъде из сайта бяха писали за нея. Нека оставя по-компетентните да си кажат мнението.

Уф, да му се не види и на лаптоп-а   Написах едно дълго обяснение, натиснах не каквото трябва и си затворих таба (имаше една емотинка на която едно жълто човече си удряше главата в стената).

Хайде пак, за втори път, по-внимателно...

За температурите, не мисля, че е от тях. Направих няколко теста с Burn-in Wizzard на SiSoft Sandra под Windows (последният път когато имах нет на "щайгата" lm_sensors не поддържаха сензорите на дъното ми) и резултатите ми изглеждат нормални. По-късно като имам възможност ще дам логовете на сандрата.
Процесорът е АМД Дюрон 1000 изпържен на 1200. Ядрото е Морган, ако не се лъжа. Паметта е 1 модул 128 МБ ДДР 333 и 1 модул 512 МБ ДДР 333.
На процесора има голям вентилатор с 80 мм перка. Отделно в кутията имам още две 80 мм перки, които осигуряват вентилацията вътре.
Според мен ако причината беше процесор-памет или прегряване, то и Уиндоуса щеше да се дъни също толкова често.

[mikis]

Цитат (vstoykov @ Юли 25 2006,18:20)

Пробвай оперативната памет. Може да го направиш с някоя жива дистрибуция (напр. VS Live, Knoppix). Ако си с VS Live напиши memtest там, където се пишат параметри на ядрото (вж. http://vstoykov.hit.bg/vslive/img/start_10.png). http://www.memtest.org/ http://www.memtest86.com/ Преди време и аз се чудих защо ядрото забива твърде често (а Windows-a изобщо не иска да зареди). Тази програма ми помогна да разбера причината.

memtest ще го пусна със сигурност.
Междудругото, когато се опитам да отворя връзката която си дал ми дава следното:

Цитат

файлът, който се опитвате да достигнете не бе намерен възможните причини за това са:     * физически не съществува на сървъра;     * грешна връзка (hyperlink) към него;     * въвели сте невалиден адрес или сте допуснали грешка.

И с риск да стана досаден, още малко съвсем добронамерен бъг-репорт  '>
Вчера изпекох VS Live на едно СД и не успях да открия как се пуска memtest   Предполагам, че грешката е в задклавиатурното устройство, но и на сайта на ВС Лайв не намерих нещо по въпроса.
Ще съм ти благодарен ако ми кажеш как става врътката  '>

[mikis]

Така. Ето изхода от бърн-ин уизард на Сисофт-Сандра:
за процесора

Цитат

SiSoftware Sandra Run 35 executing... Board Temperature : 37.0°C (Min 34.0°C; Avg 35.3°C; Max 37.0°C) CPU Temperature : 63.0°C (Min 53.0°C; Avg 60.7°C; Max 63.0°C) CPU Fan Speed : 3309rpm (Min 3277rpm; Avg 3334rpm; Max 3375rpm) CPU Voltage : 1.79V (Min 1.79V; Avg 1.83V; Max 1.86V) CPU Core Power : 55W (Min 55W; Avg 57W; Max 59W) CPU Cooling System Thermal Resistance : 0.47°C/W (Min 0.33°C/W; Avg 0.44°C/W; Max 0.47°C/W) CPU Arithmetic Benchmark : Started on 24 Юли 2006 г. at 16:55:28... CPU Arithmetic Benchmark : Finished on 24 Юли 2006 г. at 16:55:48. Burn-in Wizard Finished Successfully : Yes

и за паметта

Цитат

Run 3 executing... Board Temperature : 36.0°C (Min 36.0°C; Avg 36.0°C; Max 36.0°C) CPU Temperature : 59.0°C (Min 55.0°C; Avg 57.7°C; Max 59.0°C) CPU Fan Speed : 3342rpm (Min 3309rpm; Avg 3320rpm; Max 3342rpm) CPU Voltage : 1.82V (Min 1.82V; Avg 1.83V; Max 1.84V) CPU Core Power : 57W (Min 57W; Avg 57W; Max 58W) CPU Cooling System Thermal Resistance : 0.40°C/W (Min 0.33°C/W; Avg 0.38°C/W; Max 0.40°C/W) Memory Bandwidth Benchmark : Started on 24 Юли 2006 г. at 17:32:29... Memory Bandwidth Benchmark : Finished on 24 Юли 2006 г. at 17:33:30. Cache & Memory Benchmark : Started on 24 Юли 2006 г. at 17:33:30... Cache & Memory Benchmark : Finished on 24 Юли 2006 г. at 17:38:36. Burn-in Wizard Finished Successfully : Yes

Под Линукс memtest в крайна сметка го пуснах под grml, но има проблем със тестването на цялата памет. Имам общо 640 МБ РАМ и при опит да я тествам например с

memtest all 1 --log

вади следния изход

Allocated /*повече от колкото имам*/ bytes... trying mlock

и така зависва линукса. Мога единствено да отварям виртуални конзоли, но не и да пиша в тях.
Пробвах да задам точният размер на паметта с

memtest 640m 1 --log

но изхода е подобен на горния:

Allocated 671088640 bytes... trying mlock

и пак зависва Линукса. Пробвах и със 600 МБ, пак същото. Чак на 512 МБ запали и започна тестовете.
Аз си го обяснявам по два начина: 1. Или имам повредена памет, но не вярвам защото дали е така може да се разбере като свършат тестовете, а не преди да са започнали; 2. Бъг в програмата? Програмата я изпълнявам като root и единствения монтиран дял е swap partition /dev/hda3. Други идеи за това защо се цупи memtest?
За съжаление на тази "жива" дистрибуция няма пакета memtest86+ за да видя с него как стоят нещата.

Снощи изчетох man pages на пакета smartmontools за проверка на твърдите дискове. Никъде не пишеше "използвайте на ваша отговорност" или "възможна е загуба на данни при работа с програмата". Само пише да не се ползва за дискове на които има монтирани файлови системи, така че днес най-вероятно мисля да видя какъв заек ще излезе от там.

[cartman]

Здравей,не съм специалист,но следя темата,за да разбера и науча нещо за себе си.Това обаче ми направи впечатление:

Цитат

... единствения монтиран дял е swap partition /dev/hda3...

И имам един въпрос: пишеш,че имаш и ХР.То как се държи?Защото ако забива по същия начин (в Линукса си го установил при копиране и местене на файлове,доколкото разбирам),явно харда е заминал.Ако пък се държи стабилно (доколкото е възможно за М$ продукт '> ),то според мене трябва да погледнеш Линукската файлова система и защо имаш само swap дял.Може би ще се изхвърля,но според мене всичко се е размонтирало и е останал само swap-a.
Успех!

[kill_u]

Абе едва ли е от RAM паметта защото иначе бозата щеше да изкара син екран веднага много е чувствителна горката към повредени сектори на RAM паметта...

[redcure]

Здравей,

Според мен проблема е в харда. Преди време имах един компютър, който при прехвърлянето на по-големи файлове умираше (под Win 98 беше). Мислех, че е от паметта, но и след като я смених, проблема продължаваше. Друг проблем, който ми се беше случил със замръзване на системата беше от eth-то. Не можах да си го обясня, но при смяна на лан картата всичко си тръгна както трябва.

Във всички случай се приготви за нов hardware. Предполагам, че диска ти е Seagate. Доста хора започнаха да се оплакват от тях.

Всичко най-свежо от мен и успех.

Интересна тема...

Разбирам, че след пауза от един месец си пускаш компютъра, оставаш го за през нощта да компресира видео и след това той започва да забива много сериозно. Това значи ли, че преди да "пренощува" компютъра ти си е работил добре?
Ако е така, може би по някакъв начин е прегрял (било е топло, той е компресирал цяла нощ горкичкия). Но не знам къде може да е причината. Аз бих се усъмнил най-вече за твърдия диск. Виж тази страничка - има колекция от софтуер за тестване на дискове. Дано помогне...
Съвет за тестването на паметта с memtest86: някога бях чел, че ако правиш тестове на RAM-а при работеща ОС се тества само свободния обем, което не е много полезно. При Knoppix и VSLive memtest86 се пуска от boot prompt-a: просто пишеш memtest и натискаш Enter... '> така ще се тества много по-голям обем от паметта. Така аз съм откривал грешки по модулите памет, които съм си купувал някога...

Еми...
Успех!  '>

[mikis]

Явно съм позабравил доста работи, като например, че memtest се пуска от boot promt-а на живите дистрибуции. Благодаря за пояснението защото се оказа, че един от многото проблеми е този с паметта или по-скоро прегряването й.

В крайна сметка системата е изпържена и трябваше да се досетя, че това може да е една от причините за проблемите. Ползвах две живи дистрибуции - VS Live с Memtest86 и Knoppix с Memtest86+ като и в двата случая оставих тестовете да минат целите поне по два пъти. И така дойде първата изненада, и двете програми откриха грешки - една на тест3 и много на тест4. Направих това, което пише в документацията - започнах да махам и размествам модулите за да разбера кой точно е сдал. Пуснах тестовете на всеки модул по отделно и пак излязоха същите грешки. Тогава влязох в БИОС и върнах малко овърклокинга, върнах FSB на 133, съответно DDR на 266, пуснах пак тестовете и воала - няма грешки. Също така модула памет, който беше най-близо до процесора го преместих най-далеч и нещата с паметта и по-точно прегряването й се оправиха.

Сега на дневен ред са проблемите с дисковете.
За проверка ползвах fsck и съответните програми за съответните файлови системи. При мен /dev/hda2 e от тип ext3. Ето какво излезе в крайна сметка:

Цитат

root@3[knoppix]# fsck.ext3 -cv /dev/hda2 e2fsck 1.39-WIP (09-Apr-2006) Checking for bad blocks (read-only test): done 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/hda2: ***** FILE SYSTEM WAS MODIFIED *****   278741 inodes used (6%)    22942 non-contiguous inodes (8.2%)          # of inodes with ind/dind/tind blocks: 12579/167/0  6762362 blocks used (83%)        0 bad blocks        0 large files   243465 regular files    22514 directories     1635 character device files     3330 block device files        6 fifos      376 links     7768 symbolic links (7640 fast symbolic links)       14 sockets --------   279108 files

Така зададените опции включват read-only тест за лоши сектори с програмата badblocks и резултата е, че няма лоши сектори. Тази програма обаче може да прави и non-destructive read-write test, ако опцията "с" се ползва два пъти. Пробвах с тази команда:

root@3[knoppix]# fsck.ext3 -ccv /dev/hda2

но получавам следното съобщение:

/dev/hda2 is apparently in use by the system; it's not safe to run badblocks!

а нито една файлова система не е монтирана по време на тестовете. Не съм пробвал да пусна директно badblocks.
Имам няколко въпроса относно тази програма badblocks:
- защо горната команда ми дава такова съобщение при положение, че файловата система не е монтирана?
- има ли опасност ако пусна директно badblocks да проверява чрез non-destructive read-write test (евентуално чрез опцията "f") да съсипе информацията на съответната файлова система?
- може ли badblocks да проверява за лоши сектори и други файлови системи, например fat32 или reiserfs?

Другите тестове, които пуснах са от пакета smartmontools и по-специално smartctl. Пуснах и краткия (short) и дългия (long) тест, но не откри грешки или проблеми.

Цитат

root@1[knoppix]# smartctl -l selftest /dev/hda smartctl version 5.36 [i686-pc-linux-gnu] Copyright © 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error # 1  Extended offline    Completed without error       00%     11002         - # 2  Short offline       Completed without error       00%     11001         -

Това и за двата диска.
След това пробвах с testdisk и ето това се вижда от log-a за втория твърд диск

Цитат

Analyse Disk /dev/hdb - 20 GB / 18 GiB - CHS 38792 16 63 Geometry from i386 MBR: head=255 sector=63 heads/cylinder 255 (FAT) != 16 (HD) BAD_RS LBA=4192965 263088 BAD_RS LBA=4193028 263151 get_geometry_from_list_part_aux head=16 nbr=1 get_geometry_from_list_part_aux head=8 nbr=1 get_geometry_from_list_part_aux head=16 nbr=1 get_geometry_from_list_part_aux head=32 nbr=1 get_geometry_from_list_part_aux head=64 nbr=1 get_geometry_from_list_part_aux head=128 nbr=1 get_geometry_from_list_part_aux head=240 nbr=1 get_geometry_from_list_part_aux head=255 nbr=6 Current partition structure: check_FAT: Incorrect number of heads/cylinder 255 (FAT) != 16 (HD)  1 * FAT16 >32M               0   1  1  4159  10 63    4192902 [NO NAME] Warning: Bad ending head (CHS and LBA don't match)  2 E extended LBA          4159  11  1 38791  13 63   34909245 Warning: Bad ending head (CHS and LBA don't match)  5 L Linux                 4159  12  1 38791  13 63   34909182 Warning: Bad ending head (CHS and LBA don't match) search_part() Disk /dev/hdb - 20 GB / 18 GiB - CHS 38792 16 63 heads/cylinder 255 (FAT) != 16 (HD)    D FAT16 LBA                0   1  1  4159  10 63    4192902 [NO NAME]      FAT16, 2146 MB / 2047 MiB    D Linux                 4159  12  1 38791  13 57   34909176      EXT3 Sparse superblock, 17 GB / 16 GiB file_read(5,16,buffer,39102332(38791/15/60)) read err: Partial read file_read(5,16,buffer,39102331(38791/15/59)) read err: Partial read get_geometry_from_list_part_aux head=16 nbr=1 get_geometry_from_list_part_aux head=8 nbr=1 get_geometry_from_list_part_aux head=16 nbr=1 get_geometry_from_list_part_aux head=32 nbr=1 get_geometry_from_list_part_aux head=64 nbr=1 get_geometry_from_list_part_aux head=128 nbr=1 get_geometry_from_list_part_aux head=240 nbr=1 get_geometry_from_list_part_aux head=255 nbr=4 Warning: the current number of heads per cylinder is 16 but the correct value may be 255. You can use the Geometry menu to change this value. interface_write()   No partition found or selected for recovery simulate write! No extended partition TestDisk exited normally.

Тук въпросът ми е ако променя the current number of heads per cylinder чрез Geometry menu на същата програма, необходимо ли е и дали няма да оплескам нещата?

Отговора стана много дълъг и за сега ще спра до тук. Впрочем благодаря на всички, които се отзоваха