This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

File system inconsistency - cannot run fsck

Hello Everyone,

I had an unexpected power outage with my virtual UTM appliance this week and when booting up it gets to a point where it says:

tmp: superblock needs_recovery flag is clear but journal has data

tmp: run journal anyway

tmp: unexpected inconsistency; run fsck manually 

This seems straight forward enough however it then asks:

Give Root Password for Maintenance (or type Control-D to continue):

I typed in my password which failed so I followed the steps here to reset the password and then I tried again. The system attempts to boot, gets to the same error and still, I cannot type in the password to continue. Am I missing something here? Is there anyone who can help me out?



This thread was automatically locked due to age.
  • I ran into this as well and finally figured a way to meander through the issue and resolve the file system problem without the password. Basically, you will want to follow the steps in the password reset link you provided up to a point. The problem in this type of scenario is that you can't reset the password when the file system is dirty because it will still mount the file system as read-only when using the provided reset steps, which is why it won't boot in the first place. What I did was to follow the steps up until you're at the shell prompt (step 10, I believe), but then once you get there just run fsck. In my case using a virtualized appliance, I ran:

    fsck /dev/sda6

    Then just follow the prompts to correct the issues (usually just hitting Y over and over). If you want to verify the correct device and partition for your root volume, just run

    mount

    and look for the device/partition that's mounted to /

    Once you complete running fsck, reboot with Ctrl-Alt-Del (either on the keyboard or with the guest functions in your hypervisor). After that you can either follow the original password reset steps again to reset your root password or simply let it boot back up proper.

    Hope this helps someone!

  • This worked perfectly and saved my bacon from a remote location! Thank you!

  • Whew, was that a lifesaver!!!

    But it does beg the question... what IS the password at that point? 

    I have no trouble normally over the remote at :4444 but I was totally stuck sitting at the machine itself after a similar brownout with a corrupted disk -found an old monitor & a PS2 keyboard & no joy until I found your answer, hunched over my phone, Googling & sweating ;-)

     

    Should I set a password for that scenario? If so, how & where?

     

    It's the first time in 4 years of using Sophos UTM that simply putting the last emailed backup on a USB stick hasn't got me up & running again after a brownout.