"Recovering journal"

[Lysander]

Right, I've had a look around this forum and the internet before I posted. Here is what happened.

I did a restart, went past GRUB fine and then the screen went black for a while. I gave it some time, but after about 3 mins - and since I had no idea what was going on - I tried alt + sysreq + REISUB which usually works to reboot - nothing. So I did a hard reset. On restart, after GRUB I briefly saw the words "recovering journal", but only for about 1-2 seconds before it booted to desktop, not long enough to take a picture or anything. I have done two test restarts since and no recurring problems.

Is this something to be concerned about? From this is seems that one of the drives wasn't unmounted cleanly so maybe that's all it was?

[arochester]

That normally happens for me when I just switch off instead of closing down properly e.g. when my computer has frozen.

It's a bit like a Windows computer checking Windows because it hasn't been shut down correctly.

Once it's sorted, it's sorted.

Should be nothing to worry about. (Possibly something to be glad about?)

[Lysander]

Indeed, thank you. I wonder what caused that 3+ minute hang though. In the future should I just wait it out then?

EDIT: maybe the question has already been answered as to the potential cause, but in the future it would be good to know what to do in similar situations.

[Lysander]

Performed the check in the link above and got the following

Code: Select all

/dev/sdc1: Linux rev 1.0 ext4 filesystem data, UUID=36f2992c-6861-4b51-bd2e-988aa4ebb1b1 (needs journal recovery) (extents) (64bit) (large files) (huge files)

The answer says I can perform it through running

Code: Select all

e2fsck 

as long as the file system is not mounted. However, this is my main hard drive so I am unsure how to do that.

[dasein]

From this is seems that one of the drives wasn't unmounted cleanly so maybe that's all it was?

No maybe about it. It's entirely expected anytime you forcibly shutdown a machine

I wonder what caused that 3+ minute hang though.

A systemd "improvement" maybe? (If it were one minute, there would be an obvious answer. HoaS might have some ideas.)

However, this is my main hard drive so I am unsure how to do that.

Aw, c'mon. I'll give you a hint: it rhymes with "live medium" (or a rescue partition... either way)

[stevepusser]

What filesystem are you using? Some systems do a filesystem check every 100 boots or 30 days, and that used to take several minutes on ext3...not as long on ext4. If you interrupt the process, it will still try and repeat the check the next time you boot, too.

[Lysander]

No maybe about it. It's entirely expected anytime you forcibly shutdown a machine

Understood, but this was a normal restart, unless such can be expected with that too?

A systemd "improvement" maybe? (If it were one minute, there would be an obvious answer. HoaS might have some ideas.)

I may message him lest he miss this topic, as long as he wouldn't think such unsolicited contact were intrusive.

Aw, c'mon. I'll give you a hint: it rhymes with "live medium" (or a rescue partition... either way)

Of course, thanks, I'll try that since it tells me that journal recovery is needed. I've found a number of guides here, here, here and here. I'll report back.

What filesystem are you using? Some systems do a filesystem check every 100 boots or 30 days, and that used to take several minutes on ext3...not as long on ext4. If you interrupt the process, it will still try and repeat the check the next time you boot, too.

This is very useful information. I'm pretty sure it's ext4. Still, that lets me know not to go trigger-happy with the restart button if it happens again.

[dasein]

this was a normal restart, unless such can be expected with that too?

If the fsck was incomplete or unsuccessful, yes. Dirty is dirty until it's cleaned.

I may message him lest he miss this topic, as long as he wouldn't think such unsolicited contact were intrusive.

I'd strongly encourage you to assume that he would indeed find it so.

[Lysander]

I'd strongly encourage you to assume that he would indeed find it so.

Haha I shan't then! I'll post back after fsck.

[Lysander]

Right, I did the check, here's the whole session done in Stretch live.

Code: Select all

user@debian:~$ sudo -i
root@debian:~# umount /dev/sdc1
umount: /dev/sdc1: not mounted
root@debian:~# e2fsck /dev/sdc1
e2fsck 1.43.4 (31-Jan-2017)
/dev/sdc1: clean, 213722/4562944 files, 4188720/18226944 blocks
root@debian:~# e2fsck -n /dev/sdc1
e2fsck 1.43.4 (31-Jan-2017)
/dev/sdc1: clean, 213722/4562944 files, 4188720/18226944 blocks
root@debian:~# e2fsck -p /dev/sdc1
/dev/sdc1: clean, 213722/4562944 files, 4188720/18226944 blocks
root@debian:~# mount -a
root@debian:~# exit
logout
user@debian:~$

I additionally ran a progress bar check

Code: Select all

root@debian:~# e2fsck -f -C 0 /dev/sdc1
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                           
Pass 3: Checking directory connectivity                                        
Pass 4: Checking reference counts
Pass 5: Checking group summary information                                     
/dev/sdc1: 213823/4562944 files (0.5% non-contiguous), 4189551/18226944 blocks

Though non-contiguous doesn't seem to be anything to worry about.

