Изпечатай

[Breakfist]

Здравейте,

Опитвам да редактирам определен файл на сървъра си, но получавам грешката "Read-only file system" (дори и с root потребител).
Не съм се логвал дори в сървъра от седмици, на авто пилот работи, а грешката е на лице от снощи.
От къде се получава този проблем и най-вече ме интересува, как се оправя?

Благодаря предварително.

[b2l]

Код:

mount -n -o remount,rw /

[Breakfist]

Код:

mount: block device /dev/sda1 is write-protected, mounting read-only

[spec1]

 И как точно се логваш в сървъра ?
 Според мен сървъра е спрян не по нормалния начин (напр:
 спиране на захранването), и после е пуснат, в този случай
 започва автоматична проверка на файловите системи. 
 Пусни ръчно:
 fsck

[Breakfist]

Код:

fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
fsck.ext3: Attempt to read block from filesystem resulted in short read while checking ext3 journal for /dev/sda1

Не е спирал сървъра. Ъптайма му го погледнах преди малко и е малко над 93 дни, а проблема е от снощи..

[tolostoi]

При грешка по време на четене/писане (по-скоро писане) ядрото премонтира файловата система като рийд онли, с цел да предотврати последвали грешки с грешно записване на данни по дяла. Това е предположение, провери логовете какво точно е станало, в сценария който описах по-горе е възможно да има проблем с хард диск или памет.

[Breakfist]

Не съм особено компетентен в Linux средите, можеш ли да ми кажеш кой лог трябва да прегледам?

[spec1]

  Виж директорията:   /var/log
  Дай изхода от командата:
  dmesg

[ntrance]

Грешката се получава  от счупен хард или от нещо подобно свързано с харда  .Вариянта ти е  да демаутнеш счупения дял   после да  се опиташ да го фикснеш с fsck  . Първи вариянт  рестарт и ще ти излезне един джам да се логнеш  пак ще ти е read-only   с командата mount -n -o remount,rw /  го фиксваш да не е read-only после се опитваш да оправип счупения дял  с fsck или livecd  и фиксваш харда ти или дяла който ти го е причинил това.

[Breakfist]

Няма да стане така..

Код:

mount -n -o remount,rw /
mount: block device /dev/sda1 is write-protected, mounting read-only

Код:

fsck
fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
fsck.ext3: Attempt to read block from filesystem resulted in short read while checking ext3 journal for /dev/sda1

[dejuren]

/dev/sda1 трябва да е демонтирана при проверката, ако както предполагам това ти е кореновия дял трябва да си стартирал от лайф СД за да направиш проверка с fsck. Второ - виж това указание http://www.cyberciti.biz/tips/surviving-a-linux-filesystem-failures.html По този начин пробвай да пуснеш проверката с алтернативен суперблок, но първо си направи бекъп!! Вариант който също може да ти се наложи да опиташ е да махнеш журнала на фаловата система преди проверката и да го възстановиш после така:

Код:

sudo debugfs -w -R "feature ^needs_recovery" /dev/sda1 # remove the needs_recovery flag
sudo tune2fs -O ^has_journal /dev/sda1 # remove the journal
sudo fsck -f /dev/sda1 # check/repair the filesystem
sudo tune2fs -j /dev/sda1 # Add an ext3 journal to sda1

За втори път ти казвам първо бекъп! Не мога повече да подчертая колко е важен - препоръчва се дори проверката да се пусне на клонинг на файловата система на друг диск, не на основния.

[dev_urandom]

A какво връща

tune2fs -l /dev/sda1

?

Edit:

Дай

dumpe2fs /dev/sda1 | grep superblock

[tolostoi]

/dev/sda1 трябва да е демонтирана при проверката, ако както предполагам това ти е кореновия дял трябва да си стартирал от лайф СД за да направиш проверка с fsck. Второ - виж това указание http://www.cyberciti.biz/tips/surviving-a-linux-filesystem-failures.html По този начин пробвай да пуснеш проверката с алтернативен суперблок, но първо си направи бекъп!! Вариант който също може да ти се наложи да опиташ е да махнеш журнала на фаловата система преди проверката и да го възстановиш после така:

Код:

sudo debugfs -w -R "feature ^needs_recovery" /dev/sda1 # remove the needs_recovery flag
sudo tune2fs -O ^has_journal /dev/sda1 # remove the journal
sudo fsck -f /dev/sda1 # check/repair the filesystem
sudo tune2fs -j /dev/sda1 # Add an ext3 journal to sda1

За втори път ти казвам първо бекъп! Не мога повече да подчертая колко е важен - препоръчва се дори проверката да се пусне на клонинг на файловата система на друг диск, не на основния.

Само искам да попитам, каква е логиката на това упражнение? Не се заяждам просто искам да науча нещо ново. Питам понеже при проверка и загубени данни fsck се опитва да ги възстанови от журнала, а като си го махнал какво се случва, предполагам все едно проверява ext2.

[dejuren]

Според мен логиката е да не се обръща внимание на загубения файл /var/cache/my/directory/unsignificant_cache/file, а да се въстанови неработещата файлова система (изглежда има повреден суперблок) . Загубените файлове ще са необходимото зло, за да се върне файловата система на дяла в действие. Може и да не съм прав, това е просто мое мнение.