Ticket #86 (closed enhancement: fixed)

Opened 4 years ago

Last modified 3 years ago

Add test coverage for text-mode upgrade

Reported by: jlaska Owned by: rhe
Priority: major Milestone: Fedora 15
Component: Wiki Version:
Keywords: retrospective Cc: clumens
Blocked By: Blocking:

Description

problem

See RHBZ#590823 - Text-mode upgrade fails when installing new bootloader -- KeyError: 'bootloader'

analysis

Some tests in the install test matrix involve user interface components in both text-mode and graphical-mode (native or VNC). One such bug (RHBZ #590823) involved a problem found only during text-mode upgrades to Fedora 13. The text-mode upgrade screen shows different options thanenhancement recommendation =

enhancement recommendation

I'm hesitant to recommend specific text-mode tests for each user interface element that differs in text-mode and graphical-mode (it would be exhaustive but unachievable). As a catch-all, testing a text-mode install is included in the current matrix. Is there something small that can be done to cover the gap?

  1. Perhaps adding a text-mode upgrade test case to the install matrix, or ...
  2. Adding variations to the existing upgrade tests QA:Testcase_Anaconda_Upgrade_Update_Bootloader and QA:Testcase_Anaconda_Upgrade_Skip_Bootloader to also test text-mode, or ...
  3. <insert better idea here>

Change History

comment:1 Changed 4 years ago by rhe

  • Status changed from new to assigned
  • Owner set to rhe

I think the above suggestion1 and 2 are both ok. Test-mode generally need two tests:

  • 1. A fresh install.(Already included in the matrix)
  • 2. An update install. Tester can choose any bootloader configuration method from the two. But since the bug was discovered only on a specific configuration, having two test-mode update tests can have more coverage.

comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 4 years ago by jlaska

  • Cc clumens added

Adding clumens for some clarification on anaconda upgrade bootloader behavior.

Replying to rhe:

Two tests have been drafted for upgrading in text mode:

Nice, the tests look good.

I'm still unclear on the difference in expected results for the Skip bootloader and the update bootloader test case. When a new kernel package is installed during the upgrade, it will run grubby (see the %script of the kernel rpm) and modify grub.conf. When we choose Skip bootloader, does that mean that anaconda will not write a new bootloader configuration and will not run grub-install, but will update the existing grub.conf when the new kernel is installed?

clumens: any thoughts?

comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 4 years ago by clumens

I'm still unclear on the difference in expected results for the Skip bootloader and the update bootloader test case. When a new kernel package is installed during the upgrade, it will run grubby (see the %script of the kernel rpm) and modify grub.conf. When we choose Skip bootloader, does that mean that anaconda will not write a new bootloader configuration and will not run grub-install, but will update the existing grub.conf when the new kernel is installed?

clumens: any thoughts?

Regardless of what option you pick on the bootloader UI, the kernel's %post scriptlet will still get run. So you can't help but get grub-install run and grub.conf changed.

If you select "Skip bootloader", you won't get the screen that allows you to setup how the bootloader should be configured, anaconda won't write out a bootloader configuration for you, and it will not run whatever program installs the bootloader for your platform. You will, however, still get whatever happens when the kernel's %post script runs.

Does that clear things up a bit?

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 4 years ago by rhe

Replying to clumens:

I'm still unclear on the difference in expected results for the Skip bootloader and the update bootloader test case. When a new kernel package is installed during the upgrade, it will run grubby (see the %script of the kernel rpm) and modify grub.conf. When we choose Skip bootloader, does that mean that anaconda will not write a new bootloader configuration and will not run grub-install, but will update the existing grub.conf when the new kernel is installed?

clumens: any thoughts?

Regardless of what option you pick on the bootloader UI, the kernel's %post scriptlet will still get run. So you can't help but get grub-install run and grub.conf changed.

If you select "Skip bootloader", you won't get the screen that allows you to setup how the bootloader should be configured, anaconda won't write out a bootloader configuration for you, and it will not run whatever program installs the bootloader for your platform.

Thanks clumens, Then is there any way to test the difference between “update” and "skip" bootloader? The existing update bootloader test has the same results no matter one chooses update or skip bootloader.

comment:6 in reply to: ↑ 5 ; follow-up: ↓ 7 Changed 4 years ago by clumens

Thanks clumens, Then is there any way to test the difference between “update” and "skip" bootloader? The existing update bootloader test has the same results no matter one chooses update or skip bootloader.

I can't think of anything, no.

comment:7 in reply to: ↑ 6 ; follow-up: ↓ 8 Changed 4 years ago by jlaska

Replying to clumens:

I can't think of anything, no.

I reached out for additional thoughts on anaconda-devel-list. Maybe that will help highlight differences between upgrade and skip ... or combine the two options in the UI. Stay tuned ...

comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 4 years ago by jlaska

Replying to jlaska:

Replying to clumens:

I can't think of anything, no.

I reached out for additional thoughts on anaconda-devel-list. Maybe that will help highlight differences between upgrade and skip ... or combine the two options in the UI. Stay tuned ...

Chris provided a great breakdown on the differences between the 3 bootloader upgrade options (see https://www.redhat.com/archives/anaconda-devel-list/2010-October/msg00036.html). I'm inclined to think using that mail, we can distinguish between upgraded bootloader and skipped bootloader by comparing the MBR (stage#1) with /boot/grub/stage1. If they are equal, it was upgraded. If they are different, it was skipped.

The following command alone does not seem to be enough to do the comparison. I suspect some fiddling may be required:

# dd if=/dev/vda of=/tmp/mbr bs=512 count=1
# md5sum /tmp/mbr /boot/grub/stage1

comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed 3 years ago by jlaska

  • Milestone changed from Fedora 14 to Fedora 15

UPDATE: The initial motivation for this ticket has been resolved. The installation matrix now contains text-mode versions of the update bootloader and skip bootloader tests.

I'm moving this ticket into the F-15 branch so we can continue to track updating the cases to better detect whether the bootloader was skipped or updated (see comment:8).

comment:10 in reply to: ↑ 9 ; follow-up: ↓ 11 Changed 3 years ago by jlaska

Replying to jlaska:

I'm moving this ticket into the F-15 branch so we can continue to track updating the cases to better detect whether the bootloader was skipped or updated (see comment:8).

Just doing some ticket cleanup. Hurry, are you okay with closing this ticket out ... and creating a new ticket (if needed) to resolve any remaining bootloader upgrade issues?

comment:11 in reply to: ↑ 10 Changed 3 years ago by rhe

  • Resolution set to fixed
  • Status changed from assigned to closed

Replying to jlaska:

Replying to jlaska:

I'm moving this ticket into the F-15 branch so we can continue to track updating the cases to better detect whether the bootloader was skipped or updated (see comment:8).

Just doing some ticket cleanup. Hurry, are you okay with closing this ticket out ... and creating a new ticket (if needed) to resolve any remaining bootloader upgrade issues?

Thanks, I'm closing this ticket and open another: Ticket #198

Note: See TracTickets for help on using tickets.