#1596 Issue closed: Preparation to release ReaR 2.3¶
Labels: enhancement, fixed / solved / done
jsmeix opened issue at 2017-11-24 12:32:¶
Accumulative issue for anything that we should do
in preparation to release ReaR 2.3
like documentation updates etc...
See
https://github.com/rear/rear/wiki/Release-process
You may also have a look at previous issues like
https://github.com/rear/rear/issues/1424
https://github.com/rear/rear/issues/1373
https://github.com/rear/rear/issues/1073
jsmeix commented at 2017-11-24 13:03:¶
@gdha
I would like to suggest an addition to
https://github.com/rear/rear/wiki/Release-process
I suggest to add some kind of "dummy" git commit
where the only purpose is to get an explicit 'git log' entry
about the release so that in the whole git log it becomes
obvious until what exact git commit things belong
to what ReaR version.
Example:
In current 'git log' there is (excerpts):
commit 30099a98fdc1eab6373bc3682929bc4b9c09b54b
Author: Sebastien Chabrolles ...
Date: Fri Jul 21 22:13:38 2017 +0200
Adapt chrp-boot option when xorrisofs is used
- xorrisofs use -chrp-boot-part option to generate PPC boot while
mkisofs use -chrp-boot
commit fd13be8f1bb091e1d324d35d3be527b34346a38e
Author: Gratien D'haese ...
Date: Thu Jul 20 09:51:54 2017 -0400
prepare for release v2.2
commit 3a35f163275fa646e58dce1401614255231ab565
Merge: 4638861 942fcd0
Author: Johannes Meixner ...
Date: Tue Jul 18 16:44:01 2017 +0200
Merge pull request #1418 from gozora/issue_1370
It does not make sufficiently clear whether or not the commit
fd13be8f1bb091e1d324d35d3be527b34346a38e
is really the last commit that belongs to ReaR 2.2
or if perhaps the next newer commit
30099a98fdc1eab6373bc3682929bc4b9c09b54b
also belongs to ReaR 2.2.
It seems only from the commits itself
https://github.com/rear/rear/commit/30099a98fdc1eab6373bc3682929bc4b9c09b54b
https://github.com/rear/rear/commit/fd13be8f1bb091e1d324d35d3be527b34346a38e
https://github.com/rear/rear/commit/3a35f163275fa646e58dce1401614255231ab565
one can see which commit belongs to ReaR 2.2
because the two older ones are tagged with "rear-2.2"
while the newer one is not tagged.
Also "git log --decorate=full" shows the tag but
only for the one commit where the tag was set:
commit 30099a98fdc1eab6373bc3682929bc4b9c09b54b
Author: Sebastien Chabrolles ...
Date: Fri Jul 21 22:13:38 2017 +0200
Adapt chrp-boot option when xorrisofs is used
- xorrisofs use -chrp-boot-part option to generate PPC boot while
mkisofs use -chrp-boot
commit fd13be8f1bb091e1d324d35d3be527b34346a38e (tag: refs/tags/rear-2.2, tag: refs/tags/2.2)
Author: Gratien D'haese ...
Date: Thu Jul 20 09:51:54 2017 -0400
prepare for release v2.2
commit 3a35f163275fa646e58dce1401614255231ab565
Merge: 4638861 942fcd0
Author: Johannes Meixner ...
Date: Tue Jul 18 16:44:01 2017 +0200
Merge pull request #1418 from gozora/issue_1370
Accordingly I think an explicit git commit log entry
when a release actually happened would be helpful.
gdha commented at 2017-11-25 09:47:¶
@jsmeix Or, we can make a branch rear-2.3 from the master? Or, use
git commit --allow-empty -m '#rear-2.3' comments to our last commits
which still belong to ReaR v2.3 release?
jsmeix commented at 2017-11-27 10:37:¶
@gdha
yes, something like
git commit --allow-empty -m 'ReaR 2.3 release'
or
git commit --allow-empty -m 'ReaR 2.3 released'
is what I meant.
Such a commit can be either the last one in the ReaR 2.3 "release"
or the first one after ReaR 2.3 was successfully "released"
because both make it clear where the borderline is
between the ReaR 2.3 release and anything later.
But perhaps a branch for each ReaR release is even better
when this way users could easily download that branch
from GitHub to get a particular ReaR release.
jsmeix commented at 2017-11-29 16:20:¶
I found a minor backward incompatible change, see
https://github.com/rear/rear/issues/1512#issuecomment-347912101
On SLES11 one must explicitly specify the old ReaR behaviour
were the keys from the original system are in the recovery system
via SSH_UNPROTECTED_PRIVATE_KEYS='yes' for example like
SSH_ROOT_PASSWORD="rear" SSH_UNPROTECTED_PRIVATE_KEYS='yes'
gdha commented at 2017-11-29 16:40:¶
@rear/contributors Let us fix as many (little) issues this week and from
next week on we freeze our code (meaning no new features will be
accepted anymore in 2.3).
We need a few days to prepare the release notes (next week) and
hopefully by the end of next week we are ready for a new release? Would
that work for everybody?
jsmeix commented at 2017-11-29 16:46:¶
Perfectly fine for me.
N3WWN commented at 2017-11-29 18:42:¶
While working on https://github.com/rear/rear/issues/1598 I ran into a problem with OUTPUT=ISO backups with BACKUP=NETFS which appear to be due to changes in https://github.com/rear/rear/commit/0d119829ba507e9fd55487124f31040bd9e526ac#diff-40238ffdcc481e580d028a9d35c9b0a3
I can no longer use the following local.conf to generate rescue or backup ISOs (this worked perfectly before):
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=iso:///backup
I understand the risk/danger outlined in the related issues, but this breaks how I use ReaR in my daily routines.
Perhaps we can set name of the ISO change based on the workflow to
mitigate the issues while retaining the previous functionality? I'm
thinking something like rear-$(hostname)-$(WORKFLOW).iso, perhaps?
jsmeix commented at 2017-11-30 16:03:¶
@N3WWN
can you submit a new separated issue for your
https://github.com/rear/rear/issues/1596#issuecomment-347955896
so that we can deal with that separated from this issue here,
preferably together with a GitHub pull request that contains
whatever quick and dirty hack you may use to work around it
as an initial starting point towards a real solution because
currently I do not understand your use case i.e. how things
work for you that seem to not make sense from my point of view.
jsmeix commented at 2017-12-01 08:48:¶
https://github.com/rear/rear/issues/1596#issuecomment-347955896
is handled via
https://github.com/rear/rear/issues/1613
gdha commented at 2017-12-04 10:08:¶
Would it be OK for everyone that I trim the release notes of bit - remove all pre-1.17 notes to get it smaller again. Will verify if the info that will be removed is captured somehow in our documentation. If not then I will make issues of our web page github area.
jsmeix commented at 2017-12-04 10:38:¶
@gdha
do it just as you think it is best from your point of view
and then let me and the others proof-read it so that we
could add things that look missing from our point of view.
jsmeix commented at 2017-12-05 15:29:¶
Only FYI how current master code works for me:
Summary:
It looks good (at least for my simple setups).
Details:
I tested it on SLES12 and SLES11 with a simple setup
(system on one ext3/4 filesystem, networking via DHCP)
and both "just work" for me.
Then I became venturous and tested it on the no longer
officially supported SLES10 (disk is still '/dev/hda' there)
with same kind of simple setup.
First "rear recover" failed because SLES10 is mounting
devices by ID in /etc/fstab and "rear recover" failed to
adapt that correctly automatically:
RESCUE d49:~ # rear -D recover ... Start system layout restoration. Creating partitions for disk /dev/hda (msdos) Creating filesystem of type ext3 with mount point / on /dev/hda2. Mounting filesystem / Creating swap on /dev/hda1 Disk layout created. Restoring from '/tmp/rear.YlIHcdUTqWz1893/outputfs/d49/backup.tar.gz'... ... Restoring finished. ... Patching /etc/fstab: Replacing [ata-QEMU_HARDDISK_QM00001-part1] by [] Patching /etc/fstab: Replacing [ata-QEMU_HARDDISK_QM00001-part2] by [] Patching /boot/grub/menu.lst: Replacing [ata-QEMU_HARDDISK_QM00001-part1] by [] Patching /boot/grub/menu.lst: Replacing [ata-QEMU_HARDDISK_QM00001-part2] by [] ... Installing GRUB Legacy boot loader: Installed GRUB Legacy boot loader with /boot on disk with MBR booted on 'device (hd0) /dev/hda' with 'root (hd0,1)'. ... WARNING ! You are mounting some devices by ID. Please be aware that the IDs are hardware dependent and that you might have to adjust your fstab to match the new IDs. ... Finished recovering your system. You can explore it under '/mnt/local'.
That "replacing [disk-ID] by []" empty value does not look
promising.
The recreated system even boots but fails to mount the root
filesystem.
I changed on the original system the disk-device-IDs
into traditional kernel device nodes like /dev/hda1
in /etc/fstab and in the GRUB config files and
did "mkinitrd" plus "grub-install /dev/hda" and
created a new "rear mkbackup".
Now "rear recover" basically "just works" on my SLES10 system.
There is only a minor possible confusion with some useless
network interface migration (I have only one 'eth0' - except 'lo')
during recovery system startup via
/etc/scripts/system-setup.d/55-migrate-network-devices.sh
But when one selects "what looks least wrong" one gets
networking via DHCP and SSH in the recovery system.
schabrolles commented at 2017-12-05 16:29:¶
@jsmeix, Does the disk-by-id migration works on your sles11 and sles12 test ?
schabrolles commented at 2017-12-05 18:09:¶
@jsmeix, I just tried a backup/restore of a multipathed system.
I got the following small bug ...
RESCUE rear-rhel-142:~ # rear -D recover
Relax-and-Recover 2.2 / Git
Using log file: /var/log/rear/rear-rear-rhel-142.log
Running workflow recover within the ReaR rescue/recovery system
Starting required daemons for NFS: RPC portmapper (portmap or rpcbind) and rpc.statd if available.
Started RPC portmapper 'rpcbind'.
RPC portmapper 'rpcbind' available.
Started rpc.statd.
RPC status rpc.statd available.
Started rpc.idmapd.
Using backup archive '/tmp/rear.xAzGbMuWwaH3TfJ/outputfs/rear-rhel-142/backup.tar.gz'
Calculating backup archive size
Backup archive size is 1003M /tmp/rear.xAzGbMuWwaH3TfJ/outputfs/rear-rhel-142/backup.tar.gz (compressed)
Setting up multipathing
Activating multipath
multipath activated
Listing multipath device found
mpatha (253, 0)
Comparing disks
Ambiguous possible target disks need manual configuration (more than one with same size found)
Switching to manual disk layout configuration
Using /dev/mapper/mpatha (same name and same size) for recreating /dev/mapper/mpatha
Current disk mapping table (source -> target):
/dev/mapper/mpatha /dev/mapper/mpatha
UserInput -I LAYOUT_MIGRATION_CONFIRM_MAPPINGS needed in /usr/share/rear/layout/prepare/default/300_map_disks.sh line 211
Confirm or edit the disk mapping
1) Confirm disk mapping and continue 'rear recover'
2) Edit disk mapping (/var/lib/rear/layout/disk_mappings)
3) Use Relax-and-Recover shell and return back to here
4) Abort 'rear recover'
(default '1' timeout 10 seconds)
/dev/mapper/maptha is the orginal device (means NO MIGRATION)
but I think the change you introduced in 1e3b0d9e produce this bug:
Ambiguous possible target disks need manual configuration (more than
one with same size found)
I think the reason is the fact all disk size are put into the
replacement_hardware_disk_sizes array; even the disk which are slaves
of a multipathed device.
extract from my disklayout.conf
multipath /dev/mapper/mpatha 53687091200 /dev/sda,/dev/sdb,/dev/sdc,/dev/sdd,/dev/sde,/dev/sdf,/dev/sdg,/dev/sdh
In the example above, sda, sdb, sdc, sdd, sde, sdf, sdg, sdh are
different PATH to the same disk device. mpatha .... So, in the current
code, their sized will be stored several times .... Which conduct to the
following message: (more than one with same size found) and require
a User interaction even if only one multipath device (SAN LUN) is
presented to the system.
slaves devices size should be added into the
replacement_hardware_disk_sizes array.
jsmeix commented at 2017-12-06 11:17:¶
@schabrolles
regarding your
https://github.com/rear/rear/issues/1596#issuecomment-349359326
I think on my SLES12 and SLES11 test systems
that are KVM/QEMU virtual machines
there is actually no real disk-by-id migration:
SLES12 original system:
e205:~ # cat /etc/fstab # UUID=28e43119-dac1-4426-a71a-1d70b26d33d7 swap swap defaults 0 0 # UUID=46d7e8be-7812-49d1-8d24-e25ed0589e94 / ext4 acl,user_xattr 1 1 /dev/sda1 swap swap defaults 0 0 /dev/sda2 / ext4 acl,user_xattr 1 1 e205:~ # ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 9 Dec 6 10:05 2016-10-31-20-30-50-00 -> ../../sr0 lrwxrwxrwx 1 root root 10 Dec 6 10:05 28e43119-dac1-4426-a71a-1d70b26d33d7 -> ../../sda1 lrwxrwxrwx 1 root root 10 Dec 6 10:05 46d7e8be-7812-49d1-8d24-e25ed0589e94 -> ../../sda2
SLES12 recreated system:
d251:~ # cat /etc/fstab # UUID=28e43119-dac1-4426-a71a-1d70b26d33d7 swap swap defaults 0 0 # UUID=46d7e8be-7812-49d1-8d24-e25ed0589e94 / ext4 acl,user_xattr 1 1 /dev/sda1 swap swap defaults 0 0 /dev/sda2 / ext4 acl,user_xattr 1 1 d251:~ # ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 Dec 6 12:03 28e43119-dac1-4426-a71a-1d70b26d33d7 -> ../../sda1 lrwxrwxrwx 1 root root 10 Dec 6 12:03 46d7e8be-7812-49d1-8d24-e25ed0589e94 -> ../../sda2
SLES11 original system:
d57:~ # cat /etc/fstab /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 swap swap defaults 0 0 /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2 / ext3 acl,user_xattr 1 1 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 d57:~ # ls -l /dev/disk/by-id | grep sda lrwxrwxrwx 1 root root 9 Dec 6 10:05 ata-QEMU_HARDDISK_QM00001 -> ../../sda lrwxrwxrwx 1 root root 10 Dec 6 10:05 ata-QEMU_HARDDISK_QM00001-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Dec 6 10:05 ata-QEMU_HARDDISK_QM00001-part2 -> ../../sda2 lrwxrwxrwx 1 root root 9 Dec 6 10:05 scsi-1ATA_QEMU_HARDDISK_QM00001 -> ../../sda lrwxrwxrwx 1 root root 10 Dec 6 10:05 scsi-1ATA_QEMU_HARDDISK_QM00001-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Dec 6 10:05 scsi-1ATA_QEMU_HARDDISK_QM00001-part2 -> ../../sda2 lrwxrwxrwx 1 root root 9 Dec 6 10:05 scsi-SATA_QEMU_HARDDISK_QM00001 -> ../../sda lrwxrwxrwx 1 root root 10 Dec 6 10:05 scsi-SATA_QEMU_HARDDISK_QM00001-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Dec 6 10:05 scsi-SATA_QEMU_HARDDISK_QM00001-part2 -> ../../sda2
SLES11 recreated system:
f11:~ # cat /etc/fstab /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 swap swap defaults 0 0 /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2 / ext3 acl,user_xattr 1 1 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 f11:~ # ls -l /dev/disk/by-id | grep sda lrwxrwxrwx 1 root root 9 Dec 6 12:02 ata-QEMU_HARDDISK_QM00001 -> ../../sda lrwxrwxrwx 1 root root 10 Dec 6 12:02 ata-QEMU_HARDDISK_QM00001-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Dec 6 12:02 ata-QEMU_HARDDISK_QM00001-part2 -> ../../sda2 lrwxrwxrwx 1 root root 9 Dec 6 12:02 scsi-1ATA_QEMU_HARDDISK_QM00001 -> ../../sda lrwxrwxrwx 1 root root 10 Dec 6 12:02 scsi-1ATA_QEMU_HARDDISK_QM00001-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Dec 6 12:02 scsi-1ATA_QEMU_HARDDISK_QM00001-part2 -> ../../sda2 lrwxrwxrwx 1 root root 9 Dec 6 12:02 scsi-SATA_QEMU_HARDDISK_QM00001 -> ../../sda lrwxrwxrwx 1 root root 10 Dec 6 12:02 scsi-SATA_QEMU_HARDDISK_QM00001-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Dec 6 12:02 scsi-SATA_QEMU_HARDDISK_QM00001-part2 -> ../../sda2
jsmeix commented at 2017-12-06 14:57:¶
My first proofread of release-notes-2-3.md
https://github.com/rear/rear.github.com/pull/9
jsmeix commented at 2017-12-07 09:44:¶
@schabrolles
a bit more regarding your
https://github.com/rear/rear/issues/1596#issuecomment-349359326
I re-tested SLES12 with its default btrfs structure
on a KVM/QEMU virtual machine with a single virtual harddisk.
There is also no real disk-by-id/uuid migration done here
because during "rear recover" the btrfs filesystem and swap
get recreated with exact same UUIDs via
mkfs -t btrfs -U original_system_uuid ... mkswap -U original_system_uuid ...
SLES12 with btrfs original system:
f48:~/rear.master # cat /etc/fstab UUID=ced43af1-b606-4a27-a74c-447f9a69c7f9 swap swap defaults 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c / btrfs defaults 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /boot/grub2/x86_64-efi btrfs subvol=@/boot/grub2/x86_64-efi 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /home btrfs subvol=@/home 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /opt btrfs subvol=@/opt 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /srv btrfs subvol=@/srv 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /tmp btrfs subvol=@/tmp 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /usr/local btrfs subvol=@/usr/local 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/cache btrfs subvol=@/var/cache 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/crash btrfs subvol=@/var/crash 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/machines btrfs subvol=@/var/lib/machines 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/named btrfs subvol=@/var/lib/named 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/log btrfs subvol=@/var/log 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/opt btrfs subvol=@/var/opt 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/spool btrfs subvol=@/var/spool 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/tmp btrfs subvol=@/var/tmp 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /.snapshots btrfs subvol=@/.snapshots 0 0 f48:~/rear.master # ls -l /dev/disk/by-uuid/ | grep sda lrwxrwxrwx 1 root root 10 Dec 7 10:12 020abe70-76fd-4b92-b131-19ec050c492c -> ../../sda2 lrwxrwxrwx 1 root root 10 Dec 7 10:12 ced43af1-b606-4a27-a74c-447f9a69c7f9 -> ../../sda1
SLES12 with btrfs recreated system:
RESCUE f48:~ # cat /mnt/local/etc/fstab UUID=ced43af1-b606-4a27-a74c-447f9a69c7f9 swap swap defaults 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c / btrfs defaults 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /boot/grub2/x86_64-efi btrfs subvol=@/boot/grub2/x86_64-efi 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /home btrfs subvol=@/home 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /opt btrfs subvol=@/opt 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /srv btrfs subvol=@/srv 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /tmp btrfs subvol=@/tmp 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /usr/local btrfs subvol=@/usr/local 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/cache btrfs subvol=@/var/cache 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/crash btrfs subvol=@/var/crash 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/machines btrfs subvol=@/var/lib/machines 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/named btrfs subvol=@/var/lib/named 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/log btrfs subvol=@/var/log 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/opt btrfs subvol=@/var/opt 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/spool btrfs subvol=@/var/spool 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /var/tmp btrfs subvol=@/var/tmp 0 0 UUID=020abe70-76fd-4b92-b131-19ec050c492c /.snapshots btrfs subvol=@/.snapshots 0 0 RESCUE f48:~ # ls -l /dev/disk/by-uuid/ | grep sda lrwxrwxrwx 1 root root 10 Dec 7 09:24 020abe70-76fd-4b92-b131-19ec050c492c -> ../../sda2 lrwxrwxrwx 1 root root 10 Dec 7 09:24 ced43af1-b606-4a27-a74c-447f9a69c7f9 -> ../../sda1 RESCUE f48:~ # egrep 'ced43af1-b606-4a27-a74c-447f9a69c7f9|020abe70-76fd-4b92-b131-19ec050c492c' /var/log/rear/rear-f48.log | grep '+ mk' +++ mkfs -t btrfs -U 020abe70-76fd-4b92-b131-19ec050c492c -f /dev/sda2 +++ mkswap -U ced43af1-b606-4a27-a74c-447f9a69c7f9 /dev/sda1
jsmeix commented at 2017-12-14 09:01:¶
I would like to enhance the ReaR 2.3 release notes
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-3.md
by two leading paragraphs which summarize
new features and bigger enhancements and
(possibly) backward incompatible changes
so that users get an overview about important changes.
jsmeix commented at 2017-12-14 11:28:¶
@schabrolles
the current ReaR 2.3 release notes contain
near the bottom this section:
## Supported Architectures ReaR-2.3 is supported on: * Intel x86 type of processors * AMD x86 type of processors ReaR-2.3 may or may not fully work on: * Intel Itanium processors * PPC processors * PPC64 processors * PPC64LE processors
I assume the PPC entries could be changed
to something "less pessimistic" ;-)
schabrolles commented at 2017-12-14 11:34:¶
Yes I agree with you for PPC64 and PPC64LE .... PPC (32bits) is not really used (except on old Apple computer) ...
jsmeix commented at 2017-12-14 12:34:¶
@schabrolles
thanks for your prompt reply!
In
https://github.com/rear/rear.github.com/pull/10/commits/84070e5218bbcdf93e7b73c8ab8835a6bab6196d
PPC64 and PPC64LE processors are now supported by ReaR 2.3
but old PPC (32bit) processors are now listed as not supported
(because what is not used by us cannot be supported by us).
gdha commented at 2017-12-14 15:51:¶
@jsmeix I think we should add something about SSH_UNPROTECTED_PRIVATE_KEYS='yes' in the release notes? The updates could have undesired effect.
jsmeix commented at 2017-12-15 11:32:¶
@gdha
the SSH changes (and more) are described within
https://github.com/rear/rear.github.com/pull/10/
see the "New features and bigger enhancements"
and "Possibly backward incompatible changes" parts in
https://github.com/jsmeix/rear.github.com/blob/414b753ed2f58d5d2fc5c225c9c4e8906dea7fc1/documentation/release-notes-2-3.md
If you approve it, I would "just merge" it.
jsmeix commented at 2017-12-15 12:23:¶
I merged
https://github.com/rear/rear.github.com/pull/10/
right now to have my current changes in
so that others could adapt and enhance them if needed.
gdha commented at 2017-12-18 15:11:¶
I have the feeling we are set to release ReaR v2.3, no? Any blockers or urgent TODO's?
jsmeix commented at 2017-12-19 09:53:¶
Since
https://github.com/rear/rear/pull/1650#issuecomment-352693394
there is nothing from my side that I would still need to do before
the ReaR 2.3 release so that from my point of view
ReaR 2.3 can be released.
schabrolles commented at 2017-12-19 10:20:¶
@jsmeix let me run some additional test with migration on POWER.
schabrolles commented at 2017-12-20 08:53:¶
@jsmeix, test OK with sles11sp4 / sles12sp2 / rhel7 / rhel6 / ubuntu16.04 on PowerVM & KVM
- backup / restore on the same VM
- migration from single path (KVM) to multipathed (PowerVM)
jsmeix commented at 2017-12-20 09:14:¶
@schabrolles
many thanks for your testing!
@gozora
is it also o.k. from your point of view to release ReaR v2.3 now
or is there something left that must be done for ReaR 2.3?
gdha commented at 2017-12-20 09:17:¶
@schabrolles Could you add your updates to the Test Matrix 2.3 wiki page
please?
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.3
gozora commented at 2017-12-20 11:14:¶
@jsmeix no, I don't have anything I'm currently working on.
schabrolles commented at 2017-12-20 12:06:¶
@gdha, Just done. I've changed a bit the layout to add arch x86 and Power (title h2). The distro tested for each arch are now (title h3). Tell me if you like it or not.
gdha commented at 2017-12-20 12:39:¶
@rear/contributors Perfect - I will kick off a new release today.
jsmeix commented at 2017-12-20 13:33:¶
@gdha
could you add a git dummy commit as in
https://github.com/rear/rear/issues/1596#issuecomment-347142763
jsmeix commented at 2017-12-20 15:46:¶
Thank you!
https://github.com/rear/rear/commit/37bfa9c8591a69c83ea48bae73b6b0286ac36e8c
gdha commented at 2017-12-20 15:46:¶
ReaR-2.3 has been released - OBS build went fine - Fedora is under test
(no issues encountered).
I guess we have a clean build.
A big thank you to all of you for the hard work to make this release a success!!¶
I also made a branch called rear-2.3
jsmeix commented at 2017-12-21 09:07:¶
@gdha
great that you made a branch called 'rear-2.3'
https://github.com/rear/rear/tree/rear-2.3
I think the separated branch for the ReaR 2.3 release
is the final step in the ReaR 2.3 release process
so that I can close this issue.
With a separated branch for each ReaR release
we are even able to commit critical bug fixes there
so that users can update their ReaR release to the fixed one
from the matching 'rear-M.N' branch without getting also
whatever possibly incompatible other commits for new
features that are committed to the 'master' trunk where
the usual development happens.
Many thanks to all who contributed to ReaR!
jsmeix commented at 2018-06-25 09:38:¶
@gdha
only FYI:
I think
https://github.com/rear/rear/issues/1841#issuecomment-399884811
is a good example for my reasoning behind my
https://github.com/rear/rear/issues/1596#issuecomment-346824241
[Export of Github issue for rear/rear.]