Root filesystem mounted fine under squeeze, and after I upgraded to wheezy. I've been living with it for a bit, so I'm not exactly sure, but I think it started after doing a dist-upgrade on wheezy, but that could be coincidence. The machine is a Lenovo T400 FWIW.

boot screen photo1 shows first warnings about read-only file system; nothing is logged obviously

fsck finds no problems2

mount -o remount,rw /

above works fine

(but I have to restart network-manager and gdm3 to get a usable system; I'm not sure it is related, but I can't seem to connect to a service running on localhost, eg python -m SimpleHTTPServer 8080 and in another terminal w3m times out sending request to localhost port 8080)

I don't notice anything amiss 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

Any pointers would be much appreciated. Hopefully I'm doing something obviously wrong and fixable, but if not any hints about how to debug?


tune2fs -l /dev/sda1


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


It appears that /etc/init.d/checkroot.sh isn't being run at boot, and that's the script that finally remounts root as rw (if I run it after boot, it does exactly that). I'm using Debian testing/wheezy. There are dependency annotations in /etc/init.d files, but beyond that I'm not sure how to tell more about the init system.


Fixed, but no idea how it happened or if the fix is exactly how the system ought be. I noticed checkfs and mtab in /etc/rcS.d, but no checkroot, so I added it:

cd /etc/rcS.d
ln -s ../init.d/checkroot.sh S06checkroot.sh

After rebooting twice (first time could have been my confusion, but I added some further instrumentation to checkroot.sh between them), I'm back up with rw on boot (and the problem with listening to/requesting from localhost disappeared, so I guess it was related).

(I see on a squeeze system I have access to it's at S07checkroot.sh; I was close perhaps.)

closed as off-topic by G-Man, Archemar, Anthon, X Tian, Jenny D Oct 11 '15 at 8:45

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – G-Man, Archemar, Anthon, X Tian, Jenny D
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Did you try a fsck of the root filesystem? Boot from a liveCD, then do the fsck. – jippie Apr 18 '12 at 19:31
  • Yes. I did fsck in single user mode, screenshot linked from [2] above. – mlinksva Apr 18 '12 at 19:34
  • Try it from a liveCD, and try to mount the filesystem. Gheck dmesg for errors. – jippie Apr 18 '12 at 19:38

There is an error on your /root filesystem and fstab remounts /root as read only.

The line in fstab

UUID=2934c627-6f1a-438b-a877-1544108c7418 / ext3 errors=remount-ro 0 1

is what is causing /root to mount read only.

From the mount (8) man page

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).

You should ultimately find out what is wrong with your /root filesystem. You can easily boot from a rescue disk and run an fsck on /root. If you choose to ignore the potential errors, just change the line in fstab to errors=continue.

  • changing remount-ro to continue doesn't change behavior upon reboot. I'll have to try another fsck from a rescue disk, thanks. – mlinksva Apr 18 '12 at 19:53
  • Check the superblock. tune2fs -l /dev/sda1 and look for the entry Errors behavior. Is it set to continue or read-only? – George M Apr 18 '12 at 19:58
  • Continue. Added full output to the question. – mlinksva Apr 18 '12 at 20:16
  • It feels like we are missing something obvious...try booting from a rescue/live cd and running the fsck on all the filesystems. That's definitely the next step. – George M Apr 18 '12 at 20:33
  • fsck'd from a rescue usb and got the same, clean, output as from single user mode reflected in i.stack.imgur.com/CllFB.png (file and inode counts slightly different due to subsequent use). – mlinksva Apr 18 '12 at 22:27

I had this problem, and it was caused by the wrong UUID for the root FS being set in /etc/fstab. I guess some upgrade auto-detected it and got it wrong.

Remount the / partition rw, using blkid to get the right UUID and replace in /etc/fstab fixed it for me.


Your root filesystem isnt being mounted read/write because youre not telling it to.

UUID=2934c627-6f1a-438b-a877-1544108c7418 /               ext3 errors=remount-ro 0       1

Your mount options are only errors=remount-ro, there's nothing about read/write in there. The standard practice is to have defaults in your mount options. defaults provides several other mount options, one of them is rw, thus providing read/write.

So you need to add either defaults or rw to the options field of your fstab.

From thinking about it a bit more (and from discussion in comments below), the defaults and rw options might not fix it. The reason being is that the remount behavior is entirely dependent upon the distro's init scripts. I've seen distros pull the mount settings from fstab on boot, but its also possible that the init script is completely ignoring fstab options when it goes to remount root (and uses some hard coded settings in the script).

  • I tried adding rw earlier today to no effect. I'm not sure it should have one though, the system I'm typing on now only has relatime,errors=remount-ro as mount options, and mounts rw. I'll try defaults shortly though anyway. Thanks! – mlinksva Apr 18 '12 at 22:22
  • 1
    I suppose this behavior is dependent upon your distribution's init scripts. Its entirely possible its completely ignoring whether fstab has rw/defaults specified or not. Try doing grep remount /etc/init.d/* and see if there's an init script doing something special. – Patrick Apr 18 '12 at 22:29
  • 1
    In debian the system boots with a ro filesystem then changes to rw once it's determined that it's safe to do so. Though, I can't tell if his system is never switching to rw or switching back because of an error. – bahamat Apr 18 '12 at 23:10
  • I don't see anything suspicious in /etc/init.d scripts, but I guess I see /etc/init.d/checkroot.sh is where root is potentially fsck'd and finally remounted in its final state. That gives me someplace to continue trying to figure this out, thanks Patrick and bahamat. – mlinksva Apr 18 '12 at 23:59
  • 1
    defaults is useless if you have other options, it's only a placeholder when you have no other option and you can't leave the field empty because there are other columns to the right. rw is the default; but / is not initially mounted by looking at fstab, so the boot scripts have to pick up the right options at some point and remount it. – Gilles Apr 19 '12 at 0:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.