From Fedora Project Wiki

Revision as of 00:40, 21 October 2022 by Adamwill (talk | contribs) (add another 'ok' message)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Associated release criterion
This test case is associated with the Basic_Release_Criteria#reboot unmount 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.


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


  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 -iv '\<recovery algorithm\>' | grep -iE '\<(dirty bit|corrupt|run fsck|recovery|recovering|tree-log replay)\>'
    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. Please also include the output from the grep output as well.
  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).
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)

# btrfs kernel
BTRFS info (device vda3): start tree-log replay

# The following are not errors (they just contain suspicious keywords):

raid6: using avx2x2 recovery algorithm
kernel: CPU features: detected: Hardware dirty bit management

Expected Results

  1. Each grep command should produce no output (or it should be unrelated to disk operations).
  2. Requesting reboot should cause an orderly shutdown and restart of the system.