Bug 1873045 - test Reboot unmount results
Summary: test Reboot unmount results
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: fedora-kernel-btrfs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-27 09:05 UTC by Jaap
Modified: 2020-09-01 15:23 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-01 15:23:22 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
journal log 1 (first test) (429.96 KB, text/plain)
2020-08-27 09:05 UTC, Jaap
no flags Details
second test journal2.log (373.74 KB, text/plain)
2020-08-27 09:05 UTC, Jaap
no flags Details

Description Jaap 2020-08-27 09:05:02 UTC
Created attachment 1712792 [details]
journal log 1 (first test)

1. Please describe the problem:
Test_Day:2020-08-31_Btrfs_default mount test 

2. What is the Version-Release number of the kernel:



4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
second test after reboot had problems too.  (cannot add journal2.log here?)



7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Comment 1 Jaap 2020-08-27 09:05:58 UTC
Created attachment 1712793 [details]
second test  journal2.log

Comment 2 Chris Murphy 2020-08-31 03:30:00 UTC
Aug 27 10:46:35 localhost.localdomain kernel: Linux version 5.8.3-300.fc33.x86_64 (mockbuild.fedoraproject.org) (gcc (GCC) 10.2.1 20200804 (Red Hat 10.2.1-2), GNU ld


This test case?
https://fedoraproject.org/wiki/QA:Testcase_base_reboot_unmount

I don't see 'BTRFS info (device vda3): start tree-log replay' in either journal.

Comment 3 Jaap 2020-08-31 06:10:50 UTC
Yes 
https://fedoraproject.org/wiki/QA:Testcase_base_reboot_unmount  
sorry I did  not mention that.

Comment 4 Jaap 2020-08-31 06:45:39 UTC
(In reply to Chris Murphy from comment #2)
> Aug 27 10:46:35 localhost.localdomain kernel: Linux version
> 5.8.3-300.fc33.x86_64 (mockbuild.fedoraproject.org) (gcc
> (GCC) 10.2.1 20200804 (Red Hat 10.2.1-2), GNU ld
> 
> 
> This test case?
> https://fedoraproject.org/wiki/QA:Testcase_base_reboot_unmount
> 
> I don't see 'BTRFS info (device vda3): start tree-log replay' in either
> journal.

'Disks' shows a Btrfs Mounted at Filesystem Root.  /dev/sda-4
and it shows a Block Device /dev/zdram0)

Comment 5 Chris Murphy 2020-08-31 13:51:18 UTC
(In reply to Jaap from comment #4)
> 'Disks' shows a Btrfs Mounted at Filesystem Root.  /dev/sda-4
> and it shows a Block Device /dev/zdram0)

It's expected.

Comment 6 Chris Murphy 2020-08-31 13:55:58 UTC
>second test after reboot had problems too.  (cannot add journal2.log here?)

What problem exactly? I'm not seeing anything in either log.

Comment 7 Jaap 2020-08-31 14:57:24 UTC
On https://fedoraproject.org/wiki/QA:Testcase_base_reboot_unmount 

It says:      If there was some output from the grep command, save the full journal log using

    sudo journalctl -b > journal.log

    If the grep output does not show clearly that the output is related to a disk mount/unmount problem, open the journal.log file, find the relevant lines and verify whether this is an error related to disk mounting or an unrelated message.
    If the output is related to disk mounting, please file a bug report *) (the kernel is most likely the correct package to file the report against) and attach the journal.log file to the bug report.

The message was clearly about mount/unmount and it did advice to run btrfs.

*) That is why id did file this bug.

THe system is working fine for me now, but 'You" asked for a bug report.

Comment 8 Chris Murphy 2020-08-31 15:19:21 UTC
What output did you get from grep command?

