Das Root-Dateisystem ließ sich unter Squeeze und nach dem Upgrade auf Wheezy problemlos mounten. Ich lebe schon eine Weile damit, bin mir also nicht ganz sicher, aber ich glaube, es fing an, nachdem ich ein Dist-Upgrade auf Wheezy durchgeführt hatte, aber das könnte Zufall sein. Die Maschine ist ein Lenovo T400, FWIW.
Startbildschirmfoto1zeigt erste Warnungen über schreibgeschütztes Dateisystem; offensichtlich wird nichts protokolliert
fsck findet keine Probleme2
mount -o remount,rw /
oben funktioniert gut
(aber ich muss den Netzwerkmanager und gdm3 neu starten, um ein nutzbares System zu erhalten; ich bin nicht sicher, ob es damit zusammenhängt, aber ich kann anscheinend keine Verbindung zu einem Dienst herstellen, der auf dem lokalen Host ausgeführt wird, z. B. python -m SimpleHTTPServer 8080 und in einem anderen Terminal tritt bei w3m eine Zeitüberschreitung beim Senden einer Anforderung an den lokalen Port 8080 auf)
Ich sehe nichts Ungewöhnliches in 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
Ich bin für alle Hinweise sehr dankbar. Hoffentlich mache ich etwas offensichtlich falsch, das sich beheben lässt. Wenn nicht, haben Sie Hinweise zum Debuggen?
...
tune2fs -l /dev/sda1
Ausgänge
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
...
Es scheint, dass /etc/init.d/checkroot.sh beim Booten nicht ausgeführt wird, und das ist das Skript, das root schließlich als rw neu mountet (wenn ich es nach dem Booten ausführe, tut es genau das). Ich verwende Debian Testing/Wheezy. Es gibt Abhängigkeitsanmerkungen in /etc/init.d-Dateien, aber darüber hinaus bin ich mir nicht sicher, wie ich mehr über das Init-System erfahren kann.
...
Behoben, aber keine Ahnung, wie es passiert ist oder ob die Korrektur genau dem entspricht, was das System sein sollte. Ich habe checkfs und mtab in /etc/rcS.d bemerkt, aber kein checkroot, also habe ich es hinzugefügt:
cd /etc/rcS.d
ln -s ../init.d/checkroot.sh S06checkroot.sh
Nach zwei Neustarts (beim ersten Mal war es vielleicht meine Verwechslung, aber ich habe zwischendurch weitere Instrumentierung zu checkroot.sh hinzugefügt) bin ich beim Booten wieder mit rw oben (und das Problem mit dem Abhören/Anfordern von localhost ist verschwunden, also nehme ich an, dass es damit zusammenhing).
(Ich sehe, dass ich auf einem Squeeze-System unter S07checkroot.sh darauf zugreifen kann. Vielleicht war ich nah dran.)
Antwort1
Es liegt ein Fehler in Ihrem /root-Dateisystem vor und fstab mountet /root erneut schreibgeschützt.
Die Zeile in fstab
UUID=2934c627-6f1a-438b-a877-1544108c7418 / ext3 errors=remount-ro 0 1
ist der Grund, warum /root nur schreibgeschützt gemountet wird.
Aus der mount (8)Manpage
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).
Sie sollten letztendlich herausfinden, was mit Ihrem /root-Dateisystem nicht stimmt. Sie können problemlos von einer Rettungsdiskette booten und ein fsck auf /root ausführen. Wenn Sie die potenziellen Fehler ignorieren möchten, ändern Sie einfach die Zeile in fstab in errors=continue.
Antwort2
Ich hatte dieses Problem und es wurde dadurch verursacht, dass in /etc/fstab die falsche UUID für das Stamm-FS festgelegt wurde. Ich vermute, dass es bei einem Upgrade automatisch erkannt und falsch war.
Mounten Sie die /Partition RW erneut, indem Sie blkidzum Abrufen der richtigen UUID und zum Ersetzen in /etc/fstab das Problem für mich behoben haben.
Antwort3
Ihr Root-Dateisystem wird nicht mit Lese-/Schreibzugriff gemountet, da Sie es nicht ausdrücklich angeben.
UUID=2934c627-6f1a-438b-a877-1544108c7418 / ext3 errors=remount-ro 0 1
Ihre Einhängeoptionen sind nur errors=remount-ro, es steht nichts über Lesen/Schreiben darin. Die Standardpraxis ist, defaultsin Ihren Einhängeoptionen zu haben. defaultsbietet mehrere andere Einhängeoptionen, eine davon ist rw, und ermöglicht somit Lesen/Schreiben.
Sie müssen also entweder „ defaultsoder“ rwzum Optionsfeld Ihrer fstab hinzufügen.
BEARBEITEN:
Wenn ich etwas genauer darüber nachdenke (und aus den Kommentaren unten erläutere), kann ich sagen, dass die Optionen defaultsund rwdas Problem möglicherweise nicht beheben. Der Grund dafür ist, dass das erneute Einhängen vollständig von den Init-Skripten der Distribution abhängt. Ich habe schon erlebt, dass Distributionen die Einhängeeinstellungen beim Booten aus fstab ziehen, aber es ist auch möglich, dass das Init-Skript die Optionen von fstab vollständig ignoriert, wenn es root erneut einhängt (und einige fest codierte Einstellungen im Skript verwendet).