From Fedora Project Wiki
No edit summary
(hijack Adam's page because it's fun)
 
Line 4: Line 4:
|description=This test case ensures that disk drive(s) are properly unmounted during a power down or a restart.
|description=This test case ensures that disk drive(s) are properly unmounted during a power down or a restart.
|setup=
|setup=
# Install or deploy the Fedora release media you wish to test. Follow all defaults, except that you can use any file system supported by the installer for the system partitions (ideally, this test should be run at least once with each of them).
# Install or deploy the Fedora release media you wish to test. You can use any allowed configuration by the installer.
# Reboot to the installed system.
# Reboot to the installed system.
|actions=
|actions=
# On the installed system, run a console and become root with {{command|sudo su -}} or {{command|su -}}.
# On the installed system, search for disk mount/unmount errors using the following command: <pre>sudo journalctl -b | grep -E 'dirty bit|data may be corrupt|recovery|unmounted|recovering'</pre> If there is no output, there were no such errors and everything seems correct.
# Run the following command: {{command|journalctl -b <nowiki>|</nowiki> grep -E "dirty bit<nowiki>|</nowiki>data may be corrupt<nowiki>|</nowiki>recovery<nowiki>|</nowiki>unmounted<nowiki>|</nowiki>recovering"}} and see whether there is any output.
#* If there was some output from the grep command, save the full journal log using <pre>sudo journalctl -b > journal.log</pre> If the grep output does not show clearly that the output is related to a disk mount/unmount problem, open the {{filename|journal.log}} file, find the relevant lines and verify whether this is an error related to disk mounting or an unrelated message.
# If there was output from the grep command, run the command {{command|journalctl -b > journal.log}}. If the grep output does not show clearly that the output resulted from a disk unmount problem, open the journal.log file and search for matches to the grep output to verify that the output was related to a disk unmount problem.
#* If the output is related to disk mounting, please file a bug report (the {{pkg|kernel}} is most likely the correct package to file the report against) and attach the {{filename|journal.log}} file to the bug report.
# If the grep output is for a disk unmount problem, 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.
# Restart the system.
# Restart the test system using the command {{command|reboot}} on the virtual console.
# Repeat all the steps above once more (the first pass checks whether the system unmounted disks properly when rebooting from the installer, the second pass checks whether the system unmounted disks properly when rebooting from the installed system).
# Repeat steps 1 to 4 above.
 
{{admon/note|Manual error checking|This test relies on specific expected text in error messages. It's possible these messages may change in the future and there may be an error that is not caught by the {{command|grep}} command. Optionally you can examine the {{command|journalctl -b}} output manually for error messages that might indicate a filesystem not being cleanly unmounted at shutdown, and file a bug report if you find any.}}
{{admon/note|Manual error checking|This test relies on specific expected text in error messages. It's possible these messages may change in the future and there may be an error that is not caught by the {{command|grep}} command. Optionally you can examine the {{command|sudo journalctl -b}} output manually for error messages that might indicate a filesystem not being cleanly unmounted at shutdown, and file a bug report if you find any. Here are sample error messages from system journal that indicate errors known to us:
{{admon/note|Sample Errors|<pre> -- Logs begin at Tue 2019-08-27 09:26:40 CEST, end at Tue 2019-11-26 14:50:14 CET. --
<pre>
Nov 25 10:25:20 phoenix systemd-fsck[684]: root: recovering journal
# FAT fsck
Nov 25 10:25:20 phoenix systemd-fsck[684]: root: Clearing orphaned inode
systemd-fsck[681]: 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
12325283 (uid=1000, gid=1000, mode=0100644, size=641092)
 
Nov 25 10:25:20 phoenix systemd-fsck[684]: root: Clearing orphaned inode
# FAT kernel
12331101 (uid=1000, gid=1000, mode=0100644, size=641092)
FAT-fs (vdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Nov 25 10:25:20 phoenix systemd-fsck[684]: root: clean, 1023215/26869760
 
files, 46957728/107451392 blocks
# ext4 fsck
Nov 25 09:25:22 phoenix systemd-fsck[877]: boot: recovering journal
systemd-fsck[681]: /dev/vdb2: recovering journal
Nov 25 09:25:22 phoenix systemd-fsck[878]: fsck.fat 4.1 (2017-01-24)
 
Nov 25 09:25:22 phoenix systemd-fsck[878]: 0x25: Dirty bit is set. Fs was
# ext4 kernel
not properly unmounted and some data may be corrupt
EXT4-fs (vdb2): recovery complete
Nov 25 09:25:22 phoenix systemd-fsck[878]:  Automatically removing dirty
 
bit.
# xfs kernel
Nov 25 09:25:22 phoenix systemd-fsck[878]: Performing changes.
XFS (vdb3): Starting recovery (logdev: internal)
Nov 25 09:25:22 phoenix systemd-fsck[878]: /dev/nvme0n1p1: 34 files,
</pre>}}
6897/51145 clusters
Nov 25 09:25:22 phoenix systemd-fsck[877]: boot: clean, 103/65536 files,
67833/262144 blocks
</pre>.}}
|results=
|results=
# Each {{command|grep}} command should produce no output.
# Each {{command|grep}} command should produce no output.
# Running {{command|reboot}} should cause an orderly shutdown and restart of the system.
# Requesting reboot should cause an orderly shutdown and restart of the system.
}}
}}

Latest revision as of 14:20, 8 January 2020

Note.png
Associated release criterion
This test case is associated with the Basic_Release_Criteria#shutdown release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion. If so, please file a bug and nominate it as blocking the appropriate milestone, using the blocker bug nomination page.


Description

This test case ensures that disk drive(s) are properly unmounted during a power down or a restart.

Setup

  1. Install or deploy the Fedora release media you wish to test. You can use any allowed configuration by the installer.
  2. Reboot to the installed system.

How to test

  1. On the installed system, search for disk mount/unmount errors using the following command:
    sudo journalctl -b | grep -E 'dirty bit|data may be corrupt|recovery|unmounted|recovering'
    If there is no output, there were no such errors and everything seems correct.
    • 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.
  2. Restart the system.
  3. Repeat all the steps above once more (the first pass checks whether the system unmounted disks properly when rebooting from the installer, the second pass checks whether the system unmounted disks properly when rebooting from the installed system).
Note.png
Manual error checking
This test relies on specific expected text in error messages. It's possible these messages may change in the future and there may be an error that is not caught by the grep command. Optionally you can examine the sudo journalctl -b output manually for error messages that might indicate a filesystem not being cleanly unmounted at shutdown, and file a bug report if you find any. Here are sample error messages from system journal that indicate errors known to us:
# FAT fsck
systemd-fsck[681]: 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.

# FAT kernel
FAT-fs (vdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

# ext4 fsck
systemd-fsck[681]: /dev/vdb2: recovering journal

# ext4 kernel
EXT4-fs (vdb2): recovery complete

# xfs kernel
XFS (vdb3): Starting recovery (logdev: internal)

Expected Results

  1. Each grep command should produce no output.
  2. Requesting reboot should cause an orderly shutdown and restart of the system.