So it's just coming up as clean. I'm putting this down to experience. I can't see that there's too much for concern here, unless someone else can say.

[dasein]

Do you have more than the one partition? If so, it'd be worth fscking all of them.

Otherwise, you look good to go.

[Lysander]

Well that was interesting, I tried it on sdc2, which is extended, and sdc5, which is swap, and got the following:

Code: Select all

user@debian:~$ sudo -i
root@debian:~# umount /dev/sdc2
umount: /dev/sdc2: not mounted
root@debian:~# e2fsck /dev/sdc2
e2fsck 1.43.4 (31-Jan-2017)
e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc2
Could this be a zero-length partition?
root@debian:~# umount /dev/sdc5
umount: /dev/sdc5: not mounted
root@debian:~# e2fsck /dev/sdc5
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdc5

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

/dev/sdc5 contains a swap file system

So because sdc5 is swap, it's probably not cause for concern, which leaves sdc2.

Now I know this disk has 6 bad sectors, maybe they're in one [or both] of these two? Everything seems to perform absolutely fine apart from yesterday's minor glitch.

EDIT: I presume sdc2 is indeed a zero length partition. And as discussed before a handful of reallocated sectors is not an issue.

[dasein]

EDIT: I presume sdc2 is indeed a zero length partition. And as discussed before a handful of reallocated sectors is not an issue.

Correct on both counts. Six bad sectors is nothing, and the occasional small uptick in bad sectors is also no cause for alarm. Only a big surge or persistent increase in reallocated sectors is even slightly worrisome. And regular backups means not having to worry too much about even those.

SMART is wonderful except for two things: (1) people forget to use it and (2) sometimes the first SMART warning precedes a catastrophic failure by a matter of mere moments.

BTW, (a) you don't umount swap and (b) you don't fsck it.

[Lysander]

BTW, (a) you don't umount swap and (b) you don't fsck it.

Makes sense, come to think of it. I suppose by saying one doesn't fsck swap, you mean it's effectively fruitless/pointless, rather than damaging as such. Or at least one doesn't attempt any form of repair [mine was purely a check]*.

Anyway, I'm really thankful for your help in this thread, dasein. Much gratitude to you.

*I don't see the difference between

Code: Select all

e2fsck /dev/sdc5

and

Code: Select all

e2fsck -n /dev/sdc5 

but I imagine I'm splitting hairs now.

[dasein]

I suppose by saying one doesn't fsck swap, you mean it's effectively fruitless/pointless, rather than damaging as such.

I'm saying there's no such thing as fsck.swap.

*I don't see the difference between

Code: Select all

e2fsck /dev/sdc5

and

Code: Select all

e2fsck -n /dev/sdc5 

but I imagine I'm splitting hairs now.

Spend a few minutes with man fsck and think about the subtle difference between the two syntaxes. If you're still not sure, then post your best guess here and I'll give you another hint.

[Lysander]

Had this problem again today. Exactly as in the OP and had to do a hard reset. Had a look at the Disc utility and now there are 7 bad sectors [one up from 6].

Seems the SSD might be dying after all.

[dasein]

had to do a hard reset

REISUB didn't work?? Is it properly configured/enabled? (See http://forums.debian.net/viewtopic.php?p=432168)

Seems the SSD might be dying after all.

Always possible, of course, but 6-to-7 doesn't exactly qualify as a "massive" uptick.

Also...

1) Any obvious weirdness in logs?

2) See my earlier response in this thread for the Ultimate Solution.

[Lysander]

REISUB didn't work?? Is it properly configured/enabled? (See http://forums.debian.net/viewtopic.php?p=432168)

When I've used it before it's worked absolutely fine - and I just did a test and it worked great too. But in the instance mentioned from earlier today it did nothing, and I attempted it a few times.

Always possible, of course, but 6-to-7 doesn't exactly qualify as a "massive" uptick.

Indeed.

Also...

1) Any obvious weirdness in logs?

I spent a long time looking at /var/log/syslog but I'm not totally sure what I'm looking for.

There were a few highlighted messages in dmesg such as

Code: Select all

[    0.376958] pmd_set_huge: Cannot satisfy [mem 0xe0000000-0xe0200000] with a huge-page mapping due to MTRR override.
[    1.079054] ACPI Warning: SystemIO range 0x0000000000000400-0x000000000000041F conflicts with OpRegion 0x0000000000000400-0x000000000000040F (\SMRG) (20160831/utaddress-247)
[    3.287099] ACPI Warning: SystemIO range 0x0000000000000828-0x000000000000082F conflicts with OpRegion 0x0000000000000800-0x000000000000084F (\PMRG) (20160831/utaddress-247)
[    3.287107] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    3.287110] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x000000000000053F (\GPS0) (20160831/utaddress-247)
[    3.287113] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    3.287114] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000053F (\GPS0) (20160831/utaddress-247)
[    3.287116] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    3.287117] lpc_ich: Resource conflict(s) found affecting gpio_ich

And various highlighted entries for UFW.

2) See my earlier response in this thread for the Ultimate Solution.

Backups! [backups?]