Isso é totalmente ridículo (IMHO). Eu atualizei um computador para 16.04 (Xubuntu) e tive problemas com ele que discuti em outro lugar leia aqui . Então, esperei algumas semanas até conseguir que o computador funcionasse bem e, em seguida, atualizei meu outro computador, um single core vintage de 2006. Depois que a atualização foi instalada, não consegui inicializar no Xubuntu. Eu tentei os truques que fiz para o meu primeiro computador, acho que o mais útil foi substituir o "modo silencioso" por "nomodeset" em /boot/grub/grub.cfg. Tudo isso fez foi me iniciar em uma interface de linha de comando. Depois que eu entrei, descobri que não era possível executar o startx para iniciar o ambiente da área de trabalho da GUI. Hmmm ... Um pouco mais de caça e tentando coisas diferentes, e descobri que minha partição raiz estava no modo somente leitura. Eu descobri que eu poderia corrigir isso com o comando
sudo mount -o remount,rw /
Depois que fiz isso, o sistema entrou imediatamente no ambiente de área de trabalho GUI (embora sem o driver gráfico e em resolução reduzida). Viva! Infelizmente, isso dura apenas para a inicialização atual. Toda vez que eu inicializo, estou na linha de comando e tenho que reemitir este comando. Não é uma solução.
Ao pesquisar isso, a maioria dos posts aponta para o arquivo / etc / fstab, e aponta para a opção para o sistema de arquivos raiz
errors=remount-ro
E que esta opção é para sua proteção, porque algo está errado com o sistema de arquivos raiz e você não deve escrever nele, e na verdade é melhor fazer o backup, porque está saindo. Execute um fsck nele. Bem, acho suspeito que isso ocorra imediatamente após uma atualização. Além disso, isso é em um SSD relativamente novo, e me disseram para não executar o fsck nele de qualquer maneira. Mas eu posso remover essa opção, e o sistema de arquivos raiz ainda aparece no modo somente leitura, então este não era um problema fstab.
Algo mais me ocorreu. No arquivo grub, a linha de lançamento é
linux /vmlinuz-4.4.0-38-generic root=/dev/mapper/vg_ssd1-xubu_root_ssd1 ro nomodeset $vt_handoff
Pouco antes de "nomodeset" (alterado de "quiet splash") é "ro". O Grug está inicializando meu sistema raiz no modo somente leitura? Eu mudei o "ro" para "rw", e também mudei "nomodeset" de volta para "quiet splash", salvei o arquivo e reiniciei. Ele surgiu bem no modo gráfico na resolução correta.
Hmmm .... eu corri
sudo upgrade-grub
para reconstruir o arquivo grub.cfg. Novamente, a linha de lançamento foi alterada de volta para "ro" e seria novamente reinicializada na linha de comando.
Meu upgrade estava incompleto? Executei os seguintes comandos para verificar uma atualização completa e, com certeza, outras coisas adicionais foram instaladas:
sudo apt-get -f install
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get autoremove
sudo apt-get clean
Eu novamente corri
sudo upgrade-grub
mas mais uma vez, a linha de lançamento foi definida como "ro".
Então eu fiz mais algumas pesquisas por aí. Eu olhei no arquivo /etc/grub.d/10_linux, e fiz uma busca por "ro". Eu encontrei o seguinte trecho de código:
if test -d /sys/firmware/efi && test -e "${linux}.efi.signed"; then
sed "s/^/$submenu_indentation/" << EOF
linux ${rel_dirname}/${basename}.efi.signed root=${linux_root_device_thisversion} ro ${args}
EOF
else
sed "s/^/$submenu_indentation/" << EOF
linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}
EOF
Eu tive que pesquisar sobre o que é o conteúdo assinado, e isso é sobre uma inicialização segura que protege seu sistema contra malware no setor de inicialização. Então, minha partição de inicialização do BIOS está infectada? Eu tenho uma versão do Windows XP no sistema, embora ele não seja executado muito mais.
Mas, o status "ro" é implementado em ambos os lados da instrução if. Eu fiz algumas brincadeiras e descobri que era a condição "else" que estava sendo implementada. Então eu mudei isso de "ro" para "rw", então agora o snippet inteiro é assim:
if test -d /sys/firmware/efi && test -e "${linux}.efi.signed"; then
sed "s/^/$submenu_indentation/" << EOF
linux ${rel_dirname}/${basename}.efi.signed root=${linux_root_device_thisversion} ro ${args}
EOF
else
sed "s/^/$submenu_indentation/" << EOF
linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} rw ${args}
EOF
Eu reran
update-grub
E tudo saiu bem. Eu inspecionei a linha de lançamento no grub.cfg e ela tem "rw" ao invés de "ro".
linux /vmlinuz-4.4.0-38-generic root=/dev/mapper/vg_ssd1-xubu_root_ssd1 rw nomodeset $vt_handoff
Eu reiniciei e tudo deu certo. Então eu diria problema resolvido, mas não acho que seja. Eu não acho que isso seja apenas um bug no Grub. Alguns outros sistemas Linux encontrados pelo os-prober tinham linhas de lançamento que não especificavam "rw" ou "ro".
Eu não entendo o que está acontecendo aqui, e por que ele optou por "ro" em primeiro lugar. Se alguém puder ver algo sobre isso e uma solução melhor para esse problema, eu agradeceria muito.