linux - break out of e2fsck on boot

25
2014-04
  • johndodo

    Is it possible to somehow break out of e2fsck on boot?

    My system runs e2fsck every 30 days, which is fine by me and I want it to stay that way. But sometimes when I turn on the computer and 30 days have passed, I still want it to boot fast. For instance when I have to give a presentation off a laptop - imagine telling 50 people "we just have to wait for 10 minutes... no, I can't avoid it... yes, this is Linux, why are you asking?" :)

    If I press Ctrl+C it stops the check and continues boot sequence, but the system is unusable because root filesystem is mounted read-only. And after I reboot the check starts again.

    I have searched the Internet for the answer and there are many similar questions, but I could find no solution. Anyone know of a solution?

    Note: I am looking for a solution that would not disable fsck and that would not require any action before rebooting the computer - I do not know in advance I will have to skip the check.

    If it matters: Debian 6 (Squeeze).\

    UPDATE: I learned that it is possible to break out of e2fsck with Esc key on Ubuntu. This is exactly what I am looking for - anyone know how to make this happen on Debian?

    SOLUTION: Garrett's answer was correct, I had to edit /etc/init.d/checkroot.sh. Just before these lines:

    #
    # The actual checking is done here.
    #
    if [ "$rootcheck" = yes ]
    then
        ...
    

    I added these lines:

    if [ "$rootcheck" = yes ]
    then
        if [ -f /forcefsck ] || grep -s -w -i "forcefsck" /proc/cmdline
        then
            echo "fsck was forced."
        else
            echo "********************************************************************************************************"
            echo "*                                                                                                      *"
            echo "*  WARNING: fsck should be run, but it is disabled. Create /forcefsck and reboot at your convenience.  *"
            echo "*                                                                                                      *"
            echo "********************************************************************************************************"
            rootcheck="no"
        fi
    fi
    

    Works beautifully - I smile every time I see the message, knowing I have just rescued another half an hour of my life. :)

  • Answers
  • Community

    There are three easy ways to achieve what you're looking to do, depending on the situation.

    1. When shutting down, use the command line shutdown binary and pass the -f switch, e.g. for a reboot: shutdown -rf now. You could also make a shortcut with this if you'd prefer. This will skip the fsck check on the next reboot only.
    2. When the grub menu is displayed on boot hit 'e' to edit the current booting kernel, edit the vmlinuz line and append fastboot to the end. Like option 1, this skips the fsck check for that boot only.
    3. If you really want to disable the check entirely (not recommended), you can edit the file /etc/fstab. Find the line with your root filesystem and at the end there will be two numbers, usually 1 2. Changing the last number (2 here) to 0 will prevent all automatic boot-time fsck checks from running on that volume.

    Edit for #2: You could add a new entry to grub for fastboot, which may be more suited to your example case. This retains the normal fsck check while presenting a choice during boot.

  • Michael Kjörling

    While it does not directly address your question of how to abort a running fsck, if you know in advance that you will need a fast boot (such as if you are planning to give a presentation) then you can certainly run fsck manually at some earlier time. This will give you a new 30 days before the next automated file system check without touching any system configuration.

  • pjc50

    You can edit the startup script which calls fsck. So you could for example make it ask the console whether to do a fsck, with a timeout. The scripts are in /etc/init.d/checkroot.sh and /etc/init.d/checkfs.sh.

    I notice that my copy has this code in it which you could re-enable:

    # Disabled AC power check until fsck can be told to only check the
    # file system if it is corrupt when running on battery. (bug #526398)
    #       if which on_ac_power >/dev/null 2>&1 && [ "$rootcheck" = yes ]
    #       then
    #               on_ac_power >/dev/null 2>&1
    #               if [ "$?" -eq 1 ]
    #               then
    #                       log_warning_msg "On battery power, so skipping file system check."
    #                       rootcheck=no
    #               fi
    #       fi
    

  • Related Question

    Ubuntu Forced fsck on boot fails
  • srboisvert

    fsck has lots of errors reading block 24251xx (attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error (y)?

    Force rewrite (y)?

    Sometimes there is other output mixed in:

    [8222.00061] ata1.00: exception Emask 0x0 .bunch of hex.frozen [8222.00124] ata1.00 cmd ..bunch of hex.. in [8222.00264] res ..bunch of hex..(timeout) [8222.00124] ata1.00: status: {DRDY}

    What is going on and what should i do?

    Update: I found out about the second part. It is a Libata error message from the kernal indicating that the drive wasn't responding to a command in time. This piece of advice will supposedly help with that [i'll let you know how it goes once i get past fsck]

    In particular, timeouts may be solved by acpi=off or 'noapic' or pci=nomsi or pci=biosirq.


  • Related Answers
  • mihi

    Most likely your hard disk is dying...

    Get a live CD (Ubuntu Install/Live CD is fine).

    If you have any important data on that disk without backup, mount your disk read-only and copy all you can off the disk.

    Then, try to make an image of the partition with dd or dd_rescue, either onto another partition or as a file to somewhere else (if you don't have space, make the image to /dev/null), so that you can see if there is any physical damage to your disk.

    If there are media errors while copying the file with dd, fsck your new copy (either mount loopback or use a real partition, if you used /dev/null you have to start over with a real disk) and copy all data off you can still copy. Then try to investigate the manufacturer of your disk and whether it still has warranty. If yes, proceed with the test tools of the manufacturer... If not, check with SMART tools if there are any reallocatable sectors left and if yes try to write zeroes into the broken sectors with dd (which will reallocate them). If you don't have any luck, you will have to try to partition around the broken area; or use the -c option for mkfs.ext[23].

    If there are no media errors, you will have to reformat the disk and copy back the data again. Usually ext3 (I guess it is...) is a lot more robust than other filesystems, so I don't really think this can be a filesystem error alone...

  • derobert

    Sounds like you have a bad sector if the numbers are consistent across attempts to fsck. Unfortunately, you're going to lose whichever file was stored in that inode.

    Check smart status, it'll usually tell you how many bad blocks the disk knows about. Hopefully, its only a few. If it tells you the disk is failing, I hope you have a backup.

    Running fsck -c /dev/WHATEVER should run a bad-block scan, and then tell you what you've lost (or need to restore from a backup).