#2368 Issue closed: ReaR v2.6 Release Preps

Labels: documentation, fixed / solved / done

gdha opened issue at 2020-04-15 09:29:

Would it be feasible to get ReaR v2.6 ready by the end of May 2020?

  • [x] Close, fix or shift current ReaR v2.6 labelled issues.
  • [x] Have the Release Notes ready
  • [x] Fill up the Test Matrix ReaR v2.6
  • [x] Any other topic (just add it here)

jsmeix commented at 2020-05-19 12:51:

The currently only open issues with milestone ReaR 2.6 are
https://github.com/rear/rear/issues/1766
and
https://github.com/rear/rear/issues/1957

I think it would be OK when the first one is postponed to ReaR 2.7
but the second one can and should be cleaned up for ReaR 2.6.

jsmeix commented at 2020-05-20 14:26:

Added latest GitHub commit messages to the ReaR 2.6 release notes via
https://github.com/rear/rear.github.com/commit/f0cd761619921b74fbaebcb98d9f41a36b2c9257

jsmeix commented at 2020-05-25 10:29:

The issue in https://github.com/rear/rear/pull/2405
is a blocker for ReaR 2.6 see in particular
https://github.com/rear/rear/pull/2405#issuecomment-633482177
and
https://github.com/rear/rear/pull/2405#issuecomment-633500692

gdha commented at 2020-05-28 14:26:

@jsmeix You were updating the release notes so far. I will review these tomorrow.
If possible add something to the Test Matrix 2.6.

@rear/contributors Can we agree that on June 1st we will not add new feature to the current ReaR v2.6 release candidate. Only serious bug fixes will be applied, otherwise, we cannot test properly.

jsmeix commented at 2020-05-29 11:40:

So far I added SLES 11 SP 4 and
SLES 12 SP 5 with default btrfs structure and
SLES 15 SP 1 with default btrfs structure to
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6

As time permits I would like to also add SLE 12 and 15 with default LVM cases
i.e. with what comes out of YaST's "LVM-based Proposal" by default.

gdha commented at 2020-06-02 08:06:

@jsmeix Thank you for the excellent release notes. Extremely detailed and clear - the best ever - thanks Johannes for your hard work.

I will try to test fedora 32 this week so we can add it to the Matrix.

Shall we try to get ReaR 2.6 released by mid June?

jsmeix commented at 2020-06-02 09:22:

You are welcome!

ReaR 2.6 release mid June is OK for me.

jsmeix commented at 2020-06-02 11:11:

@OliverO2
I have a question regarding what Ubuntu versions could be
listed as supported by the upcoming ReaR 2.6 release.

In your recent pull requests
https://github.com/rear/rear/pull/2376
https://github.com/rear/rear/pull/2363
https://github.com/rear/rear/pull/2361
https://github.com/rear/rear/pull/2353
https://github.com/rear/rear/pull/2350
you wrote
How was this pull request tested? On Ubuntu 18.04.4 LTS
and in https://github.com/rear/rear/pull/2278
and https://github.com/rear/rear/pull/2166
and https://github.com/rear/rear/pull/2131 you wrote
Ubuntu 18.04.3 LTS and Ubuntu 18.04.2 LTS
so it seems Ubuntu 18.04 LTS is well tested.

The last of your pull requests that contains Ubuntu 16.04 is
https://github.com/rear/rear/pull/2119
which is just before the ReaR 2.5 release
so it seems ReaR 2.6 was no longer tested with Ubuntu 16.04.

Currently we would still list Ubuntu 16 as supported in the
ReaR 2.6 release notes, cf.
https://github.com/rear/rear.github.com/commit/bab64c0a9dc14fd24962fd7326422ade390aa021

OliverO2 commented at 2020-06-02 11:45:

@jsmeix
My records show that the last system was migrated from Ubuntu 16.04 LTS to 18.04 LTS in June 2019. Since then, all ReaR tests on my side were done on Ubuntu 18.04 LTS only. I have no indication about ReaR becoming incompatible with Ubuntu 16.04, so I would assume that it still works.

What I was thinking about was doing a small test on Ubuntu's current 20.04 LTS release. Would that be of interest for ReaR's 2.6 release?

jsmeix commented at 2020-06-02 12:19:

@OliverO2
even a small "smoke test" on Ubuntu 20.04 LTS would be much appreciated
because - as far as I know - we do not yet have any tests there.

I could add your test overview to our "Test Matrix rear 2.6"
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6

Many thanks in advance!

OliverO2 commented at 2020-06-02 12:53:

@jsmeix
OK, I'll do those Ubuntu tests, expecting to complete them this week, which should be compatible with your envisioned mid June release. I'll report results in this issue. Thanks for coordinating!

OliverO2 commented at 2020-06-04 11:36:

First test result:

