El sistema de archivos raíz se montó bien bajo compresión y después de actualizar a Wheezy. He estado viviendo con esto por un tiempo, así que no estoy exactamente seguro, pero creo que comenzó después de hacer una actualización dist en wheezy, pero eso podría ser una coincidencia. La máquina es una Lenovo T400 FWIW.
foto de la pantalla de arranque1muestra las primeras advertencias sobre el sistema de archivos de sólo lectura; obviamente no se registra nada
fsck no encuentra problemas2
mount -o remount,rw /
arriba funciona bien
(pero tengo que reiniciar network-manager y gdm3 para obtener un sistema utilizable; no estoy seguro de que esté relacionado, pero parece que no puedo conectarme a un servicio que se ejecuta en localhost, por ejemplo, python -m SimpleHTTPServer 8080 y en otro terminal w3m agota el tiempo de envío de la solicitud al puerto localhost 8080)
No noto nada malo en fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/sda1 during installation
UUID=2934c627-6f1a-438b-a877-1544108c7418 / ext3 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=39b1f59e-6193-4c46-8b4d-80b183f0b19c none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/sdb1 /media/usb0 auto rw,user,noauto 0 0
Cualquier consejo sería muy apreciado. Con suerte, estoy haciendo algo obviamente incorrecto y solucionable, pero si no, ¿algún consejo sobre cómo depurar?
...
tune2fs -l /dev/sda1
salidas
tune2fs 1.42.2 (27-Mar-2012)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 2934c627-6f1a-438b-a877-1544108c7418
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 14893056
Block count: 59547904
Reserved block count: 2977395
Free blocks: 50391869
Free inodes: 14576981
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1009
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Tue May 3 01:44:56 2011
Last mount time: Wed Apr 18 13:11:25 2012
Last write time: Tue Apr 17 23:51:46 2012
Mount count: 5
Maximum mount count: 25
Last checked: Tue Apr 17 23:51:46 2012
Check interval: 15552000 (6 months)
Next check after: Sun Oct 14 23:51:46 2012
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 9145036
Default directory hash: half_md4
Directory Hash Seed: af8ca7f0-bcad-49f3-98c0-9b19a531a885
Journal backup: inode blocks
...
Parece que /etc/init.d/checkroot.sh no se ejecuta en el arranque, y ese es el script que finalmente vuelve a montar la raíz como rw (si lo ejecuto después del arranque, hace exactamente eso). Estoy usando Debian testing/wheezy. Hay anotaciones de dependencia en los archivos /etc/init.d, pero más allá de eso, no estoy seguro de cómo contar más sobre el sistema de inicio.
...
Se solucionó, pero no tengo idea de cómo sucedió o si la solución es exactamente como debería ser el sistema. Noté checkfs y mtab en /etc/rcS.d, pero no checkroot, así que lo agregué:
cd /etc/rcS.d
ln -s ../init.d/checkroot.sh S06checkroot.sh
Después de reiniciar dos veces (la primera vez podría haber sido mi confusión, pero agregué más instrumentación a checkroot.sh entre ellas), volví a ejecutar rw en el arranque (y el problema con escuchar/solicitar desde localhost desapareció, así que Supongo que estaba relacionado).
(Veo que en un sistema de compresión al que tengo acceso está en S07checkroot.sh; quizás estuve cerca).
Respuesta1
Hay un error en su sistema de archivos /root y fstab vuelve a montar /root como de solo lectura.
La línea en fstab
UUID=2934c627-6f1a-438b-a877-1544108c7418 / ext3 errors=remount-ro 0 1
es lo que hace que /root se monte en solo lectura.
Desde la mount (8)página de manual
errors={continue|remount-ro|panic}
Define the behaviour when an error is encountered. (Either ignore errors
and just mark the filesystem erroneous and continue, or remount the
filesystem read-only, or panic and halt the system.) The default is set in
the filesystem superblock, and can be changed using tune2fs(8).
En última instancia, debería descubrir qué está mal con su sistema de archivos /root. Puede arrancar fácilmente desde un disco de rescate y ejecutar un fsck en /root. Si elige ignorar los posibles errores, simplemente cambie la línea en fstab a errors=continue.
Respuesta2
Tuve este problema y fue causado por un UUID incorrecto para el FS raíz configurado en /etc/fstab. Supongo que alguna actualización lo detectó automáticamente y se equivocó.
Vuelva a montar la partición / rw, utilícela blkidpara obtener el UUID correcto y reemplácela en /etc/fstab, lo arregló para mí.
Respuesta3
Su sistema de archivos raíz no se está montando en lectura/escritura porque no se lo está indicando.
UUID=2934c627-6f1a-438b-a877-1544108c7418 / ext3 errors=remount-ro 0 1
Sus opciones de montaje son solo errors=remount-ro, no hay nada sobre lectura/escritura allí. La práctica estándar es tener defaultsopciones de montura. defaultsproporciona varias otras opciones de montaje, una de ellas es rw, proporcionando así lectura/escritura.
Por lo tanto, debe agregar defaultso rwal campo de opciones de su fstab.
EDITAR:
Al pensarlo un poco más (y a partir de la discusión en los comentarios a continuación), es posible que las opciones defaultsy rwno lo solucionen. La razón es que el comportamiento de remontaje depende completamente de los scripts de inicio de la distribución. He visto distribuciones que extraen la configuración de montaje de fstab en el arranque, pero también es posible que el script de inicio ignore por completo las opciones de fstab cuando vuelve a montar la raíz (y usa algunas configuraciones codificadas en el script).