From Fedora Project Wiki

Fedora Test Day - Encrypted Block Device Installation

WHAT

It's time to kick the tires on encrypted block device installation support in F10-Alpha. There have been several changes on this front recently, most notably the arrival of plymouth. The plan is meet and try to poke holes in encrypted block device installations. We'll have a host of QA and Development characters hanging out discussing bugs (aka "features"), expectations, and test areas. I've included details below for how you can contribute below.

WHEN

DATE: Thursday, August 14th, 2008

TIME: Between 12:00 and 21:00 UTC (8am -> 5pm EDT)

WHERE

Discussion will be held on IRC in the #fedora-qa channel. There are quite a few different IRC clients out there you can use to join the discussion, including:

WHY

Have you tried installing using an encrypted block device yet? Support for installing to encrypted block devices was added in Fedora 9 (see https://fedoraproject.org/wiki/Anaconda/Features/EncryptedBlockDevices). While this support has been present for an entire release, it hasn't yet been given a thorough test review. Additionally, with the presence of plymouth, the method by which unlocking your encrypted devices has changed dramatically.

It's the new hotness and it could use your help in identifying use cases and recovery

WHO

The following cast of characters will be available testing, workarounds, bug fixes, and general discussion ...

  • dlehman
  • halfline
  • jlaska
  • bo09
  • atodorov
  • rwilliam
  • mganisin

If you'd like to sign up to help field questions, please add your name to the list above.

HOW

There are many ways you can help, depending on your interests and skill level.

Triage NEW Bugs

Much like a field hospital, bug triage describes the art of quickly addressing the big issues in a bug, and moving it on for further review by the development team. Unlike a field hospital, there should be no blood or gunfire. The triage process has generated quite a following. As outlined on the BugZappers home, triage is a several step process:

  1. Getting started
  2. Finding bugs to triage, the list we'll use for Test Day includes:
  3. Taking action

One should not spend more than 5 minutes triaging a single bug. If you have more time to spare, and are looking to get a bit more involved, please proceed with Bug Verification or Test Execution.

Verify Fixes

Important.png
FIXME
Do we need details, perhaps just a small list
  1. Visit a list of bugs here
  2. Update
  3. Select a bug to verify
  4. Each bug should outline steps to reproduce
  5. If you have followed those steps, and are unable to reproduce the failure, move to CLOSED RAWHIDE
Note.png
ADD THIS
Give people an idea of what they need to verify bugs, like:
  1. A system running {Rawhide?, Fedora 10 Alpha?}
    • If VM will work, give instructions on how anyone can do this from soup to nuts, somewhere.
    • If not, tell them where to get Rawhide boot media and point them at the Installation Guide
  2. A browser (preferably on a separate computer, or the VM host?)
  3. Requires more time investment than bug triage, but still easy to do

Exploratory Testing

Exploratory testing is an approach to software testing that is not scripted or planned in as much detail as a more traditional test plan. Rather than walking through a series of pre-defined test cases, the tester is asked to think about the high-level test areas in the software. From there, the tester is encouraged to use their knowledge of the product and the code in order to navigate through different areas of the software. As they walk through the software, their emphasis is to find bugs, expose new test areas, and learn more about the product to help guide future test efforts.

The simplest definition from Exploratory Testing Explained by James Bach works the best:

Exploratory testing is simultaneous learning, test design, and test execution.

For further reading on exploratory testing can be found at http://en.wikipedia.org/wiki/Exploratory_testing.

Test Areas

For our test day, let's define the following test areas as primary focus areas for exploratory testing:

  1. Software RAID - mix encrypted raid devices, raid members
  2. LVM - physical volumes, logical volumes
  3. File system probing - Scanning a filesystem that may, or may not, contain encrypted block devices (includes rescue-mode)
  4. Rescue mode - can we find and use encrypted devices?
  5. Passphrase prompt - anything related to passphrase prompting, different keyboards, languages, hitting <back> or <cancel> several times
  6. SELinux - different policies, permissive, enforcing ... does this affect storing or checking the passphrase?

Targeted Testing

Not in the mood for exploratory testing? That's fine. We've taken the time to define explicit test cases for the different test areas noted above.

How you can help:

Test execution

With a spare system(s) in hand, you are welcome to walk through one or more of the following test cases.

The goal is to flesh out any bugs in the software that might be exposed by your special hardware environment.

Important.png
Data May Be Destroyed
Any time you are testing installation, it is tremendously easy to reformat all partitions on your drive, thus loosing all data. Before proceeding, ensure your data is backed up.

Test review

See a typo in the proposed test matrix? Have an interesting hardware scenario to share? Is something not clear? Help us improve the test coverage.

Come join us on #fedora-qa, ask questions, propose changes, and share your issues.

Known Issues

Both encrypted block device installation, and plymouth have been available for testing already. As a result, there is a list of bugs already filed for each area. Before you file a new bug, please refer to the following before filing a new bug: