Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add automated backup and restore tests #3

Merged
merged 17 commits into from Oct 3, 2023

Conversation

pcahyna
Copy link
Member

@pcahyna pcahyna commented Sep 1, 2023

This PR adds two Beakerlib ( https://github.com/beakerlib/beakerlib/wiki/man ) tests for the complete unattended backup and restore process:

  • make-backup-and-restore-bios, by @lzaoral. This tests backup and restore using the USB method, backup is stored to a second disk drive, which is also used to boot the rescue system from. This test can not be executed automatically in CI until the test infrastructure we are using (Testing Farm) supports adding a second disk to the VMs where the tests are executing. It serves as a basis for the second test:
  • make-backup-and-restore-iso, by @antonvoznia. This uses the ISO output. A ramdisk is used to emulate the CD-ROM drive. The ISO image with backup gets written to the ramdisk after ReaR recovery starts and before it starts reformatting the disk (where the ISO image is stored) to ensure that the backup persists until we need to restore it. The changes relative to make-backup-and-restore-bios are described in "A. Voznia: Automation of testing of operating system backup and recovery (2023)" https://dspace.cvut.cz/handle/10467/107238.

Solves one part of rear/rear#3014 (tests will need to enabled in the rear repository in order to get executed in CI).

lzaoral and others added 4 commits August 31, 2023 17:10
Will serve as a basis for a new test using a virtual CD drive
instead of a second disk.
Can be changed if ReaR is being run from a non-default location (git
checkout for example).
@gdha
Copy link
Member

gdha commented Sep 1, 2023

@pcahyna you should now have the required permissions to merge the PR

Copy link
Contributor

@lzaoral lzaoral left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried the make-backup-and-restore-iso test locally and it works!

Nitpicks:

  • Outdated years in copyright.
  • You probably want to update authors in the remaining files in the make-backup-and-restore-iso directory.
  • I'd squash the make-backup-and-restore-iso related commits before merging.

I'd add more comments what is the make-backup-and-restore-iso test actually trying to achieve.
While it is great that it works, I have no idea how and why are the memdisk shenanigans required.

Comment on lines +81 to +107
ISO_DEFAULT=automatic
ISO_RECOVER_MODE=unattended' | tee $REAR_CONFIG" \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes are included in 4cafe30 but do not seem to be related to it at all.

@@ -73,13 +73,15 @@ rlJournalStart
rlPhaseEnd

rlPhaseStartSetup "Create /etc/rear/local.conf"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably want to use $REAR_CONFIG here as well?

rlRun "rm -f drive_layout.{old,new}" 0 "Remove lsblk outputs"
rlRun "rm -rf /root/rear*.log /var/log/rear/*" 0 "Remove ReaR logs"
rlRun "rm -f $REAR_HOME_DIRECTORY/drive_layout.{old,new}" 0 "Remove lsblk outputs"
rlRun "rm -rf rear*.log /var/log/rear/*" 0 "Remove ReaR recovery log"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will the plain rear*.log glob remove correct files? Few lines above, the same file as referenced with the $REAR_HOME_DIRECTORY prefix. (Also, the message change seems unnecessary.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe now that rear*.log should be always referenced as /root/rear*.log and not as $REAR_HOME_DIRECTORY/rear*.log. So, few lines above it is wrong. This is because this log is created by ReaR recovery and it creates it under /root unconditionally (more precisely, under $ROOT_HOME_DIR, which is set to ~root by default). So it is not affected by our $REAR_HOME_DIRECTORY setting.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lzaoral the last commit should resolve all the $REAR_HOME_DIRECTORY confusion ...

rlLog "Setup GRUB"
rlRun "echo 'menuentry \"ReaR-recover\" {
loopback loop (hd0,msdos2)/root/rear/var/lib/rear/output/rear-fedora.iso
linux (loop)/isolinux/kernel rw selinux=0 console=ttyS0,9600 console=tty0 auto_recover unattended
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure that we will always use these hard-coded console devices? What was wrong with the detection implemented in therlPhaseStartSetup "Redirect ReaR output to $CONSOLE_DEVICE" phase which was removed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like next commits do not even need these parameters, right?

rlLog "Setup GRUB"
rlRun "echo 'menuentry \"ReaR-recover\" {
loopback loop (hd0,msdos2)/root/rear/var/lib/rear/output/rear-fedora.iso
linux (loop)/isolinux/kernel rw selinux=0 console=ttyS0,9600 console=tty0 auto_recover unattended
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, is it intended that we boot the recovery directly from GRUB? I know that it has some issues with chainloading but it would be nice to also test the bootloader (ISOLINUX AFAIK) stored on the ISO image.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, it looks like next commits have done exactly that...

@@ -60,9 +60,12 @@ check_and_submit_rear_log() {
rlFileSubmit $path "rear-$1.log"
}

ROOT_DISK=$(df -hT | grep /$ | awk '{print $1}')
Copy link
Contributor

@lzaoral lzaoral Sep 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this works reliably enough then fine, but device naming in linux is not stable.

edit: typo

rlPhaseStartSetup "Make small iso file that is bootable by memdisk"
rlRun "xorriso -as mkisofs -r -V 'REAR-ISO' -J -J -joliet-long -cache-inodes -b isolinux/isolinux.bin -c isolinux/boot.cat -boot-load-size 4 -boot-info-table -no-emul-boot -eltorito-alt-boot -dev $REAR_ISO_OUTPUT/rear-$HOSTNAME_SHORT.iso -o $REAR_ISO_OUTPUT/small-rear.iso -- -rm_r backup"
rlPhaseEnd

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: two empty lines.

Comment on lines 120 to 121
rlLog "Copying memdisk"
rlRun "cp /usr/share/syslinux/memdisk /boot/"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These commands can be combined because rlRun can specify comments.

Comment on lines 111 to 112
rlLog "Setup GRUB"
rlRun "echo 'menuentry \"ReaR-recover\" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These commands can be combined because rlRun can specify comments.

@pcahyna
Copy link
Member Author

pcahyna commented Sep 10, 2023

@lzaoral I believe I addressed most of your comments. Please check whether the comments added to the script are explanatory enough.

Copy link
Contributor

@lzaoral lzaoral left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update, @pcahyna! I was not able to successfully execute the test using tmt on Fedora Rawhide (it might be useful to also add a default test plan in the future) even after applying the following patch:

diff --git a/tests/make-backup-and-restore-iso/main.fmf b/tests/make-backup-and-restore-iso/main.fmf
index 286bb23..4db7762 100644
--- a/tests/make-backup-and-restore-iso/main.fmf
+++ b/tests/make-backup-and-restore-iso/main.fmf
@@ -1,6 +1,7 @@
 summary: 'Test basic functionality of ReaR on systems with BIOS using bootable ISO image'

 require:
+    - rear
     - syslinux-extlinux
     - syslinux-nonlinux
     - xorriso

The test timeouted after a while. Direct execution though 1mt also ended with a failure during boot of the rescue environment. Very small nitpick below. Also, I'd still squash the commits that lead to the final version of make-backup-and-restire-iso before merging.

tests/make-backup-and-restore-iso/runtest.sh Outdated Show resolved Hide resolved
@lzaoral
Copy link
Contributor

lzaoral commented Sep 26, 2023

As noted by @pcahyna in a private conversation, the test (or more probably ReaR) is not yet compatible with Fedora Rawhide. I was able to successfully execute the test both using tmt and 1mt on a RHEL 9 machine with a sufficiently large amount of RAM.

@pcahyna
Copy link
Member Author

pcahyna commented Sep 26, 2023

@lzaoral the test plan will be in the ReaR repository: pcahyna/rear#13 . It also includes information about the excluded Fedora versions and the reason behind.

antonvoznia and others added 13 commits October 3, 2023 17:27
REAR_BIN = path to the ReaR executable
REAR_CONFIG = the configuration file (local.conf)
REAR_HOME_DIRECTORY = directory with various test outputs

Co-authored-by: Pavel Cahyna <pcahyna@redhat.com>
Co-authored-by: Lukáš Zaoral <lukaszaoral@outlook.com>
Co-authored-by: antonvoznia <antoncty@gmail.com>
This uses the ISO output. A ramdisk is used to emulate the CD-ROM drive.
The ISO image with backup gets written to the ramdisk after ReaR
recovery starts and before it starts reformatting the disk (where the
ISO image is stored) to ensure that the backup persists until we need to
restore it. The changes relative to make-backup-and-restore-bios are
described in "A. Voznia: Automation of testing of operating system
backup and recovery (2023)" https://dspace.cvut.cz/handle/10467/107238.

Co-authored-by: Pavel Cahyna <pcahyna@redhat.com>
Delete hardcoded hostname, get it from hostname -s

Get disk's name of root partition

Add rear to tmt metadata requirements

Co-authored-by: Pavel Cahyna <pcahyna@redhat.com>
Co-authored-by: Lukáš Zaoral <lukaszaoral@outlook.com>
Use relative path to boot partition

Find boot partition via GRUB search

Rename iso without backup to be more clear
@pcahyna
Copy link
Member Author

pcahyna commented Oct 3, 2023

I squashed and reworded commits without any content changes. Merging.

@pcahyna
Copy link
Member Author

pcahyna commented Nov 18, 2023

As noted by @pcahyna in a private conversation, the test (or more probably ReaR) is not yet compatible with Fedora Rawhide.

Solved in PR rear/rear#3079

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants