checkroot.sh blocks writing /var (fsck)

Bug #246367 reported by Troy Cauble
4
Affects Status Importance Assigned to Milestone
sysvinit (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: initscripts

Booting hung on automatic fsck of my root partition.
The checkroot.sh startup script includes this block:

        PROGRESS_FILE=`mktemp -p /var/run` || PROGRESS_FILE=/var/run/checkroot_fsck
        set -m
        logsave -s $FSCK_LOGFILE fsck -C3 $force $fix -t $roottype $rootdev >/dev/console 2>&1 3>$PROGRESS_FILE &
        set +m
        usplash_progress "$PROGRESS_FILE"
        rm -f $PROGRESS_FILE

Note that fsck ... > /var/run/checkroot_fsck
I believe this causes a problem when /var is on / (not a separate partition), which is mounted read-only.

I worked around this by setting VERBOSE=yes in /etc/default/rcS, which causes a different path through checkroot.sh.
Then my root fsck at boot was not blocked.

-troy

$ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

/var/run is a temporary read-write filesystem and is mounted by S01mountkernfs.sh very early on in the boot process. fsck can still write to /var/run even though the root filesystem is read-only, so I very much doubt that is the issue here. Bare in mind that the default Ubuntu configuration does not have a separate /var partition, so everyone would have this problem if this was really the cause of your issue. The only time that fsck would not be able to write to /var/run would be if the mounting of /var/run failed for some reason.

Do you not get an error when fsck stops? Have you tried booting in recovery mode to look for errors?

Thanks

Changed in sysvinit:
status: New → Incomplete
Revision history for this message
Troy Cauble (troycauble) wrote :

Chris is correct. My bad. Sorry for any confusion.

I'm not sure what it was, but:

1) VERBOSE=yes did work as a work-around. I did a lot of /forcefsck reboots with and without this setting.
2) The problem stopped when I stopped booting 2.6.22-14 and started booting 2.6.24-19. The former may
be a holdover from my 7.10 Kubuntu install.

Wild guess: Was this special /var/run supported in that kernel?

Thanks,
-troy

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

/var/run is just a tmpfs which has been supported for a very long time (since 2.4 series kernels I believe).

Are you seeing any error messages when you boot in to recovery mode? Perhaps you could also try removing the 'quiet' and 'splash' options from the kernel command line. I can assist you if you need any help with that.

Thanks

Revision history for this message
Troy Cauble (troycauble) wrote :

Thanks, but I consider my problem solved.
-troy

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

This bug report is being closed due to your last comment regarding this being solved. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status . Thank you again for taking the time to report this bug and helping to make Ubuntu better. Feel free to submit any future bugs you may find.

Changed in sysvinit:
status: Incomplete → Invalid
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.