Ubuntu 18.04.4 LTS (Desktop)

  • ReaR GitHub master 7281059eb12662f1c9815171f1b65ebf9cd218d9 of 2020-05-29
  • rear mkopalpba, rear mkrescue on x86_64 bare metal

    • 3 SSDs, two of them (sda, sdb) using a mirrored Btrfs configuration on TCG-Opal 2 hardware-encrypted drives
    • lsblk -io NAME,FSTYPE,SIZE,MOUNTPOINT sda 238,5G |-sda1 vfat 93M /boot/efi |-sda2 btrfs 223,1G /volumes/01 -sda3 swap 15,3G [SWAP] sdb 238,5G |-sdb1 vfat 93M |-sdb2 btrfs 223,1G-sdb3 swap 15,3G sdc 119,2G -sdc1 crypto_LUKS 119,2G-Foxtrot-02 btrfs 119,2G /volumes/02

    • etc/rear/local.conf: SSH_ROOT_PASSWORD='***' BACKUP=INTERNAL OUTPUT=RAWDISK BTRFS_SUBVOLUME_GENERIC_SETUP="true" SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/ubuntu/shimx64.efi" OUTPUT_URL="file:///mnt/reserve/Transfer.nobackup/ReaR-Testing/Output"

    • rear recover on VirtualBox VM:
    • Recreating disk layout, skipping TCG Opal-2 SED setup (unavailable in emulation), skipping sdb mirror.
    • Complete restore of /boot/efi and / (using internal unpublished backup software).

jsmeix commented at 2020-06-04 11:58:

@OliverO2
thank you!

I added it right now to
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6

OliverO2 commented at 2020-06-04 19:34:

Second test result:

Ubuntu 20.04 LTS (Desktop)

  • ReaR GitHub master 7281059eb12662f1c9815171f1b65ebf9cd218d9 of 2020-05-29
  • rear mkrescue on VirtualBox VM (x86_64):

    • lsblk -io NAME,FSTYPE,SIZE,MOUNTPOINT NAME FSTYPE SIZE MOUNTPOINT sda 256G |-sda1 vfat 512M /mnt/local/boot/efi `-sda2 ext4 255.5G /mnt/local sdb 256G

    • etc/rear/local.conf: SSH_ROOT_PASSWORD='***' OUTPUT=RAWDISK SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/ubuntu/shimx64.efi" OUTPUT_URL="file:///tmp/ReaR-Output"

    • rear recover on VirtualBox VM:
    • Recreating disk layout only (as no backup method was used).

jsmeix commented at 2020-06-05 09:00:

@OliverO2
thank you once more!

I also added it right now to
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6

gdha commented at 2020-06-09 15:43:

image
I noticed that the SELinux relabeling process is working too hard. There is no need to relabel /sys directories IMHO? This what I saw while rebooting a Fedora 32 test VM

gdha commented at 2020-06-11 11:55:

@rear/contributors Can we do a release by mid next week? Any blockers still pending? Documentation seems polished. Anything missing? Now it is to time to inspect and test.
Thanks all for your valuable contributions.

jsmeix commented at 2020-06-15 08:59:

A release by mid this week (i.e. from about Wednesday 17. June) is OK for me.

OliverO2 commented at 2020-06-15 11:38:

I have one more thing. Issue and PR upcoming this afternoon. Small change in the TCG Opal-2 PBA to fix a boot issue when unlocking self-encrypted disks. Hope it's OK to integrate into this release.

OliverO2 commented at 2020-06-15 13:35:

I expect to do one complete mkrescue/recover cycle on Ubuntu 20.04, scheduled to run tonight. This would complete an entry in the test matrix for v2.6.

OliverO2 commented at 2020-06-16 08:28:

I have now tested a complete mkrescue/recover cycle on Ubuntu 20.04. Everything worked out of the box except that DHCP was not enabled on the rescue system. So I added a separate Network Manager auto-detection. PR upcoming.

OliverO2 commented at 2020-06-16 09:57:

So this would be my final test matrix entry for Ubuntu 20.04 Desktop:

Ubuntu 20.04 LTS (Desktop)

  • ReaR GitHub master fb23c5d711af9ee505a9b03ea7324a098f90891d of 2020-06-09
    • plus DHCP auto-detection commit 76f6bf8d925a249ca522365d780036ad38d174b7
  • rear mkopalpba, rear mkrescue on x86_64 bare metal

    • 3 SSDs, two of them (sda, sdb) using a mirrored Btrfs configuration on TCG-Opal 2 hardware-encrypted drives
    • lsblk -io NAME,FSTYPE,SIZE,MOUNTPOINT sda 238,5G |-sda1 vfat 93M /boot/efi |-sda2 btrfs 223,1G /volumes/01 -sda3 swap 15,3G [SWAP] sdb 238,5G |-sdb1 vfat 93M |-sdb2 btrfs 223,1G-sdb3 swap 15,3G sdc 119,2G -sdc1 crypto_LUKS 119,2G-Foxtrot-02 btrfs 119,2G /volumes/02

    • etc/rear/local.conf: SSH_ROOT_PASSWORD='***' BACKUP=INTERNAL OUTPUT=RAWDISK BTRFS_SUBVOLUME_GENERIC_SETUP="true" SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/ubuntu/shimx64.efi" OUTPUT_URL="file:///mnt/reserve/Transfer.nobackup/ReaR-Testing/Output"

    • rear recover on x86_64 bare metal:
    • 1 SSD (TCG-Opal 2 hardware-encrypted drive), 1 HDD
    • lsblk -io NAME,FSTYPE,SIZE,MOUNTPOINT NAME FSTYPE SIZE MOUNTPOINT sda 238,5G |-sda1 vfat 93M /boot/efi |-sda2 btrfs 223,1G / -sda3 swap 15,3G [SWAP] sdb 931,5G-sdb1 crypto_LUKS 931,5G `-Foxtrot-02 btrfs 931,5G /volumes/02

    • Complete restore (using internal unpublished backup software).

