Solução do Ubuntu VM “read only file system”?

Question

Eu ia instalar as ferramentas VMWare em uma máquina virtual do servidor Ubuntu, mas me deparei com a questão de não ser capaz de criar um diretório cdrom no diretório / mnt. Então eu testei para ver se era apenas um problema de permissões, mas eu não conseguia nem criar uma pasta no diretório inicial. Ele continua a afirmar que é um sistema de arquivos somente leitura. Eu sei um pouco sobre Linux e não me sinto confortável com isso ainda. Qualquer conselho seria muito apreciado.

Informações solicitadas de um comentário:

username@servername:~$ mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

Para uma saída raiz segura.

root@server01:~# mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

    

Answer 1

Embora esta seja uma questão relativamente antiga, a resposta ainda é a mesma. Você tem uma máquina virtual (em execução em um host físico) e algum tipo de armazenamento (armazenamento compartilhado - um SAN FC, armazenamento iSCSI, um compartilhamento NFS - ou armazenamento local).

Com a virtualização, muitas máquinas virtuais tentam acessar os mesmos recursos físicos ao mesmo tempo. Devido a limitações físicas (número de operações de leitura / gravação - IOPS, taxa de transferência, latência), pode haver um problema para atender a todas as solicitações de armazenamento de todas as máquinas físicas ao mesmo tempo. O que geralmente acontece: você poderá ver "tentativas SCSI" e falhas nas operações SCSI nos sistemas operacionais de suas máquinas virtuais. Se você receber muitos erros / tentativas em um determinado período de tempo, o kernel configurará os sistemas de arquivos montados como somente leitura para evitar danos ao sistema de arquivos.

Para encurtar a história: seu armazenamento físico não é "poderoso" o suficiente. Existem muitos processos (máquinas virtuais) acessando o sistema de armazenamento ao mesmo tempo, suas máquinas virtuais não obtêm a resposta do armazenamento com rapidez suficiente e o sistema de arquivos é somente leitura.

Não há muitas coisas que você pode fazer. A solução óbvia é melhor / armazenamento adicional. Você também pode modificar os parâmetros para tempos limite de SCSI no kernel do Linux. Detalhes são descritos, por exemplo, em:

link

link

No entanto, isso apenas "adiará" seus problemas, porque o kernel só recebe mais tempo antes que o sistema de arquivos seja definido como somente leitura. (Ou seja, você não resolve a causa do problema).

Minha experiência (vários anos com a VMware) é que esse problema existe apenas com os kernels do Linux (estamos usando o RHEL e o SLES) e não com os servidores do Windows. Além disso, esse problema ocorre em todos os tipos de armazenamento - FC, iSCSI, armazenamento local. Para nós, o componente mais crítico (e caro) em nossa infraestrutura virtual é o armazenamento. (Estamos usando agora o HP LeftHand com conexões iSCSI de 1 Gbps e não tivemos nenhum problema de armazenamento desde então. Escolhemos o LeftHand (através de soluções FC tradicionais) por sua escalabilidade.

    

Answer 2

Uma explicação provável é que há um problema de hardware (falha parcial no disco) e que o kernel remontou o sistema de arquivos raiz como somente leitura assim que detectou o problema, a fim de minimizar o problema. Uma maneira mais confiável de verificar as opções de montagem atuais é cat /proc/mounts ( grep ' / ' /proc/mounts para o sistema de arquivos raiz, ignore uma linha rootfs / … que é um artefato do processo de inicialização). Você presumivelmente descobrirá que rw,errors=remount-ro foi alterado para ro (outras opções podem ser exibidas além disso).

Os logs do kernel provavelmente contêm a mensagem Remounting filesystem read-only , precedida por erros de acesso ao disco. Os logs normalmente vivem em /var/log/kern.log , no entanto, se isso estiver em um sistema de arquivos agora somente leitura, a mensagem não será mostrada lá, embora os erros anteriores devam aparecer. Você também pode ver os últimos erros do kernel com o comando dmesg .

Como um aparte, no Ubuntu, o local habitual para pontos de montagem (usado pela interface de desktop) está sob /media (por exemplo, /media/cdrom0 ), embora você possa usar /mnt ou /mnt/cdrom se desejar.

¹ _{mount relatórios de /etc/mtab . Se o sistema de arquivos raiz for somente leitura, /etc/mtab não pode ser mantido atualizado.}

    

Answer 3

O que aconteceu foi que houve uma queda de energia no data center recentemente. Desde então, não toquei no meu servidor. Uma vez que nosso data center perde força, o VSphere torna o sistema de arquivos do Ubuntu somente legível até que seja reiniciado. Eu teria tentado reiniciar, mas não queria que todo o monitoramento ficasse maluco. Eu silenciei o Nagios (serviço de monitoramento) e tudo está funcionando bem agora que reiniciei o sistema. Obrigado por toda a entrada. É muito apreciado.

    

Answer 4

Pode ser óbvio, mas você é usuário "root" ao tentar fazer isso? / mnt é de propriedade de root e somente gravável por root. Você também pode verificar se você teve erros na inicialização. Sua saída acima diz que / (e, portanto, / mnt) deve ser remontado somente para leitura se o processo de inicialização detectar erros. Você pode alterar isso (ou seja, remontar como r / w) com o comando mount, mas eu não faria isso a menos que você tenha certeza de que o que causou o erro não é sério.