Я использую Gentoo Linux, и некоторое время корневая файловая система монтируется только для чтения при загрузке. По понятным причинам это довольно раздражает, так как большинство сервисов запускаются неправильно (я не использую отдельную файловую систему для /var). После запуска системы я должен войти в систему, перемонтировать корневую файловую систему для чтения-записи, исправить /etc /mtab, смонтировать все остальные файловые системы из /etc /fstab, а затем запустить все отсутствующие демоны. Я знаю, что есть способы заставить систему работать должным образом с файловой системой только для чтения, но я бы скорее восстановил старое поведение доступной для записи корневой файловой системы.
Странно то, что после запуска mount / -o remount,rw
, файловая система монтируется в режиме записи без каких-либо ошибок. Я подозревал некоторые проблемы с fsck, но теперь я отключил автоматические проверки файловой системы на разделе (tune2fs -c0 -i0
).
Когда я запускаю dmesg, только эти строки вообще упоминают раздел, хотя я не уверен, что ничего не потеряно, потому что /var /log не доступен для записи:
EXT3-fs (sda5): mounted filesystem with writeback data mode</code>
EXT3-fs (sda5): using internal journal
Строка в /etc /fstab выглядит так:
/dev/sda5 / ext3 noatime 0 1
Я использую ядро 2.6.34-gentoo-r6 (та же проблема существовала с предыдущим ядром 2.6.31). Я создал его, используя genkernel 3.4.10.906. Моя конфигурация grub выглядит так:
title=Gentoo Linux (2.6.34-gentoo-r6)
root (hd0,0)
kernel /kernel-genkernel-x86_64-2.6.34-gentoo-r6 root=/dev/ram0 real_root=/dev/sda5 vga=792 CONSOLE=/dev/tty1 resume=/dev/sda6
initrd /initramfs-genkernel-x86_64-2.6.34-gentoo-r6
Кроме того, я запускаю baselayout 2.0.0 с openrc 0.6.3, если это важно. sysvinit 2.87-r3 также установлен, я не знаю, используется ли он на самом деле.
Вот вывод dumpe2fs:
Filesystem volume name: hd-root
Last mounted on: <not available>
Filesystem UUID: 387432ca-2464-4c61-ba15-11c4af1c0418
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: 1528912
Block count: 6104692
Reserved block count: 0
Free blocks: 413799
Free inodes: 674036
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1022
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8176
Inode blocks per group: 511
Filesystem created: Tue Dec 9 14:48:56 2008
Last mount time: Mon Sep 27 00:00:15 2010
Last write time: Sun Sep 26 23:55:12 2010
Mount count: 39
Maximum mount count: -1
Last checked: Sun Sep 26 23:51:51 2010
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Journal inode: 8
First orphan inode: 698281
Default directory hash: tea
Directory Hash Seed: 4229715b-4ad1-4285-940b-9960db1cb4e1
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x003d9991
Journal start: 1
Я понятия не имею, что может вызвать эту проблему. Я не могу найти никаких сообщений об ошибках, и, ища в Интернете, я нахожу только руководства, как намеренно монтировать корневую файловую систему для чтения.