jsmeix commented at 2020-06-16 10:42:

@gdha
could you have a look at
https://github.com/rear/rear/pull/2427
because that additional code is used by the above
https://github.com/rear/rear/issues/2368#issuecomment-644663685

jsmeix commented at 2020-06-16 13:05:

I added
https://github.com/rear/rear/issues/2368#issuecomment-644663685
to https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6

gdha commented at 2020-06-17 16:48:

@rear/contributors We have just released rear-2.6. Try it out if possible. Tomorrow we will announce it if that is OK by you (contributors)

jsmeix commented at 2020-06-18 11:39:

I added test "SLES 15 SP 1 with default LVM and LUKS encryption and btrfs structure" to
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6
This is the last test I liked to do and all tests "just worked" for me
so currently all looks fine to me with ReaR 2.6.

jsmeix commented at 2020-06-18 11:45:

@gdha
will you do

        Tag version in master branch:

git tag -s -a rear-2.xx -m "Rear release 2.xx"
git tag -s -a 2.xx -m "Rear release 2.xx"

according to
https://github.com/rear/rear/wiki/Release-process
because currently git log shows topmost only

... 10e049b76a4e7a19c90d34c65bd9ab8e05dd3083 Wed Jun 17 17:24:11 2020 +0200
last preps before releasing rear-2.6

while for ReaR 2.5 we had in git log

... ce9496be82a7d5d899afe7d060ed5cbb2f28bea9 Fri May 10 11:37:57 2019 +0200
ReaR 2.5 release

jsmeix commented at 2020-06-18 11:54:

@gdha
it seems doc/rear.8 is not updated
to what there is in doc/rear.8.adoc
because doc/rear.8.adoc mentiones
e.g. "Rubrik Cloud Data Management (CDM)"
which is not in doc/rear.8 (as far as I see).

gdha commented at 2020-06-18 13:19:

@jsmeix I forgot the last git push yesterday evening. The man page is in fact not the source itself, it is rear.8.adoc and is automatically build during package creation. I never have been a fan of rear.8 being pushed into the master source tree (as it is not the source). And, we already had a few times in the past that people edit the man page itself instead of the source rear.8.adoc file.

jsmeix commented at 2020-06-19 09:38:

After sleeping over it my current idea how to deal
with the duplicated man page source files is:

On the one had there must not be duplicated source files
which means doc/rear.8 cannot stay as is.

On the other hand the ReaR sources should contain a man page
(e.g. to also have a man page in a plain git source checkout)
which means a doc/rear.8 source file needs to be there.

I think the way out of this dilemma is to have a doc/rear.8 source file
that contains only a small static man page text that points the user
to the actual man page text in the doc/rear.8.adoc file.

This way the doc/rear.8 source file could be still overwritten and
replaced with full man page content generated from doc/rear.8.adoc
by package making tools.

jsmeix commented at 2020-06-19 13:44:

Since https://github.com/rear/rear/issues/2368#issuecomment-645491075
this issue is marked as done
and latest git commits in our master code are now

* ...3b898aab68e96fde4c02c33733bb3f56c705be1b Thu Jun 18 15:13:36 2020 +0200
rear.8 man page left-over :

* ... c40fd8efdc2b9822c05ba17b0ad219ffad5c19b0 Wed Jun 17 18:41:46 2020 +0200
ReaR 2.6 release :

* ... 10e049b76a4e7a19c90d34c65bd9ab8e05dd3083 Wed Jun 17 17:24:11 2020 +0200
last preps before releasing rear-2.6 :

so https://github.com/rear/rear/issues/2368#issuecomment-645963960
is solved
and
https://raw.githubusercontent.com/rear/rear/master/doc/rear.8
looks up to date
so https://github.com/rear/rear/issues/2368#issuecomment-645967893
is also solved.

From my point of view this issue is completely done now
so that I close it hereby.

Many thanks to all ReaR maintainers and contributors
who helped and worked together to create ReaR 2.6!
Thank you so much!


[Export of Github issue for rear/rear.]