Comment 9 Jaap 2020-09-01 06:19:03 UTC
(In reply to Chris Murphy from comment #8)
> What output did you get from grep command?



Sep 01 08:08:21 localhost.localdomain kernel: FAT-fs (sdb1): Volume was
not properly unmounted. Some data may be corrupt. Please run fsck.
[~]$

this was the output from grep. just after install and now. Sorry for delay, login to bugzilla gives problems on Fed33 machine.

Comment 10 Chris Murphy 2020-09-01 13:04:27 UTC
OK here it is in attached journal2

Aug 27 10:46:39 localhost.localdomain kernel: scsi 5:0:0:0: Direct-Access     JetFlash Transcend 8GB    1100 PQ: 0 ANSI: 6
...
Aug 27 10:47:38 localhost.localdomain kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Aug 27 10:47:38 localhost.localdomain udisksd[615]: Mounted /dev/sdb1 at /run/media/jaap/4F6B-B1D5 on behalf of uid 1000

I'm guess it's a USB drive or stick that wasn't umounted before the reboot. Here it is in the prior boot:

Aug 27 10:07:05 localhost.localdomain kernel: scsi 5:0:0:0: Direct-Access     JetFlash Transcend 8GB    1100 PQ: 0 ANSI: 6
...

Aug 27 10:11:05 localhost.localdomain kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Aug 27 10:11:05 localhost.localdomain udisksd[658]: Mounted /dev/sdb1 at /run/media/jaap/4F6B-B1D5 on behalf of uid 1000



Both logs show:

Aug 27 10:11:05 localhost.localdomain udisksd[658]: udisks_state_check_mounted_fs_entry: block device /dev/sdb1 is busy, skipping cleanup
Aug 27 10:47:38 localhost.localdomain udisksd[615]: udisks_state_check_mounted_fs_entry: block device /dev/sdb1 is busy, skipping cleanup

I think it's a previously existing problem and just isn't being automatically fixed at mount time.

Jaap, you need to unmount this drive and fsck it to fix the problem. But it doesn't seem related to the installation process or a kernel bug. Next, try and track down whether it's being properly umounted automatically when you reboot or shutdown, and if you get this 'not properly unmounted' message again at the next boot. If you do the likely culprit is udisks2 not unmounting it for some reason. For example:


1. insert stick
2. confirm no kernel error messages
3. reboot without removing the stick first
4. check kernel error messages for FAT-fs. Errors?

Comment 11 Jaap 2020-09-01 14:14:25 UTC
I did fsck the USB stick, that mentioned a dirty spot, and did repair.


After that I did this: without the stick inserted. (so /dev/sdb1 is not mentioned)
st ~]$ df -H
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        2.1G     0  2.1G   0% /dev
tmpfs           2.1G  110M  2.0G   6% /dev/shm
tmpfs           824M  1.9M  822M   1% /run
/dev/sda4       498G   12G  485G   3% /
tmpfs           2.1G   54k  2.1G   1% /tmp
/dev/sda4       498G   12G  485G   3% /home
/dev/sda3       1.1G  165M  789M  18% /boot
/dev/sda2       630M   39M  591M   7% /boot/efi
tmpfs           412M  168k  412M   1% /run/user/1000
After that I did the test..

[jaap@localhost ~]$ sudo journalctl -b | grep -iv '\<recovery algorithm\>' | grep -iE '\<(dirty bit|corrupt|run fsck|recovery|recovering|tree-log replay)\>'
Sep 01 15:41:42 localhost.localdomain kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Sep 01 15:42:28 localhost.localdomain kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Sep 01 15:55:49 localhost.localdomain kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

On "Gnome ? Disks" a /dev/sda1  exists, unmounted. (this is an IMac, so there is some OSX stuff, I guess)

Now insert USB stick

~]$ sudo journalctl -b | grep -iv '\<recovery algorithm\>' | grep -iE '\<(dirty bit|corrupt|run fsck|recovery|recovering|tree-log replay)\>'
[sudo] password for jaap: 
Sep 01 15:41:42 localhost.localdomain kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Sep 01 15:42:28 localhost.localdomain kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Sep 01 15:55:49 localhost.localdomain kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[jaap@localhost ~]$ df -H
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        2.1G     0  2.1G   0% /dev
tmpfs           2.1G  141M  2.0G   7% /dev/shm
tmpfs           824M  1.9M  822M   1% /run
/dev/sda4       498G   12G  485G   3% /
tmpfs           2.1G   54k  2.1G   1% /tmp
/dev/sda4       498G   12G  485G   3% /home
/dev/sda3       1.1G  165M  789M  18% /boot
/dev/sda2       630M   39M  591M   7% /boot/efi
tmpfs           412M  168k  412M   1% /run/user/1000
/dev/sdb1       7.9G   22M  7.9G   1% /run/media/jaap/4F6B-B1D5

after reboot:

run the test and no text after test. problem solved.

Comment 12 Chris Murphy 2020-09-01 15:23:22 UTC
Thanks for testing!


Note You need to log in before you can comment on or make changes to this bug.