解决办法
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显示版本信息