/dev/sda1 must be recovered on every boot

Bug #1261730 reported by Removed by request
44
This bug affects 8 people
Affects Status Importance Assigned to Milestone
upstart (Ubuntu)
Confirmed
High
Unassigned

Bug Description

I'm using Ubuntu 14.04 dev with mountall 2.52. On every boot I'm seeing these lines:

[ 8.535902] EXT4-fs (sda1): INFO: recovery required on readonly filesystem
[ 8.536025] EXT4-fs (sda1): write access will be enabled during recovery
[ 17.599477] EXT4-fs (sda1): recovery complete
[ 17.615731] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

I'm also wondering why it isn't telling me how many inodes were repaired (I remember to have seen this number on "real" recoveries a while ago).

Tags: precise trusty
affects: cryptsetup (Ubuntu) → mountall (Ubuntu)
Revision history for this message
Steve Langasek (vorlon) wrote :

Why are you filing this bug against mountall? It's not mountall that's causing the filesystem to fail to unmount cleanly before reboot.

> I'm also wondering why it isn't telling me how many inodes were repaired (I
> remember to have seen this number on "real" recoveries a while ago).

Not in the kernel message. The messages you're citing are the kernel remounting it rw to do journal recovery after an unclean shutdown.

Changed in mountall (Ubuntu):
status: New → Incomplete
Revision history for this message
Removed by request (removed3425744) wrote :

> Why are you filing this bug against mountall? It's not mountall that's causing the filesystem to fail to unmount cleanly before > reboot.

Which package should it be assigned then?

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1261730] Re: /dev/sda1 must be recovered on every boot

On Tue, Dec 17, 2013 at 07:30:17PM -0000, Sworddragon wrote:
> Which package should it be assigned then?

That depends on what's causing your disk to not be cleanly remounted
read-only on shutdown. Do you get any error messages on shutdown if booted
without 'splash'?

Revision history for this message
Removed by request (removed3425744) wrote :

I could debug it down to a testcase. Just create the file /etc/init/test.conf with the following lines:

start on mounted and stopped mounted-tmp
exec mkdir -p /tmp/no-journal

After a reboot the recovery will happen. If you comment out the exec stanza all is fine again. But I don't know how such a simple upstrat script would cause this behavior.

affects: mountall (Ubuntu) → upstart (Ubuntu)
Changed in upstart (Ubuntu):
status: Incomplete → New
Revision history for this message
Removed by request (removed3425744) wrote :

I have figured out a little more: On removing "mounted and " on the start stanza the recovery doesn't appear anymore. But this still leaves the question why this should cause such a behavior.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in upstart (Ubuntu):
status: New → Confirmed
tags: added: trusty
Changed in upstart (Ubuntu):
importance: Undecided → High
Revision history for this message
latimerio (fomember) wrote :

I have 14.04 LTS running as a virtual machine which I upgrade from 12.02 LTS and I do now see the error too on every boot.
Thus I think it is not the disk but some other cause which leads to this error.

Revision history for this message
Boris Gjenero (boris-gjenero) wrote :

In 14.10 amd64, mountall keeps running, causing init to keep /var/log/upstart/mountall.log open for writing, which prevents root from being remounted read-only.

These things are easy to examine by adding a /bin/sh line to /etc/init.d/reboot in do_stop() before "reboot -d -f -i". Then when you reboot you can switch to virtual console 1 and use lsof and other commands to explore what is going on. For example this is the line in lsof output showing the problem:
init 1 root 8w REG 8,5 613 1062101 /var/log/upstart/mountall.log

I added a
/usr/bin/killall mountall
line to /etc/init.d/umountroot before root is supposed to be remounted read-only. That seems to fix the problem. You need the full path because /usr/bin isn't in PATH, and don't use -9.

Ken Sharp (kennybobs)
tags: added: precise
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.