解決辦法
1.重啟看是否可以修復（很多機器可以）
2.使用用fsck – y 來修復文件系統
3.若，在進行修復的時候有的分區會報錯，重新啟動系統問題依舊
查看下分區結構
[root@localhost mobile]# more /etc/fstab
[root@localhost ~]# more /proc/mounts
[root@localhost ~]# mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (ro)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
查看ro掛載的分區,如果發現有ro，就重新mount
umount /dev/sda1
mount /dev/sda1 /boot
如果發現有提示「device is busy」，找到是什麼進程使得他busy
fuser -m /boot 將會顯示使用這個模塊的pid
fuser -mk /boot 將會直接kill那個pid
然後重新mount即可。
4.直接remount，命令為
[root@localhost ~]# mount -o rw,remount /boot
2. 如何使用ESX修復Linux虛擬機重啟只讀模式
在發生錯誤時，Linux文件系統能配置成三種不同的模式：
errors=continue / errors=remount-ro / errors=panic
這三種模式分別表示忽略錯誤並只標記文件系統錯誤繼續運行，或者重啟系統為只讀，或者終止系統。
默認設置在文件系統superblock里，並能使用tune2fs(8)更改。
第一選擇（繼續運行）可能對包含非重要數據的系統管用，不過在給定的環境里讓伺服器在寫入錯誤之後繼續運行，就像什麼都有發生過一樣，這樣是不太好的。第三種選擇如果檢測到文件系統錯誤時，容易導致伺服器到內核的終止運行。不過，重啟可能不能修復問題，並且現在伺服器處於可更改狀態，管理員很難知道伺服器的狀況。
文件系統的理想設置是在檢測出錯誤時能重啟成只讀模式。這樣的話，管理員能診斷問題，採取合適的策略。重啟文件系統為只讀有時有一點影響，或者有時能導致伺服器不能正常停止運行。例如，如果一台Linux Web伺服器的/var/log文件系統重啟為只讀，這台伺服器上的一些服務將終止功能，因為不能寫入日誌。
那麼所有這一切與ESX有何關系？
路徑故障問題
多數ESX安裝為了共享存儲而附屬到存儲區域網路（SAN）上，並且這些伺服器有多路徑的傾向。多路徑是用於維持與SAN相連的一種技術，萬一發生存儲處理器、主機匯流排適配器、交換機，甚至光纖通道這樣的故障時還能與SAN連接。盡管ESX利用了多路徑，不過在給定時間里只有一條路徑可用。如果路徑失效，ESX開始發送和接收所有磁碟活動到另一條路徑時會發生路徑故障。
發生路徑故障是常見的，可能一個月一次或兩次。首要問題是Linux虛擬機對ESX路徑故障如何反應。如果發生路徑故障時，Linux虛擬機的磁碟寫入正進行一半，ESX將通知虛擬機的虛擬SCSI控制器線路繁忙，並且指示控制器等待。虛擬機決定磁碟不可訪問並有磁碟寫入故障，這引起錯誤。這個錯誤的處理將與文件系統所設置的「錯誤」值協調。由於在出現錯誤時，重啟系統為只讀模式逐漸成為標准做法，產生錯誤的文件系統在重啟動時就成只讀的了。只要文件系統不包括/var/log，那麼應該在syslog包括這個錯誤，如下所示：
SCSI Error : <0 0 0 0> return code = 0x20008
end_request: I/O error， dev sda， sector 4928181 Aborting journal on device dm-0 ext3_abort called.
EXT3-fs error (device dm-0): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only.
在經常發生錯誤時，這種做法是合適的，因為這給管理員提供了查找事件起因的機會，以便以後不再發生此類情況。
不過使用ESX和多路徑的話，發生路徑故障的機率增加了。如果發生這樣的情況，你該作出什麼反應？
使用ESX時，在當錯誤提示重啟配置為只讀模式的話，路徑故障經常發生。這是由於ESX和多路徑技術造成的，萬一發生某些請求故障，ESX和多路徑技術用於保持與存儲區域網路的固定連接。解決這個問題有以下三種方法：
1.在一小部分Linux版本上可以下載VMware補丁修復這個問題。
2.編輯內核源並手動安裝新內核模塊。
3.設置虛擬機以便在發生問題時發送郵件給你，然後你可以發送郵件請求VMware給Linux打上補丁。
3. Linux突然變成只讀文件系統,是何原因
可以先進入挽救模式備份數據後重做系統。
具體是什麼原因有很多。
最有可能是卸載了安裝包，同時把關聯的依賴包都卸載了。
這樣導致系統文件的缺失。
另外硬碟損壞也會導致這個問題。
4. Linux報錯只讀文件系統（集群非法關機、斷電）踩坑
出現錯誤的原因是由於我突發奇想寫了一個reboot集群的腳本，導致集群非法關機，然後就炸了。。。
在我使用上述reboot腳本後，發現MobaXterm（遠程工具）ssh死活連不上了。
趕緊檢查集群，發現如下報錯：
由於心急沒有管報錯（第一次見看不懂），直接輸密碼進入界面（我的是無可視化界面的CentOS 6.5）。
進界面後首先嘗試ssh其他節點。報錯。
嘗試從宿主機ping虛擬機，也ping不通。
那麼首先確定網路問題，查看/etc/sysconfig/network-scripts/ifcfg-eth0下的ip配置。
沒有問題。
輸入命令查看ip：
發現只有127.0.0.1，此時基本確定網路服務故障或未自啟動。
輸入命令啟動網路服務：
可以看到ip正常了。
測試宿主機ping虛擬機也正常了。
測試虛擬機ping虛擬機也正常了。
測試ssh本機也正。。。等等！
ssh沒通，報錯如下：
和最開始的報錯是一樣的，有了經驗，大致也猜測的出很有可能sshd服務也沒有自啟動。
輸入sshd啟動命令：
控制台報錯信息：
/var/lock/subsys/sshd not group or world-writable
出現此報錯，整個系統問題已經初現端倪。
雖然啟動sshd服務報錯了，但嘗試ssh本機卻正常了。
此時試著啟動集群的各個進程。
果然，大量報錯。
只讀文件系統 幾個大字摧毀我幼小的心靈
想起解決的網路、ssh問題，明白了罪惡的源頭就在....
就是它！萬惡之源！
首先查看掛載的分區：
又有報錯，不過看不懂。猜測是mount命令相關的文件也被修改成只讀了。
開機報錯的/dev/sda1分區並沒有掛載，而/dev/sda3是正常的rw（讀寫）狀態。
我有點暈。
嘗試修復/dev/sda3分區：
第一次使用fsck命令，看不太明白，不過該命令沒起到什麼作用。
有點絕望，隨手嘗試了修改/dev/sda3分區的狀態:
居然不報錯了！
至此報錯全部消失，網路服務和ssh服務也正常開機自啟了。
留下懵逼的我，具體原理日後學習再補充。
5. 如何使用ESX修復Linux虛擬機重啟只讀模式
在檢測到錯誤時，將Linux伺服器上的文件系統配置成重啟後的只讀模式是常見做法。不過，這種設置在結合使用VMware VI3時可能有意想不到的結果。
在發生錯誤時，Linux文件系統能配置成三種不同的模式：
errors=continue / errors=remount-ro / errors=panic
這三種模式分別表示忽略錯誤並只標記文件系統錯誤繼續運行，或者重啟系統為只讀，或者終止系統。
默認設置在文件系統superblock里，並能使用tune2fs(8)更改。
第一選擇（繼續運行）可能對包含非重要數據的系統管用，不過在給定的環境里讓伺服器在寫入錯誤之後繼續運行，就像什麼都有發生過一樣，這樣是不太好的。第三種選擇如果檢測到文件系統錯誤時，容易導致伺服器到內核的終止運行。不過，重啟可能不能修復問題，並且現在伺服器處於可更改狀態，管理員很難知道伺服器的狀況。
文件系統的理想設置是在檢測出錯誤時能重啟成只讀模式。這樣的話，管理員能診斷問題，採取合適的策略。重啟文件系統為只讀有時有一點影響，或者有時能導致伺服器不能正常停止運行。例如，如果一台Linux Web伺服器的/var/log文件系統重啟為只讀，這台伺服器上的一些服務將終止功能，因為不能寫入日誌。
那麼所有這一切與ESX有何關系？
路徑故障問題
多數ESX安裝為了共享存儲而附屬到存儲區域網路（SAN）上，並且這些伺服器有多路徑的傾向。多路徑是用於維持與SAN相連的一種技術，萬一發生存儲處理器、主機匯流排適配器、交換機，甚至光纖通道這樣的故障時還能與SAN連接。盡管ESX利用了多路徑，不過在給定時間里只有一條路徑可用。如果路徑失效，ESX開始發送和接收所有磁碟活動到另一條路徑時會發生路徑故障。
發生路徑故障是常見的，可能一個月一次或兩次。首要問題是Linux虛擬機對ESX路徑故障如何反應。如果發生路徑故障時，Linux虛擬機的磁碟寫入正進行一半，ESX將通知虛擬機的虛擬SCSI控制器線路繁忙，並且指示控制器等待。虛擬機決定磁碟不可訪問並有磁碟寫入故障，這引起錯誤。這個錯誤的處理將與文件系統所設置的「錯誤」值協調。由於在出現錯誤時，重啟系統為只讀模式逐漸成為標准做法，產生錯誤的文件系統在重啟動時就成只讀的了。只要文件系統不包括/var/log，那麼應該在syslog包括這個錯誤，如下所示：
SCSI Error : <0 0 0 0> return code = 0x20008
end_request: I/O error， dev sda， sector 4928181 Aborting journal on device dm-0 ext3_abort called.
EXT3-fs error (device dm-0): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only.
在經常發生錯誤時，這種做法是合適的，因為這給管理員提供了查找事件起因的機會，以便以後不再發生此類情況。
不過使用ESX和多路徑的話，發生路徑故障的機率增加了。如果發生這樣的情況，你該作出什麼反應？
使用ESX時，在當錯誤提示重啟配置為只讀模式的話，路徑故障經常發生。這是由於ESX和多路徑技術造成的，萬一發生某些請求故障，ESX和多路徑技術用於保持與存儲區域網路的固定連接。解決這個問題有以下三種方法：
1.在一小部分Linux版本上可以下載VMware補丁修復這個問題。
2.編輯內核源並手動安裝新內核模塊。
3.設置虛擬機以便在發生問題時發送郵件給你，然後你可以發送郵件請求VMware給Linux打上補丁。
在上半部分中，TechTarget中國的特約虛擬化專家Andrew Kutz在發生錯誤時，Linux文件系統能配置成哪三種不同的模式，並且描述了為什麼我們要使用第二種重啟後為只讀的模式以及這種模式在結合使用ESX時有什麼問題。本文我們將詳細解釋解決這些問題的方法。
現在我們來詳細講解這些選項。
選項1：執行VMware修復
許多用戶在VMware論壇上抱怨關於路徑故障的問題，VMware必須作出反應，所以他們為一小部分Linux版本發布了技術基礎文章和解決方案。現在為止，補丁所支持的Linux版本有Red Hat Enterprise Linux 3和4以及SUSE Linux Enterprise Server 9 SP3。如果你所管理的虛擬機使用的是這些操作系統里的一種作為子操作系統的話，那麼可以得到在「VMware's support Web site under KB 51306」得到修復支持。
選項2：修復內核模塊源（kernel mole source）
如果你的Linux版本不屬於VMware補丁支持的范疇，也可以修復這個問題。我們可以對虛擬機隱瞞文件里發生了一個問題，以便阻止文件系統錯誤。
現在，多數裝載軟體包管理系統的Linux版本裝載了內核源和內核header包，如RPM或DEB。要修補的話，內核源和內核header包都要設置，因為header包里包含最新的.config文件。為了下載Ubuntu Linux源和header包，只需輸入：
sudo apt-get install linux-source-`uname -r | sed "s/-.*//g"` linux- headers-`uname -r`
更改目錄到/usr/src，這有個目錄用於存放header包，不過不存放源。你需要釋放源工具包：
tar xjf linux-source-`uname -r | sed "s/-.*//g"`.tar.bz2
用編輯器打開文件「/usr/src/linux-source- `uname -r | sed "s/-.*//g"`/drivers/message/fusion/mptscsi.h」。在739行左右出現下面這樣的欄位：
if (scsi_status == MPI_SCSI_STATUS_BUSY)
sc->result = (DID_BUS_BUSY << 16) | scsi_status; else
sc->result = (DID_OK << 16) | scsi_status;
更換這個欄位的第二行，如下所示：
if (scsi_status == MPI_SCSI_STATUS_BUSY)
// sc->result = (DID_BUS_BUSY << 16) | scsi_status;
sc->result = (DID_OK << 16) | scsi_status; else
sc->result = (DID_OK << 16) | scsi_status;
保存文件退出編輯。從header的根目錄復制.config文件到源的根目錄。更改目錄到源目錄並運行：
make oldconfig
這個命令將從復制到源目錄的header包解析.config文件，接下來的命令需要執行一段時間：
make moles
下一步是用新內核模式取代舊的。在這樣做之前，請確保備份了舊內核模式，然後輸入：
cp /lib/moles/`uname -r`/kernel/drivers/message/fusion/mptscsih.ko / lib/moles/`uname -r`/kernel/drivers/message/fusion/mptscsih.ko.bak
現在復制新文件取代上面的：
cp /usr/src/linux-source-`uname -r | sed "s/-.*//g"`/drivers/message/ fusion/mptscsih.ko /lib/moles/`uname -r`/kernel/drivers/message/ fusion/
重啟伺服器，系統就不再那麼容易出現路徑故障了。
如果你運行的是Ubuntu虛擬機，內核版本為2.6.15-28-686，想走捷徑的話繼續往下看。我已經上傳了已修改好的源和內核對象文件到我的網站上，你可以直接去網站下載。這個文件是mptscsih.tar.gz。
選項3：Email通知
如果Linux虛擬機不受VMware補丁的支持，你也不太願意修改內核源的話，你至少應該配置虛擬機，以便發生問題時你能知道。一種方法是創建一個腳本，每10分鍾運行一次或隨你所選。下面是一個腳本例子：
#!/bin/bash
#
# use the first argument to this script as the
# email address to send notifications to
TO="$1"
#
# get the output from the mount command
#
MOUNT_OUT=`mount`
#
# see if the string 'ro' exists in the
# output of the mount command. be careful，
# if there is a CD-ROM inserted into the
# server this will always be true and you
# will get a lot of false positives
echo $MOUNT_OUT | grep \(ro\)
#
# get the return code for the grep
# operation.
#
RO=$？
#
# grep returns an exit code
# of 0 if there is a match
#
if [ "$RO" = "0" ]
then
#
# send an e-mail notification saying
# that there is a file-system that
# has been mounted as read-only
#
BODY=$MOUNT_OUT
echo read-only file systems found
echo $BODY
`which sendmail` -f root@`hostname --fqdn` -t << FooBar
From: root@`hostname --fqdn`
To: $TO
Subject: `hostname` has read-only file systems $BODY
FooBar
#
# exit with a status code of 1 if
# read-only file systems were found
#
exit 1
fi
#
# exit with a status code of 0 if no
# read-only file systems were found
#
exit 0
安裝這個腳本，不要忘記給它一個郵箱地址。如果虛擬機的一個文件系統重啟為只讀時，它會提醒你，給你忽略這個問題的機會。記住，這個腳本假定你運行的是本地郵件伺服器，不過也可以修改成通過中繼主機發送郵件。
6. linux文件系統自動變成只讀 為什麼
因為當前用戶對那個文件沒有相應的許可權，你可以在那個目錄執行命令 ls -l查看當前迴文件以及相應的所有者和對應的許可權答，drwxrwxrwx應該是這樣的，每一個字母都有可能是 - ，其中第一個d表示是不是文件夾，後面的分成三組，分別對應所有者，所屬組，其它用戶。r是讀許可權，w是寫，x是執行。 如果你是Ubuntu系統的話可以用sudo命令提升用戶許可權，系統會提示你輸入root用戶的密碼。如果是Redhat, Fedora, CentOS之類的系統就直接su -，然後系統會提示你輸入root密碼，這回你就有許可權了。 用root用戶是可以修改文件的所有者和所屬組的。詳細的你可以查一下chown和chgrp命令。要修改相應的許可權可以看一下chmod命令。 如果還有不明白的可以追問或者私信。Linux系統其實很不錯，日常用也很不錯，你需要的都能滿足。
7. linux系統文件只讀怎麼解決
1、mount:
用於查看哪個模塊輸入只讀，一般顯示為：
/dev/hda1 on / type ext3 (rw)
none on /proc type proc (rw)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda5 on /home type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/hda2 on /usr/local type ext3 (rw)
/dev/nb1 on /EarthView/RAW type ext3 (ro)（變為只讀了）
2、如果發現有ro，就重新mount，或者umount以後再
3、umount /dev/nb1
如果發現有提示「device is busy」，找到是什麼進程使得他busy
fuser -m /mnt/data 將會顯示使用這個模塊的pid
fuser -mk /mnt/data 將會直接kill那個pid
然後重新mount即可。
4、還有一種方法是直接remount，命令為
mount -o rw,remount /mnt/data
二
具體深入的做法，情況不同可以自行選擇：
伺服器/var/log/messages報錯 ：
end_request: I/O error, dev sda, sector 122194293 Buffer I/O error on device sda1, logical block 446493 lost page write e to I/O error on sda1
下面是整個處理全過程
[root@php5 ~]# fdisk -lu #第一步 ：找出本地扇片所在的分區。
Disk /dev/sda: 73.4 GB, 73407868928 bytes
255 heads, 63 sectors/track, 8924 cylinders, total 143374744 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 63 4096574 2048256 83 Linux
/dev/sda2 4096575 75778604 35841015 83 Linux
/dev/sda3 75778605 129034079 26627737+ 83 Linux
/dev/sda4 129034080 143364059 7164990 5 Extended
/dev/sda5 129034143 139267484 5116671 83 Linux
/dev/sda6 139267548 143364059 2048256 82 Linux swap
[root@php5 ~]# tune2fs -l /dev/sda3 |grep "Block size" #找到block大小。
Block size: 4096
(122194293-75778605)*512/4096 =528691 利用公式算出邏輯塊地址
b = (int)((L-S)*512/B)
[root@php5 ~]# debugfs
debugfs 1.35 (28-Feb-2004)
debugfs: open /deb/sda3
/deb/sda3: No such file or directory while opening filesystem
debugfs: open /dev/sda3
debugfs: icheck 582391
Block Inode number
582391 277584
debugfs: ncheck 277584
Inode Pathname
277584 /users/inn.net.cn/data/upload/download/innshow004.rar
debugfs: quit
[root@php5 ~]#dd if=/dev/zero of=/dev/sda1 bs=4096 count=1 seek=582391 #找到這個快的文件之後，需要做好備份，我們強制把它設置為0位元組。
[root@php5 ~]# sync
8. 如何快速解決linux只讀系統 Read-only file system
解決方法 ：使用fsck手動修復，具體操作如下： 使用root進入單用戶模式，運行 fsck.ext3 -y /dev/vda3 說明：ext3的文件系統使用fsck.ext3，ext4文件系統使用fsck.etx4。/dev/vda3是系統/根分區。運行完畢後，reboot重啟系統就恢復正常。20多台出問題的都是這樣修復的，無失敗案例。fsck.ext3開始進入掃描、修正文件系統，這個過程有時很快，有時比較長，中間有數次停頓的過程，只需等待即可，千萬不要以為死機而重啟伺服器。修正完文件系統後，如果沒有提示重啟系統，也需要reboot來重啟系統。 擴展知識：fsck簡介 fsck不僅可以對文件系統進行掃描，還能修正文件系統的一些問題。注意的是fsck掃描文件系統時一定要在單用戶模式、修復模式或把設備umount後進行。建議在單用戶模式下運行。如果掃描正常運行中的系統，會造成系統文件損壞。 文件系統掃描工具有fsck、fsck.ext2、fsck.ext3、fsck.ext4、fsck.msdos、fsck.cramfs、fsck.ext4dev、fsck.vfat。最好是根據不同的文件系統來調用不同的掃描工具，比如ext3的文件系統使用fsck.ext3，ext4文件系統使用fsck.ext4等。 /dev/vda3是ext3的文件系統，這里介紹fsck.ext3的參數： [語法] fsck.ext3[必要參數][選擇參數][設備代號] [功能] fsck.ext3命令：針對ext3文件系統進行檢測修復 -a非互交模式，自動修復 -c檢查是否存在有損壞的區塊。 -C <反敘述器> fsck.ext3命令會把全部的執行過程，都交由其逆向敘述，便於監控程序 -d詳細顯示命令執行過程 -f強制進行檢查 -F檢查文件系統之前，先清理該保存設備塊區內的數據 -l <損壞區塊文件> 把文件中所列出的損壞區塊，加入標記 -L <損壞區塊文件> 清除所有損壞標志，重新標記 -n非交互模式,把欲檢查的文件系統設成只讀 -P <數字> 設置fsck.ext2命令所能處理的inode大小為多少 -r交互模式 -R忽略目錄 -s順序檢查 -S效果和指定「-s」參數類似 -t 顯示fsck.ext2命令的時序信息。 -v顯示詳細的處理過程 -y關閉互動模式 -b <分區第一個磁區地址> 指定分區的第一個磁區的起始地址/Super Block -B <區塊大小> 設置該分區每個區塊的大小 -I設置欲檢查的文件系統，其inode緩沖區的區塊數目 -V顯示版本信息