From 832525179c9c0509b33bdacc1ba568673af1b665 Mon Sep 17 00:00:00 2001
From: gdha <gratien.dhaese@gmail.com>
Date: Thu, 19 Dec 2024 14:27:03 +0000
Subject: [PATCH] ReaR v2.8 release notes added

---
 docs/issues/2019-02-01.2028.issue.open.md   |  254 +++
 docs/issues/2024-09-09.3316.issue.closed.md |  233 ++
 docs/issues/2024-12-03.3352.pr.closed.md    |   71 +
 docs/issues/2024-12-03.3353.pr.merged.md    |   30 +
 docs/issues/2024-12-04.3354.pr.merged.md    |   90 +
 docs/issues/2024-12-04.3355.pr.open.md      |   95 +
 docs/issues/2024-12-04.3356.pr.merged.md    |  134 ++
 docs/issues/2024-12-05.3357.issue.open.md   |  221 ++
 docs/issues/2024-12-10.3359.issue.open.md   |   88 +
 docs/issues/2024-12-11.3360.issue.open.md   |   26 +
 docs/issues/2024-12-11.3361.issue.open.md   |  220 ++
 docs/issues/2024-12-11.3362.issue.open.md   |  165 ++
 docs/issues/2024-12-12.3363.issue.open.md   |  100 +
 docs/issues/2024-12-16.3364.pr.merged.md    |   86 +
 docs/issues/2024-12-16.3365.pr.merged.md    |  201 ++
 docs/issues/2024-12-17.3366.pr.open.md      |   40 +
 docs/issues/2024-12-17.3367.pr.merged.md    |   23 +
 docs/issues/2024-12-18.3368.issue.open.md   |  539 +++++
 docs/issues/2024-12-18.3369.issue.open.md   |   29 +
 docs/issues/2024-12-18.3370.pr.merged.md    |  203 ++
 docs/issues/2024-12-19.3371.pr.open.md      |   40 +
 docs/issues/index.md                        |   21 +
 docs/releasenotes/rear28.md                 | 2217 +++++++++++++++++++
 mkdocs.yml                                  |    1 +
 24 files changed, 5127 insertions(+)
 create mode 100644 docs/issues/2019-02-01.2028.issue.open.md
 create mode 100644 docs/issues/2024-09-09.3316.issue.closed.md
 create mode 100644 docs/issues/2024-12-03.3352.pr.closed.md
 create mode 100644 docs/issues/2024-12-03.3353.pr.merged.md
 create mode 100644 docs/issues/2024-12-04.3354.pr.merged.md
 create mode 100644 docs/issues/2024-12-04.3355.pr.open.md
 create mode 100644 docs/issues/2024-12-04.3356.pr.merged.md
 create mode 100644 docs/issues/2024-12-05.3357.issue.open.md
 create mode 100644 docs/issues/2024-12-10.3359.issue.open.md
 create mode 100644 docs/issues/2024-12-11.3360.issue.open.md
 create mode 100644 docs/issues/2024-12-11.3361.issue.open.md
 create mode 100644 docs/issues/2024-12-11.3362.issue.open.md
 create mode 100644 docs/issues/2024-12-12.3363.issue.open.md
 create mode 100644 docs/issues/2024-12-16.3364.pr.merged.md
 create mode 100644 docs/issues/2024-12-16.3365.pr.merged.md
 create mode 100644 docs/issues/2024-12-17.3366.pr.open.md
 create mode 100644 docs/issues/2024-12-17.3367.pr.merged.md
 create mode 100644 docs/issues/2024-12-18.3368.issue.open.md
 create mode 100644 docs/issues/2024-12-18.3369.issue.open.md
 create mode 100644 docs/issues/2024-12-18.3370.pr.merged.md
 create mode 100644 docs/issues/2024-12-19.3371.pr.open.md
 create mode 100644 docs/releasenotes/rear28.md

diff --git a/docs/issues/2019-02-01.2028.issue.open.md b/docs/issues/2019-02-01.2028.issue.open.md
new file mode 100644
index 00000000..7e4c9767
--- /dev/null
+++ b/docs/issues/2019-02-01.2028.issue.open.md
@@ -0,0 +1,254 @@
+[\#2028 Issue](https://github.com/rear/rear/issues/2028) `open`: BTRFS Raid / Multi Disk setup is currently not supported
+=========================================================================================================================
+
+**Labels**: `needs sponsorship`, `severe improvement`
+
+#### <img src="https://avatars.githubusercontent.com/u/1926396?u=705546e01ca12110cc5f18b9dbc2ffe1b447cd76&v=4" width="50">[ChojinDSL](https://github.com/ChojinDSL) opened issue at [2019-02-01 16:41](https://github.com/rear/rear/issues/2028):
+
+I've noticed that ReaR doesn't correctly work with a BTRFS Multiple Disk
+setup.
+
+E.g. a BTRFS Volume can consist of multiple disks in a variety of
+configurations, e.g. single, RAID1, RAID10, RAID5/6, etc..
+
+It seems as if ReaR only creates a single disk BTRFS Volume during
+recovery. This could create problem if the backup is larger than a
+single disk.
+
+Since BTRFS supports many mixed configurations, e.g. Metadata as RAID1
+but Data as RAID10, accurately detecting the original layout might be
+tricky.  
+However, at the very least it would be very nice if ReaR could detect if
+a BTRFS Volume consists of multiple devices and then re-creates the
+BTRFS volume with the member devices during recovery.
+
+If you create the BTRFS volume with just a list of devices, then per
+default the volume will be created as a "single" volume, but with the
+total capacity of all member devices. Since BTRFS supports rebalancing
+to migrate from single to RAID1/10/5/6, it would be easy for the user to
+rebalance their system back to their original layout, after recovery has
+taken place and the system has bootet into the OS.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2019-02-05 10:04](https://github.com/rear/rear/issues/2028#issuecomment-460579609):
+
+I implemented the current Btrfs support in ReaR and  
+I never had a Btrfs setup on multiple disks  
+so that I think you are right that currently  
+ReaR does not support a Btrfs filesystem that is on more than one
+partition.
+
+See  
+"Disk layout file syntax" at  
+[https://github.com/rear/rear/blob/master/doc/user-guide/06-layout-configuration.adoc](https://github.com/rear/rear/blob/master/doc/user-guide/06-layout-configuration.adoc)  
+that reads (excerpt)
+
+    Filesystems
+
+    fs <device> <mountpoint> <filesystem type> [uuid=<uuid>] [label=<label>] [blocksize=<block size(B)>] [<reserved_blocks=<nr of reserved blocks>] [max_mounts=<nr>] [check_interval=<number of days>d] [options=<filesystem options>]
+
+    Btrfs Default SubVolumes
+
+    btrfsdefaultsubvol <device> <mountpoint> <btrfs_subvolume_ID> <btrfs_subvolume_path>
+
+    Btrfs Normal SubVolumes
+
+    btrfsnormalsubvol <device> <mountpoint> <btrfs_subvolume_ID> <btrfs_subvolume_path>
+
+    Btrfs Mounted SubVolumes
+
+    btrfsmountedsubvol <device> <subvolume_mountpoint> <mount_options> <btrfs_subvolume_path>
+
+where all show only `device` but no `devices`.
+
+See also  
+[https://github.com/rear/rear/issues/2023](https://github.com/rear/rear/issues/2023)
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2019-02-05 11:43](https://github.com/rear/rear/issues/2028#issuecomment-460607949):
+
+@ChojinDSL  
+to get an idea how a Btrfs setup on multiple disks could look like  
+could you please post here the output of the command
+
+    lsblk -i -p -o NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
+
+on your original system or systems when you have different kind of them.
+
+Perhaps you may need to specify some more output columns that could be  
+of particular interest in case of Btrfs on multiple disks, see
+`lsblk -h`  
+what output columns are available for the `lsblk` command on your  
+particular system.
+
+By the way:  
+What Linux distribution and version do you use?  
+Cf.  
+[https://github.com/rear/rear/blob/master/.github/ISSUE\_TEMPLATE.md](https://github.com/rear/rear/blob/master/.github/ISSUE_TEMPLATE.md)
+
+#### <img src="https://avatars.githubusercontent.com/u/1926396?u=705546e01ca12110cc5f18b9dbc2ffe1b447cd76&v=4" width="50">[ChojinDSL](https://github.com/ChojinDSL) commented at [2019-02-05 15:35](https://github.com/rear/rear/issues/2028#issuecomment-460683215):
+
+@jsmeix Here's the output of lsblk you asked for.
+
+I use Debian Stretch at the moment.
+
+    NAME        KNAME     PKNAME   TRAN TYPE FSTYPE   SIZE MOUNTPOINT
+    /dev/sda    /dev/sda           sas  disk          1.7T 
+    |-/dev/sda1 /dev/sda1 /dev/sda      part vfat     512M /boot/efi
+    |-/dev/sda2 /dev/sda2 /dev/sda      part btrfs    1.5T /
+    `-/dev/sda3 /dev/sda3 /dev/sda      part swap   127.7G [SWAP]
+    /dev/sdb    /dev/sdb           sas  disk          1.7T 
+    |-/dev/sdb1 /dev/sdb1 /dev/sdb      part          512M 
+    |-/dev/sdb2 /dev/sdb2 /dev/sdb      part btrfs    1.5T 
+    `-/dev/sdb3 /dev/sdb3 /dev/sdb      part swap   127.7G [SWAP]
+    /dev/sdc    /dev/sdc           sas  disk          1.7T 
+    |-/dev/sdc1 /dev/sdc1 /dev/sdc      part          512M 
+    |-/dev/sdc2 /dev/sdc2 /dev/sdc      part btrfs    1.5T 
+    `-/dev/sdc3 /dev/sdc3 /dev/sdc      part swap   127.7G [SWAP]
+    /dev/sdd    /dev/sdd           sas  disk          1.7T 
+    |-/dev/sdd1 /dev/sdd1 /dev/sdd      part          512M 
+    |-/dev/sdd2 /dev/sdd2 /dev/sdd      part btrfs    1.5T 
+    `-/dev/sdd3 /dev/sdd3 /dev/sdd      part swap   127.7G [SWAP]
+    /dev/sde    /dev/sde           sas  disk          1.7T 
+    |-/dev/sde1 /dev/sde1 /dev/sde      part          512M 
+    |-/dev/sde2 /dev/sde2 /dev/sde      part btrfs    1.5T 
+    `-/dev/sde3 /dev/sde3 /dev/sde      part swap   127.7G [SWAP]
+    /dev/sdf    /dev/sdf           sas  disk          1.7T 
+    |-/dev/sdf1 /dev/sdf1 /dev/sdf      part          512M 
+    |-/dev/sdf2 /dev/sdf2 /dev/sdf      part btrfs    1.5T 
+    `-/dev/sdf3 /dev/sdf3 /dev/sdf      part swap   127.7G [SWAP]
+    /dev/sdg    /dev/sdg           sas  disk          1.7T 
+    |-/dev/sdg1 /dev/sdg1 /dev/sdg      part          512M 
+    |-/dev/sdg2 /dev/sdg2 /dev/sdg      part btrfs    1.5T 
+    `-/dev/sdg3 /dev/sdg3 /dev/sdg      part swap   127.7G [SWAP]
+    /dev/sdh    /dev/sdh           sas  disk          1.7T 
+    |-/dev/sdh1 /dev/sdh1 /dev/sdh      part          512M 
+    |-/dev/sdh2 /dev/sdh2 /dev/sdh      part btrfs    1.5T 
+    `-/dev/sdh3 /dev/sdh3 /dev/sdh      part swap   127.7G [SWAP]
+
+#### <img src="https://avatars.githubusercontent.com/u/1926396?u=705546e01ca12110cc5f18b9dbc2ffe1b447cd76&v=4" width="50">[ChojinDSL](https://github.com/ChojinDSL) commented at [2019-02-12 10:04](https://github.com/rear/rear/issues/2028#issuecomment-462696494):
+
+BTRFS is a bit unusual since it's so flexible and allows for very
+unusual setups.  
+It's probably easier to get information about the underlying BTRFS setup
+using some of BTRFS's own tools.
+
+e..g
+
+    #############
+    btrfs fi show
+
+    Label: 'ROOT'  uuid: 69a8d230-fe68-4504-bb14-1742acdb8967
+            Total devices 8 FS bytes used 2.23GiB
+            devid    1 size 1.51TiB used 1.27GiB path /dev/sda2
+            devid    2 size 1.51TiB used 1.27GiB path /dev/sdb2
+            devid    3 size 1.51TiB used 1.27GiB path /dev/sdc2
+            devid    4 size 1.51TiB used 1.27GiB path /dev/sdd2
+            devid    5 size 1.51TiB used 1.27GiB path /dev/sde2
+            devid    6 size 1.51TiB used 1.27GiB path /dev/sdf2
+            devid    7 size 1.51TiB used 1.27GiB path /dev/sdg2
+            devid    8 size 1.51TiB used 1.27GiB path /dev/sdh2
+
+    ###############
+    btrfs fi usage /
+
+    Overall:
+        Device size:                  12.10TiB
+        Device allocated:             10.12GiB
+        Device unallocated:           12.09TiB
+        Device missing:                  0.00B
+        Used:                          4.47GiB
+        Free (estimated):              6.05TiB      (min: 6.05TiB)
+        Data ratio:                       2.00
+        Metadata ratio:                   2.00
+        Global reserve:               16.00MiB      (used: 0.00B)
+
+    Data,RAID10: Size:4.00GiB, Used:2.16GiB
+       /dev/sda2     512.00MiB
+       /dev/sdb2     512.00MiB
+       /dev/sdc2     512.00MiB
+       /dev/sdd2     512.00MiB
+       /dev/sde2     512.00MiB
+       /dev/sdf2     512.00MiB
+       /dev/sdg2     512.00MiB
+       /dev/sdh2     512.00MiB
+
+    Metadata,RAID10: Size:1.00GiB, Used:71.77MiB
+       /dev/sda2     128.00MiB
+       /dev/sdb2     128.00MiB
+       /dev/sdc2     128.00MiB
+       /dev/sdd2     128.00MiB
+       /dev/sde2     128.00MiB
+       /dev/sdf2     128.00MiB
+       /dev/sdg2     128.00MiB
+       /dev/sdh2     128.00MiB
+
+    System,RAID10: Size:64.00MiB, Used:16.00KiB
+       /dev/sda2       8.00MiB
+       /dev/sdb2       8.00MiB
+       /dev/sdc2       8.00MiB
+       /dev/sdd2       8.00MiB
+       /dev/sde2       8.00MiB
+       /dev/sdf2       8.00MiB
+       /dev/sdg2       8.00MiB
+       /dev/sdh2       8.00MiB
+
+    Unallocated:
+       /dev/sda2       1.51TiB
+       /dev/sdb2       1.51TiB
+       /dev/sdc2       1.51TiB
+       /dev/sdd2       1.51TiB
+       /dev/sde2       1.51TiB
+       /dev/sdf2       1.51TiB
+       /dev/sdg2       1.51TiB
+       /dev/sdh2       1.51TiB
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2019-02-13 13:10](https://github.com/rear/rear/issues/2028#issuecomment-463193378):
+
+@ChojinDSL  
+I know Btrfs "is a bit unusual" (polite wording ;-)
+
+Btrfs' features just break traditional assumptions  
+how a stack of storage objects is usually organized  
+(like disks =&gt; partitions =&gt; filesystems =&gt; mountpoints).
+
+You may have a look at  
+[https://github.com/rear/rear/pull/1603\#issuecomment-347839823](https://github.com/rear/rear/pull/1603#issuecomment-347839823)  
+and  
+[https://github.com/rear/rear/pull/1603\#issuecomment-347860869](https://github.com/rear/rear/pull/1603#issuecomment-347860869)  
+and follow the links therein.
+
+I fear implementing support for Btrfs setup on multiple disks  
+may require that the whole disk layout code in ReaR needs  
+to be fundamentally changed, enhanced, and overhauled.  
+On the other hand  
+[https://github.com/rear/rear/issues/2023\#issuecomment-456764118](https://github.com/rear/rear/issues/2023#issuecomment-456764118)  
+indicates that perhaps it could be even easier than it looks like.
+
+#### <img src="https://avatars.githubusercontent.com/in/15368?v=4" width="50">[github-actions](https://github.com/apps/github-actions) commented at [2020-06-28 01:33](https://github.com/rear/rear/issues/2028#issuecomment-650665291):
+
+Stale issue message
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-13 07:18](https://github.com/rear/rear/issues/2028#issuecomment-2540742272):
+
+I guess we'll have to come back to this issue eventually and probably
+treat BTRFS more like LVM and RAID and not just like another filesystem.
+If we move BTRFS to the LVM / RAID layer then we could treat it as a
+NOOP in the filesystem creation stage.
+
+I'd like to reopen this and mark it as waiting for sponsor, WDYT
+@rear/contributors ?
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-13 12:31](https://github.com/rear/rear/issues/2028#issuecomment-2541347386):
+
+I reopened it as a "severe improvement"  
+with target milestone "ReaR 3.1"  
+because (as far as I understand it) "ReaR 3.0"  
+is primarily intended to deprecate old features soon  
+so "ReaR 3.0" is intended to be relaeased  
+"relatively soon" after "Rear 2.8"  
+so implementing big things which take longer time  
+cannot be done for "ReaR 3.0".
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-09-09.3316.issue.closed.md b/docs/issues/2024-09-09.3316.issue.closed.md
new file mode 100644
index 00000000..b32b00b0
--- /dev/null
+++ b/docs/issues/2024-09-09.3316.issue.closed.md
@@ -0,0 +1,233 @@
+[\#3316 Issue](https://github.com/rear/rear/issues/3316) `closed`: Question : Does REAR can backup OracleASM shared disk ?
+==========================================================================================================================
+
+**Labels**: `support / question`, `needs sponsorship`, `external tool`,
+`special hardware or VM`, `no-issue-activity`
+
+#### <img src="https://avatars.githubusercontent.com/u/176000482?v=4" width="50">[NewNow479](https://github.com/NewNow479) opened issue at [2024-09-09 00:39](https://github.com/rear/rear/issues/3316):
+
+-   ReaR version ("/usr/sbin/rear -V"): **Relax-and-Recover 2.7 / Git**
+
+-   OS version ("cat /etc/os-release" or "lsb\_release -a" or "cat
+    /etc/rear/os.conf"): **RedHatEnterpriseServer 7**
+
+-   ReaR configuration files ("cat **/etc/rear/site.conf**" and/or "cat
+    /etc/rear/local.conf"):
+
+This is site.conf from VM 1. The same file exist for VM 2 with
+`AUTOEXCLUDE_DISKS=y`
+
+    OUTPUT=ISO
+    OUTPUT_URL=nfs://nfs-server/backup_in/REAR-TEST/
+
+    BACKUP=NETFS
+    BACKUP_PROG=tar
+    BACKUP_URL=nfs://nfs-server/backup_in/REAR-TEST/
+    BACKUP_TYPE=incremental
+
+    FULLBACKUPDAY="Mon"
+    AUTOEXCLUDE_DISKS=n
+
+-   Hardware vendor/product = **VM on VMWare KVM**
+
+-   Firmware = **BIOS** and bootloader = **GRUB**
+
+-   Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or
+    multipath (DM or NVMe): Using **vSAN** (virtual SAN)
+
+-   Storage layout ("lsblk -ipo
+    NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
+
+<!-- -->
+
+    [root@node1 ~]# lsblk -ip
+    NAME                          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
+    /dev/sda                        8:0    0  160G  0 disk
+    |-/dev/sda1                     8:1    0    1G  0 part /boot
+    `-/dev/sda2                     8:2    0  159G  0 part
+      |-/dev/mapper/rhel-root     253:0    0 56,2G  0 lvm  /
+      |-/dev/mapper/rhel-swap     253:1    0    5G  0 lvm  [SWAP]
+      |-/dev/mapper/rhel-tmp      253:2    0  4,7G  0 lvm  /tmp
+      `-/dev/mapper/rhel-u01      253:3    0 93,1G  0 lvm  /u01
+    /dev/sdb                        8:16   0   16G  0 disk
+    `-/dev/sdb1                     8:17   0   16G  0 part
+    /dev/sdc                        8:32   0   50G  0 disk
+    `-/dev/sdc1                     8:33   0   50G  0 part
+    /dev/sdd                        8:48   0   35G  0 disk
+    `-/dev/sdd1                     8:49   0   35G  0 part
+      `-/dev/mapper/vg_app-lv_app 253:4    0   35G  0 lvm  /app
+    /dev/sr0                       11:0    1 1024M  0 rom
+    [root@node1 ~]# lsblk -ipf
+    NAME                          FSTYPE      LABEL UUID                                   MOUNTPOINT
+    /dev/sda
+    |-/dev/sda1                   xfs               0dfb72a7-4b5c-40a3-a112-bda4bb86377b   /boot
+    `-/dev/sda2                   LVM2_member       dkzOm0-K27j-PVot-QXBF-wBvb-qMgx-zXO5UF
+      |-/dev/mapper/rhel-root     xfs               a10256eb-2cdd-430e-a80d-3bafbd8c2c44   /
+      |-/dev/mapper/rhel-swap     swap              0387eafb-b07e-4b6c-8866-7880c8d1f868   [SWAP]
+      |-/dev/mapper/rhel-tmp      xfs               81524856-ac81-4e57-9cc2-6402f2a5767f   /tmp
+      `-/dev/mapper/rhel-u01      xfs               d10a1f41-7018-47fc-9f90-ce5e844d317a   /u01
+    /dev/sdb
+    `-/dev/sdb1                   oracleasm   OCR1
+    /dev/sdc
+    `-/dev/sdc1                   oracleasm   DATA1
+    /dev/sdd
+    `-/dev/sdd1                   LVM2_member       C1qVAh-w7oo-KbD4-4I10-8sem-RDGr-FJ4gOJ
+      `-/dev/mapper/vg_app-lv_app xfs               c27ebec4-c8e0-4e4a-bc92-b8429a2a1785   /app
+
+-   Description of the issue (ideally so that others can reproduce it):
+
+I have two virtual machines (VMs) created, each connected to an NFS
+server that can store backup files as tar and ISO files. Each VM has
+four disks:
+
+1.  /sda: Boot disk.
+2.  /sdb: Shared disk for Oracle database.
+3.  /sdc: Another shared disk for Oracle database.
+4.  /sdd: Shared disk for log files.
+
+The VMs are set up in an **active/active cluster** configuration. The
+main goal of this setup is to create a cluster of two or more VMs and to
+back up the shared disks.
+
+For VM 1, I specified the option **AUTOEXCLUDE\_DISKS=n** in my
+site.conf file to ensure all my partitions are recreated during
+recovery.
+
+For VM 2, I set **AUTOEXCLUDE\_DISKS=y** to avoid saving the shared
+disks, as VM 1 is responsible for this task.
+
+However, I am encountering an issue on VM 1 where /sdb is not
+partitioned or specified in the disklayout.conf file when I boot from
+the rescue image with my backup on VM 1, while /sdc is.
+
+Example here of `disklayout.conf` :
+
+    # Disk /dev/sda
+    # Format: disk <devname> <size(bytes)> <partition label type>
+    disk /dev/sda 171798691840 msdos
+    # Partitions on /dev/sda
+    # Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
+    part /dev/sda 1073741824 1048576 primary boot /dev/sda1
+    part /dev/sda 170720755712 1074790400 primary lvm /dev/sda2
+    # Disk /dev/sdb
+    # Format: disk <devname> <size(bytes)> <partition label type>
+    disk /dev/sdb 17179869184 msdos
+    # Partitions on /dev/sdb
+    # Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
+    # Disk /dev/sdc
+    # Format: disk <devname> <size(bytes)> <partition label type>
+    disk /dev/sdc 53687091200 msdos
+    # Partitions on /dev/sdc
+    # Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
+    part /dev/sdc 53686042624 1048576 primary none /dev/sdc1
+    # Disk /dev/sdd
+    # Format: disk <devname> <size(bytes)> <partition label type>
+    disk /dev/sdd 37580963840 msdos
+    # Partitions on /dev/sdd
+    # Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
+    part /dev/sdd 37579915264 1048576 primary lvm /dev/sdd1
+
+As you can see in this example, there is a missing line for /dev/sdb
+specifying the partition size, partition start, and type, such as:
+`part /dev/sdb <partition_size> <partition_start> primary none /dev/sdb1`.  
+No partition is specified for `/dev/sdb1`
+
+I'm also adding **diskdeps.conf** :
+
+    [root@node1 ~]#  cat /var/lib/rear/layout/diskdeps.conf
+    /dev/sda1 /dev/sda
+    /dev/sda2 /dev/sda
+    /dev/sdc1 /dev/sdc
+    /dev/sdd1 /dev/sdd
+    /dev/vg_app pv:/dev/sdd1
+    pv:/dev/sdd1 /dev/sdd1
+    /dev/rhel pv:/dev/sda2
+    pv:/dev/sda2 /dev/sda2
+    /dev/mapper/rhel-root /dev/rhel
+    /dev/mapper/rhel-swap /dev/rhel
+    /dev/mapper/rhel-tmp /dev/rhel
+    /dev/mapper/rhel-u01 /dev/rhel
+    /dev/mapper/vg_app-lv_app /dev/vg_app
+    fs:/ /dev/mapper/rhel-root
+    fs:/tmp /dev/mapper/rhel-tmp
+    fs:/tmp fs:/
+    fs:/u01 /dev/mapper/rhel-u01
+    fs:/u01 fs:/
+    fs:/app /dev/mapper/vg_app-lv_app
+    fs:/app fs:/
+    fs:/boot /dev/sda1
+    fs:/boot fs:/
+
+And disk\_mapping :
+
+    [root@node1~]# cat /var/lib/rear/layout/disk_mappings
+    /dev/sda /dev/sda
+    /dev/sdb /dev/sdb
+    /dev/sdc /dev/sdc
+    /dev/sdd /dev/sdd
+
+And disktodo.conf :
+
+    [root@node1~]# cat /var/lib/rear/layout/disktodo.conf
+    todo /dev/sda disk
+    todo /dev/sda1 part
+    todo /dev/sda2 part
+    todo /dev/sdb disk
+    todo /dev/sdc disk
+    todo /dev/sdc1 part
+    todo /dev/sdd disk
+    todo /dev/sdd1 part
+    todo pv:/dev/sdd1 lvmdev
+    todo pv:/dev/sda2 lvmdev
+    todo /dev/vg_app lvmgrp
+    todo /dev/rhel lvmgrp
+    todo /dev/mapper/rhel-root lvmvol
+    todo /dev/mapper/rhel-swap lvmvol
+    todo /dev/mapper/rhel-tmp lvmvol
+    todo /dev/mapper/rhel-u01 lvmvol
+    todo /dev/mapper/vg_app-lv_app lvmvol
+    todo fs:/ fs
+    todo fs:/tmp fs
+    todo fs:/u01 fs
+    todo fs:/app fs
+    todo fs:/boot fs
+    todo swap:/dev/mapper/rhel-swap swap
+
+As you can see, the `todo /dev/sdb1 part` is missing, but my partition
+is functional (see `lsblk` output below).
+
+Can someone try to help me on this one ? @jsmeix
+
+**Steps to Reproduce**
+
+1.  Create two VMs connected to an NFS server.
+2.  Configure the VMs with four disks as described.
+3.  Set up rear backup with AUTOEXCLUDE\_DISKS=n in site.conf (cf
+    sife.conf below).
+4.  Perform a rear backup. (The issue should already be evident at this
+    step, check disklayout.conf)
+5.  Boot from the rear rescue image and initiate recovery.
+6.  Observe that /sdb is not partitioned or included in disklayout.conf.
+
+**Expected Behavior**  
+Both **/sdb** and **/sdc** should be partitioned and **included in the
+disklayout.conf** file during the recovery process, ensuring all shared
+disks are correctly restored.
+
+**Actual Behavior**  
+Only **/sdc** is partitioned, and **/sdb** is **missing from the
+disklayout.conf** file during the recovery process.
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-10-03 09:51](https://github.com/rear/rear/issues/3316#issuecomment-2390990775):
+
+@NewNow479 See my reply in issue
+[https://github.com/rear/rear/issues/3284\#issuecomment-2337377931](https://github.com/rear/rear/issues/3284#issuecomment-2337377931)
+
+#### <img src="https://avatars.githubusercontent.com/in/15368?v=4" width="50">[github-actions](https://github.com/apps/github-actions) commented at [2024-12-03 02:49](https://github.com/rear/rear/issues/3316#issuecomment-2513431702):
+
+Stale issue message
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-03.3352.pr.closed.md b/docs/issues/2024-12-03.3352.pr.closed.md
new file mode 100644
index 00000000..1dcdb8d4
--- /dev/null
+++ b/docs/issues/2024-12-03.3352.pr.closed.md
@@ -0,0 +1,71 @@
+[\#3352 PR](https://github.com/rear/rear/pull/3352) `closed`: cleanup: move grubby and grub2-editenv to 300\_include\_grub\_tools.sh (\#3349)
+=============================================================================================================================================
+
+**Labels**: `cleanup`, `won't fix / can't fix / obsolete`
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) opened issue at [2024-12-03 08:58](https://github.com/rear/rear/pull/3352):
+
+##### Pull Request Details:
+
+-   Type: **Cleanup**
+
+-   Impact: **Low**
+
+-   Reference to related issue (URL): \#3349
+
+-   How was this pull request tested? manually
+
+-   Description of the changes in this pull request: `grubby` and
+    `grub2-editenv` were added by PR \#3349 into the
+    `conf/GNU/Linux.conf` file in the `PROGS` section. However, it seems
+    proper to move these 2 programs to the
+    `prep/GNU/Linux/300_include_grub_tools.sh` script.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-03 11:04](https://github.com/rear/rear/pull/3352#issuecomment-2514232463):
+
+According to
+
+    git log -p --follow usr/share/rear/prep/GNU/Linux/300_include_grub_tools.sh
+
+usr/share/rear/prep/GNU/Linux/300\_include\_grub\_tools.sh  
+originated in  
+[https://github.com/rear/rear/commit/ccae513d8362078c5d4bcffe9b1167835e6449b8](https://github.com/rear/rear/commit/ccae513d8362078c5d4bcffe9b1167835e6449b8)  
+but I do not understand the reason WHY it exists.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-03 14:04](https://github.com/rear/rear/pull/3352#issuecomment-2514648915):
+
+I also don't think it should be described as `feat:` or **Enhancement**,
+as the change is not user-visible, isn't **Cleanup** more appropriate?
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-12-04 08:24](https://github.com/rear/rear/pull/3352#issuecomment-2516524418):
+
+If there are no further objections I would like to merge the PR
+tomorrow?
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-04 12:12](https://github.com/rear/rear/pull/3352#issuecomment-2517180352):
+
+@gdha please remove the last commit - it is totally unrelated to the PR
+topic.
+
+By the way, please change the Type: in the template.
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-12-04 13:32](https://github.com/rear/rear/pull/3352#issuecomment-2517400478):
+
+[https://github.com/rear/rear/pull/3354](https://github.com/rear/rear/pull/3354)
+will be used instead and we close this PR.  
+Noticed when we remove rear.8 from the source tree the builds will fail.
+
+    == Prepare manual ==
+    /usr/bin/make -C doc man
+    make[1]: Entering directory '/builddir/build/BUILD/rear-snapshot/doc'
+    asciidoc -b docbook -d manpage rear.8.adoc
+    /bin/bash: asciidoc: command not found
+    make[1]: *** [Makefile:38: rear.8.xml] Error 127
+    make[1]: Leaving directory '/builddir/build/BUILD/rear-snapshot/doc'
+    make: *** [Makefile:151: man] Error 2
+    error: Bad exit status from /var/tmp/rpm-tmp.Dnn2jw (%install)
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-03.3353.pr.merged.md b/docs/issues/2024-12-03.3353.pr.merged.md
new file mode 100644
index 00000000..a7e03a9f
--- /dev/null
+++ b/docs/issues/2024-12-03.3353.pr.merged.md
@@ -0,0 +1,30 @@
+[\#3353 PR](https://github.com/rear/rear/pull/3353) `merged`: cleanup: Finish the change of "Arch to "Arch\_Linux"
+==================================================================================================================
+
+**Labels**: `cleanup`, `fixed / solved / done`
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) opened issue at [2024-12-03 11:23](https://github.com/rear/rear/pull/3353):
+
+#### Relax-and-Recover (ReaR) Pull Request Template
+
+Please fill in the following items before submitting a new pull request:
+
+##### Pull Request Details:
+
+-   Type: **Cleanup**
+
+-   Impact: **Low**
+
+-   Reference to related issue (URL): \#3344
+
+-   How was this pull request tested?  
+    not tested.
+
+-   Description of the changes in this pull request:  
+    Change the occurrences of "Arch" (as the identifier of a
+    distribution) that have remained after PR \#3344 to "Arch\_Linux".
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-04.3354.pr.merged.md b/docs/issues/2024-12-04.3354.pr.merged.md
new file mode 100644
index 00000000..63f1b7de
--- /dev/null
+++ b/docs/issues/2024-12-04.3354.pr.merged.md
@@ -0,0 +1,90 @@
+[\#3354 PR](https://github.com/rear/rear/pull/3354) `merged`: cleanup: move grubby and grub2-editenv to 300\_include\_grub\_tools.sh (\#3349)
+=============================================================================================================================================
+
+**Labels**: `cleanup`, `fixed / solved / done`
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) opened issue at [2024-12-04 13:24](https://github.com/rear/rear/pull/3354):
+
+##### Pull Request Details:
+
+-   Type: **Cleanup**
+
+-   Impact: **Low**
+
+-   Reference to related issue (URL): \#3349  
+    PS: this PR replaces PR-3352
+
+-   How was this pull request tested? manually
+
+-   Description of the changes in this pull request: `grubby` and
+    `grub2-editenv` were added by PR \#3349 into the
+    `conf/GNU/Linux.conf` file in the `PROGS` section. However, it seems
+    proper to move these 2 programs to the
+    `prep/GNU/Linux/300_include_grub_tools.sh` script.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-05 08:05](https://github.com/rear/rear/pull/3354#issuecomment-2519520750):
+
+usr/share/rear/prep/GNU/Linux/300\_include\_grub\_tools.sh  
+does not tell why it exists at all, see  
+[https://github.com/rear/rear/pull/3352\#issuecomment-2514232463](https://github.com/rear/rear/pull/3352#issuecomment-2514232463)
+
+I.e. what the reason is why GRUB tools are needed within  
+the recovery system regardless that during "rear recover"  
+GRUB is installed within the recreated target system  
+via chroot into the recreated target system.
+
+According to  
+[https://github.com/rear/rear/pull/3352\#discussion\_r1867492931](https://github.com/rear/rear/pull/3352#discussion_r1867492931)  
+and  
+[https://github.com/rear/rear/pull/3352\#discussion\_r1867916286](https://github.com/rear/rear/pull/3352#discussion_r1867916286)  
+the reason why  
+usr/share/rear/prep/GNU/Linux/300\_include\_grub\_tools.sh  
+exists is not for "rear recover" but for a different use case  
+which is using the ReaR recovery system to repair the system,  
+in particular to repair GRUB on the original system  
+(e.g. because the original system fails to boot).
+
+So  
+usr/share/rear/prep/GNU/Linux/300\_include\_grub\_tools.sh  
+should be enhanced with an initial comment that  
+explains why it it exists at all for example like
+
+    # GRUB tools are not required inside the recovery system
+    # for "rear recover" because during "rear recover"
+    # GRUB is installed within the recreated target system
+    # via chroot into the recreated target system.
+    # Nevertheless GRUB tools are useful inside the
+    # recovery system for a different use case which is
+    # using the ReaR recovery system to repair the system,
+    # in particular to repair GRUB on the original system
+    # when the original system fails to boot.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-05 08:53](https://github.com/rear/rear/pull/3354#issuecomment-2519656634):
+
+Via  
+[https://github.com/rear/rear/commit/2478b4cf9100e77d28c414591e2ec6b330851b49](https://github.com/rear/rear/commit/2478b4cf9100e77d28c414591e2ec6b330851b49)  
+I explained in prep/GNU/Linux/300\_include\_grub\_tools.sh  
+why it exists at all.
+
+My above assumption that GRUB tools are not needed within  
+the ReaR recovery system because during "rear recover"  
+GRUB is installed within the recreated target system  
+via chroot into the recreated target system  
+is not true because
+
+    # There is one exception for GRUB2: grub-probe or grub2-probe
+    # This is required inside the recovery system because the function
+    # is_grub2_installed is also called during "rear recover"
+    # in finalize/Linux-i386/630_install_grub.sh
+    # and finalize/Linux-i386/660_install_grub2.sh
+    # And 'type -p grub-probe || type -p grub2-probe' is called during "rear recover"
+    # in finalize/Linux-ppc64le/660_install_grub2.sh
+    # and finalize/SUSE_LINUX/s390/660_install_grub2_and_zipl.sh
+    # Other code places that call 'has_binary grub-probe' or 'has_binary grub2-probe'
+    # are not run during "rear recover"
+    # (at least as far as I <jsmeix@suse.de> found out up to now dated 05 Dec. 2024)
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-04.3355.pr.open.md b/docs/issues/2024-12-04.3355.pr.open.md
new file mode 100644
index 00000000..09593410
--- /dev/null
+++ b/docs/issues/2024-12-04.3355.pr.open.md
@@ -0,0 +1,95 @@
+[\#3355 PR](https://github.com/rear/rear/pull/3355) `open`: Storing and reading Self Encrypted Disk (SED) password from TPM
+===========================================================================================================================
+
+**Labels**: `enhancement`
+
+#### <img src="https://avatars.githubusercontent.com/u/40496304?v=4" width="50">[prolez](https://github.com/prolez) opened issue at [2024-12-04 14:11](https://github.com/rear/rear/pull/3355):
+
+#### Relax-and-Recover (ReaR) Pull Request Template
+
+Please fill in the following items before submitting a new pull request:
+
+##### Pull Request Details:
+
+-   Type: Enhancement
+
+-   Impact: Low
+
+-   Reference to related issue (URL):
+    [https://github.com/rear/rear/issues/3074](https://github.com/rear/rear/issues/3074)
+
+-   How was this pull request tested? on production environment
+
+-   Description of the changes in this pull request: Add functions in
+    unlock-opal-disks to offer storing password in TPM2
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-06 13:46](https://github.com/rear/rear/pull/3355#issuecomment-2523291614):
+
+@prolez  
+thank you for your enhancement for ReaR!
+
+We are currently in the final process of releasing ReaR 2.8,  
+cf.
+[https://github.com/rear/rear/issues/3238\#issuecomment-2516532775](https://github.com/rear/rear/issues/3238#issuecomment-2516532775)  
+so we cannot include this PR in the current ReaR 2.8.  
+We will have a look for the subsequent ReaR 3.0.
+
+I am not a SED user so I cannot try out things on my own.  
+I can only comment from what I notice form plain looking  
+at the code changes of this pull request in  
+[https://github.com/rear/rear/pull/3355/files](https://github.com/rear/rear/pull/3355/files)
+
+I notice `at_password` and when I see something like  
+"password" or "encryption" or "key" in the code  
+it indicates the code deals with some kind of "secret value"  
+and then I am wondering if the code deals sufficiently well  
+with secrets.
+
+See the inital comments in usr/share/rear/conf/default.conf  
+currently online at  
+[https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf\#L13](https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L13)  
+how to deal sufficiently well with secrets.
+
+See also the function LogSecret() in  
+usr/share/rear/lib/\_input-output-functions.sh  
+currently online at  
+[https://github.com/rear/rear/blob/master/usr/share/rear/lib/\_input-output-functions.sh\#L462](https://github.com/rear/rear/blob/master/usr/share/rear/lib/_input-output-functions.sh#L462)
+
+See also our "Relax-and-Recover Security Architecture" document at  
+[https://relax-and-recover.org/documentation/security-architecture](https://relax-and-recover.org/documentation/security-architecture)  
+which reads (excerpt)
+
+    To facilitate protecting secrets even from
+    verbose tracing of the Bash scripts (set -x),
+    it is important to wrap statements
+    that handle secrets like this:
+
+    # set a variable with a secret
+    { VAR='secret_value' ; } 2>>/dev/$SECRET_OUTPUT_DEV
+
+    # use the variable with the secret
+    { COMMAND $SECRET_ARGUMENT ; } 2>>/dev/$SECRET_OUTPUT_DEV
+
+For an example how the latter is used see  
+usr/share/rear/rescue/default/500\_ssh.sh  
+online at  
+[https://github.com/rear/rear/blob/master/usr/share/rear/rescue/default/500\_ssh.sh](https://github.com/rear/rear/blob/master/usr/share/rear/rescue/default/500_ssh.sh)
+
+For an example how the latter is used to get user input  
+in a confidential way, see the comment of the UserInput function  
+in usr/share/rear/lib/\_input-output-functions.sh  
+currently online at  
+[https://github.com/rear/rear/blob/master/usr/share/rear/lib/\_input-output-functions.sh\#L1090](https://github.com/rear/rear/blob/master/usr/share/rear/lib/_input-output-functions.sh#L1090)
+
+To verify that your code deals sufficiently well with secrets  
+run it in ReaR debugscript mode with '-D' e.g. like
+
+    # rear -D mkrescue
+
+and then carefully inspect your ReaR log file  
+and verify that no secret value appears therein.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-04.3356.pr.merged.md b/docs/issues/2024-12-04.3356.pr.merged.md
new file mode 100644
index 00000000..afac9987
--- /dev/null
+++ b/docs/issues/2024-12-04.3356.pr.merged.md
@@ -0,0 +1,134 @@
+[\#3356 PR](https://github.com/rear/rear/pull/3356) `merged`: In 100\_copy\_as\_is.sh error out if symlinking VAR\_DIR SHARE\_DIR fails
+=======================================================================================================================================
+
+**Labels**: `bug`, `fixed / solved / done`
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) opened issue at [2024-12-04 14:22](https://github.com/rear/rear/pull/3356):
+
+-   Type: **Bug Fix**
+
+-   Impact: **Low**
+
+coreutils 8.16 was released in 2012 so the '-r' option  
+should be supported since more than 10 years  
+so it is unlikely that someone is actually hit by it  
+BUT  
+some older Linux distributions with rather old coreutils  
+may still be in use somewhere so it is good to care about  
+this possible error because when 'ln' fails here, the  
+consequence is severe (recovery system startup fails)  
+and it shows up (too) late (at "rear recover" time)  
+AND  
+this issue is introduced in ReaR 2.8 by  
+[https://github.com/rear/rear/pull/3206](https://github.com/rear/rear/pull/3206)  
+so it could be considered as a regression in ReaR 2.8
+
+-   Reference to related issue (URL):
+
+[https://github.com/rear/rear/pull/3206](https://github.com/rear/rear/pull/3206)  
+therein  
+[https://github.com/rear/rear/pull/3206\#discussion\_r1868998080](https://github.com/rear/rear/pull/3206#discussion_r1868998080)  
+and subsequent comments
+
+-   How was this pull request tested?
+
+Tested on SLES11-SP4 where 'ln' from coreutils 8.12  
+does not support the '-r/--relative' option  
+which is supported since coreutils 8.16
+
+Also tested on a system where 'ln' supports '-r'  
+i.e. on SLES15-SP6 with coreutils 8.32
+
+-   Description of the changes in this pull request:
+
+In build/GNU/Linux/100\_copy\_as\_is.sh  
+failsafe symlinking of VAR\_DIR and SHARE\_DIR  
+and error out if symlinking fails because  
+with non-default VAR\_DIR and/or SHARE\_DIR  
+(e.g. when running from checkout)  
+it is mandatory that in the ReaR recovery system  
+all ReaR files are accessible via the default  
+/var/lib/rear and /usr/share/rear directories,  
+see
+[https://github.com/rear/rear/pull/3206](https://github.com/rear/rear/pull/3206)
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-05 09:10](https://github.com/rear/rear/pull/3356#issuecomment-2519698111):
+
+@rear/contributors  
+provided there are no objections,  
+I would like to merge it tomorrow afternoon
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-06 12:23](https://github.com/rear/rear/pull/3356#issuecomment-2523105121):
+
+Just merged "bona fide" without further testing  
+(that all CI tests passed indicates it is OK)  
+so I had only tested the initial changes  
+[https://github.com/rear/rear/pull/3356/commits/5bdeaff0c7cfcc6b3f217339b50bcd3412bdaa1e](https://github.com/rear/rear/pull/3356/commits/5bdeaff0c7cfcc6b3f217339b50bcd3412bdaa1e)
+
+I adapted  
+[https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8](https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8)  
+where I had tested things only with the initial changes  
+[https://github.com/rear/rear/pull/3356/commits/5bdeaff0c7cfcc6b3f217339b50bcd3412bdaa1e](https://github.com/rear/rear/pull/3356/commits/5bdeaff0c7cfcc6b3f217339b50bcd3412bdaa1e)
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-06 12:27](https://github.com/rear/rear/pull/3356#issuecomment-2523112180):
+
+To be on the safe side to avoid that pull request commits  
+may somehow get lost in GitHub as reference here  
+my initial changes in this pull request  
+[https://github.com/rear/rear/commit/5bdeaff0c7cfcc6b3f217339b50bcd3412bdaa1e](https://github.com/rear/rear/commit/5bdeaff0c7cfcc6b3f217339b50bcd3412bdaa1e)
+
+    # Symlinking non-default VAR_DIR and SHARE_DIR to defaults (e.g. when running from checkout or REAR_VAR configuration):
+    Log "In ReaR recovery system symlinking non-default VAR_DIR and SHARE_DIR to defaults if needed (e.g. when running from checkout)"
+    # When running with non-default VAR_DIR and/or SHARE_DIR it is mandatory that in the ReaR recovery system
+    # all ReaR files are accessible via the default /var/lib/rear and /usr/share/rear directories - otherwise
+    # the ReaR recovery system startup fails in usr/share/rear/skel/default/etc/scripts/system-setup with
+    # "ERROR: ReaR recovery cannot work without /usr/share/rear/conf/default.conf"
+    # so we error out if making a needed symlink fails.
+    # On old systems with /bin/ln from coreutils < 8.16 'ln' did not support the '-r/--relative' option
+    # but a relative symlink is needed in portable mode, see https://github.com/rear/rear/pull/3206
+    if ! test "$VAR_DIR" = /var/lib/rear ; then
+        Log "In ReaR recovery system make symlink /var/lib/rear to VAR_DIR '$VAR_DIR'"
+        if ! ln -v -srf "$ROOTFS_DIR/$VAR_DIR" $ROOTFS_DIR/var/lib/rear ; then
+            is_true "$PORTABLE" && Error "Failed to make relative symlink (needed in portable mode) /var/lib/rear to VAR_DIR '$VAR_DIR'"
+            Log "'ln -srf VAR_DIR' failed, trying without '-r' option"
+            ln -v -sf "$VAR_DIR" $ROOTFS_DIR/var/lib/rear || Error "Failed to make symlink /var/lib/rear to VAR_DIR '$VAR_DIR'"
+        fi
+    fi
+    if ! test "$SHARE_DIR" = /usr/share/rear ; then
+        Log "In ReaR recovery system make symlink /usr/share/rear to SHARE_DIR '$SHARE_DIR'"
+        if ! ln -v -srf "$ROOTFS_DIR/$SHARE_DIR" $ROOTFS_DIR/usr/share/rear ; then
+            is_true "$PORTABLE" && Error "Failed to make relative symlink (needed in portable mode) /usr/share/rear to SHARE_DIR '$SHARE_DIR'"
+            Log "'ln -srf SHARE_DIR' failed, trying without '-r' option"
+            ln -v -sf "$SHARE_DIR" $ROOTFS_DIR/usr/share/rear || Error "Failed to make symlink /usr/share/rear to SHARE_DIR '$SHARE_DIR'"
+        fi
+    fi
+
+versus the finally merged changes  
+[https://github.com/rear/rear/commit/780140679cfc88b1f329d354202266e936926c78](https://github.com/rear/rear/commit/780140679cfc88b1f329d354202266e936926c78)
+
+    # Symlinking non-default VAR_DIR and SHARE_DIR to defaults (e.g. when running from checkout or REAR_VAR configuration):
+    Log "In ReaR recovery system symlinking non-default VAR_DIR and SHARE_DIR to defaults if needed (e.g. when running from checkout)"
+    # When running with non-default VAR_DIR and/or SHARE_DIR it is mandatory that in the ReaR recovery system
+    # all ReaR files are accessible via the default /var/lib/rear and /usr/share/rear directories - otherwise
+    # the ReaR recovery system startup fails in usr/share/rear/skel/default/etc/scripts/system-setup with
+    # "ERROR: ReaR recovery cannot work without /usr/share/rear/conf/default.conf"
+    # so we error out if making a needed symlink fails.
+    # On old systems with /bin/ln from coreutils < 8.16 'ln' did not support the '-r/--relative' option
+    # but a relative symlink is needed in portable mode, see https://github.com/rear/rear/pull/3206
+    if ! test "$VAR_DIR" = /var/lib/rear ; then
+        Log "In ReaR recovery system make symlink /var/lib/rear to VAR_DIR '$VAR_DIR'"
+        ln -v -srf "$ROOTFS_DIR/$VAR_DIR" $ROOTFS_DIR/var/lib/rear || Error "Failed to symlink /var/lib/rear to '$VAR_DIR'"
+    fi
+    if ! test "$SHARE_DIR" = /usr/share/rear ; then
+        Log "In ReaR recovery system make symlink /usr/share/rear to SHARE_DIR '$SHARE_DIR'"
+        ln -v -srf "$ROOTFS_DIR/$SHARE_DIR" $ROOTFS_DIR/usr/share/rear || Error "Failed to symlink /usr/share/rear to '$SHARE_DIR'"
+    fi
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-09 09:15](https://github.com/rear/rear/pull/3356#issuecomment-2527352895):
+
+Thank you very much @jsmeix
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-05.3357.issue.open.md b/docs/issues/2024-12-05.3357.issue.open.md
new file mode 100644
index 00000000..42a56d6b
--- /dev/null
+++ b/docs/issues/2024-12-05.3357.issue.open.md
@@ -0,0 +1,221 @@
+[\#3357 Issue](https://github.com/rear/rear/issues/3357) `open`: finalize/.../660\_install\_grub2.sh automatism fails on RAID1
+==============================================================================================================================
+
+**Labels**: `enhancement`, `bug`
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) opened issue at [2024-12-05 15:03](https://github.com/rear/rear/issues/3357):
+
+-   ReaR version ("/usr/sbin/rear -V"):
+
+current GitHub master code
+
+-   ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+    /etc/rear/local.conf"):
+
+see
+[https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8\#sles-15-sp-6-with-raid1-and-luks-encryption-and-lvm-and-default-btrfs-structure](https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8#sles-15-sp-6-with-raid1-and-luks-encryption-and-lvm-and-default-btrfs-structure)
+
+-   Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+    guest or PowerVM LPAR):
+
+KVM/QEMU VM with BIOS and two 15G virtual harddisks /dev/vda and
+/dev/vdb
+
+-   System architecture (x86 compatible or PPC64/PPC64LE or what exact
+    ARM device):
+
+x86\_64
+
+-   Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or
+    ELILO or Petitboot):
+
+BIOS
+
+-   Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or
+    multipath (DM or NVMe):
+
+RAID 1 of two 15G virtual harddisks /dev/vda and /dev/vdb
+
+-   Storage layout ("lsblk -ipo
+    NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
+
+see
+[https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8\#sles-15-sp-6-with-raid1-and-luks-encryption-and-lvm-and-default-btrfs-structure](https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8#sles-15-sp-6-with-raid1-and-luks-encryption-and-lvm-and-default-btrfs-structure)
+
+-   Description of the issue (ideally so that others can reproduce it):
+
+In finalize/Linux-i386/660\_install\_grub2.sh the current automatism
+fails to determine where to install GRUB2 when there is more than one
+disk where GRUB2 can and should be installed
+
+-   Workaround, if any:
+
+Explicity specifying the right disks where GRUB2 should be installed
+
+    GRUB2_INSTALL_DEVICES="/dev/vda /dev/vdb"
+
+-   Attachments, as applicable ("rear -D mkrescue/mkbackup/recover"
+    debug log files):
+
+Excerpt of "rear -D recover" console output:
+
+    Recreating initrd with /usr/bin/dracut...
+    Recreated initrd with /usr/bin/dracut
+    Installing GRUB2 boot loader...
+    Determining where to install GRUB2 (no GRUB2_INSTALL_DEVICES specified)
+    Failed to install GRUB2 - you may have to manually install it
+    WARNING:
+    For this system
+    SUSE_LINUX/15.6 on Linux-i386 (based on SUSE/15/i386)
+    there is no code to install a boot loader on the recovered system
+    or the code that we have failed to install the boot loader correctly.
+    Please contribute appropriate code to the Relax-and-Recover project,
+    see http://relax-and-recover.org/development/
+    Take a look at the scripts in /usr/share/rear/finalize - for example
+    for PC architectures like x86 and x86_64 see the script
+    /usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
+    and for POWER architectures like ppc64le see the script
+    /usr/share/rear/finalize/Linux-ppc64le/660_install_grub2.sh
+    ---------------------------------------------------
+    |  IF YOU DO NOT INSTALL A BOOT LOADER MANUALLY,  |
+    |  THEN YOUR SYSTEM WILL NOT BE ABLE TO BOOT.     |
+    ---------------------------------------------------
+    You can use 'chroot /mnt/local bash --login'
+    to change into the recovered system and
+    manually install a boot loader therein.
+
+Excerpt of "rear -D recover" log file  
+(excluding 'set -x' lines with more than two leading '++')
+
+    ++ LogPrint 'Determining where to install GRUB2 (no GRUB2_INSTALL_DEVICES specified)'
+    2024-12-05 15:33:34.139126941 Determining where to install GRUB2 (no GRUB2_INSTALL_DEVICES specified)
+    ++ test /mnt/local = /mnt/local
+    ++ bootparts='/dev/md127p3
+    /dev/md127p4'
+    ++ test '/dev/md127p3
+    /dev/md127p4'
+    ++ disks='/dev/vda
+    /dev/vdb'
+    ++ test '/dev/vda
+    /dev/vdb'
+    ++ grub2_installed_disks=()
+    ++ for disk in $disks
+    ++ is_disk_a_pv /dev/vda
+    ++ disk=/dev/vda
+    ++ awk '$1 == "lvmdev" && $3 == "/dev/vda" { exit 1 }' /var/lib/rear/layout/disklayout.conf
+    ++ return 1
+    ++ part=/dev/md127p3
+    ++ for bootpart in $bootparts
+    ++ bootdisk='/dev/vda
+    /dev/vdb'
+    ++ test /dev/vda = '/dev/vda
+    /dev/vdb'
+    ++ for bootpart in $bootparts
+    ++ bootdisk='/dev/vda
+    /dev/vdb'
+    ++ test /dev/vda = '/dev/vda
+    /dev/vdb'
+    ++ bootdisk='/dev/vda
+    /dev/vdb'
+    ++ test '/dev/vda
+    /dev/vdb'
+    ++ is_disk_grub_candidate '/dev/vda
+    /dev/vdb'
+    ++ local 'disk=/dev/vda
+    /dev/vdb'
+    ++ local disk_partitions part
+    ++ local label flags
+    ++ is_disk_a_pv '/dev/vda
+    /dev/vdb'
+    ++ disk='/dev/vda
+    /dev/vdb'
+    ++ awk '$1 == "lvmdev" && $3 == "/dev/vda
+    /dev/vdb" { exit 1 }' /var/lib/rear/layout/disklayout.conf
+    awk: cmd. line:1: $1 == "lvmdev" && $3 == "/dev/vda
+    awk: cmd. line:1:                         ^ unterminated string
+    awk: cmd. line:1: $1 == "lvmdev" && $3 == "/dev/vda
+    awk: cmd. line:1:                         ^ syntax error
+    ++ return 0
+    ++ return 1
+    ++ continue
+    ++ for disk in $disks
+    ++ is_disk_a_pv /dev/vdb
+    ++ disk=/dev/vdb
+    ++ awk '$1 == "lvmdev" && $3 == "/dev/vdb" { exit 1 }' /var/lib/rear/layout/disklayout.conf
+    ++ return 1
+    ++ part=/dev/md127p3
+    ++ for bootpart in $bootparts
+    ++ bootdisk='/dev/vda
+    /dev/vdb'
+    ++ test /dev/vdb = '/dev/vda
+    /dev/vdb'
+    ++ for bootpart in $bootparts
+    ++ bootdisk='/dev/vda
+    /dev/vdb'
+    ++ test /dev/vdb = '/dev/vda
+    /dev/vdb'
+    ++ bootdisk='/dev/vda
+    /dev/vdb'
+    ++ test '/dev/vda
+    /dev/vdb'
+    ++ is_disk_grub_candidate '/dev/vda
+    /dev/vdb'
+    ++ local 'disk=/dev/vda
+    /dev/vdb'
+    ++ local disk_partitions part
+    ++ local label flags
+    ++ is_disk_a_pv '/dev/vda
+    /dev/vdb'
+    ++ disk='/dev/vda
+    /dev/vdb'
+    ++ awk '$1 == "lvmdev" && $3 == "/dev/vda
+    /dev/vdb" { exit 1 }' /var/lib/rear/layout/disklayout.conf
+    awk: cmd. line:1: $1 == "lvmdev" && $3 == "/dev/vda
+    awk: cmd. line:1:                         ^ unterminated string
+    awk: cmd. line:1: $1 == "lvmdev" && $3 == "/dev/vda
+    awk: cmd. line:1:                         ^ syntax error
+    ++ return 0
+    ++ return 1
+    ++ continue
+    ++ is_true 1
+    ++ case "$1" in
+    ++ return 0
+    ++ is_true
+    ++ case "$1" in
+    ++ return 1
+    ++ LogPrintError 'Failed to install GRUB2 - you may have to manually install it'
+    2024-12-05 15:33:34.291918389 Failed to install GRUB2 - you may have to manually install it
+
+What looks fishy therein at first glance is things like
+
+    ++ bootdisk='/dev/vda
+    /dev/vdb'
+    ...
+    ++ is_disk_grub_candidate '/dev/vda
+    /dev/vdb'
+    ++ local 'disk=/dev/vda
+    /dev/vdb'
+    ++ local disk_partitions part
+    ++ local label flags
+    ++ is_disk_a_pv '/dev/vda
+    /dev/vdb'
+    ++ disk='/dev/vda
+    /dev/vdb'
+    ++ awk '$1 == "lvmdev" && $3 == "/dev/vda
+    /dev/vdb" { exit 1 }' /var/lib/rear/layout/disklayout.conf
+    awk: cmd. line:1: $1 == "lvmdev" && $3 == "/dev/vda
+    awk: cmd. line:1:                         ^ unterminated string
+    awk: cmd. line:1: $1 == "lvmdev" && $3 == "/dev/vda
+    awk: cmd. line:1:                         ^ syntax error
+
+where variable and function names use singular  
+'bootdisdk' 'disk' 'is\_disk\_grub\_candidate' 'is\_disk\_a\_pv'  
+but they get an argument with more than one disk
+
+    /dev/vda
+    /dev/vdb
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-10.3359.issue.open.md b/docs/issues/2024-12-10.3359.issue.open.md
new file mode 100644
index 00000000..f11768b6
--- /dev/null
+++ b/docs/issues/2024-12-10.3359.issue.open.md
@@ -0,0 +1,88 @@
+[\#3359 Issue](https://github.com/rear/rear/issues/3359) `open`: BACKUP\_PROG=rsync: Is it possible to backup and restore to/from an NFS share that has root squash enabled?
+============================================================================================================================================================================
+
+#### <img src="https://avatars.githubusercontent.com/u/75754329?v=4" width="50">[scook207](https://github.com/scook207) opened issue at [2024-12-10 16:04](https://github.com/rear/rear/issues/3359):
+
+I'm trying to use rsync to backup to an NFS share with root squash
+enabled. It's not clear to me what root squash enabled means, but I
+believe all root file permissions are mapped to the nobody user.  
+I'm getting lots of errors like the one below in the
+rsync-<hostnmae>.log file:
+
+2024/12/07 14:54:28 \[17059\] rsync: chown
+"/tmp/rear.CClpFWqalqYxnZo/outputfs/watch/backup/home/bs/.cache/evolution/addressbook"
+failed: Operation not permitted (1)
+
+AI and Google searches indicate that this is being caused by "root
+squash enabled" on the NFS share. AI suggests adding these options to
+the rear command:
+
+sudo rear -v mkbackup -- --rsync-options="--no-owner --no-group"
+
+I suspect that if I use those options, then I'll be unable to perform a
+restore from the backup since all the file permissions will be set to
+nobody:nobody.
+
+Any tips on how to configure Relax-and-Recover to backup to an NFS share
+with root-squash enabled?
+
+Happening on serveral servers. Right now I'm troubleshooting a RHEL 6.10
+server running ReaR 2.4.
+
+Thanks,  
+SC
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-10 17:47](https://github.com/rear/rear/issues/3359#issuecomment-2532434062):
+
+` -- --rsync-options="--no-owner --no-group"`
+
+I am afraid that AI has made that up.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-10 17:48](https://github.com/rear/rear/issues/3359#issuecomment-2532438667):
+
+Please show your local.conf file (without any passwords / secrets of
+course)
+
+#### <img src="https://avatars.githubusercontent.com/u/75754329?v=4" width="50">[scook207](https://github.com/scook207) commented at [2024-12-11 15:15](https://github.com/rear/rear/issues/3359#issuecomment-2536281325):
+
+Looks like site.conf is being used to configure rear. Here are the
+contents:
+
+BACKUP=NETFS  
+BACKUP\_PROG=rsync  
+BACKUP\_URL=nfs://hetnas1/mnt/tank/backups/rear\_backups  
+AUTOEXCLUDE\_AUTOFS=y  
+BACKUP\_RSYNC\_OPTIONS=(--sparse --archive --hard-links --numeric-ids
+--stats --log-file="$LOG\_DIR/rsync-$HOSTNAME.log")  
+BACKUP\_OPTIONS=nfsvers=3,nolock
+
+local.conf contains the commented out default message "This file
+etc/rear/local.conf..."
+
+Thanks,  
+SC
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-12-17 13:14](https://github.com/rear/rear/issues/3359#issuecomment-2548430662):
+
+@scook207 Why not using the `BACKUP=RSYNC` workflow? Have a look at
+`/usr/share/rear/conf/default.conf` file for how-to...
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-17 15:37](https://github.com/rear/rear/issues/3359#issuecomment-2548783077):
+
+@scook207
+
+    BACKUP=NETFS
+    BACKUP_PROG=rsync
+
+I see, not sure if there is some rsync trick to make it work under such
+conditions (you can try `--fake-super`, but you will need extended
+attributes enabled on the share). The easiest option is to use `tar`
+(which is the default for `BACKUP_PROG` ) instead of `rsync`, if a
+single tarball as the backup is enough for you. Another option is to use
+`BACKUP=RSYNC` as @gdha has suggested, if `rsync` can connect to your
+backup location (either over `ssh` or over the rsync protocol).
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-11.3360.issue.open.md b/docs/issues/2024-12-11.3360.issue.open.md
new file mode 100644
index 00000000..fef4e624
--- /dev/null
+++ b/docs/issues/2024-12-11.3360.issue.open.md
@@ -0,0 +1,26 @@
+[\#3360 Issue](https://github.com/rear/rear/issues/3360) `open`: Officially support Alma Linux, Rocky Linux and Oracle Linux as RHEL clones
+===========================================================================================================================================
+
+**Labels**: `needs sponsorship`
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) opened issue at [2024-12-11 07:27](https://github.com/rear/rear/issues/3360):
+
+Suggestion: Add Alma Linux and Oracle Linux to our supported distros
+
+-   Add support in `run-in-docker` to build packages
+-   Test from time to time
+
+This is probably very relevant to our users as these two distros are the
+remaining main RHEL clones that receive updates.
+
+However, we really would like to see other people - e.g. users of those
+distros - stepping in and support testing here.
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-12-17 13:10](https://github.com/rear/rear/issues/3360#issuecomment-2548422547):
+
+And what about Rocky Linux?
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-11.3361.issue.open.md b/docs/issues/2024-12-11.3361.issue.open.md
new file mode 100644
index 00000000..1b62eec1
--- /dev/null
+++ b/docs/issues/2024-12-11.3361.issue.open.md
@@ -0,0 +1,220 @@
+[\#3361 Issue](https://github.com/rear/rear/issues/3361) `open`: Artix Linux: LUKS2 hash is not correctly recognized when the cryptdevice contains a key-slot with pbkdf2
+=========================================================================================================================================================================
+
+**Labels**: `enhancement`
+
+#### <img src="https://avatars.githubusercontent.com/u/17392981?u=b3ed5e11972846e089ecac7aeb7830607cb64b86&v=4" width="50">[castilma](https://github.com/castilma) opened issue at [2024-12-11 13:17](https://github.com/rear/rear/issues/3361):
+
+<!-- Relax-and-Recover (ReaR) Issue Template
+Fill in the following items when submitting a new issue.
+Use GitHub Markdown, see "Basic writing and formatting syntax" on
+https://docs.github.com/en/get-started/writing-on-github
+Support is voluntary without guarantee/warranty/liability -->
+
+-   ReaR version ("/usr/sbin/rear -V"):  
+    Relax-and-Recover 2.7 / Git
+
+-   OS version ("cat /etc/os-release" or "lsb\_release -a" or "cat
+    /etc/rear/os.conf"):
+
+<!-- -->
+
+    NAME="Artix Linux"
+    PRETTY_NAME="Artix Linux"
+    ID=artix
+    BUILD_ID=rolling
+    ANSI_COLOR="0;36"
+    HOME_URL="https://www.artixlinux.org/"
+    DOCUMENTATION_URL="https://wiki.artixlinux.org/"
+    SUPPORT_URL="https://forum.artixlinux.org/"
+    BUG_REPORT_URL="https://bugs.artixlinux.org/"
+    PRIVACY_POLICY_URL="https://terms.artixlinux.org/docs/privacy-policy/"
+    LOGO=artixlinux-logo
+
+-   ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+    /etc/rear/local.conf"):
+
+<!-- -->
+
+    OUTPUT=RAWDISK
+    #OUTPUT_URL=
+
+    BACKUP=REQUESTRESTORE
+
+    REQUIRED_PROGS+=( restic )
+
+    KEYMAP="de-neo"
+    BOOTLOADER="GRUB2"
+
+-   Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+    guest or PowerVM LPAR):  
+    PC
+
+-   System architecture (x86 compatible or PPC64/PPC64LE or what exact
+    ARM device):  
+    x86\_64
+
+-   Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or
+    ELILO or Petitboot):  
+    UEFI, GRUB
+
+-   Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or
+    multipath (DM or NVMe):  
+    SSD
+
+-   Storage layout ("lsblk -ipo
+    NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
+
+<!-- -->
+
+    NAME KNAME     PKNAME    TRAN   TYPE  FSTYPE LABEL   SIZE MOUNTPOINT
+    /dev/sda
+    |    /dev/sda            sata   disk               447,1G 
+    |-/dev/sda1
+    |    /dev/sda1 /dev/sda         part                 200M /efi
+    |-/dev/sda2
+    |    /dev/sda2 /dev/sda         part                   1M 
+    `-/dev/sda3
+      |  /dev/sda3 /dev/sda         part               446,9G 
+      `-/dev/mapper/lvmSystem
+        |  /dev/dm-0 /dev/sda3        crypt              446,9G 
+        |-/dev/mapper/lvmSystem-volSwap
+        |  /dev/dm-1 /dev/dm-0        lvm                    8G [SWAP]
+        `-/dev/mapper/lvmSystem-volRoot
+           /dev/dm-2 /dev/dm-0        lvm                438,9G /
+    /dev/sr0
+         /dev/sr0            sata   rom                  7,8G 
+
+-   Description of the issue (ideally so that others can reproduce it):
+
+If a key-slot uses the key derivation function `pbkdf2`, luksDump
+outputs a `Hash:` line for that entry. This  
+breaks the 'hash' checking code in `260_crypt_layout.sh`, because
+multiple `Hash:` lines exist and the test argument is not quoted:  
+[https://github.com/rear/rear/blob/40cbaaf50b689b73be77b9a12b4321a787db6681/usr/share/rear/layout/save/GNU/Linux/260\_crypt\_layout.sh\#L118](https://github.com/rear/rear/blob/40cbaaf50b689b73be77b9a12b4321a787db6681/usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh#L118)
+
+Like in line 87, the extraction should probably just choose one line,
+but not always the first one! Right now it accepts all lines:  
+[https://github.com/rear/rear/blob/40cbaaf50b689b73be77b9a12b4321a787db6681/usr/share/rear/layout/save/GNU/Linux/260\_crypt\_layout.sh\#L88](https://github.com/rear/rear/blob/40cbaaf50b689b73be77b9a12b4321a787db6681/usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh#L88)
+
+Reproduce like this:
+
+    $ head -c 10M /dev/zero >img.iso
+    $ cryptsetup luksFormat --type luks1 img.iso 
+    $ cryptsetup convert /tmp/img.iso  --type luks2
+    $ cryptsetup luksDump /tmp/img.iso 
+    LUKS header information
+    Version:        2
+    Epoch:          2
+    Metadata area:  16384 [bytes]
+    Keyslots area:  2064384 [bytes]
+    UUID:           f100df28-dd7b-4fd4-890f-da0115a7e079
+    Label:          (no label)
+    Subsystem:      (no subsystem)
+    Flags:          (no flags)
+
+    Data segments:
+      0: crypt
+        offset: 2097152 [bytes]
+        length: (whole device)
+        cipher: aes-xts-plain64
+        sector: 512 [bytes]
+
+    Keyslots:
+      0: luks2
+        Key:        512 bits
+        Priority:   normal
+        Cipher:     aes-xts-plain64
+        Cipher key: 512 bits
+        PBKDF:      pbkdf2
+        Hash:       sha256
+        Iterations: 1222116
+        Salt:       ae d6 86 ce 59 8d 45 a1 83 12 e6 1e 76 df ca 20 
+                    a2 f7 0e cb f5 18 15 b0 fd bc d1 14 54 f3 5a a1 
+        AF stripes: 4000
+        AF hash:    sha256
+        Area offset:32768 [bytes]
+        Area length:258048 [bytes]
+        Digest ID:  0
+    Tokens:
+    Digests:
+      0: pbkdf2
+        Hash:       sha256
+        Iterations: 76293
+        Salt:       d5 86 16 6c 54 2c 62 da 36 b4 82 31 84 67 9d f5 
+                    6f 3c e5 a0 d3 82 33 32 54 bd d0 0d ec 89 ac b0 
+        Digest:     75 7b b1 29 cd 6b 14 98 22 26 72 1c c4 ca a5 fd 
+                    db 3e fd a3
+
+Note the new 'Hash:' line in the first key slot. I believe rear is
+interested in the second one under `Digests:`.
+
+Background: I upgraded my LUKS1 device to LUKS2 (after reading [this
+PSA](https://mjg59.dreamwidth.org/66429.html)), but did not follow the
+last step to update the pbkdf to argon, which I is the default for luks2
+devices. So I ended up having a keyslot with the 'pbkdf2', which should
+be pretty rare with luks2.
+
+-   Workaround, if any:  
+    Update the keyslot by running
+    `$ cryptsetup luksConvertKey <DEVICE> --pbkdf argon2id` with the
+    corresponding password.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-11 14:27](https://github.com/rear/rear/issues/3361#issuecomment-2536152881):
+
+@castilma  
+did you get some
+
+    "No 'hash' value for LUKS.. volume ..."
+
+message on your terminal?  
+If at all you would have got such a message only  
+if you did run "rear mkbackup/mkrescue" in verbose mode.
+
+As far as I see in its comments the current code in  
+layout/save/GNU/Linux/260\_crypt\_layout.sh  
+[https://github.com/rear/rear/blob/master/usr/share/rear/layout/save/GNU/Linux/260\_crypt\_layout.sh](https://github.com/rear/rear/blob/master/usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh)  
+seems to work as intended
+
+        79          # More than one keyslot may be defined - use key_size from the first slot.
+        80          # Depending on the version the "cryptsetup luksDump" command outputs the key_size value
+        81          # as a line like
+        82          #         Key:        512 bits
+        83          # and/or as a line like
+        84          #         Cipher key: 512 bits
+        85          # cf. https://github.com/rear/rear/pull/2504#issuecomment-718729198 and subsequent comments
+        86          # so we grep for both lines but use only the first match from the first slot:
+        87          key_size=$( grep -E -m 1 "Key:|Cipher key:" $TMP_DIR/cryptsetup.luksDump | sed -r 's/^.+:\s*(.+) bits$/\1/' )
+        88          hash=$( grep "Hash" $TMP_DIR/cryptsetup.luksDump | sed -r 's/^.+:\s*(.+)$/\1/' )
+    ...
+       102      # Using plain test to ensure a value is a single non empty and non blank word
+       103      # without quoting because test " " would return zero exit code
+       104      # cf. "Beware of the emptiness" in https://github.com/rear/rear/wiki/Coding-Style
+    ...
+       118      if ! test $hash ; then
+
+which does not mean that the current code  
+will work for all possible cases  
+so the current code may need to be enhanced  
+to error out if a mandatory condition is not fulfilled  
+or to even also work for more special cases like this one.
+
+Perhaps in current code
+
+       118      if ! test $hash ; then
+       119          LogPrint "No 'hash' value for LUKS$version volume $target_name in $source_device"
+       120      fi
+
+LogPrint should be at least LogPrintError or even Error  
+but right now I don't know if a hash value is mandatory.
+
+#### <img src="https://avatars.githubusercontent.com/u/17392981?u=b3ed5e11972846e089ecac7aeb7830607cb64b86&v=4" width="50">[castilma](https://github.com/castilma) commented at [2024-12-11 19:22](https://github.com/rear/rear/issues/3361#issuecomment-2536915692):
+
+Yes, I got some of these  
+`"No 'hash' value for LUKS.. volume ..."` lines. (I think it was with -v
+passed.)
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-11.3362.issue.open.md b/docs/issues/2024-12-11.3362.issue.open.md
new file mode 100644
index 00000000..4865559d
--- /dev/null
+++ b/docs/issues/2024-12-11.3362.issue.open.md
@@ -0,0 +1,165 @@
+[\#3362 Issue](https://github.com/rear/rear/issues/3362) `open`: Artix Linux: update defaults or documentation to make EFI-bootable rescue systems on USB devices simpler
+=========================================================================================================================================================================
+
+**Labels**: `support / question`
+
+#### <img src="https://avatars.githubusercontent.com/u/17392981?u=b3ed5e11972846e089ecac7aeb7830607cb64b86&v=4" width="50">[castilma](https://github.com/castilma) opened issue at [2024-12-11 21:25](https://github.com/rear/rear/issues/3362):
+
+-   ReaR version ("/usr/sbin/rear -V"):  
+    Relax-and-Recover 2.7 / Git
+
+-   ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+    /etc/rear/local.conf"):
+
+<!-- -->
+
+    OUTPUT=USB
+    USB_DEVICE="/dev/disk/by-label/REAR-000"
+    USING_UEFI_BOOTLOADER=1
+
+    BOOTLOADER="EFI"
+
+    BACKUP=REQUESTRESTORE
+
+-   Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+    guest or PowerVM LPAR):  
+    PC
+
+-   System architecture (x86 compatible or PPC64/PPC64LE or what exact
+    ARM device):  
+    x86\_64
+
+-   Description of the issue (ideally so that others can reproduce it):
+
+I spent multiply hours the last days getting a rescue system as either a
+rawimage (to later dd(1) onto a usb device) or directly on a usb device
+that would boot on my laptop.
+
+The (almost silent, i.e. no WARNING prefix being logged before) skipping
+of some steps made it more difficult for me to find out, what/where the
+issue is, until I found (ok, I admit, read) a relevant line in the rear
+-v mkrescue output.  
+(In my defense, the verbose output contains a lot of lines, and the
+important ones are not prefixed with a big WARNING or similar.)  
+I just saw the empty /dev/sdb1 (efi partition)
+
+I looked through default.conf and saw
+
+    # USING_UEFI_BOOTLOADER
+    #
+    # UEFI (Secure booting) support is partly available in ReaR (at least for Fedora, RHEL)
+    …
+    # The next variable can explicitly specify whether or not an UEFI bootloader should be used:
+    # USING_UEFI_BOOTLOADER=   means let ReaR try to find it out by itself (default)
+
+I ignored it, because it adds `(Secure booting)`, which is not what I
+want.  
+Now I feel that by default rear should make a EFI bootable usb device,
+at least if there is a 'REAR-EFI' partition, which is created by rear
+format -- --efi /dev/sdb, which kinda states intent to boot this on an
+EFI compatible computer.  
+This is what I would expect what 'finding out by itself' means.  
+It seems, that's not what it actually does.  
+Only explicitly setting `=1` passes this check (If I understand this
+code correctly) :  
+[https://github.com/rear/rear/blob/40cbaaf50b689b73be77b9a12b4321a787db6681/usr/share/rear/output/USB/Linux-i386/100\_create\_efiboot.sh\#L20-L25](https://github.com/rear/rear/blob/40cbaaf50b689b73be77b9a12b4321a787db6681/usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh#L20-L25)
+
+Anyways, I also found
+
+    # Bootloader used for the USB medium.
+    # At the moment only empty/unset and "grub" is supported.
+    # USB_BOOTLOADER="grub" uses GRUB2 as bootloader for USB with BIOS. GRUB Legacy is not supported.
+    # Default is using GRUB2 for EFI other then elilo, extlinux for ext, syslinux otherwise:
+    USB_BOOTLOADER=
+
+The last comment line seems not to be correct english, which made it
+guess what it means.  
+One (wrong) thing I understood is rear creates a EFI bootable rescue USB
+device by default.  
+Since that is wrong, I would suggest to explicitly mention that
+`USING_UEFI_BOOTLOADER` needs to be set.
+
+The [user
+guide](https://relax-and-recover.org/rear-user-guide/basics/configuration.html)
+states
+
+> OUTPUT=RAWDISK: Create a bootable raw disk image on as
+> rear-$(hostname).raw.gz. Supports UEFI boot if syslinux/EFI or Grub
+> 2/EFI is installed. Supports Legacy BIOS boot if syslinux is
+> installed. Supports UEFI/Legacy BIOS dual boot if syslinux and one of
+> the supported EFI bootloaders are installed.
+
+which again sounds to me like the rescue system will be UEFI-bootable if
+the relevant packages are installed.
+
+Looking at some other issues about UEFI this does not seem to be a
+priority usecase. But I'd be happy if you update the docs so other
+people don't have to loose as much time with this as I did.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-12 08:48](https://github.com/rear/rear/issues/3362#issuecomment-2538226671):
+
+@castilma  
+because of your  
+[https://github.com/rear/rear/issues/3361](https://github.com/rear/rear/issues/3361)  
+I assume you use Artix Linux also here.
+
+The whole booting setup of the ReaR recovery system  
+has become a mess of various pieces and methods  
+that has grown over a long time  
+BUT  
+we at ReaR upstream do not have the manpower  
+to properly clean it up and overhaul it  
+SO  
+things stay "as is" as long as noone finds the time  
+to contribute what is needed to substantially  
+improve things.
+
+With careful manual configuration  
+things can be made working as needed  
+for one's specific use case.
+
+In general regarding Artix Linux:
+
+Artix Linux is not one of the known to be  
+supported Linux based operating systems, see  
+"Supported and Unsupported Operating Systems" in  
+[https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt](https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt)
+
+In particular we at ReaR upstream do not use Artix Linux.
+
+[https://en.wikipedia.org/wiki/Artix\_Linux](https://en.wikipedia.org/wiki/Artix_Linux)  
+reads
+
+    Artix does not use systemd,
+    instead opting to provide OpenRC, runit, s6, and dinit,
+    in its place.
+
+This calls for problems because ReaR does not support  
+any other init system than the nowadays usual systemd  
+and to some extent SysVinit but this is no longer tested.
+
+So likely your ReaR recovery system may fail  
+to boot and/or fail to startup because currently  
+ReaR has no support to setup the init system for  
+the ReaR recovery system when on the original system  
+OpenRC, runit, s6, or dinit is used as init system.
+
+FYI  
+in general you may have a look at the section  
+"Inappropriate expectations" in  
+[https://en.opensuse.org/SDB:Disaster\_Recovery](https://en.opensuse.org/SDB:Disaster_Recovery)
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 15:11](https://github.com/rear/rear/issues/3362#issuecomment-2551578631):
+
+With  
+[https://github.com/rear/rear/commit/d5b48f30e299049c9e6d5df1d1a19b74b3b8bdcf](https://github.com/rear/rear/commit/d5b48f30e299049c9e6d5df1d1a19b74b3b8bdcf)  
+I improved the USB\_BOOTLOADER description in default.conf  
+to make it clear that for UEFI with GRUB2 also  
+USING\_UEFI\_BOOTLOADER must be set appropriately,  
+see
+[https://github.com/rear/rear/pull/3364](https://github.com/rear/rear/pull/3364)
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-12.3363.issue.open.md b/docs/issues/2024-12-12.3363.issue.open.md
new file mode 100644
index 00000000..56b21ab9
--- /dev/null
+++ b/docs/issues/2024-12-12.3363.issue.open.md
@@ -0,0 +1,100 @@
+[\#3363 Issue](https://github.com/rear/rear/issues/3363) `open`: ReaR does not recognise USB SSD but sees USB flashdrive
+========================================================================================================================
+
+**Labels**: `waiting for info`, `support / question`
+
+#### <img src="https://avatars.githubusercontent.com/u/161465998?v=4" width="50">[rudolf3577](https://github.com/rudolf3577) opened issue at [2024-12-12 16:10](https://github.com/rear/rear/issues/3363):
+
+<!-- Relax-and-Recover (ReaR) Issue Template
+Fill in the following items when submitting a new issue.
+Use GitHub Markdown, see "Basic writing and formatting syntax" on
+https://docs.github.com/en/get-started/writing-on-github
+Support is voluntary without guarantee/warranty/liability -->
+
+-   ReaR version ("/usr/sbin/rear -V"):  
+    Relax-and-Recover 2.7 / Git
+
+-   If your ReaR version is not the current version, explain why you
+    can't upgrade:
+
+-   OS version ("cat /etc/os-release" or "lsb\_release -a" or "cat
+    /etc/rear/os.conf"):
+
+Kernel: 6.8.0-50-generic arch: x86\_64 bits: 64 compiler: gcc v: 13.3.0
+clocksource: tsc  
+Desktop: Cinnamon v: 6.2.9 tk: GTK v: 3.24.41 wm: Muffin v: 6.2.0 vt: 7
+dm: LightDM v: 1.30.0  
+Distro: Linux Mint 22 Wilma base: Ubuntu 24.04 noble
+
+-   ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+    /etc/rear/local.conf"):
+
+local.conf:  
+OUTPUT=USB  
+BACKUP=NETFS  
+BACKUP\_URL="usb:///dev/disk/by-label/REAR-000"
+
+-   Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+    guest or PowerVM LPAR):  
+    Laptop System: Apple product: MacBookAir5,1
+
+-   System architecture (x86 compatible or PPC64/PPC64LE or what exact
+    ARM device):
+
+x86 compatible
+
+-   Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or
+    ELILO or Petitboot):
+
+GRUB
+
+-   Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or
+    multipath (DM or NVMe):
+
+Local Storage: total: 1.14 TiB used: 515.45 GiB (44.3%)  
+ID-1: /dev/sda vendor: OWC model: Aura Pro S MA258 size: 931.51 GiB
+speed: 6.0 Gb/s tech: SSD  
+serial: <filter> fw-rev: 6ANR scheme: GPT  
+ID-2: /dev/sdb vendor: OWC model: Mercury Electra 6G SSD size: 232.89
+GiB type: USB rev: 3.0  
+spd: 5 Gb/s lanes: 1 tech: SSD serial: <filter> fw-rev: 0204
+
+-   NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
+
+-   Description of the issue (ideally so that others can reproduce it):
+
+Format and BU creation works as advertised with a USB flash drive. But
+when I use the USB mounted 256GB (sdb) ReaR fails to see it and format
+it.
+
+-   Workaround, if any:
+
+-   Attachments, as applicable ("rear -D mkrescue/mkbackup/recover"
+    debug log files):  
+    Attached log file  
+    [ReaR-Dump.docx](https://github.com/user-attachments/files/18114359/ReaR-Dump.docx)
+
+You can drag-drop log files into this editor to create an attachment  
+or paste verbatim text like command output or file content  
+by including it between a leading and a closing line of  
+three backticks like this:
+
+    verbatim content
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-12-14 08:48](https://github.com/rear/rear/issues/3363#issuecomment-2543007720):
+
+@rudolf3577 Could you provide the debug logs so we can see what and
+where it goes wrong? (ReaR option `-D`).
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-12-14 15:29](https://github.com/rear/rear/issues/3363#issuecomment-2543155252):
+
+Try to add in the local.conf file with the latest ReaR sources (ReaR
+v2.8 will be released in a week or so):
+
+    # To avoid that our USB disk will be wiped out
+    WRITE_PROTECTED_FS_LABEL_PATTERNS=( "$USB_LABEL" "REAR-000" )
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-16.3364.pr.merged.md b/docs/issues/2024-12-16.3364.pr.merged.md
new file mode 100644
index 00000000..756a39fc
--- /dev/null
+++ b/docs/issues/2024-12-16.3364.pr.merged.md
@@ -0,0 +1,86 @@
+[\#3364 PR](https://github.com/rear/rear/pull/3364) `merged`: Fix some typos
+============================================================================
+
+**Labels**: `documentation`, `fixed / solved / done`, `minor bug`
+
+#### <img src="https://avatars.githubusercontent.com/u/17392981?u=b3ed5e11972846e089ecac7aeb7830607cb64b86&v=4" width="50">[castilma](https://github.com/castilma) opened issue at [2024-12-16 14:55](https://github.com/rear/rear/pull/3364):
+
+##### Pull Request Details:
+
+-   Type: **Documentation enhancement**
+
+-   Impact: **Low**
+
+-   How was this pull request tested? Not at all.
+
+-   Description of the changes in this pull request:  
+    Just fixes some text in default.conf.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-16 15:08](https://github.com/rear/rear/pull/3364#issuecomment-2545879834):
+
+@castilma  
+the current actual changes in this pull request  
+do not fix something in usr/share/rear/conf/default.conf  
+but they fix correctly typos in comments in other files.
+
+Will you add more typo fixes to this pull request  
+or is it finished for now so that it could be  
+"just merged" right now?
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-16 15:11](https://github.com/rear/rear/pull/3364#issuecomment-2545885890):
+
+No real bug (a severe typo in documentation could be a real problem)  
+so nothing urgent here so I set milestone to ReaR 3.0
+
+#### <img src="https://avatars.githubusercontent.com/u/17392981?u=b3ed5e11972846e089ecac7aeb7830607cb64b86&v=4" width="50">[castilma](https://github.com/castilma) commented at [2024-12-17 10:56](https://github.com/rear/rear/pull/3364#issuecomment-2548143415):
+
+Are you referring to my issue with USB\_BOOTLOADER?  
+Since it was mentioned that my operating system is not the target
+audience, I wasn't sure you were interested in something like:
+
+    --- a/usr/share/rear/conf/default.conf
+    +++ b/usr/share/rear/conf/default.conf
+    @@ -1231,6 +1231,7 @@ USB_BIOS_BOOT_DEFAULT=""
+     # At the moment only empty/unset and "grub" is supported.
+     # USB_BOOTLOADER="grub" uses GRUB2 as bootloader for USB with BIOS. GRUB Legacy is not supported.
+     # Default is using GRUB2 for EFI other then elilo, extlinux for ext, syslinux otherwise:
+    +# (Whether an EFI-bootloader is installed at all is controlled by USING_UEFI_BOOTLOADER.)
+     USB_BOOTLOADER=
+     #
+     # Resulting files that should be copied onto the USB stick:
+
+Maybe that's not needed anymore if PR \#3366 gets merged.
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 12:58](https://github.com/rear/rear/pull/3364#issuecomment-2551261352):
+
+IMHO both this PR and your suggestion in
+[https://github.com/rear/rear/pull/3364\#issuecomment-2548143415](https://github.com/rear/rear/pull/3364#issuecomment-2548143415)
+are good, happy to see this in 2.8 @jsmeix
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 13:23](https://github.com/rear/rear/pull/3364#issuecomment-2551313015):
+
+I will "just merge" it in about one hour or so  
+unless severe objections against "typo fixes in comments" appear ;-)
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 14:50](https://github.com/rear/rear/pull/3364#issuecomment-2551515225):
+
+@castilma  
+thank you for your contribution to ReaR!
+
+Also small things like typo fixes matter because  
+correct spelling shows that we care about details.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 15:11](https://github.com/rear/rear/pull/3364#issuecomment-2551578718):
+
+With  
+[https://github.com/rear/rear/commit/d5b48f30e299049c9e6d5df1d1a19b74b3b8bdcf](https://github.com/rear/rear/commit/d5b48f30e299049c9e6d5df1d1a19b74b3b8bdcf)  
+I improved the USB\_BOOTLOADER description in default.conf  
+to make it clear that for UEFI with GRUB2 also  
+USING\_UEFI\_BOOTLOADER must be set appropriately,  
+see
+[https://github.com/rear/rear/issues/3362](https://github.com/rear/rear/issues/3362)
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-16.3365.pr.merged.md b/docs/issues/2024-12-16.3365.pr.merged.md
new file mode 100644
index 00000000..502cd476
--- /dev/null
+++ b/docs/issues/2024-12-16.3365.pr.merged.md
@@ -0,0 +1,201 @@
+[\#3365 PR](https://github.com/rear/rear/pull/3365) `merged`: savelayout: error out on mounted multi-disk BTRFS filesystems
+===========================================================================================================================
+
+**Labels**: `enhancement`, `fixed / solved / done`
+
+#### <img src="https://avatars.githubusercontent.com/u/48823770?v=4" width="50">[lzaoral](https://github.com/lzaoral) opened issue at [2024-12-16 14:57](https://github.com/rear/rear/pull/3365):
+
+##### Pull Request Details:
+
+-   Type: **Bug Fix** / **"Workaround"**
+
+-   Impact: **High**
+
+-   Reference to related issue (URL):
+    [https://github.com/rear/rear.github.com/pull/22\#issuecomment-2540763985](https://github.com/rear/rear.github.com/pull/22#issuecomment-2540763985)
+
+-   How was this pull request tested? `rear savelayout` on a Fedora 41
+    system with different combinations of (un)mounted single disk and
+    multi disk BTRFS filesystems
+
+-   Description of the changes in this pull request:
+
+Error out on mounted multi-disk BTRFS filesystems because ReaR does not
+support this scenario at the moment.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-16 15:31](https://github.com/rear/rear/pull/3365#issuecomment-2545940363):
+
+Regarding  
+[https://github.com/rear/rear/pull/3365\#discussion\_r1886997203](https://github.com/rear/rear/pull/3365#discussion_r1886997203)
+
+Works for me on SLES 12 SP5:
+
+    # rpm -qf /usr/sbin/btrfs
+    btrfsprogs-4.5.3-24.27.x86_64
+
+    # btrfs filesystem show /
+    Label: none  uuid: b3fc4e1d-63bc-4ec7-b131-0c43b8245b68
+            Total devices 1 FS bytes used 4.80GiB
+            devid    1 size 12.99GiB used 7.02GiB path /dev/sda2
+
+    # for mp in $( findmnt -a -n -l -t btrfs -o TARGET ) ; \
+      do btrfs filesystem show $mp | grep -q 'Total devices 1' \
+         && echo OK for $mp \
+         || echo FAILED for $mp ; \
+      done
+    OK for /
+    OK for /var/lib/pgsql
+    OK for /var/lib/mailman
+    OK for /var/lib/named
+    OK for /tmp
+    OK for /opt
+    OK for /boot/grub2/i386-pc
+    OK for /var/spool
+    OK for /var/lib/mariadb
+    OK for /.snapshots
+    OK for /var/lib/machines
+    OK for /var/crash
+    OK for /srv
+    OK for /var/lib/mysql
+    OK for /var/cache
+    OK for /home
+    OK for /var/lib/libvirt/images
+    OK for /var/opt
+    OK for /var/tmp
+    OK for /var/log
+    OK for /boot/grub2/x86_64-efi
+    OK for /usr/local
+
+Works for me for SLES 15 SP6:
+
+    # rpm -qf /usr/sbin/btrfs
+    btrfsprogs-6.5.1-150600.2.4.x86_64
+
+    # btrfs filesystem show /
+    Label: none  uuid: bad9f5d9-6a37-4902-b5fc-ded16e84f357
+            Total devices 1 FS bytes used 5.36GiB
+            devid    1 size 12.99GiB used 9.07GiB path /dev/vda2
+
+    # for mp in $( findmnt -a -n -l -t btrfs -o TARGET ) ; \
+      do btrfs filesystem show $mp | grep -q 'Total devices 1' \
+         && echo OK for $mp \
+         || echo FAILED for $mp ; \
+      done
+    OK for /
+    OK for /.snapshots
+    OK for /boot/grub2/i386-pc
+    OK for /boot/grub2/x86_64-efi
+    OK for /home
+    OK for /opt
+    OK for /root
+    OK for /srv
+    OK for /tmp
+    OK for /usr/local
+    OK for /var
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-16 15:45](https://github.com/rear/rear/pull/3365#issuecomment-2545976907):
+
+@lzaoral  
+perhaps a more failsafe implementation could be  
+to first grep for "Total devices" (perhaps with ignore case?)  
+and only if that matches grep for  
+not "Total devices 1 " (with trailing space)  
+for example something like
+
+    # Only test when 'btrfs filesystem' shows the number of "Total devices":
+    if grep -qi "total devices" ... ; then
+        # Ensure a btrfs filesystem consists of only one device
+        # cf. https://github.com/rear/rear/issues/2028
+        if ! grep -qi "total devices 1 " ... ; then
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-16 16:09](https://github.com/rear/rear/pull/3365#issuecomment-2546039387):
+
+@rear/contributors  
+please have a look here and  
+if time permits and when you have a system with btrfs  
+check if this also works for you  
+because currently it is intended to be included  
+in ReaR 2.8 according to  
+[https://github.com/rear/rear.github.com/pull/22\#issuecomment-2540763985](https://github.com/rear/rear.github.com/pull/22#issuecomment-2540763985)
+
+When issues appear with the change here  
+we can easily postpone it to ReaR 3.0 because  
+when we do not do the check in this pull request  
+it is not worse than it was all the time up to ReaR 2.7
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-16 16:12](https://github.com/rear/rear/pull/3365#issuecomment-2546046917):
+
+> When issues appear with the change here we can easily postpone it to
+> ReaR 3.0 because when we do not do the check in this pull request it
+> is not worse than it was all the time up to ReaR 2.7
+
+I'd rather include this check now as we know about the problem and I
+always prefer direct and clear communication to our users over "just
+failing".
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-16 16:21](https://github.com/rear/rear/pull/3365#issuecomment-2546066766):
+
+I fully agree with  
+[https://github.com/rear/rear/pull/3365\#issuecomment-2546046917](https://github.com/rear/rear/pull/3365#issuecomment-2546046917)  
+in particular during "rear mkrescue" because  
+even if some Error() exit would be false in some cases,  
+it can be relatively easily removed in the code by the user and  
+we get (hopefully) informed by the user via a GitHub issue,  
+in contrast to "somehow failing elsewhere" where "elsewhere"  
+is likely during "rear recover" which is much more annoying  
+for the user and debugging is much more complicated  
+both for us and the user.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 08:37](https://github.com/rear/rear/pull/3365#issuecomment-2550690908):
+
+@pcahyna  
+could you also have a look here and tell your opinion  
+whether or not it should be included in ReaR 2.8  
+provided @lzaoral commits something like his  
+[https://github.com/rear/rear/pull/3365\#discussion\_r1887046610](https://github.com/rear/rear/pull/3365#discussion_r1887046610)  
+or if this pull request should be postponed to ReaR 3.0  
+because without this pull request it is not worse  
+than it had been all the time up to ReaR 2.7  
+cf.
+[https://github.com/rear/rear/pull/3365\#issuecomment-2546039387](https://github.com/rear/rear/pull/3365#issuecomment-2546039387)  
+and
+[https://github.com/rear/rear/pull/3365\#discussion\_r1887100637](https://github.com/rear/rear/pull/3365#discussion_r1887100637)
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 11:36](https://github.com/rear/rear/pull/3365#issuecomment-2551090931):
+
+@rear/contributors  
+I intend to merge it in one hour or so  
+unless severe objections appear against the currrently implemented
+
+    grep -qE 'Total devices ([2-9]|[1-9][0-9]+) '
+
+method which is tested on Red Hat / Fedora and SLES 12 / 15.
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 12:56](https://github.com/rear/rear/pull/3365#issuecomment-2551256659):
+
+Tested is always a very hard arguments, so let's go ahead with it. We
+can improve it when the output changes.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 15:29](https://github.com/rear/rear/pull/3365#issuecomment-2551620462):
+
+FYI an addendum regarding  
+[https://github.com/rear/rear/pull/3365\#discussion\_r1887100637](https://github.com/rear/rear/pull/3365#discussion_r1887100637)  
+that reads (excerpt)
+
+    any chance to have something more robust
+    that [sic] matching on the english text output of the tool?
+
+The **english** therein made me wonder if ReaR  
+actually enforces English text output of what it calls  
+and yes, it does because sbin/rear enforces C locale
+
+    # Make sure that we use only English:
+    export LC_CTYPE=C LC_ALL=C LANG=C
+
+Phew!  
+;-)
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-17.3366.pr.open.md b/docs/issues/2024-12-17.3366.pr.open.md
new file mode 100644
index 00000000..43e497e6
--- /dev/null
+++ b/docs/issues/2024-12-17.3366.pr.open.md
@@ -0,0 +1,40 @@
+[\#3366 PR](https://github.com/rear/rear/pull/3366) `open`: Make the auto detection for USING\_UEFI\_BOOTLOADER probe /efi too
+==============================================================================================================================
+
+#### <img src="https://avatars.githubusercontent.com/u/17392981?u=b3ed5e11972846e089ecac7aeb7830607cb64b86&v=4" width="50">[castilma](https://github.com/castilma) opened issue at [2024-12-17 10:55](https://github.com/rear/rear/pull/3366):
+
+Check if /efi has an ESP mounted for the auto detection of
+USING\_UEFI\_BOOTLOADER.
+
+##### Pull Request Details:
+
+-   Type: **Enhancement**
+
+-   Impact: **Normal**
+
+-   Reference to related issue (URL):
+    [https://github.com/rear/rear/issues/3362](https://github.com/rear/rear/issues/3362)
+
+-   How was this pull request tested?  
+    Not at all, (yet?).
+
+-   Description of the changes in this pull request:  
+    Rear tries to auto detect whether the current system is booted via
+    an EFI partition. For that it checks whether `/boot/efi` or `/boot`
+    is a EFI-system-partition. The Arch Wiki says using `/boot/efi` is
+    discouraged and `/efi` should be used, refering to the
+    [UAPI-Group](https://uapi-group.org/specifications/specs/boot_loader_specification/#mount-points)
+    and [Lennart
+    Poettering](https://github.com/systemd/systemd/pull/3757#issuecomment-234290236).
+    I assume many more people will have `/efi` in the future, so rear
+    could check that too.
+
+I believe there is nothing else to change, but I haven't looked to deep
+into this. I don't know whether the rescue system has to do something
+extra for the ESP to recreate the system. If it does, one would need to
+adjust that.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-17.3367.pr.merged.md b/docs/issues/2024-12-17.3367.pr.merged.md
new file mode 100644
index 00000000..e4c029ee
--- /dev/null
+++ b/docs/issues/2024-12-17.3367.pr.merged.md
@@ -0,0 +1,23 @@
+[\#3367 PR](https://github.com/rear/rear/pull/3367) `merged`: Schlomo prepare for release 2.8
+=============================================================================================
+
+**Labels**: `enhancement`, `documentation`, `cleanup`,
+`fixed / solved / done`
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) opened issue at [2024-12-17 20:37](https://github.com/rear/rear/pull/3367):
+
+My updates on the docs for the 2.8 release.
+
+Please feel free to edit / change as you see fit as I won't have time
+for this tomorrow.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 11:43](https://github.com/rear/rear/pull/3367#issuecomment-2551109070):
+
+@rear/contributors  
+I intend to merge it in one hour or so  
+unless severe objections appear
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-18.3368.issue.open.md b/docs/issues/2024-12-18.3368.issue.open.md
new file mode 100644
index 00000000..8e8326a5
--- /dev/null
+++ b/docs/issues/2024-12-18.3368.issue.open.md
@@ -0,0 +1,539 @@
+[\#3368 Issue](https://github.com/rear/rear/issues/3368) `open`: "make dist" ReaR tarball misses usr/share/rear/skel/default/root/.vimrc
+========================================================================================================================================
+
+**Labels**: `minor bug`
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) opened issue at [2024-12-18 13:46](https://github.com/rear/rear/issues/3368):
+
+See  
+[https://github.com/rear/rear/issues/3238\#issuecomment-2551305334](https://github.com/rear/rear/issues/3238#issuecomment-2551305334)  
+excerpt
+
+    # make dist OFFICIAL=1 && echo OK || echo FAILED
+    ...
+    OK
+
+    # git ls-files . --ignored --exclude-standard --others
+    dist/rear-2.7.tar.gz
+
+usr/share/rear/skel/default/root/.vimrc  
+is not in dist/rear-2.7.tar.gz  
+but this file is needed because  
+[https://github.com/rear/rear/issues/3151](https://github.com/rear/rear/issues/3151)  
+cf.  
+[https://github.com/rear/rear/issues/3238\#issuecomment-2551280753](https://github.com/rear/rear/issues/3238#issuecomment-2551280753)
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 13:49](https://github.com/rear/rear/issues/3368#issuecomment-2551373630):
+
+@rear/contributors  
+could you please have a look here?
+
+I think this should be fixed for ReaR 2.8  
+because otherwise the minor issue  
+[https://github.com/rear/rear/issues/3151](https://github.com/rear/rear/issues/3151)  
+would not be fixed in ReaR 2.8 packages  
+that are built from our dist/rear-2.8.tar.gz
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 13:54](https://github.com/rear/rear/issues/3368#issuecomment-2551385989):
+
+Let's just add an empty `.vimrc` to `skel/default` with a comment line
+explaining why it is there. Or we can add it to `/etc/vimrc` same place?
+Wouldn't that have the same effect and it would be more obvious?
+
+Users who want to carry along their own VIM config can still use
+`COPY_AS_IS` to do so and it will override our empty default
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 14:10](https://github.com/rear/rear/issues/3368#issuecomment-2551421568):
+
+I have the same `.vimrc`
+
+    " An empty vimrc file to avoid that 'vi' inside the ReaR recovery system shows
+    " Failed to source defaults.vim - Press ENTER or type command to continue
+    " see https://github.com/rear/rear/issues/3151
+
+as copies now in  
+usr/share/rear/skel/default/etc/.vimrc  
+usr/share/rear/skel/default/.vimrc  
+usr/share/rear/skel/default/root/.vimrc  
+and did
+
+    make dist OFFICIAL=1
+
+and all three are missing in dist/rear-2.7.tar.gz
+
+BUT  
+when I make another copy as  
+usr/share/rear/skel/default/root/vimrc  
+(i.e. without leading dot)  
+then it gets included in dist/rear-2.7.tar.gz  
+so it seems dot-files are ignored.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 14:10](https://github.com/rear/rear/issues/3368#issuecomment-2551421789):
+
+> usr/share/rear/skel/default/root/.vimrc  
+> is not in dist/rear-2.7.tar.gz
+
+Do you know why?
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 14:11](https://github.com/rear/rear/issues/3368#issuecomment-2551423280):
+
+If I knew why I would "just fix" it, cf.  
+[https://github.com/rear/rear/issues/3238\#issuecomment-2551334213](https://github.com/rear/rear/issues/3238#issuecomment-2551334213)
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 14:17](https://github.com/rear/rear/issues/3368#issuecomment-2551436909):
+
+I guess it is because of `--exclude=".??*"` passed to tar, which
+originates in 56959b54fc by @schlomo .
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 14:19](https://github.com/rear/rear/issues/3368#issuecomment-2551442705):
+
+Unfortunately, if we remove this, I suspect we will get unwanted stuff
+in the build, like `.github`, `.fmf` and `.shellcheckrc`.
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 14:20](https://github.com/rear/rear/issues/3368#issuecomment-2551443703):
+
+@jsmeix the root cause is that we exlcude dot files when building the
+tar in
+[https://github.com/rear/rear/blob/3d17f43a3c0279344c7cd97125b86971081107cb/Makefile\#L90](https://github.com/rear/rear/blob/3d17f43a3c0279344c7cd97125b86971081107cb/Makefile#L90)
+
+Therefore we have the ability to use an **archive** as skel, see
+[https://github.com/rear/rear/blob/master/usr/share/rear/skel/Debian/default.tar.gz](https://github.com/rear/rear/blob/master/usr/share/rear/skel/Debian/default.tar.gz)
+
+But for this specific problem I'd prefer to solve the `vim` problem via
+shipping an `/etc/vimrc` in the hope that such a file would make vim
+happy without a `/root/.vimrc` as dot files are often not noticed by
+users. If possible.
+
+Or we use code to create the dotfile in the rescue system.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 14:29](https://github.com/rear/rear/issues/3368#issuecomment-2551464909):
+
+Ah!  
+`/etc/vimrc` is not a dot-file - I missed that.  
+I will try to fix it this way for ReaR 2.8...
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 14:29](https://github.com/rear/rear/issues/3368#issuecomment-2551465625):
+
+If I remove `--exclude=".??*"` from the Makefile, I get this difference
+in the resulting tar :
+
+    --- unpatched.list      2024-12-18 15:26:29.207157564 +0100
+    +++ patched.list        2024-12-18 15:25:45.518053248 +0100
+    @@ -462,6 +462,7 @@
+     rear-2.7/usr/share/rear/lib/output-functions.sh
+     rear-2.7/usr/share/rear/lib/config-functions.sh
+     rear-2.7/usr/share/rear/lib/mkbackup-workflow.sh
+    +rear-2.7/usr/share/rear/lib/.shellcheckrc
+     rear-2.7/usr/share/rear/lib/udev-workflow.sh
+     rear-2.7/usr/share/rear/lib/mail-functions.sh
+     rear-2.7/usr/share/rear/lib/layoutonly-workflow.sh
+    @@ -579,6 +580,7 @@
+     rear-2.7/usr/share/rear/skel/default/mnt/cdrom/
+     rear-2.7/usr/share/rear/skel/default/mnt/local/
+     rear-2.7/usr/share/rear/skel/default/root/
+    +rear-2.7/usr/share/rear/skel/default/root/.vimrc
+     rear-2.7/usr/share/rear/skel/default/etc/
+     rear-2.7/usr/share/rear/skel/default/etc/lilo.conf
+     rear-2.7/usr/share/rear/skel/default/etc/syslog-ng.conf
+    @@ -1422,6 +1424,7 @@
+     rear-2.7/usr/share/rear/restore/NSR/default/400_restore_with_nsr.sh
+     rear-2.7/usr/share/rear/restore/SUSE_LINUX/
+     rear-2.7/usr/share/rear/restore/SUSE_LINUX/910_create_missing_directories.sh
+    +rear-2.7/usr/share/rear/.shellcheckrc
+     rear-2.7/usr/share/rear/rescue/
+     rear-2.7/usr/share/rear/rescue/NETFS/
+     rear-2.7/usr/share/rear/rescue/NETFS/default/
+
+looks good. @schlomo what do you mean by "Therefore we have the ability
+to use an archive as skel"? How is it related to excludign dot files
+from the dist archive?
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 14:36](https://github.com/rear/rear/issues/3368#issuecomment-2551481029):
+
+@pcahyna
+[https://github.com/rear/rear/blob/3d17f43a3c0279344c7cd97125b86971081107cb/usr/share/rear/rescue/default/010\_merge\_skeletons.sh\#L30-L34](https://github.com/rear/rear/blob/3d17f43a3c0279344c7cd97125b86971081107cb/usr/share/rear/rescue/default/010_merge_skeletons.sh#L30-L34)
+
+If the `.vimrc` dotfile would be in such a skel archive then it wouldn't
+be filtered out in the `make dist` process. I had added this feature a
+long time ago as a way to add arbitrary stuff via the skel process that
+would cause problems with git. For example, a block or character device
+probably wouldn't work either.
+
+But, I'd rather use a non-dotfile to solve a problem as this is much
+easier to see and understand than having to look into an archive hidden
+somewhere deep in our source tree. That is why I was asking if
+`/etc/vimrc` would also solve the problem.
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 14:39](https://github.com/rear/rear/issues/3368#issuecomment-2551488840):
+
+@pcahyna and I'd rather exclude the development relevant files like
+`.shellcheckrc` from our dist archive.
+
+In any case we have slightly different behavior of the `make dist`
+process depending on if it runs from a git checkout or not, as it reacts
+to the presence of `.gitignore` files to also exclude everything
+mentioned there, which covers for example a `var` directory that is
+created if you happen to run `./usr/sbin/rear` from the git checkout
+prior to running `make dist` (this is the original reason for me to
+include that feature of handling `.gitignore` properly for `tar`).
+
+HTH for context
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 14:39](https://github.com/rear/rear/issues/3368#issuecomment-2551490473):
+
+Unfortunately it neither works with /etc/vimrc  
+nor with /etc/.vimrc in the ReaR recovery system.
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 14:52](https://github.com/rear/rear/issues/3368#issuecomment-2551522144):
+
+@jsmeix `vim --version` suggests to use `/usr/share/vim/vimrc` and maybe
+we should simply add this folder to our default `COPY_AS_IS` to simply
+include the original system's vim configuration. If vim is not
+installed, then nothing happens. And if it is installed, then it will
+work with the defaults.
+
+<img width="880" alt="image" src="https://github.com/user-attachments/assets/b9237024-2857-4b38-a17e-55555a2e6c16" />
+
+So it seems like `/etc/vim/vimrc` is not standard but enabled by Debian
+via a symlink. Maybe adding both paths (`/etc/vim` and `/usr/share/vim`)
+to `COPY_AS_IS` would be a "correct" way to resolve this?
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 14:53](https://github.com/rear/rear/issues/3368#issuecomment-2551525173):
+
+> If the `.vimrc` dotfile would be in such a skel archive then it
+> wouldn't be filtered out in the `make dist` process.
+
+Not sure if I get it. What if there is a non-dotfile in the archive? It
+would not get filtered either. What makes the `.??*` pattern special?
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 14:58](https://github.com/rear/rear/issues/3368#issuecomment-2551546713):
+
+the skel archive is a means to transport anything whatsoever into the
+rescue system. this of course also works for non-dotfiles. It is only
+required for special or weird stuff.
+
+The `.??*` pattern is not special, it simply ensures to not match on
+dotfiles with less than 2 characters after the dot which is a common way
+to not match on `.` and `..`. Maybe a shorter pattern like `.*` would
+have sufficed, I don't remember if I tried that or not.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 15:00](https://github.com/rear/rear/issues/3368#issuecomment-2551551821):
+
+But what's the problem with dotfiles in the first place? Is it related
+to the skel archive or not (if it also works for non-dotfiles)?
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 15:14](https://github.com/rear/rear/issues/3368#issuecomment-2551586393):
+
+Unfortunately it neither works with /etc/vim/vimrc  
+nor with /etc/vim/.vimrc in the ReaR recovery system.
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 15:19](https://github.com/rear/rear/issues/3368#issuecomment-2551596311):
+
+I think the only "problem" is, that we filter out dotfiles in the
+`make dist` process.
+
+BTW, I just noticed in
+[https://github.com/rear/rear/blob/486b76b1a8a47afdf0a032b32989c94c47503f7a/usr/share/rear/build/GNU/Linux/130\_create\_dotfiles.sh\#L32](https://github.com/rear/rear/blob/486b76b1a8a47afdf0a032b32989c94c47503f7a/usr/share/rear/build/GNU/Linux/130_create_dotfiles.sh#L32)
+
+we check for `vi` not `vim` but talk about including the config for
+`vim`. Maybe `vi` (the not-improved VI) has a different config or works
+without?
+
+I now understand that @jsmeix tried to fix the missing VIM rc file via
+[https://github.com/rear/rear/commit/700727b53855d551c0620c46a839755894b26eb3\#diff-86dae0514a9be4af4b9a40cd2670d62f8d815757a620cdebd29038458af0c2d6](https://github.com/rear/rear/commit/700727b53855d551c0620c46a839755894b26eb3#diff-86dae0514a9be4af4b9a40cd2670d62f8d815757a620cdebd29038458af0c2d6)
+and that we now realize that it didn't work for package building.
+
+@jsmeix to quickly resolve this I'd suggest to also create the `.vimrc`
+(with the dot) in
+[https://github.com/rear/rear/blob/486b76b1a8a47afdf0a032b32989c94c47503f7a/usr/share/rear/build/GNU/Linux/130\_create\_dotfiles.sh\#L32](https://github.com/rear/rear/blob/486b76b1a8a47afdf0a032b32989c94c47503f7a/usr/share/rear/build/GNU/Linux/130_create_dotfiles.sh#L32)
+or, to try creating a `/usr/share/vim/vimrc` file instead. AFAIK
+`/etc/vim/vimrc` is actually not the path that `vim` looks for.
+`vim --version` will show you the actual paths it checks.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 15:33](https://github.com/rear/rear/issues/3368#issuecomment-2551632256):
+
+In my ReaR recovery sytem made on SLES 15 SP6:
+
+    RESCUE localhost:~ # vim --version
+    -bash: vim: command not found
+
+    RESCUE localhost:~ # vi --version
+    VIM - Vi IMproved 9.1 (2024 Jan 02)
+    ...
+       system vimrc file: "/etc/vimrc"
+         user vimrc file: "$HOME/.vimrc"
+     2nd user vimrc file: "~/.vim/vimrc"
+          user exrc file: "$HOME/.exrc"
+           defaults file: "$VIMRUNTIME/defaults.vim"
+      fall-back for $VIM: "/usr/share/vim"
+
+No, it just lies because /etc/vimrc does not work  
+at least not in my ReaR recovery system :-(
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 15:39](https://github.com/rear/rear/issues/3368#issuecomment-2551645740):
+
+> I think the only "problem" is, that we filter out dotfiles in the
+> `make dist` process.
+
+Let's stop filtering them, then?
+
+    diff --git a/Makefile b/Makefile
+    index 731c05af7..54f5d4ee1 100644
+    --- a/Makefile
+    +++ b/Makefile
+    @@ -87,7 +87,7 @@ RUNASUSER :=
+     endif
+     
+     # .gitignore is optional, avoid tar errors if it does not exist, e.g. in a dist archive
+    -tarparams = $(shell test -f .gitignore && echo --exclude-from=.gitignore --exclude=.gitignore) --exclude=".??*" $(DIST_CONTENT)
+    +tarparams = $(shell test -f .gitignore && echo --exclude-from=.gitignore --exclude=.gitignore) $(DIST_CONTENT)
+     
+     DIST_FILES := $(shell tar -cv -f /dev/null $(tarparams))
+     
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 15:43](https://github.com/rear/rear/issues/3368#issuecomment-2551654292):
+
+@pcahyna  
+my personal feeling is that currently we are too near  
+the ReaR 2.8 release so that I feel rather uncomfortable  
+with changing what "make dist OFFICIAL=1" does  
+ONLY  
+because of this minor issue here, in particular because  
+[https://github.com/rear/rear/issues/3151](https://github.com/rear/rear/issues/3151)  
+is only an annoying message so 'vi' works inside  
+the ReaR recovery system - and how often is 'vi'  
+used inside ReaR recovery system in practice?
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 15:43](https://github.com/rear/rear/issues/3368#issuecomment-2551655288):
+
+> Therefore we have the ability to use an **archive** as skel, see
+> [https://github.com/rear/rear/blob/master/usr/share/rear/skel/Debian/default.tar.gz](https://github.com/rear/rear/blob/master/usr/share/rear/skel/Debian/default.tar.gz)
+
+By the way (not related to the original problem anymore), having a
+gzipped archive in our source tree is at best an antipattern and at
+worst a way to sneakily inject malware (who knows what is inside? see
+the xz attack), so I hope we will get rid of it.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 15:47](https://github.com/rear/rear/issues/3368#issuecomment-2551664741):
+
+@pcahyna  
+I agree that having a gzipped archive in our source tree  
+is bad but I don't agree to get rid of that functionality  
+where a user could add a gzipped archive as neded in his  
+skel tree to get special things into his ReaR recovery system  
+as he needs it - think about a complex piece of software  
+where COPY\_AS\_IS, REQUIRED\_PROGS, and LIBS could be  
+needlessly complicaded for the usre compared to  
+"simply pack what is needed into an archive".
+
+But I never used that functionality myself  
+so I cannot tell if it is actually useful in practice.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 15:50](https://github.com/rear/rear/issues/3368#issuecomment-2551678423):
+
+I meant, get rid of the archive, not of the functionality.
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 16:23](https://github.com/rear/rear/issues/3368#issuecomment-2551758396):
+
+While I understand and agree with your thoughts about having an archive
+in the source tree I'd like to keep it there to keep testing the skel
+archive feature.
+
+I'm fine with removing the dotfile exclude from the tar creation process
+because in
+[https://github.com/rear/rear/blob/cc1e9e493a4b975b77148eef749a0040e11622ec/Makefile\#L12](https://github.com/rear/rear/blob/cc1e9e493a4b975b77148eef749a0040e11622ec/Makefile#L12)
+we have an explicit include of the files relevant for ReaR. That already
+excludes top-level dotfiles and development stuff in order to create a
+"clean" dist archive. For cleaning up we should then also remove all the
+other development-related dotfiles (shellcheckrc, gitignore) from the
+source tree and have those only on the top level.
+
+For actually solving the vimrc problem, the SLES example maybe confirms
+my suggestion that we should add common vimrc locations to `COPY_AS_IS`.
+
+Or we don't deal with it for 2.8 - also totally fine for me as I'm using
+`nano` for small editing needs 😁
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 16:30](https://github.com/rear/rear/issues/3368#issuecomment-2551774509):
+
+Regarding usr/share/rear/skel/Debian/default.tar.gz
+
+    # tar -tzvf usr/share/rear/skel/Debian/default.tar.gz
+    -rw-r--r-- root/root 1059 2007-10-05 16:06 lib/linux-sound-base/noOSS.modprobe.conf
+
+It doesn't look as if this single file  
+could not be a regular file in skel?
+
+    # git log -p --follow usr/share/rear/skel/Debian/default.tar.gz
+
+tells that it originated since "Switch to trunk model"  
+which means it is there "since the beginning of time"  
+i.e. beyond what we can see in retrospect in git
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 16:42](https://github.com/rear/rear/issues/3368#issuecomment-2551800730):
+
+Yes, I just put some BS into that archive to see that the mechanism
+works.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 16:43](https://github.com/rear/rear/issues/3368#issuecomment-2551804248):
+
+From my current (Wednesday evening) point of view  
+I would prefer to "don't deal with it for 2.8"  
+and deal with it properly for ReaR 3.0.
+
+I assume an appropriate
+
+    COPY_AS_IS+=( /path/to/some/vimrc )
+
+is a sufficient workaround in ReaR 2.8  
+for users who want to avoid the annoying message.
+
+Alternatively @schlomo @pcahyna if you work longer today  
+and find a solution that you tested that it works for you  
+the please make a pull request (we may still postpone  
+a pull request to ReaR 3.0 if we think it is better/safer  
+to "don't deal with it for 2.8").
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 16:50](https://github.com/rear/rear/issues/3368#issuecomment-2551819896):
+
+@schlomo  
+does your  
+[https://github.com/rear/rear/issues/3368\#issuecomment-2551800730](https://github.com/rear/rear/issues/3368#issuecomment-2551800730)  
+mean the current usr/share/rear/skel/Debian/default.tar.gz  
+content lib/linux-sound-base/noOSS.modprobe.conf  
+is only a test and that noOSS.modprobe.conf is not  
+actually needed in the ReaR recovery system for Debian?
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 17:14](https://github.com/rear/rear/issues/3368#issuecomment-2551869523):
+
+> @schlomo does your [\#3368
+> (comment)](https://github.com/rear/rear/issues/3368#issuecomment-2551800730)
+> mean the current usr/share/rear/skel/Debian/default.tar.gz content
+> lib/linux-sound-base/noOSS.modprobe.conf is only a test and that
+> noOSS.modprobe.conf is not actually needed in the ReaR recovery system
+> for Debian?
+
+The file contains the following:
+
+    blacklist ac97
+    blacklist ac97_codec
+    blacklist ac97_plugin_ad1980
+    blacklist ad1848
+    blacklist ad1889
+    blacklist adlib_card
+    blacklist aedsp16
+    blacklist ali5455
+    blacklist btaudio
+    blacklist cmpci
+    blacklist cs4232
+    blacklist cs4281
+    blacklist cs461x
+    blacklist cs46xx
+    blacklist emu10k1
+    blacklist es1370
+    blacklist es1371
+    blacklist esssolo1
+    blacklist forte
+    blacklist gus
+    blacklist i810_audio
+    blacklist kahlua
+    blacklist mad16
+    blacklist maestro
+    blacklist maestro3
+    blacklist maui
+    blacklist mpu401
+    blacklist nm256_audio
+    blacklist opl3
+    blacklist opl3sa
+    blacklist opl3sa2
+    blacklist pas2
+    blacklist pss
+    blacklist rme96xx
+    blacklist sb
+    blacklist sb_lib
+    blacklist sgalaxy
+    blacklist sonicvibes
+    blacklist sound
+    blacklist sscape
+    blacklist trident
+    blacklist trix
+    blacklist uart401
+    blacklist uart6850
+    blacklist via82cxxx_audio
+    blacklist v_midi
+    blacklist wavefront
+    blacklist ymfpci
+    blacklist ac97_plugin_wm97xx
+    blacklist ad1816
+    blacklist audio
+    blacklist awe_wave
+    blacklist dmasound_core
+    blacklist dmasound_pmac
+    blacklist harmony
+    blacklist sequencer
+    blacklist soundcard
+    blacklist usb-midi
+
+I would indeed assume that this is long obsolete, at least
+[https://en.wikipedia.org/wiki/Open\_Sound\_System](https://en.wikipedia.org/wiki/Open_Sound_System)
+suggests that this doesn't apply any more.
+
+I'm also totally fine with just removing this archive and to fix
+problems if somebody complains about a problem here.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 17:16](https://github.com/rear/rear/issues/3368#issuecomment-2551873753):
+
+> my personal feeling is that currently we are too near  
+> the ReaR 2.8 release so that I feel rather uncomfortable  
+> with changing what "make dist OFFICIAL=1" does  
+> ONLY  
+> because of this minor issue here
+
+@jsmeix this is an entirely reasonable approach. OTOH, when changing the
+Makefile, it is easy to check what is being introduced by the change:
+
+    make OFFICIAL=1 dist
+    tar tzf dist/rear-2.7.tar.gz > unpatched.list
+    # here change the Makefile...
+
+    make OFFICIAL=1 dist
+    tar tzf dist/rear-2.7.tar.gz > patched.list
+    diff -u unpatched.list patched.list
+
+so I will leave it up to you.
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-18 17:23](https://github.com/rear/rear/issues/3368#issuecomment-2551887190):
+
+Yes, I also prefer to get a release now, TBH. So please what you deem
+right @jsmeix
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 17:30](https://github.com/rear/rear/issues/3368#issuecomment-2551900242):
+
+> if you work longer today  
+> and find a solution that you tested that it works for you  
+> the please make a pull request (we may still postpone  
+> a pull request to ReaR 3.0 if we think it is better/safer  
+> to "don't deal with it for 2.8").
+
+I will try to make a PR out of the proposed Makefile change.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-18 17:31](https://github.com/rear/rear/issues/3368#issuecomment-2551902752):
+
+> While I understand and agree with your thoughts about having an
+> archive in the source tree I'd like to keep it there to keep testing
+> the skel archive feature.
+
+Testing is useful, but I would very much prefer to move the test to
+[https://github.com/rear/rear-integration-tests/](https://github.com/rear/rear-integration-tests/)
+where it is clearly separate from ReaR sources.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 07:58](https://github.com/rear/rear/issues/3368#issuecomment-2553008543):
+
+I postpone this issue to ReaR 3.0 because  
+I like to focus on the actual ReaR 2.8 release now  
+because I have to leave today already at 14:00
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-18.3369.issue.open.md b/docs/issues/2024-12-18.3369.issue.open.md
new file mode 100644
index 00000000..8ef86288
--- /dev/null
+++ b/docs/issues/2024-12-18.3369.issue.open.md
@@ -0,0 +1,29 @@
+[\#3369 Issue](https://github.com/rear/rear/issues/3369) `open`: Makefile contains "obsproject = Archiving:Backup:Rear:Snapshot" which does no longer exist
+===========================================================================================================================================================
+
+**Labels**: `cleanup`, `ReaR Project`
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) opened issue at [2024-12-18 14:26](https://github.com/rear/rear/issues/3369):
+
+In current master code  
+[https://github.com/rear/rear/blob/master/Makefile\#L58](https://github.com/rear/rear/blob/master/Makefile#L58)
+
+        obsproject = Archiving:Backup:Rear:Snapshot
+
+but this OBS project is meanwhile removed.
+
+Because 'obsproject = Archiving:Backup:Rear:Snapshot'  
+is used if "Not official build" this issue should not matter for
+
+    make obs OFFICIAL=1
+
+in  
+[https://github.com/rear/rear/wiki/Release-process\#preparation](https://github.com/rear/rear/wiki/Release-process#preparation)  
+so this issue should not affect  
+[https://github.com/rear/rear/issues/3238](https://github.com/rear/rear/issues/3238)  
+so this issue could be fixed after the ReaR 2.8 release
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-18.3370.pr.merged.md b/docs/issues/2024-12-18.3370.pr.merged.md
new file mode 100644
index 00000000..78e6c4eb
--- /dev/null
+++ b/docs/issues/2024-12-18.3370.pr.merged.md
@@ -0,0 +1,203 @@
+[\#3370 PR](https://github.com/rear/rear/pull/3370) `merged`: ReaR 2.8 release preparations
+===========================================================================================
+
+**Labels**: `fixed / solved / done`, `ReaR Project`
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) opened issue at [2024-12-18 16:03](https://github.com/rear/rear/pull/3370):
+
+See
+[https://github.com/rear/rear/wiki/Release-process\#preparation](https://github.com/rear/rear/wiki/Release-process#preparation)
+
+Done:
+
+-   rear.8.adoc : Update version number and release date
+
+-   usr/sbin/rear : Update VERSION and RELEASE\_DATE
+
+-   packaging/rpm/rear.spec : Update Version
+
+-   packaging/debian/changelog : Add changelog entries
+
+-   packaging/debian/rear.dsc : Update Version
+
+WIP (perhaps for tomorrow):
+
+-   doc/rear-release-notes.txt related things
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-18 17:10](https://github.com/rear/rear/pull/3370#issuecomment-2551860622):
+
+With the current commits in this pull request  
+doc/rear-release-notes.txt  
+is the only file left that needs to be updated regarding ReaR 2.8  
+i.e. no other file falsely contains '2.7' where it should be '2.8'.
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-12-19 09:09](https://github.com/rear/rear/pull/3370#issuecomment-2553143203):
+
+@jsmeix All is fine for me - happy release!
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 09:42](https://github.com/rear/rear/pull/3370#issuecomment-2553213788):
+
+Via the last two commits I replaced  
+the old doc/rear-release-notes.txt  
+by a completely new one to finally solve  
+[https://github.com/rear/rear/issues/3302](https://github.com/rear/rear/issues/3302)
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-12-19 09:46](https://github.com/rear/rear/pull/3370#issuecomment-2553237981):
+
+@jsmeix Could you please correct some misspelled words before the actual
+release?
+
+    Error: ./doc/rear-release-notes.txt:688: clude ==> clued, clue
+    Error: ./doc/rear-release-notes.txt:799: accomodating ==> accommodating
+    Error: ./doc/rear-release-notes.txt:1007: avod ==> avoid
+    Error: ./doc/rear-release-notes.txt:1184: belogs ==> belongs
+    Error: ./doc/rear-release-notes.txt:1191: specifiy ==> specify
+    Error: ./doc/rear-release-notes.txt:1[27](https://github.com/rear/rear/actions/runs/12410085401/job/34644976651?pr=3370#step:6:28)4: enfore ==> enforce
+    Error: ./doc/rear-release-notes.txt:1493: configuation ==> configuration
+    Error: ./doc/rear-release-notes.txt:1539: exlude ==> exclude, exude
+    Error: ./doc/rear-release-notes.txt:1627: incresed ==> increased
+    Error: ./doc/rear-release-notes.txt:1654: Previosly ==> Previously
+    Error: ./doc/rear-release-notes.txt:1654: possitions ==> positions
+    Error: ./doc/rear-release-notes.txt:1751: tha ==> than, that, the
+    Error: ./doc/rear-release-notes.txt:2046: interactiv ==> interactive
+    Error: ./doc/rear-release-notes.txt:2048: characte ==> character
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 09:51](https://github.com/rear/rear/pull/3370#issuecomment-2553270829):
+
+In the new one  
+[https://github.com/rear/rear/blob/jsmeix-rear28-preparations/doc/rear-release-notes.txt](https://github.com/rear/rear/blob/jsmeix-rear28-preparations/doc/rear-release-notes.txt)  
+the line breaks are sometimes not very good  
+(but the content is at least readable).  
+I created it as described in  
+[https://github.com/rear/rear.github.com/blob/master/README.md](https://github.com/rear/rear.github.com/blob/master/README.md)  
+via
+
+    export LC_ALL=POSIX
+    export LANG=POSIX
+    lynx --dump https://relax-and-recover.org/documentation/release-notes-2-8 >rear-release-notes.txt
+
+So I leave the line breaks as is.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 09:55](https://github.com/rear/rear/pull/3370#issuecomment-2553283296):
+
+@gdha  
+thank you for review.  
+I will fix the misspelled words in  
+[https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md](https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md)  
+and re-generate doc/rear-release-notes.txt from it.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 10:12](https://github.com/rear/rear/pull/3370#issuecomment-2553318705):
+
+Fixed typos (which all wrere only in the git commit messages)  
+[https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md](https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md)  
+via  
+[https://github.com/rear/rear.github.com/commit/c3bd395a15dc6f3643598096b7e275be15a235fd](https://github.com/rear/rear.github.com/commit/c3bd395a15dc6f3643598096b7e275be15a235fd)
+
+In  
+[https://github.com/rear/rear/pull/3370\#issuecomment-2553237981](https://github.com/rear/rear/pull/3370#issuecomment-2553237981)  
+the following happened because of those "not very good"  
+line breaks of what 'lynx' produces:
+
+    # for w in tha interactiv characte ; do grep -A1 -w "$w" rear-release-notes.txt ; done
+
+    New variable USE_RAMDISK configures rescue system to use a ramdisk for tools tha
+    t need to check for free disk space.
+
+    In the UserInput function drain stdin if stdin is a terminal (i.e. in interactiv
+    e mode):
+
+    The primarily intended use case is to discard possibly already existing characte
+    rs
+
+And 'clude' is false alarm:
+
+    # grep -w 'clude' rear-release-notes.txt
+
+    * Remove duplicates in backup-[in/ex]clude.txt but keep the ordering
+
+#### <img src="https://avatars.githubusercontent.com/u/101384?v=4" width="50">[schlomo](https://github.com/schlomo) commented at [2024-12-19 10:19](https://github.com/rear/rear/pull/3370#issuecomment-2553333901):
+
+@jsmeix I'm sorry, please generate the text release notes as you see
+fit.
+
+If the text release notes file makes so much work, maybe we can get rid
+of it or simply have a one-liner pointing to the home page? Less effort
+and good enough? I'm not sure if so many users actually only can read
+the release notes when it is shipped with the ReaR package itself.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-12-19 10:22](https://github.com/rear/rear/pull/3370#issuecomment-2553341033):
+
+> @jsmeix I'm sorry, please generate the text release notes as you see
+> fit.
+>
+> If the text release notes file makes so much work, maybe we can get
+> rid of it or simply have a one-liner pointing to the home page? Less
+> effort and good enough? I'm not sure if so many users actually only
+> can read the release notes when it is shipped with the ReaR package
+> itself.
+
+Or just use the original file in markdown format?
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 10:38](https://github.com/rear/rear/pull/3370#issuecomment-2553380703):
+
+    lynx -dont_wrap_pre --dump https://relax-and-recover.org/documentation/release-notes-2-8 >rear-release-notes.txt
+
+improves things - at least in the git commit messages.  
+Now the `tha` `interactiv` `characte` issues are gone.
+
+But '-dont\_wrap\_pre' still results "strange" line breaks  
+in normal text, e.g.
+
+         * New portable mode --portable and OUTPUT=PORTABLE, see
+           [23]https://github.com/rear/rear/blob/master/doc/user-guide/17-Port
+           able-Mode.adoc for more information.
+
+where the long URL gets wrapped within the word "Portable".
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 10:49](https://github.com/rear/rear/pull/3370#issuecomment-2553401610):
+
+Allow lines up to 100 characters for normal text  
+helps a lot to avoid ugly looking line breaks:
+
+    lynx -dont_wrap_pre -width=100 --dump https://relax-and-recover.org/documentation/release-notes-2-8 >rear-release-notes.txt
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 11:01](https://github.com/rear/rear/pull/3370#issuecomment-2553425570):
+
+The updated  
+[https://github.com/rear/rear/blob/jsmeix-rear28-preparations/doc/rear-release-notes.txt](https://github.com/rear/rear/blob/jsmeix-rear28-preparations/doc/rear-release-notes.txt)  
+looks rather good to me.
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 11:06](https://github.com/rear/rear/pull/3370#issuecomment-2553434279):
+
+@rear/contributors  
+I will merge this pull request very soon  
+to be able to do "the actual release" today  
+(I must leave at 14:00 today because of an appointment).
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 11:17](https://github.com/rear/rear/pull/3370#issuecomment-2553454480):
+
+Latest commit updates rear-release-notes.txt  
+with the latest ReaR 2.8 commit messages from  
+[https://github.com/rear/rear.github.com/commit/7477f38d929b128cdc6977cb99da9cca54e29d30](https://github.com/rear/rear.github.com/commit/7477f38d929b128cdc6977cb99da9cca54e29d30)
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 11:26](https://github.com/rear/rear/pull/3370#issuecomment-2553471272):
+
+The failing "Codespell / codespell" check is now  
+[https://github.com/rear/rear/actions/runs/12411610323/job/34649664834?pr=3370](https://github.com/rear/rear/actions/runs/12411610323/job/34649664834?pr=3370)  
+only because of
+
+    Error: ./doc/rear-release-notes.txt:660: clude ==> clued, clue
+
+which is false alarm, see  
+[https://github.com/rear/rear/pull/3370\#issuecomment-2553318705](https://github.com/rear/rear/pull/3370#issuecomment-2553318705)
+
+#### <img src="https://avatars.githubusercontent.com/u/1788608?u=925fc54e2ce01551392622446ece427f51e2f0ce&v=4" width="50">[jsmeix](https://github.com/jsmeix) commented at [2024-12-19 11:45](https://github.com/rear/rear/pull/3370#issuecomment-2553505795):
+
+All checks are successful  
+except "Codespell / codespell" which is false alarm.  
+So I merge it now.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-12-19.3371.pr.open.md b/docs/issues/2024-12-19.3371.pr.open.md
new file mode 100644
index 00000000..ec792e84
--- /dev/null
+++ b/docs/issues/2024-12-19.3371.pr.open.md
@@ -0,0 +1,40 @@
+[\#3371 PR](https://github.com/rear/rear/pull/3371) `open`: Do not remove dotfiles from the release archive
+===========================================================================================================
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) opened issue at [2024-12-19 08:32](https://github.com/rear/rear/pull/3371):
+
+##### Pull Request Details:
+
+-   Type: **Bug Fix**
+
+-   Impact: **Low**
+
+-   Reference to related issue (URL):  
+    Closes \#3368.
+
+-   How was this pull request tested?
+
+<!-- -->
+
+    make OFFICIAL=1 dist
+    tar tzf dist/rear-2.7.tar.gz > unpatched.list
+    # here apply the change
+
+    make OFFICIAL=1 dist
+    tar tzf dist/rear-2.7.tar.gz > patched.list
+    diff -u unpatched.list patched.list
+
+Result is at
+[https://github.com/rear/rear/issues/3368\#issuecomment-2551465625](https://github.com/rear/rear/issues/3368#issuecomment-2551465625)
+
+-   Description of the changes in this pull request:  
+    Do not remove dotfiles from the release archive. Avoids dropping
+    .vimrc from /root of the rescue ramdisk. This also adds
+    .shellcheckrc to the release tarballs, so package builds using
+    static analyzers (OpenScanHub) will know what ShellCheck warnings to
+    ignore.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/index.md b/docs/issues/index.md
index 5fa1d8b3..4c2e4979 100644
--- a/docs/issues/index.md
+++ b/docs/issues/index.md
@@ -2025,6 +2025,7 @@
 - [\#2026 Issue](2019-01-29.2026.issue.closed.md) `closed`: rear.spec: Remove obsolete BuildRoot tag
 - [\#2027 Issue](2019-01-29.2027.issue.closed.md) `closed`: rear.spec: Remove obsolete Group tag
 - [\#2028 Issue](2019-02-01.2028.issue.closed.md) `closed`: BTRFS Raid / Multi Disk setup is currently not supported
+- [\#2028 Issue](2019-02-01.2028.issue.open.md) `open`: BTRFS Raid / Multi Disk setup is currently not supported
 - [\#2029 Issue](2019-02-01.2029.issue.closed.md) `closed`: No /verify/BORG/ script to verify a BORG backup can be restored
 - [\#2030 PR](2019-02-04.2030.pr.merged.md) `merged`: Basic support for EFISTUB booting.
 - [\#2031 PR](2019-02-04.2031.pr.merged.md) `merged`: Documentation for EFISTUB boot support.
@@ -3427,6 +3428,7 @@
 - [\#3314 PR](2024-09-06.3314.pr.merged.md) `merged`: Request BIOS for backup and restore tests
 - [\#3315 Issue](2024-09-08.3315.issue.closed.md) `closed`: ReaR BACKUP=BACULA director not responding but bacula works perfectly on ubuntu 20.04 how to resove
 - [\#3315 Issue](2024-09-08.3315.issue.open.md) `open`: ReaR BACKUP=BACULA director not responding but bacula works perfectly on ubuntu 20.04 how to resove
+- [\#3316 Issue](2024-09-09.3316.issue.closed.md) `closed`: Question : Does REAR can backup OracleASM shared disk ?
 - [\#3316 Issue](2024-09-09.3316.issue.open.md) `open`: Question : Does REAR can backup OracleASM shared disk ?
 - [\#3317 PR](2024-09-09.3317.pr.merged.md) `merged`: Disable the backup & recovery test on Fedora
 - [\#3318 PR](2024-09-13.3318.pr.closed.md) `closed`: Create wiki-release-notes.yml
@@ -3462,6 +3464,25 @@
 - [\#3349 PR](2024-11-27.3349.pr.merged.md) `merged`: After doing lots of experiments with RAMdisks it is good to have some…
 - [\#3350 Issue](2024-12-02.3350.issue.closed.md) `closed`: find on menu.c32 hangs on NFS mount point (via 300\_create\_isolinux.s
 - [\#3351 PR](2024-12-02.3351.pr.merged.md) `merged`: fix: add -xdev option to find to avoid hanging NFS (\#3350
+- [\#3352 PR](2024-12-03.3352.pr.closed.md) `closed`: cleanup: move grubby and grub2-editenv to 300\_include\_grub\_tools.sh (\#3349
 - [\#3352 PR](2024-12-03.3352.pr.open.md) `open`: cleanup: move grubby and grub2-editenv to 300\_include\_grub\_tools.sh (\#3349
+- [\#3353 PR](2024-12-03.3353.pr.merged.md) `merged`: cleanup: Finish the change of "Arch to "Arch\_Linux"
 - [\#3353 PR](2024-12-03.3353.pr.open.md) `open`: cleanup: Finish the change of "Arch to "Arch\_Linux"
+- [\#3354 PR](2024-12-04.3354.pr.merged.md) `merged`: cleanup: move grubby and grub2-editenv to 300\_include\_grub\_tools.sh (\#3349
+- [\#3355 PR](2024-12-04.3355.pr.open.md) `open`: Storing and reading Self Encrypted Disk (SED
+- [\#3356 PR](2024-12-04.3356.pr.merged.md) `merged`: In 100\_copy\_as\_is.sh error out if symlinking VAR\_DIR SHARE\_DIR fails
+- [\#3357 Issue](2024-12-05.3357.issue.open.md) `open`: finalize/.../660\_install\_grub2.sh automatism fails on RAID1
+- [\#3359 Issue](2024-12-10.3359.issue.open.md) `open`: BACKUP\_PROG=rsync: Is it possible to backup and restore to/from an NFS share that has root squash enabled?
+- [\#3360 Issue](2024-12-11.3360.issue.open.md) `open`: Officially support Alma Linux, Rocky Linux and Oracle Linux as RHEL clones
+- [\#3361 Issue](2024-12-11.3361.issue.open.md) `open`: Artix Linux: LUKS2 hash is not correctly recognized when the cryptdevice contains a key-slot with pbkdf2
+- [\#3362 Issue](2024-12-11.3362.issue.open.md) `open`: Artix Linux: update defaults or documentation to make EFI-bootable rescue systems on USB devices simpler
+- [\#3363 Issue](2024-12-12.3363.issue.open.md) `open`: ReaR does not recognise USB SSD but sees USB flashdrive
+- [\#3364 PR](2024-12-16.3364.pr.merged.md) `merged`: Fix some typos
+- [\#3365 PR](2024-12-16.3365.pr.merged.md) `merged`: savelayout: error out on mounted multi-disk BTRFS filesystems
+- [\#3366 PR](2024-12-17.3366.pr.open.md) `open`: Make the auto detection for USING\_UEFI\_BOOTLOADER probe /efi too
+- [\#3367 PR](2024-12-17.3367.pr.merged.md) `merged`: Schlomo prepare for release 2.8
+- [\#3368 Issue](2024-12-18.3368.issue.open.md) `open`: "make dist" ReaR tarball misses usr/share/rear/skel/default/root/.vimrc
+- [\#3369 Issue](2024-12-18.3369.issue.open.md) `open`: Makefile contains "obsproject = Archiving:Backup:Rear:Snapshot" which does no longer exist
+- [\#3370 PR](2024-12-18.3370.pr.merged.md) `merged`: ReaR 2.8 release preparations
+- [\#3371 PR](2024-12-19.3371.pr.open.md) `open`: Do not remove dotfiles from the release archive
 - # Issues History of Relax-and-Recover (index.md)
diff --git a/docs/releasenotes/rear28.md b/docs/releasenotes/rear28.md
new file mode 100644
index 00000000..3c415919
--- /dev/null
+++ b/docs/releasenotes/rear28.md
@@ -0,0 +1,2217 @@
+---
+layout: default
+title: Release Notes for Relax-and-Recover Version 2.8
+---
+
+This document contains the latest release notes for the Open Source Software project Relax-and-Recover.
+
+Relax-and-Recover website: [relax-and-recover.org](https://relax-and-recover.org/)
+
+GitHub project: [github.com/rear](https://github.com/rear)
+
+For the release notes of previous Relax-and-Recover versions see the
+Relax-and-Recover website release notes: [relax-and-recover.org/documentation](/documentation)
+
+
+## Overview
+
+Relax-and-Recover (abbreviated ReaR) is the de facto standard disaster recovery framework on Linux.
+
+It is in particular used on enterprise Linux distributions like Red Hat Enterprise Linux (RHEL)
+and SUSE Linux Enterprise Server (SLES).
+
+ReaR is a system administrator tool and framework to create a bootable disaster recovery system image
+for bare metal disaster recovery with data backup restore on physical or virtual replacement hardware.
+
+For bare metal disaster recovery the ReaR recovery system is booted on pristine replacement hardware.
+On replacement hardware first the storage setup/layout is recreated (disk partitioning, filesystems, mount points),
+then a backup restore program is called to restore the data (system files) into the recreated storage,
+and finally a boot loader is installed.
+
+System administrators use the ReaR framework to set up a disaster recovery procedure
+as part of their disaster recovery policy (which complements their existing backup policy).
+
+ReaR complements backup and restore of data with bare metal disaster recovery. ReaR can also act as local backup software,
+but ReaR is not a a backup management software. In many enterprise environmentments, data backup and restore happens via dedicated backup software which is integrated by ReaR and used to restore the data onto a replacement system as part of the automated disaster recovery procedure implemented by ReaR.
+
+ReaR has support for built-in backup methods using 'tar' and 'rsync' that are used for backup and restore.
+
+ReaR integrates supports the following 3rd party, also commercial, tools for restoring a backup.
+
+The complete list of backup methods (`BACKUP=...`) is:
+
+* `AVA` Dell EMC Avamar / EMC Avamar
+* `BACULA` Bacula
+* `BAREOS` [Bareos](https://docs.bareos.org/Appendix/DisasterRecoveryUsingBareos.html#linux)
+* `BLOCKCLONE` block device cloning via `dd`
+* `BORG` Borg Backup
+* `CDM` Rubrik Cloud Data Management
+* `DP` OpenText Data Protector
+* `DUPLICITY` Duplicity / Duply
+* `EXTERNAL` External custom restore method
+* `FDRUPSTREAM` FDR/Upstream
+* `GALAXY11` Commvault Galaxy 11 / Commvault Simpana
+* `NBKDC` NovaStor DataCenter
+* `NBU` Veritas NetBackup / Symantec NetBackup
+* `NETFS` ReaR built-in backup and restore via `rsync` or `tar` to a network file system or to a locally attached backup disk (USB, eSATA, ...)
+* `NFS4SERVER` NFS4 server to push data *to* the rescue system
+* `NSR` Dell EMC NetWorker / EMC NetWorker / Legato NetWorker
+* `OBDR` One Button Disaster Recovery via tape
+* `PPDM` [Dell PowerProtect Data Manager](https://infohub.delltechnologies.com/en-us/t/simplifying-linux-bmr-for-powerprotect-data-manager-using-rear-relax-and-recover-disaster-recovery-solution/)
+* `RBME` [Rsync Backup Made Easy](https://github.com/schlomo/rbme)
+* `REQUESTRESTORE` Request restore from a human operator
+* `RSYNC` ReaR built-in backup using `rsync` via `rsync` or `ssh` protocol
+* `SESAM` [SEP Sesam](https://wiki.sep.de/wiki/index.php/Bare_Metal_Recovery_Linux)
+* `TSM` IBM Storage Protect / Tivoli Storage Manager / IBM Spectrum Protect
+* `VEEAM` Veeam Backup
+
+ReaR integrates well with Disaster Recovery Linux Manager (DRLM) [drlm.org](https://drlm.org), which can act as a central management tool for ReaR deployments.
+
+## System and Software Requirements
+
+ReaR is written entirely in the native language for system administration: as shell (bash) scripts.
+The intent is that experienced users and system admins can adapt or extend the ReaR scripts
+as needed to make things work for their specific cases.
+
+We need Bash version 4 which is standard on current GNU/Linux systems.
+
+The default backup software used by ReaR is standard GNU/tar.
+
+ReaR is known to work on x86 (32bit and 64bit) and ppc64le architectures.
+ReaR was also ported to ia64 and arm architectures, but these are rarely tested.
+
+## Support
+
+Relax-and-Recover (ReaR) is a Free and Open Source Software project under GPLv3 license.
+
+The creators of ReaR have spend many, many hours in development and support.
+We may give voluntary support, but only as work-life balance allows it.
+Some of the maintainers also provide paid support as a commercial service.
+
+ReaR has a long history (since 2006) and we can therefore only support the latest release version.
+If you have a problem, we urge you to install the latest stable ReaR version
+or the snapshot (development) version available on GitHub before submitting an issue.
+We understand that it is not always possible to install the latest version on hundreds of systems,
+so we are willing to support previous versions of ReaR when you buy a support contract.
+We cannot handle all those various support requests on a voluntary base
+and we give paid projects priority, therefore, we urge our customers
+to buy a support contract for one or more systems.
+Buying a support contract actually buys time for the core developers to work on ReaR.
+
+See the Relax-and-Recover website support [relax-and-recover.org/support](/support)
+
+## Supported and Unsupported Operating Systems
+
+We try to keep our "Test Matrix" wiki pages up-to-date with feedback we receive from the community.
+For example for ReaR 2.8 see <https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8>
+
+ReaR 2.8 is supported on the following Linux operating systems:
+
+* Fedora 40, 41 (Silverblue not supported)
+* RHEL 7, 8, and 9
+* RHEL clones (CentOS, Scientific Linux, Alma Linux, Oracle Linux) 7, 8, and 9
+* SLES 15
+* openSUSE Leap 15.x
+* Debian 10 and 11
+* Ubuntu 20.04, 22.04, 24.04
+* Arch Linux / Manjaro
+
+ReaR 2.8 dropped official support for the following Linux operating systems:
+
+* Fedora < 39
+* RHEL < 7
+* RHEL clones (CentOS, Scientific Linux, Alma Linux, Oracle Linux) < 7
+* SLES < 15
+* openSUSE Leap < 15.x and older openSUSE versions
+* openSUSE Tumbleweed
+* Debian < 10
+* Ubuntu < 20
+
+Usually ReaR 2.8 should also work on newer versions of the above listed supported Linux operating systems
+but sometimes arbitrary failures can happen when software that is used by ReaR
+(like partitioning tools, filesystem tools, bootloader tools, ISO image creating tools, networking tools, and so on)
+changes in not fully backward compatible ways or when there are innovations of the basic system
+(like kernel, storage, bootloader, init, networking, and so on)
+that are not yet supported by ReaR.
+
+In theory ReaR 2.8 should work on openSUSE Tumbleweed
+but in practice arbitrary failures could happen at any time
+because the Tumbleweed distribution is a pure rolling release version of openSUSE
+containing the latest stable versions of all software
+(cf. <https://en.opensuse.org/Portal:Tumbleweed>)
+so arbitrary changes of any software are possible at any time
+that could arbitrarily break how ReaR works.
+
+ReaR 2.8 may still work for SLES < 15 and openSUSE Leap < 15.x
+but it is no longer tested there so arbitrary regressions could appear,
+in particular on systems with Bash before version 4.
+
+ReaR 2.8 and earlier versions are known to no longer work
+for the following Linux operating systems:
+
+* RHEL 5 (and probably also CentOS 5): See issue #1766
+* SLES 9 and 10: See issue #1842
+
+If you need support for an unsupported Linux operating system you must acquire a ReaR support contract.
+
+Requests to port ReaR to another operating system (not Linux) can only be achieved with serious sponsoring.
+
+## Supported and Unsupported Architectures
+
+ReaR 2.8 is supported on:
+
+* Intel x86 (32bit and 64bit) architectures
+* AMD x86 (64bit) architecture
+* PPC64LE architecture
+
+ReaR 2.8 may or may not work on:
+
+* PPC64 processors
+* Intel Itanium processors
+* ARM type of processors
+* IBM Z "s390x" type of processors
+
+ReaR 2.8 is known to not support:
+
+* old PPC (32bit) processors
+
+If you need to get ReaR working on an architecture that is currently not supported,
+you can buy consultancy from one of our official developers.
+
+## Unsupported Features and Known Issues
+
+We are aware of the following issues and limitations in ReaR 2.8:
+
+* BTRFS support is limited to single-device configurations and doesn't cover advanced BTRFS features like spanning file systems over multiple devices, BTRFS built-in RAID and multi disk configurations. (#2028)
+* [Oracle ASM](https://docs.oracle.com/en/database/oracle/oracle-database/23/ostmg/asm-intro.html) is not supported by ReaR. (#3284)
+
+All of those can be resolved via sponsoring or support contracts, unfortunately we cannot handle all those various requests on a voluntary base. Alternatively we'll be very happy to accept contributions to resolve those issues via GitHub pull requests.
+
+## Relax-and-Recover Releases
+
+The first release of ReaR, version 1.0, was posted to the web in July 2006.
+This document lists new features, backward incompatible changes, and defect fixes for the current release only,
+please refer to [our documentation](/documentation) for the older release notes for previous versions.
+Unless otherwise noted releases of ReaR are intended to work reasonably backward compatible with previous versions.
+In addition to the GPL disclaimer of warranty and liability there is no guarantee that all works backward compatible.
+In general the older a system is the less likely it is that a newer ReaR version works.
+For each ReaR version upgrade and for each change of a software that is used by ReaR and
+for each change of your basic system you must re-validate that your disaster recovery procedure still works for you.
+
+## Relax-and-Recover Version 2.8 (December 2024)
+
+Things like 'issue NNNN' or only '#NNNN' refer to the GitHub issues tracker <https://github.com/rear/rear/issues>
+
+### New features, bigger enhancements, and possibly backward incompatible changes:
+
+* New support for additional commercial backup software
+
+  * Veeam Backup.
+
+  * Dell PowerProtect Data Manager.
+  
+  * CommvaultGalaxy 11 (Simpana).
+
+* Bareos integration was rewritten and updated.
+
+* New portable mode `--portable` and `OUTPUT=PORTABLE`, see <https://github.com/rear/rear/blob/master/doc/user-guide/17-Portable-Mode.adoc> for more information.
+
+* Improved handling and protecting of secrets in ReaR configuration variables. New `-e`/`--expose-secrets` option to show secrets in configuration variables.
+
+* New non-interactive mode `-n`/`--non-interactive` to suppress all interactive questions and answers and facilitate truly unattended recovery automation.
+
+* `NFS4SERVER` as new restore method where the rescue systems starts an NFS4 server to push the data to the rescue system.
+
+* New OpalPBA AuthToken feature.
+
+* Layout changes and fixes for S/390 DASDs (major code overhauling).
+
+* Initial basic `barrel` support, see <https://github.com/aschnell/barrel>
+
+* By default `rear recover` wipes disks that get completely recreated via `DISKS_TO_BE_WIPED=""` in default.conf.
+
+### Details (mostly in chronological order - newest topmost):
+
+Only changes of the ReaR software and its documentation that could be of common interest are listed here.
+For example changes of ReaR GitHub infrastructure things (like GitHub workflows, actions, CI, and package building)
+or minor changes in documentation (like unimportant typo fixes) are not listed here.
+To see all changes use the 'git log' command on a local git clone/checkout
+or view the ReaR 2.8 changes at GitHub <https://github.com/rear/rear/commits/rear-2.8>
+or the current ReaR GitHub master code changes <https://github.com/rear/rear/commits/master>
+
+The following entries are basically excerpts of what the command
+
+```sh
+git log --format="%ae %H %ad%n%s :%n%b%n" --graph | fmt -w 160 -u -t
+```
+
+shows in a local git clone:
+
+
+&nbsp;
+```
+In default.conf improve the USB_BOOTLOADER description 
+to make it clear that for UEFI with GRUB2 also 
+USING_UEFI_BOOTLOADER must be set appropriately, 
+see https://github.com/rear/rear/issues/3362 
+and https://github.com/rear/rear/pull/3364
+```
+&nbsp;
+```
+savelayout: error out on mounted multi-disk BTRFS filesystems (#3365) :
+error out on mounted multi-disk BTRFS filesystems
+because ReaR does not support this scenario at the moment, see 
+https://github.com/rear/rear.github.com/pull/22#issuecomment-2540763985 
+and https://github.com/rear/rear/issues/2028
+```
+&nbsp;
+```
+In 100_copy_as_is.sh error out if symlinking VAR_DIR SHARE_DIR fails (#3356) :
+In build/GNU/Linux/100_copy_as_is.sh 
+error out if symlinking VAR_DIR and/or SHARE_DIR fails 
+because with non-default VAR_DIR and/or SHARE_DIR 
+(e.g. when running from checkout) 
+it is mandatory that in the ReaR recovery system 
+all ReaR files are accessible via the default 
+/var/lib/rear and /usr/share/rear directories, 
+see https://github.com/rear/rear/pull/3356 
+So old systems with 'ln' from coreutils < 8.16 
+that does not support the '-r/--relative' option 
+are no longer supported because the 
+relative symlink is needed for portable mode, 
+see https://github.com/rear/rear/pull/3206
+```
+&nbsp;
+```
+Merge pull request #3351 :
+fix: add -xdev option to find to avoid hanging NFS (#3350)
+```
+&nbsp;
+```
+Call 'lsblk' with 'MOUNTPOINTS' to show all mounted btrfs subvolumes (#3348) :
+In layout/save/GNU/Linux/100_create_layout_file.sh 
+try to call 'lsblk' with 'MOUNTPOINTS' with plural 'S' 
+to show all mounted btrfs subvolumes 
+in contrast to 'MOUNTPOINT' that shows only 
+a random one of the mounted btrfs subvolumes 
+which is misleading when several btrfs subvolumes 
+of one btrfs are mounted,
+see https://github.com/rear/rear/pull/3348
+```
+&nbsp;
+```
+Update 400_create_include_exclude_files.sh (#3347) :
+In backup/NETFS/default/400_create_include_exclude_files.sh 
+skip to add /.snapshots by default to the backup include list 
+see https://github.com/rear/rear/issues/3346
+```
+&nbsp;
+```
+Minor os-detection improvements (#3344) :
+See https://github.com/rear/rear/pull/3344 
+* Remove incorrect check for SUSE_LINUX: 
+  On SUSE, the OS_MASTER_VENDOR variable is set to SUSE and not SUSE_LINUX. 
+  Since the code was still executed on this platform and no problems have been 
+  reported so far, let's assume that it is safe and remove this redundant condition. 
+  Related: https://github.com/rear/rear/issues/3149#issuecomment-1966068640 
+* Set OS_VENDOR to Arch_Linux on Arch Linux: 
+  Because the plain 'Arch' could be confused with 'Architecture'. 
+  Related: https://github.com/rear/rear/issues/3149#issuecomment-1972731026
+```
+&nbsp;
+```
+Minimal changes to fix detection of Fedora from `/etc/os-release` (#3171) :
+See https://github.com/rear/rear/pull/3171 
+and https://github.com/rear/rear/issues/3149 
+* Search for `rhel` when detecting RHEL: 
+  The `redhat` substring is present only in auxiliary variables and URLs
+  in `/etc/os-release` both on Fedora and RHEL. 
+  Therefore, the `grep` worked only by accident on RHEL and was broken 
+  on Fedora because it wrongly classified Fedora as RHEL because 
+  its BUG_REPORT_URL refers to Red Hat's Bugzilla. 
+  On the other hand, `rhel` is the actual `ID` of RHEL and this string 
+  is not present in Fedora's `/etc/os-release` at all. 
+  Resolves: https://github.com/rear/rear/issues/3149#issuecomment-1964290116 
+* Always source a script in SourceStage at most once: 
+  Use `sort -u` to ensure that each relevant script is listed 
+  and sourced only once and that duplicates get discarded. 
+  Otherwise, some scripts could have been executed repeatedly 
+  (see the last linked comment '.../3149#issuecomment-1935586311'). 
+  Especially, when `OS_VENDOR` and `OS_MASTER_VENDOR` 
+  have the same value which is the case at least on Fedora. 
+  Related: https://github.com/rear/rear/pull/3171#pullrequestreview-2053278291 
+  Resolves: https://github.com/rear/rear/issues/3149#issuecomment-1935586311 
+```
+&nbsp;
+```
+Make sourcing DUPLY_PROFILE reasonably secure (#3345) :
+See https://github.com/rear/rear/issues/3293 
+and https://github.com/rear/rear/issues/3259 
+Overhauled prep/DUPLICITY/default/200_find_duply_profile.sh 
+so that now only an explicitly user specified DUPLY_PROFILE 
+will get sourced to avoid that some automatism 
+finds and sources whatever it may have found. 
+Error out when DUPLY_PROFILE is empty or does not exist 
+to make the user aware that he must explicitly 
+specify his correct DUPLY_PROFILE. 
+In default.conf explain the new DUPLY_PROFILE behaviour 
+that is backward incompatible but much more secure. 
+In 500_make_duplicity_backup.sh overhauled the code 
+that makes a backup with duply in particular 
+regarding command output which appears in the logfile 
+only in debug modes. 
+Also stdout to stderr redirections are no longer needed, see 
+https://github.com/rear/rear/wiki/Coding-Style#what-to-do-with-stdin-stdout-and-stderr 
+```
+&nbsp;
+```
+Update default.conf :
+In default.conf fixed a typo in the 
+DISABLE_DEPRECATION_ERRORS description 
+('sete' in "Users who sete this")
+and by the way improved the text a bit 
+e.g. telling more about "feature" than about "code" 
+and be more outspoken that without talking to us 
+deprecated features get removed without further notice 
+to urge users to actually do open GitHub issues
+```
+&nbsp;
+```
+Make get_disklabel_type() also work for 'multipath' devices (#3334) :
+Without this fix, get_disklabel_type() used to find a disk to install GRUB on 
+was returning nothing when the disk was a multipath device. 
+The reason is that then the line in disklayout.conf starts with 'multipath' 
+but ReaR had searched for 'disk' only. Now it also searches for 'multipath'. 
+See https://github.com/rear/rear/pull/3334 
+```
+&nbsp;
+```
+Merge pull request #3329 :
+Fix partition naming on RHEL when migrating devices :
+The previous code was appending a "p" to the device name
+unconditionally, which ended up having partition names such as 'wwidp0'
+instead of 'wwid1', when the device name (e.g. 'wwid') ended with a
+letter and not a digit.
+The new code applies the proper naming, which is 'wwid1' when device
+doesn't end with a digit (e.g. 'wwid'), and 'wwid0000p1' when the device
+(e.g. 'wwid0000') ends with a digit.
+```
+&nbsp;
+```
+Use OS_MASTER_VERSION for major releases (#3331) :
+Use OS_MASTER_VERSION for major releases, see 
+https://github.com/rear/rear/pull/3331 
+Contrary to its name, the OS_MASTER_VERSION variable 
+was already used for this purpose for some versions, e.g. RHEL 7. 
+This fixes version comparison on RHEL 10 and newer. 
+Related: https://github.com/rear/rear/issues/3149#issuecomment-1966068640 
+Fixes commit: f4932c1cfe13d4a855bec93c1d3aa0b2b9128c6a 
+"Add OS version mappings for RHEL 8 and RHEL 9"
+```
+&nbsp;
+```
+Merge pull request #3312 :
+#3178 improve USB device detection
+#3312 improve the text output; add example on how to fetch NVME RAW_USB_DEVICE device
+#3312 parse string through uniq for RAW_USB_DEVICE
+```
+&nbsp;
+```
+BACKUP=NSR: Deprecate 650_check_iso_recoverable.sh (#3309) :
+Deprecate layout/save/NSR/default/650_check_iso_recoverable.sh 
+because it conflicts with "rear checklayout", see 
+https://github.com/rear/rear/issues/3069 
+```
+&nbsp;
+```
+In 990_verify_rootfs.sh show relative paths in user messages for files in ROOTFS_DIR (#3308) :
+In build/default/990_verify_rootfs.sh 
+enhanced how files from within the ReaR recovery system 
+(i.e. files from within ROOTFS_DIR) are shown to the user: 
+In user messages it is misleading to show the full path from 
+within the recovery system without leading ROOTFS_DIR 
+for example showing /bin/parted for what actually is 
+/var/tmp/rear.XXX/rootfs/bin/parted 
+because for the user /bin/parted means the full path 
+on his original system but there is no /bin/parted on 
+the original system because there it is /usr/sbin/parted 
+so to show files inside the recovery system to the user 
+even without (the long) leading ROOTFS_DIR we can show them 
+as relative path i.e. without leading slash e.g. as bin/parted 
+when from the context it should be clear enough 
+that a file inside the recovery system is meant. 
+```
+&nbsp;
+```
+Merge pull request #3281 :
+conf: reintroduce Linux-s390.conf :
+The conf directory is the expected location for architecture-specific settings.
+Moreover, the 305_include_s390_tools.sh script contained a potentially harmful
+check that could result in all s390/s390x tools being omitted from the recovery
+image with disastrous results.
+Fixes: cba3590b27bedb526e5b439cd8d4d01e1ec0169a ("pull #2142")
+Resolves: https://github.com/rear/rear/issues/3144
+```
+&nbsp;
+```
+Overhauled SLE11-SLE12-SAP-HANA-UEFI-example.conf (#3306) :
+In conf/examples/SLE11-SLE12-SAP-HANA-UEFI-example.conf 
+removed the meanwhile outdated and obsolete 
+information about ebiso, see 
+https://github.com/rear/rear/issues/3084#issuecomment-1833496190 
+so with /usr/bin/xorrisofs it "just works" 
+to make a UEFI bootable ISO image 
+that should boot even with Secure Boot, cf. 
+https://github.com/rear/rear/issues/3084#issuecomment-1835773844 
+Additionally I added a part about SECURE_BOOT_BOOTLOADER, see 
+https://github.com/rear/rear/issues/3300 
+Furthermore I overhauled the whole comment texts, in particular: 
+Removed the parts about SSH_ROOT_PASSWORD. 
+Added hint about SAN and multipath to look at 
+conf/examples/RHEL7-PPC64LE-Multipath-PXE-GRUB.conf 
+Plus several more general improvements of the comment texts.
+```
+&nbsp;
+```
+Update local.conf description comment :
+In the local.conf comment explain that 
+one must ensure commands in configuration files 
+work always without errors regardless in which
+environment those commands will be run, 
+in particular on the original system and 
+also within the ReaR recovery system, 
+see https://github.com/rear/rear/issues/3296
+```
+&nbsp;
+```
+Autodetect secure boot via mokutil and guess the secure boot shim (#3278) :
+* Autodetect Secure Boot status via mokutil and guess the secure boot shim 
+* Check that a shim is found when Secure Boot is active, improved diagnostic messages 
+Fixes #3276 
+```
+&nbsp;
+```
+Improve layout configuration part of the user guide (#3125)
+```
+&nbsp;
+```
+Automatically include mounted btrfs subvolumes in NETFS backups (#3175) :
+* automatically exclude btrfs snapshot subvolumes from 'btrfsmountedsubvol' 
+  Related: https://github.com/rear/rear/pull/3175#issuecomment-1983498175 
+* automatically include mounted btrfs subvolumes in NETFS backups 
+  ... unless they are explicitly excluded. 
+  Resolves: https://github.com/rear/rear/issues/2928 
+* always add the excluded component in RESTORE_EXCLUDE_FILE 
+  Otherwise, the component itself would not be included if it had any child 
+  components of the `fs` type. 
+ * automatically exclude btrfs subvolume children of excluded components
+```
+&nbsp;
+```
+Migrate MAC addresses and interface names in NetworkManager keyfiles
+during network configuration migration (#3179) :
+* Migrate NM keyfiles during network conf migration 
+  See https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/ 
+  for more details on NetworkManager keyfiles. 
+  Only MAC addresses and interface names are migrated for now. 
+  TODO: migrate also IP addresses and routes. 
+* Quote name when assembling network files to patch 
+  Otherwise patching fails on files with spaces in them, often used by NetworkManager.
+* Quote network config filenames in log messages 
+  - especially useful with file names containing spaces.
+```
+&nbsp;
+```
+improve device recognition when creating efibootmgr entry (#3267) :
+via the get_device_name function to normalize the device names
+```
+&nbsp;
+```
+Merge pull request #3041 :
+Reorder systemd units in the rescue system and make sure syslog is started
+Start syslog after rescue system init :
+The syslog socket used to be started early in the rescue system boot and
+for some reason this does not work well: logging to /dev/log does not
+trigger the start of rsyslogd and therefore the log data are never read
+(happens on RHEL 9 at least).
+Fix by ordering the syslog start after basic system initialization
+(sysinit.target), just like usual daemons.
+Separate automated ReaR startup :
+Make it a separate script and systemd unit. This allows to run services
+after sysinit (which initializes network) but before ReaR starts.
+Especially useful for network backup daemons that are needed to restore
+files during "rear recover".
+Configure network-online.target in rescue system :
+Services that need network to be configured can be made to be run after
+this target.
+This matches the usual systemd setup: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
+Intended especially for 3rd party network backup solutions where restore
+needs some daemon running and communicating over network in the rescue
+system.
+```
+&nbsp;
+```
+Merge pull request #3261 :
+bareos: require Bareos Director >= 21 :
+The Bareos ReaR integration uses features introduced with Bareos 20.
+However, the oldest official supported version of Bareos is 21
+(the current version is Bareos 23).
+Therefore we add a requirement for a Bareos Director >= 21.
+```
+&nbsp;
+```
+Rewrite Bareos integration (#3240) :
+Major rework of Baros support provided by the Bareos company 
+* remove untested bextract method, now we only use bconsole 
+* update to support recent Bareos versions 
+* autoconfigure client, job and fileset if possible 
+* automatic (latest) and manual (bconsole commands) restore 
+* improved logging of bconsole output 
+* start bareos-fd in restore-only mode to prevent accidentally creating a backup of the rescue system 
+* generate systemd unit for bareos-fd 
+* ensure client is fully functional 
+* create bareos specific functions to handle bareos tasks 
+* significantly simplify code, improve readability 
+* remove variables not needed any more 
+* show progress information during restore 
+* get jobid from restore command from returned result 
+* bcommand now works without the "@out" command, which might get removed with Bareos >= 24. 
+```
+&nbsp;
+```
+Merge pull request #3242 :
+Fix IPv6 address support in OUTPUT_URL/BACKUP_URL :
+Currently there is no proper support for IPv6 addresses in
+OUTPUT_URL/BACKUP_URL properties:
+- OUTPUT_URL=nfs://2001:db8:ca2:6::101/root/REAR is not recognized
+  (and should not be)
+- OUTPUT_URL=nfs://[2001:db8:ca2:6::101]/root/REAR fails
+  because of bash substitutions occurring in various places
+- OUTPUT_URL="nfs://\[2001:db8:ca2:6::101\]/root/REAR" works
+  but is somehow cumbersome (double quotes + square brackets quoting).
+This patch makes the following (proper) scheme work with both NFS and SSHFS:
+  OUTPUT_URL=nfs://[2001:db8:ca2:6::101]/root/REAR
+  OUTPUT_URL=sshfs://[2001:db8:ca2:6::101]/root/REAR
+For this to occur, a lot of bash quoting had to be fixed.
+```
+&nbsp;
+```
+In 990_verify_rootfs.sh fix issue #3021 (#3250) :
+In build/default/990_verify_rootfs.sh 
+for each 'not found' shared object 
+(i.e. a shared object that was 'not found' by 'ldd') 
+check whether or not the shared object 
+may exist nevertheless in the recovery system 
+and if yes, we may sufficiently safely assume 
+things are OK in the ReaR recovery system 
+so we do not report it as missing to the user 
+(for debugging we have all in the log), see 
+https://github.com/rear/rear/issues/3021#issuecomment-2165453757 
+Additionally in 990_verify_rootfs.sh 
+more consistent level when messages are shown, 
+i.e. now only LogPrint and LogPrintError 
+to show nothing (except errors) when not in verbose mode 
+and all messages when in verbose mode 
+to make the messages as a whole 
+better understandable by the user. 
+```
+&nbsp;
+```
+On POWER tell the user when the initrd is big (#3233) :
+In pack/GNU/Linux/900_create_initramfs.sh 
+tell the user on POWER architecture 
+when the initrd is bigger than 100 MiB 
+that this may cause a boot failure, see 
+https://github.com/rear/rear/issues/3189 
+Show initrd size in MiB (not in bytes) to the user. 
+Added user info messages to consider things like 
+REAR_INITRD_COMPRESSION='lzma' 
+MODULES=('loaded_modules') 
+FIRMWARE_FILES=('no') 
+and COPY_AS_IS_EXCLUDE_TSM in case of BACKUP=TSM 
+```
+&nbsp;
+```
+Fix version test in udev start by desupporting systemd < 190  (#3239)
+```
+&nbsp;
+```
+Set RECOVERY_MODE also in PORTABLE mode (#3228) :
+In sbin/rear set RECOVERY_MODE also in PORTABLE mode, 
+because the PORTABLE mode is meant to be used only 
+to run 'rear recover' within a foreign rescue system 
+see https://github.com/rear/rear/pull/3206#issuecomment-2122159018 
+and https://github.com/rear/rear/pull/3206#issuecomment-2122173021
+```
+&nbsp;
+```
+Update 400_save_directories.sh (#3232) :
+In prep/default/400_save_directories.sh 
+dirty hack to fix 
+https://github.com/rear/rear/issues/3222 
+for now until a proper solution is found, cf. 
+https://github.com/rear/rear/pull/3223
+```
+&nbsp;
+```
+In 400_create_include_exclude_files.sh fixed regression of pull request 3221 :
+In backup/NETFS/default/400_create_include_exclude_files.sh 
+fixed a regression of 
+https://github.com/rear/rear/pull/3221 
+that errors out in case of 
+rear -C something_else_backup mkbackuponly 
+when not the basic system but only something else 
+should be backed up as documented in 
+doc/user-guide/11-multiple-backups.adoc 
+see https://github.com/rear/rear/pull/3221#issuecomment-2129240645
+```
+&nbsp;
+```
+In sbin/rear make it clear when ReaR's TMP_DIR is used (#3225) :
+In usr/sbin/rear make it more clear 
+in a comment and in DebugPrint messages 
+when ReaR's TMP_DIR gets used 
+(in contrast to the system's TMPDIR), 
+see https://github.com/rear/rear/pull/3225
+```
+&nbsp;
+```
+Overhauled 400_create_include_exclude_files.sh (#3221) :
+Overhauled backup/NETFS/default/400_create_include_exclude_files.sh 
+* Now do first backup the mounted filesystems to backup '/' first 
+  so the basic system files get stored first in the backup and 
+  then backup what is specified in BACKUP_PROG_INCLUDE 
+  see https://github.com/rear/rear/pull/3177#issuecomment-1985926458 
+  and https://github.com/rear/rear/issues/3217#issue-2277985295 
+* Report suspicious cases as LogPrintError to have the user at least informed. 
+* Remove duplicates in backup-[in/ex]clude.txt but keep the ordering 
+  to avoid possibly unwanted and unexpected subtle consequences 
+  see https://github.com/rear/rear/pull/3175#issuecomment-1985382738 
+* Verify that at least '/' is in backup-include.txt 
+  see https://github.com/rear/rear/issues/3217 
+* Redirect stdout into files exactly at the command where needed 
+  instead of more global redirections, cf. "horrible coding style" 
+  in https://github.com/rear/rear/pull/3175#issuecomment-2109554865 
+Update backup/NETFS/default/500_make_backup.sh 
+* In backup/NETFS/default/500_make_backup.sh 
+  unique_unsorted is no longer needed because 
+  backup-include.txt is already without duplicates 
+  because unique_unsorted is now called in 
+  backup/NETFS/default/400_create_include_exclude_files.sh 
+```
+&nbsp;
+```
+change find backup procedure for Veeam V12.1 and later (#3214) :
+Running rear recover on different hardware will not show the backups of the original system due to the way 
+how Veeam registers the rescue system as a new client (under the same name, but with different ID). 
+This change handles this situation by searching for all backups for HOSTNAME and selecting the newest one. 
+Searching for HOSTNAME, which is guaranteed to be a short machine name, also to matches the fqdn
+in case the system is registered in Veeam under the fqdn instead of the short machine name.
+```
+&nbsp;
+```
+enable default ramdisk if not set to satisfy Veeam 12.1ff requirements (#3216) :
+Closes #3213
+```
+&nbsp;
+```
+default.conf example for COPY_AS_IS_EXCLUDE_TSM (#3212) :
+In default.conf explain how one could reduce 
+the size of the ReaR recovery system initrd 
+in particular on POWER architecture 
+via COPY_AS_IS_TSM and alternatively 
+via COPY_AS_IS_EXCLUDE_TSM, see 
+https://github.com/rear/rear/issues/3189 
+and describe the about 123 MiB initrd size limit on POWER 
+(128 MiB minus about 4 MiB for additional prep boot data), see 
+https://github.com/rear/rear/pull/3212#issuecomment-2092481874 
+Also tell about generic methods to reduce the size of the initrd 
+like MODULES=( 'loaded_modules' ) 
+and REAR_INITRD_COMPRESSION="lzma" 
+and mention that on POWER by default 
+FIRMWARE_FILES=( 'no' ) is used. 
+```
+&nbsp;
+```
+Merge pull request #3182 :
+#3067 use exit code of nc to check BACULA directory availability
+#3082 improved the way to grab the BACULA_DIRECTOR and BACULA_CLIENT
+```
+&nbsp;
+```
+Better describe OUTPUT_PREFIX and NETFS_PREFIX (#3204) :
+In default.conf better descriptions 
+for OUTPUT_PREFIX and NETFS_PREFIX 
+(OUTPUT_PREFIX was not at all described) 
+plus explanation how OUTPUT_PREFIX and NETFS_PREFIX 
+belong to each other for the usual case 
+OUTPUT=ISO and BACKUP=NETFS 
+and made it explicit that by default 
+NETFS_PREFIX="$OUTPUT_PREFIX" 
+to get backup.tar.gz and ISO image stored 
+at the same place.
+```
+&nbsp;
+```
+Add veeam support (#3150) :
+Initial VEEAM Bare Metal Recovery integration 
+Register the Veeam Linux Agent to Veeam VBRServer with Role of Veeam Restore Operator 
+Query latest Fullbackup, mount and copy it to the original restored operating system disks 
+``` 
+&nbsp;
+```
+Implement portable mode --portable and OUTPUT=PORTABLE
+```
+&nbsp;
+```
+New unique_unsorted() function (#3177) :
+In lib/global-functions.sh added a 
+new unique_unsorted() function 
+that outputs lines in a file or from STDIN 
+without subsequent duplicate lines 
+which keeps the ordering of the lines, see 
+https://github.com/rear/rear/pull/3177 
+In backup/NETFS/default/500_make_backup.sh use 
+unique_unsorted $TMP_DIR/backup-include.txt 
+to ignore duplicate arguments provided 
+to 'tar' and 'rsync' what should be archived 
+to avoid that 'tar' and 'rsync' archive 
+exact same things multiple times 
+which needlessly increases backup time and 
+in case of 'tar' the backup archive size and 
+storage space and backup restore time, cf. 
+https://github.com/rear/rear/pull/3175#issuecomment-1985306750 
+``` 
+&nbsp;
+```
+move all /var/run to /run directories in skel :
+Fixing b838a352136811900511a209d06c809ce552e636
+```
+&nbsp;
+```
+Add OS version mappings for RHEL 8 and RHEL 9 Remember MASTER version
+and combinations so that RHEL 9.3 will be mapped to Fedora/9
+``` 
+&nbsp;
+```
+Check recover mode before applying remote update Remove double check for recovery system :
+Fixes #3198
+```
+&nbsp;
+```
+change /var/run to be a symlink to /run accommodating current systemd requirements and FHS recommendation :
+fixes #3197
+maybe also fixes #3139
+``` 
+&nbsp;
+```
+Set GRUB2_IMAGE_FORMAT correctly in prep/Linux-i386/330_set_efi_arch.sh (#3192) :
+In prep/Linux-i386/330_set_efi_arch.sh 
+set GRUB2_IMAGE_FORMAT=i386-efi in case of i686|i586|i386 
+and set GRUB2_IMAGE_FORMAT=x86_64-efi in case of x86_64 
+to fix https://github.com/rear/rear/issues/3191 
+and https://github.com/rear/rear/issues/3195 
+Additionally describe current GRUB2_IMAGE_FORMAT usage 
+only in case of EFI so that currently it does not matter 
+when GRUB2_IMAGE_FORMAT is set to a value for EFI systems 
+also on BIOS systems, cf. 
+https://github.com/rear/rear/issues/3191#issuecomment-2036618057 
+``` 
+&nbsp;
+```
+Set TMPDIR to ReaR's TMP_DIR for programs that are called by ReaR :
+In usr/sbin/rear set TMPDIR to ReaR's TMP_DIR (within BUILD_DIR) 
+(except in RECOVERY_MODE to avoid failures in "chroot /mnt/local"). 
+This ensures that also for programs that are called by ReaR 
+ReaR will clean up all temporary stuff carefully and completely 
+via the function cleanup_build_area_and_end_program() and 
+it ensures that temporary files from programs that are called by ReaR 
+are sufficiently safe against unwanted access by non-root users 
+via 'mktemp -d' where BUILD_DIR and implicitly TMP_DIR=$BUILD_DIR/tmp 
+has permissions only for root but none for the group or others, 
+see https://github.com/rear/rear/issues/3167 
+Furthermore added the changes from 
+https://github.com/rear/rear/pull/3181 
+to fix https://github.com/rear/rear/issues/3180 
+which is also about BUILD_DIR / TMPDIR related code. 
+```
+&nbsp;
+```
+Merge pull request #3183 :
+Stale NFS detection in a very early stage #3109
+``` 
+&nbsp;
+```
+Merge pull request #3176 :
+skip btrfs subvolumes when detecting ESP partitions :
+The idea is to find all direct partitions that contain the ESP
+mount point and to skip all other transitive `fs:` dependencies.
+The `diskdeps.conf` file contains following entries on default Fedora
+installations (the list was shortened to only the relevant ones):
+ /dev/vda1 /dev/vda
+ /dev/vda4 /dev/vda
+ /dev/vda5 /dev/vda
+ fs:/boot/efi /dev/vda1
+ fs:/boot/efi fs:/boot
+ fs:/boot/efi fs:/
+ fs:/boot/efi btrfsmountedsubvol:/
+ fs:/boot /dev/vda4
+ fs:/boot fs:/
+ fs:/boot btrfsmountedsubvol:/
+ fs:/ /dev/vda5
+ btrfsmountedsubvol:/ /dev/vda5
+The ESP partition is only on `/dev/vda1`.  However, the `find_partition` call
+was not taking into account the need to skip mounted btrfs subvolumes as well.
+Therefore, `/dev/vda5` was listed as an ESP partition as well.
+This change makes sure that only direct ESP partitions are listed and
+fixes a bug where ReaR would create broken BootXXXX entries which point to
+completely unrelated partitions.
+```
+&nbsp;
+```
+docs: document booting of ReaR rescue initramfs on s390/s390x (#3158) :
+In doc/user-guide/04-scenarios.adoc 
+document booting of ReaR rescue initramfs on s390/s390x, see the related 
+https://github.com/rear/rear/issues/3149#issuecomment-1943375764
+```
+&nbsp;
+```
+Allow 'shell' workflow in recovery system :
+Add 'shell' to the workflows that are allowed 
+to be run from within the ReaR recovery system 
+because it can be useful for special cases, cf. 
+https://github.com/rear/rear/issues/3170#issuecomment-1981222992
+``` 
+&nbsp;
+```
+Update 04-scenarios.adoc :
+In doc/user-guide/04-scenarios.adoc 
+removed parts that mention 'udev' 
+from the section about USB devices, cf. 
+https://github.com/rear/rear/pull/3103#issuecomment-1973785249 
+and also removed some other parts there 
+which are outdated, could be misleading, 
+or are questionable or discursive 
+to make the text simpler and more to the point
+```
+&nbsp;
+```
+Fix some of the OS detection issues (#3149) :
+Delete init/default/005_verify_os_conf.sh - reasoning: 
+The generation of the /etc/rear/os.conf file is permanent. 
+Once it is created, it won't be regenerated unless it is manually removed. 
+Therefore, it will contain incorrect values if ReaR detects them incorrectly 
+like in https://github.com/rear/rear/issues/3149#issue-2125066459 
+and/or it will contain stale information after major version system upgrades, 
+see also https://github.com/rear/rear/issues/3149#issuecomment-1964290116 
+Furthermore in lib/config-functions.sh in SetOSVendorAndVersion() 
+fix the collection of VERSION_ID from /etc/os-release because 
+the code had falsely assumed that the VERSION_ID value 
+is enclosed in quotation marks which is false on Fedora, 
+see https://github.com/rear/rear/pull/3165 and the related 
+https://github.com/rear/rear/issues/3149#issuecomment-1964290116
+``` 
+&nbsp;
+```
+Replace the OUTPUT=IPL with equivalent OUTPUT=RAMDISK (#3153) :
+The initial PR with s390 support in ReaR introduced 
+undocumented OUTPUT=IPL which is redundant because 
+it does the same thing as the documented OUTPUT=RAMDISK. 
+This commit removes the IPL directory sub-tree and introduces 
+a fallback that replaces OUTPUT=IPL with OUTPUT=RAMDISK 
+during the prep phase with a deprecation warning, 
+see https://github.com/rear/rear/pull/3153 and the related 
+https://github.com/rear/rear/issues/3149#issuecomment-1941620475
+```
+&nbsp;
+```
+Merge pull request #3163 :
+Error out if TMPDIR is set in user config :
+Setting TMPDIR in {site,local}.conf has not worked since
+0022063 (PR #2633), as discussed in #2654.
+```
+&nbsp;
+```
+Update 03-configuration.adoc :
+In doc/user-guide/03-configuration.adoc 
+removed the outdated and obsolete part about TMPDIR=/bigdisk 
+because since the default is /var/tmp there is enough space 
+for things like a big ISO image
+```
+&nbsp;
+```
+Update rescue-and-backup-on-same-ISO-image-example.conf :
+In conf/examples/rescue-and-backup-on-same-ISO-image-example.conf 
+removed wrong TMPDIR=/mnt2/tmp 
+that is no longer needed since the default is /var/tmp which has enough space, cf. 
+https://github.com/rear/rear/pull/3163#issuecomment-1965886579
+```
+&nbsp;
+```
+Use dracut by default in SUSE 550_rebuild_initramfs.sh (#3155) :
+Overhauled finalize/SUSE_LINUX/i386/550_rebuild_initramfs.sh 
+Now it uses dracut by default and mkinitrd as fallback 
+see https://github.com/rear/rear/issues/3152 
+Additionally improved the user messages (in particular the warnings) 
+to make it more clear that the point is to decide if the recreated system 
+will boot with the initrd 'as is' from the backup restore, 
+cf. https://github.com/rear/rear/issues/3162 
+Furthermore removed the whole INITRD_MODULES code 
+because INITRD_MODULES is not used and 
+/etc/sysconfig/kernel does no longer exist since SLES12 
+so the INITRD_MODULES code is dead code.
+```
+&nbsp;
+```
+ErrorIfDeprecated when 'gpt_sync_mbr' is used (#3159) :
+In layout/save/default/950_verify_disklayout_file.sh 
+ErrorIfDeprecated when 'gpt_sync_mbr' is used 
+see https://github.com/rear/rear/issues/3148
+```
+&nbsp;
+```
+Fix issue 3151: missing .vimrc and overhauled 130_create_dotfiles.sh (#3154) :
+Create an empty 
+usr/share/rear/skel/default/root/.vimrc 
+to fix https://github.com/rear/rear/issues/3151 
+Furthermore in build/GNU/Linux/130_create_dotfiles.sh 
+dynamically generate .bash_history entries depending on 
+whether or not 'nano' and 'vi' are available, see 
+https://github.com/rear/rear/issues/3151#issuecomment-1941544530 
+and see https://github.com/rear/rear/pull/1306 regarding nano 
+and https://github.com/rear/rear/issues/1298 when vi is not available. 
+```
+&nbsp;
+```
+Merge pull request #3145 :
+Support saving and restoring hybrid BIOS/UEFI bootloader setup and clean up bootloader detection.
+Abort if BOOTLOADER=GRUB and GRUB 2 is installed:
+BOOTLOADER = "GRUB" used to mean GRUB 2 if GRUB 2 was installed and GRUB
+Legacy if not. With the improved GRUB detection, we don't want this
+ambiguity any more. "GRUB" should mean GRUB Legacy and GRUB2 should mean
+GRUB 2.
+Warn when using BOOTLOADER = GRUB:
+Update comments for the code that detects if the "GRUB" value for
+BOOTLOADER actually means GRUB2 and emit warnings (using LogPrintError)
+about "GRUB" value to mean GRUB 2 being deprecated and the GRUB Legacy
+support itself being deprecated as well.
+Do not error out in this situation as erroring out near the end of
+recovery only to inform about a deprecated setting would be unhelpful.
+Check that disk is suitable before installing GRUB:
+Not all disks are suitable for GRUB installation into their MBR. For
+example, GPT-partitioned disks need a BIOS boot partition
+( https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html )
+and attempting to install GRUB on disks without it makes grub-install
+error out. This is shown in the recovery log on a BIOS system with
+GPT-partitioned disks, where /dev/vdb and the following disks are part
+of the / volume, but don't have a BIOS boot partition.
+To fix that, introduce function is_disk_grub_candidate and use it before
+installing GRUB/GRUB2 on the disk. This functions currently performs the
+check for the BIOS boot partition on GPT-formatted disks and the check
+that the disk is not a LVM PV.
+Support BOOTLOADER=GRUB with UEFI:
+This will happen with hybrid boot: BOOTLOADER=GRUB indicates that there
+is the BIOS version of GRUB installed and at the same time,
+USING_UEFI_BOOTLOADER=1 indicates theat there is also an EFI bootloader.
+Note that it is now perfectly legal to have USING_UEFI_BOOTLOADER=1
+and BOOTLOADER neither EFI nor GRUB2-EFI nor ELILO. This will happen
+with hybrid BIOS/UEFI booting: BOOTLOADER will be detected as GRUB2, but
+USING_UEFI_BOOTLOADER=1.
+BOOTLOADER=EFI is now intended as a fallback when no other bootloader is
+found to avoid an empty BOOTLOADER value.
+Detect GRUB2 when saving layout:
+We used to distinguish between GRUB and GRUB2 when reinstalling the
+bootloader. This meant that the saved bootloader was wrong: GRUB for
+GRUB2. Detect GRUB2 earlier, already at the moment when we guess the
+bootloader, and save the correct value.
+This should help with the problem reported in PR #3128 (misdetection of
+GRUB2 as GRUB on any non-SUSE distro).
+```
+&nbsp;
+```
+OUTPUT=PXE: Support downloading kernel and initrd by HTTP (#3100) :
+For OUTPUT=PXE added support for downloading kernel and initrd by HTTP. 
+Details are described in default.conf. The main changes are: 
+PXE_TFTP_URL: deprecated, use PXE_TFTP_UPLOAD_URL 
+PXE_HTTP_URL: deprecated, use PXE_HTTP_DOWNLOAD_URL 
+PXE_TFTP_UPLOAD_URL: where the TFTP files shall be put 
+PXE_HTTP_UPLOAD_URL: where the HTTP files shall be put 
+PXE_HTTP_DOWNLOAD_URL: where the HTTP files shall be downloaded from 
+new prep/PXE/default/010_PXE_check.sh (deprecation warnings) 
+new output/PXE/default/801_copy_to_http.sh 
+see https://github.com/rear/rear/pull/3100 
+```
+&nbsp;
+```
+Merge pull request #3136 :
+Include GRUB tools unconditionally and don't create $VAR_DIR/recovery/bootdisk in prep.
+Do not detect GRUB before including GRUB tools:
+When there was a file matching grub* in /boot (e.g. /boot/grub2FAIL),
+the code got confused by the glob pattern intended to match /boot/grub
+or /boot/grub2 and subsequently the rest of the script was skipped, as
+grubdir got assigned something like "/boot/grub2 /boot/grub2FAIL", which
+does not exist, so grubdir was set to /boot/grub, which does not exist
+either, and grub-probe fails.
+As a result, the GRUB tools were not included in the recovery image.
+```
+&nbsp;
+```
+Merge pull request #3138 :
+Add support for new backup software Dell PowerProtect Data Manager.
+Fully automated restore if lockbox works.
+Ask admin to "set lockbox" and wait for working lockbox.
+Point in time restore.
+Restore EFI System Partition from ReaR rescue image if needed.
+Modularise LD_LIBRARY_PATH handling for third-party backup tools.
+Ensure minimum Bash version: Fixes #2941
+Support automated keyboard configuration on systems with setupcon: Fixes #3133
+Fix module names with underscore bug: Fixes #3137
+Support Bash assoc arrays and improve rear shell.
+```
+&nbsp;
+```
+Let is_write_protected() report devices without device node as not write protected (#3091) :
+In lib/write-protect-functions.sh 
+let the is_write_protected function report candidate devices 
+without device node as not write protected 
+because not all /sys/block devices have a "dev" file 
+e.g. /sys/block/nvme0c0n1 has no /dev/nvme0c0n1 device node 
+see https://github.com/rear/rear/issues/3085 
+Because the is_write_protected function is meant to identify 
+write-protected disks and partitions, only candidate devices 
+with a device node are considered for write protection. 
+Additionally completely overhauled lib/write-protect-functions.sh 
+which now contains only the is_write_protected function 
+(the only one intended to be called by other scripts). 
+The former helper functions are not needed as functions because 
+all what happens is a single straightforward sequence of actions. 
+```
+&nbsp;
+```
+Merge pull request #3131 :
+Improve the description of AUTOEXCLUDE_PATH:
+Separate the example of AUTOEXCLUDE_PATH handling from the treatment of
+/tmp. /tmp is a bad example, because it is handled specially by the
+default setting of another config variable (BACKUP_PROG_EXCLUDE).
+Use /mnt as an example for AUTOEXCLUDE_PATH instead and make clear that
+AUTOEXCLUDE_PATH=( /tmp ) does not exclude files under /tmp from the
+backup and an independent setting is used for that purpose.
+```
+&nbsp;
+```
+Make initrd accessible only by root (#3123) :
+In pack/GNU/Linux/900_create_initramfs.sh call 
+chmod 0600 "$TMP_DIR/$REAR_INITRD_FILENAME" 
+to let only 'root' access the ReaR initrd because 
+the ReaR recovery system in the initrd can contain secrets 
+(not by default but when certain things are explicitly 
+configured by the user like SSH keys without passphrase) 
+see https://github.com/rear/rear/issues/3122 
+and https://bugzilla.opensuse.org/show_bug.cgi?id=1218728 
+```
+&nbsp;
+```
+Merge pull request #3124 :
+Take AUTOEXCLUDE_PATH into account in layout doc:
+Since PR #2261, /media is included in the default AUTOEXCLUDE_PATH. This
+means that a filesystem mounted on a directory like /media/backup will
+not be included in the layout. This makes the example invalid, as it
+describes how a filesystem mounted under /media/backup will be included
+in the layout and what manual steps are needed to exclude it.
+To preserve the validity of the example, change all paths in the example
+from /media/backup to /backup.
+Take this opportunity to also describe the AUTOEXCLUDE_PATH variable
+among other autoexclusions.
+```
+&nbsp;
+```
+More clear AUTOEXCLUDE_PATH description in default.conf :
+In default.conf make it more clear how the defaults for 
+AUTOEXCLUDE_PATH and BACKUP_PROG_EXCLUDE interact 
+when /tmp is a separated filesystem, see 
+https://github.com/rear/rear/pull/2261#discussion_r1444282008
+```
+&nbsp;
+```
+Set 'dmesg -n [4-6]' in new 'setup' script 007_set_dmesg_level.sh (#3113) :
+The new 'setup' stage script setup/default/007_set_dmesg_level.sh 
+sets 'dmesg -n [4-6]' for the worksflows 
+recover layoutonly restoreonly finalizeonly mountonly 
+depending on verbose and debug modes for ReaR. 
+This is related to https://github.com/rear/rear/pull/3108 
+```
+&nbsp;
+```
+Set 'dmesg -n 5' in etc/scripts/boot (#3108) :
+In [skel/default]/etc/scripts/boot set 'dmesg -n 5'
+to limit console logging for 'dmesg' messages to level 5 
+so that kernel error and warning messages appear 
+(intermixed with ReaR messages) on the console 
+so that the user can notice when things go wrong 
+in kernel area which helps to understand problems, 
+see the related issue 
+https://github.com/rear/rear/issues/3107 
+```
+&nbsp;
+```
+Fixed 800_enforce_usb_output.sh (#3110) :
+Overhauled build/USB/default/800_enforce_usb_output.sh 
+Now LogPrintError infos and BugError when OUTPUT=USB 
+got somehow modified in $ROOTFS_DIR/etc/rear/local.conf 
+plus explanatory comments in the code. 
+Triggered by https://github.com/rear/rear/pull/3103 
+and replacing this by a new pull request. 
+```
+&nbsp;
+```
+Error() instead of BugError() in 850_make_USB_bootable.sh (#3104) :
+In output/USB/Linux-i386/850_make_USB_bootable.sh replaced the 
+BugError "Filesystem ... on $RAW_USB_DEVICE could not be found" 
+with explanatory LogPrintError plus Error what the actual reason is, 
+similar as in the related https://github.com/rear/rear/pull/3102 
+because in most cases this is not a bug in ReaR but an error 
+like a user configuration error for OUTPUT=USB e.g. 
+see https://github.com/rear/rear/issues/1571 
+and https://github.com/rear/rear/issues/3098 
+Use first LogPrintError for an additional info message 
+and then Error for the actual error message. 
+In those LogPrintError plus Error message pairs 
+show both $BUILD_DIR/outputfs and $RAW_USB_DEVICE 
+because $BUILD_DIR/outputfs is a meaningless directory 
+of the form /var/tmp/rear.XXXXXXXXXXXXXXX/outputfs 
+so $RAW_USB_DEVICE provides some context to the user 
+that those two messages are about his USB or disk device. 
+```
+&nbsp;
+```
+Merge pull request #3105 :
+Do not touch $BUILD_DIR/outputfs :
+Remove a forgotten mkdir -p $BUILD_DIR/outputfs/$NETFS_PREFIX command in
+restore/NETFS/default/400_restore_backup.sh.
+Should have been deleted in 7dda23d708854db2d09db1308c159aea667763c0
+with other code that touched the backup location.
+For the YUM method, the same change was already done in 6b9d8d8508183144f56eec92b828ae037c03a6f7
+```
+&nbsp;
+```
+Merge pull request #3102 :
+OUTPUT=USB: add a check that OUTPUT_URL is mounted :
+If OUTPUT_URL uses the file:// scheme, ReaR aborts with a weird error
+message "BUG: Filesystem where the booting related files are on ...
+could not be found" in output/USB/Linux-i386/850_make_USB_bootable.sh.
+```
+&nbsp;
+```
+Tell WHY in DebugPrint in 320_autoexclude.sh :
+In layout/save/default/320_autoexclude.sh tell WHY in DebugPrint message: 
+Before (e.g. when something is mounted below tmp): 
+"Automatically excluding filesystem /tmp/sdb" 
+Now: 
+"Automatically excluding filesystem /tmp/sdb (belongs to /tmp in AUTOEXCLUDE_PATH)" 
+Noticed while reproducing https://github.com/rear/rear/issues/3101
+```
+&nbsp;
+```
+New RECOVERY_COMMANDS array (#3089) :
+New RECOVERY_COMMANDS array (plus RECOVERY_COMMANDS_LABEL) 
+to specify the "rear recover" commands which are automatically called 
+after the ReaR recovery system has started up to recreate the system 
+in 'auto_recover'/'automatic' or 'unattended' mode. 
+By default "rear recover" is called (which was hardcoded before). 
+See https://github.com/rear/rear/pull/3070#discussion_r1397363473 
+Additionally in skel/default/etc/scripts/system-setup call bash 'read' 
+with a 'timeout' (normally 30 seconds or 3 seconds in unattended mode) 
+to automatically proceed (in particular in unattended mode), 
+cf. https://github.com/rear/rear/issues/1366 
+```
+&nbsp;
+```
+Merge pull request #3070 :
+New REBOOT_COMMANDS config array variable: 
+In skel/default/etc/scripts/system-setup 
+replaced the hardcoded 'reboot' 
+by using a REBOOT_COMMANDS array 
+(plus REBOOT_COMMANDS_LABEL string) 
+so the user could specify a alternative command 
+like 'shutdown' or 'poweroff' 
+see https://github.com/rear/rear/issues/3068 
+or a sequence of commands if needed 
+(plus a label that is shown to the user). 
+Additionally in skel/default/etc/scripts/system-setup: 
+Use USER_INPUT_INTERRUPT_TIMEOUT 
+and USER_INPUT_UNATTENDED_TIMEOUT 
+instead of hardcoded 'sleep' timeout values 
+to speed up things in 'unattended_recovery' mode. 
+Show non-zero exit codes to the user 
+when sourcing config files failed. 
+Abort when /usr/share/rear/conf/default.conf 
+does not exist (or is empty). 
+Set SECRET_OUTPUT_DEV="null" 
+also for sourcing other config files (e.g. local.conf), cf. 
+https://github.com/rear/rear/commit/9629b29dbbb73efb6229c4bfc509d1fcb70b29e3 
+```
+&nbsp;
+```
+Merge pull request #3079 :
+Do not mount /sys if already mounted:
+Newer versions of systemd (starting with Fedora 39) seem to mount /sys
+themselves. Mounting it again leads to errors on the recovery system
+startup (startup scripts failing with status=219/CGROUP ), see
+https://github.com/rear/rear/issues/3017.
+Do the same for the other system mountpoints like /proc, /dev, /dev/pts.
+Not sure if they suffer from the same problem, but they probably could.
+```
+&nbsp;
+```
+Merge pull request #3078 :
+Mention xorrisofs when no ISO image tool is found:
+xorrisofs is supposed to be the preferred method, so mention it first
+among the suggested tools that the user can install to produce an ISO
+image if none is found.
+```
+&nbsp;
+```
+Merge pull request #3073 :
+Resolve libs for executable links in COPY_AS_IS :
+Do not skip symbolic links when adding libraries required by executables
+in COPY_AS_IS. The symlink targets will be copied later by
+build/default/490_fix_broken_links.sh.  We thus need library
+dependencies for symlinked executables just like for normal executables
+and build/default/490_fix_broken_links.sh does not perform library
+dependency scan, so we need to do it at the same place as for normal
+executables (in build/GNU/Linux/100_copy_as_is.sh). Otherwise it can
+happen that we add a (broken) symlink via COPY_AS_IS, the actual
+executable is then added by build/default/490_fix_broken_links.sh, but
+without its libraries, and "rear mkrescue" then fails because required
+libraries are missing. Happens for example with
+/usr/lib/systemd/systemd-sysv-install, which is a symlink to
+/bin/chkconfig and gets added to COPY_AS_IS in
+prep/GNU/Linux/280_include_systemd.sh.
+Gets rid of one exception for symlinks, which looks good in any case
+(shorter and simpler code).
+```
+&nbsp;
+```
+Merge pull request #3072 :
+New USER_INPUT_UNATTENDED_TIMEOUT config variable 
+to specify the timeout in seconds (by default 3) 
+for how long UserInput() waits for user input 
+when ReaR is run in 'unattended' or 'non-interactive' mode. 
+```
+&nbsp;
+```
+Update default.conf :
+In default.conf describe that 
+with MIGRATION_MODE='TRUE' ('TRUE' in uppercase letters) 
+one can enforce MIGRATION_MODE also when 
+"rear recover" is run in 'unattended' or 'non-interactive' mode.
+```
+&nbsp;
+```
+Update 250_compare_disks.sh :
+In layout/prepare/default/250_compare_disks.sh 
+use USER_INPUT_INTERRUPT_TIMEOUT (default 30) 
+instead of USER_INPUT_TIMEOUT (default 300) 
+because USER_INPUT_INTERRUPT_TIMEOUT matches better 
+the intent of the user confirmation dialog 
+when "Disk configuration looks identical"
+```
+&nbsp;
+```
+Merge pull request #3061 :
+Save LVM pool metadata volume size in disk layout:
+Instead of letting LVM use the default pool metadata volume size when
+restoring a layout with thin pools, use the size from the original
+system. The pool metadata size will be saved in disklayout.conf as the
+new key "poolmetadatasize" on the thin pool LV.
+This makes the layout of the recovered system closer to the original
+system.
+Prevents some cases of recovery failures during layout restoration: if
+the original system used a non-default (in particular, smaller) metadata
+volume size, and the space in the VG was fully used, there would not be
+enough space in the VG for recovery of all LVs (as layout restoration
+would create a larger pool metadata size than before and if restoring to
+disks of the same size, the space will be missing elsewhere).
+```
+&nbsp;
+```
+Merge pull request #3058 :
+Skip useless xfs mount options when mounting during recovery:
+In the case of XFS, some of the mount options can be harmful for
+mounting the filesystem during layout restoration:
+The logbsize=... mount option is a purely performance/memory usage
+optimization option, which can lead to mount failures, because it must
+be an integer multiple of the log stripe unit and the log stripe unit
+can be different in the recreated filesystem from the original
+filesystem (for example when using MKFS_XFS_OPTIONS, or in some exotic
+situations involving an old filesystem, see GitHub issue #2777 ). If
+logbsize is not an integer multiple of the log stripe unit, mount fails
+with the warning "XFS (...): logbuf size must be greater than or equal
+to log stripe size" in the kernel log (and a confusing error message
+"mount: ...: wrong fs type, bad option, bad superblock on ..., missing
+codepage or helper program, or other error." from the mount command),
+causing the layout restoration in the recovery process to fail.
+Wrong sunit/swidth can cause mount to fail as well, with this in the
+kernel log: "kernel: XFS (...): alignment check failed: sunit/swidth vs.
+agsize".
+Therefore, remove the logbsize=... and sunit=.../swidth=... from XFS
+mount options before mounting the file system.
+```
+&nbsp;
+```
+Update 450_check_BACULA_client_configured.sh :
+In prep/BACULA/default/450_check_BACULA_client_configured.sh 
+show the command or file name to the user if one is missing 
+to make it clear to the user what exactly is missing. 
+This enhancement was triggered by 
+https://github.com/rear/rear/issues/3060
+```
+&nbsp;
+```
+Merge pull request #2961 :
+For the automated serial console setup for the recovery system 
+use only the 'console=...' kernel arguments from the original system 
+which fixes https://github.com/rear/rear/issues/2843 
+and it means that no longer all "real serial devices" get 
+auto-enabled as serial consoles in the recovery system, see 
+https://github.com/rear/rear/pull/2749#issuecomment-1196650631 
+That new default behaviour is described in default.conf. 
+In particular prep/GNU/Linux/200_include_serial_console.sh 
+and lib/serial-functions.sh were overhauled which results 
+that rescue/GNU/Linux/400_use_serial_console.sh is obsolete. 
+```
+&nbsp;
+```
+Update 510_current_disk_usage.sh :
+In layout/save/GNU/Linux/510_current_disk_usage.sh 
+USB_DEVICE_FILESYSTEM_LABEL must not be empty, otherwise 
+readlink -f "/dev/disk/by-label/$USB_DEVICE_FILESYSTEM_LABEL" 
+would result '/dev/disk/by-label'
+```
+&nbsp;
+```
+Update 400_save_directories.sh :
+In prep/default/400_save_directories.sh 
+USB_DEVICE_FILESYSTEM_LABEL must not be empty, otherwise 
+grep -vE "this|that|$USB_DEVICE_FILESYSTEM_LABEL" 
+would output nothing at all.
+```
+&nbsp;
+```
+Merge pull request #3054 :
+Fail safe USB_DEVICE_BOOT_LABEL setting and fallback: 
+In output/USB/Linux-i386/300_create_grub.sh 
+check with "lsblk -no LABEL $RAW_USB_DEVICE" 
+if something with USB_DEVICE_BOOT_LABEL exists on the USB device 
+and if not try to use USB_DEVICE_FILESYSTEM_LABEL 
+if something with that label exists on the USB device 
+and if yes use that as USB_DEVICE_BOOT_LABEL, 
+otherwise error out
+```
+&nbsp;
+```
+Update default.conf :
+In default.conf better (more generic) description 
+of USB_DEVICE_FILESYSTEM_PERCENTAGE 
+that also takes a possible 'bios_grub' partition 
+and an optional boot partition into account.
+```
+&nbsp;
+```
+Merge pull request #3053 :
+Better description of BACKUP=RBME in default.conf - triggered by 
+https://github.com/rear/rear/issues/3050#issuecomment-1748197886
+```
+&nbsp;
+```
+Merge pull request #3047 :
+Skip invalid disk drives (zero sized, no media) when saving layout:
+Revert commit 0a1d634ed15500bb21f37ac1bbb11c8a4bb11545.
+We now skip disks with no data (like when there is no medium), so
+incomplete disk entries (without partition type) should not occur
+anymore. Restore the code that aborted when such disks were encountered.
+Incomplete entries should not be allowed to occur, as they could confuse
+the layout restoration code. Moreover, the layout restoration wipes
+all disks in the layout, so if during layout restoration there happens
+to be a medium in the drive that was empty during layout save, the data
+on the medium would get overwritten and lost. And if there is not medium,
+the layout recreation script would fail.
+See the discussion at https://github.com/rear/rear/issues/2958#issuecomment-1479588829
+Validate disk when saving layout :
+Introduce checks for disk usability beyond validating the device name.
+In some cases the device name may be valid, but there are no data,
+typically because it is a drive with removable media and there is no
+medium in the tray. Happens typically with card (e.g. SD card) readers
+with empty slot.
+This is a normal occurrence, so do not Error out, only display a message
+and skip the device.
+```
+&nbsp;
+```
+Merge pull request #3043 :
+Remove the lvmdevices file at the end of recovery :
+The file /etc/lvm/devices/system.devices restricts LVM to disks with
+given (hardware) IDs (serial numbers, WWNs). See lvmdevices(8).
+Unfortunately, when restoring to different disks than in the original
+system, it will mean that LVM is broken in the recovered system (it
+won't find any disks).  Therefore it is safer to remove the file to
+force the old behavior where LVM scans all disks. This used to be the
+LVM default (use_devicesfile=0).
+```
+&nbsp;
+```
+Merge pull request #3038 :
+In the DoExitTasks function skip 'sleep 3' 
+when all went well and DoExitTasks is called at normal exit 
+to avoid needless 3 seconds delay of normal end of program.
+```
+&nbsp;
+```
+Merge pull request #3037 :
+Avoid multiple 'set -x' messages for one message output function call (like LogPrint): 
+In lib/_input-output-functions.sh use '2>>/dev/$DISPENSABLE_OUTPUT_DEV' 
+for all functions that output messages (print on the terminal or log something) 
+to avoid that in debugscript mode 'set -x' debug messages 
+about message output functions appear more than once in the log file. 
+E.g. for "LogPrint 'text'" such 'set -x' debug messages appeared three times: 
+The first one for the initial "LogPrint 'text'" call plus two more 
+for the subsequently resulting "Log 'text'" and "echo 'text" calls. 
+Now only one 'set -x' debug message appears in the log: 
+Only the first one for the initial message output function call.
+```
+&nbsp;
+```
+Merge pull request #3039 :
+In doc/rear.8.adoc describe the new -e/--expose-secrets option 
+see https://github.com/rear/rear/pull/3006 
+and https://github.com/rear/rear/issues/2967 
+Additionally a more exact description what the non-interactive mode does 
+and some general simplifications of other GLOBAL OPTIONS texts.
+```
+&nbsp;
+```
+Set SECRET_OUTPUT_DEV in etc/scripts/system-setup :
+In usr/share/rear/skel/default/etc/scripts/system-setup 
+set SECRET_OUTPUT_DEV="null" before sourcing default.conf 
+see https://github.com/rear/rear/pull/3034#issuecomment-1691609782
+```
+&nbsp;
+```
+Merge pull request #3036 :
+Overhauled init/default/998_dump_variables.sh 
+so that its intended functionality happens 
+only when explicitly requested by the user 
+by calling 'rear' with the 'expose-secrets' option 
+to avoid that possibly confidential values 
+are output into the log file by accident, see 
+https://github.com/rear/rear/issues/2967
+```
+&nbsp;
+```
+Merge pull request #3034 :
+Use '{ SECRET COMMAND ; } 2>>/dev/$SECRET_OUTPUT_DEV' 
+instead of '{ SECRET COMMAND ; } 2>/dev/null' 
+because '{ ... ; } 2>>/dev/$SECRET_OUTPUT_DEV' 
+makes debugging still possible for the user 
+by calling rear with the '--expose-secrets' option 
+and SECRET_OUTPUT_DEV makes it clear which redirections 
+are explicitly meant to hide secrets to distinguish them 
+from usual unwanted output discard via '2>/dev/null' 
+see https://github.com/rear/rear/pull/3006 
+and https://github.com/rear/rear/issues/2967 
+```
+&nbsp;
+```
+Merge pull request #3031 :
+Secure Boot support for OUTPUT=USB: 
+In output/USB/Linux-i386/100_create_efiboot.sh 
+added SECURE_BOOT_BOOTLOADER related code that is based 
+on the code in output/ISO/Linux-i386/250_populate_efibootimg.sh 
+with some adaptions to make it work within the existing USB code. 
+The basic idea for Secure Boot booting of the ReaR recovery system 
+is to "just copy" the (signed) EFI binaries of the Linux distribution 
+(shim*.efi and grub*.efi as first and second stage UEFI bootloaders) 
+instead of let ReaR make its own EFI binary via build_bootx86_efi() 
+see https://github.com/rear/rear/pull/3031
+```
+&nbsp;
+```
+Merge pull request #3030 :
+In format/USB/default/200_check_usb_layout.sh 
+error out if USB_DEVICE_FILESYSTEM is invalid 
+instead of silently using the default value 'ext3' 
+because it is clearer to abort for configuration errors 
+than silently "correcting" a users's specified value, 
+see https://github.com/rear/rear/issues/3029 
+```
+&nbsp;
+```
+Merge pull request #3025 :
+Fixed create_grub2_cfg function usage: 
+Introduced GRUB2_SET_ROOT_COMMAND config variable 
+in addition to the existing GRUB2_SEARCH_ROOT_COMMAND 
+to get consistency how GRUB2 sets and/or searches its 'root' device 
+and adapted the create_grub2_cfg function calls accordingly. 
+Furthermore enhanced some messages regarding Secure Boot setup.
+```
+&nbsp;
+```
+Merge pull request #3027 :
+In build/GNU/Linux/100_copy_as_is.sh 
+ensure to really get all COPY_AS_IS files copied by using 
+'tar ... -i' when extracting to avoid a false regular exit of 'tar' 
+in particular when padding zeroes get added when a file being read shrinks 
+because for 'tar' (without '-i') two consecutive 512-blocks of zeroes mean EOF, 
+cf. https://github.com/rear/rear/pull/3027
+```
+&nbsp;
+```
+Update 830_copy_kernel_initrd.sh :
+In output/USB/Linux-i386/830_copy_kernel_initrd.sh 
+make it clear in the log file that the log file on USB is unfinished 
+so when one is looking at such a log file on USB from another user 
+one gets not confused why things are missing (e.g. the 'backup' stage) in such a log file 
+cf. https://github.com/rear/rear/issues/3017#issuecomment-1620385835
+```
+&nbsp;
+```
+Merge pull request #3023 :
+In prep/SESAM/default/400_prep_sesam.sh 
+do no longer add SESAM_WORK_DIR to COPY_AS_IS_EXCLUDE. 
+After the SESAM excludes have been fixed 
+via https://github.com/rear/rear/pull/3019 
+tests with more recent sesam client versions have shown 
+that the service fails to start up during recovery image boot 
+due to missing semaphore files. Removing the sesam work directory 
+where those information is stored from the excludes solves this problem. 
+See https://github.com/rear/rear/issues/3018
+```
+&nbsp;
+```
+Merge pull request #3019 :
+In lib/sesam-functions.sh 
+fix default exclude paths for BACKUP=SESAM 
+because the exclude paths did contain a trailing '/' 
+so 'tar' did not match ('tar' is picky about exclude items) 
+and then things ended up in the ISO image, 
+see https://github.com/rear/rear/issues/3018
+```
+&nbsp;
+```
+Merge pull request #3006 :
+New --expose-secrets option plus SECRET_OUTPUT_DEV: 
+In sbin/rear added --expose-secrets option and SECRET_OUTPUT_DEV. 
+Script code usage example: 
+{ SECRET COMMAND ; } 2>>/dev/$SECRET_OUTPUT_DEV 
+In lib/_input-output-functions.s added LogSecret function. 
+Script code usage example: 
+{ LogSecret "secret text" || Log "public text" ; } 2>>/dev/$SECRET_OUTPUT_DEV 
+Both are requirements to solve 
+https://github.com/rear/rear/issues/2967 
+```
+&nbsp;
+```
+Merge pull request #2991 :
+ISO OUTPUT Improvements to filter RESULT_FILES transferred
+```
+&nbsp;
+```
+Merge pull request #2980 :
+SYSLINUX timeout is now a configuration item
+```
+&nbsp;
+```
+Merge pull request #2988 :
+Implement non-interactive mode to abort on repeated UserInput calls in the absence of user interaction.
+Add fully automated restore to REQUESTRESTORE, where ReaR waits for a signal file to appear.
+Mention experimental state of non-interactive mode in README.
+```
+&nbsp;
+```
+In layout/save/GNU/Linux/200_partition_layout.sh 
+also show the disk device in the 
+"Unsupported partition table" error message 
+to make it meaningful on systems with more than one disk.
+Add fallback wipefs command for CentOS 6.
+Add -f (force) option to wipefs command in 120_include_raid_code.sh
+```
+&nbsp;
+```
+Do not leak the SSH_ROOT_PASSWORD value into the log file: 
+In build/default/500_ssh_setup.sh 
+rescue/default/500_ssh.sh 
+restore/YUM/default/970_set_root_password.sh 
+restore/ZYPPER/default/970_set_root_password.sh 
+run commands that deal with SSH_ROOT_PASSWORD 
+in a confidential way via { confidential_command ; } 2>/dev/null 
+see https://github.com/rear/rear/issues/2967
+```
+&nbsp;
+```
+Do not leak the OPAL_PBA_DEBUG_PASSWORD value into the log file :
+In prep/OPALPBA/Linux-i386/001_configure_workflow.sh 
+run commands that deal with OPAL_PBA_DEBUG_PASSWORD 
+in a confidential way via { confidential_command ; } 2>/dev/null 
+see https://github.com/rear/rear/issues/2967
+```
+&nbsp;
+```
+Merge pull request #2985 :
+Do not leak the GALAXY11_PASSWORD value into the log file: 
+In verify/GALAXY11/default/420_login_to_galaxy_and_setup_environment.sh 
+run commands that deal with GALAXY11_PASSWORD 
+in a confidential way via { confidential_command ; } 2>/dev/null 
+see https://github.com/rear/rear/issues/2967
+```
+&nbsp;
+```
+Update 04-scenarios.adoc :
+In doc/user-guide/04-scenarios.adoc 
+explain that when a command like 
+export VAR='secret_value' 
+is run on the original system, then one must ensure 
+to not keep that command in a shell history file. 
+This is an addedum to 
+https://github.com/rear/rear/pull/2156 
+which was triggered by what was done in 
+https://github.com/rear/rear/pull/2982
+```
+&nbsp;
+```
+Update default.conf :
+In default.conf cleaned up all cases of variables for secret values 
+by having a generic explanatory comment at the beginning 
+(instead of several similar comments at each place) and 
+by setting such variables always via { VAR=... ; } 2>/dev/null 
+to mark them for us and our users that they are meant for secret values 
+and also to provide templates how to set such variables properly 
+in user config files (e.g. local.conf or site.conf).
+In default.conf increased the default USER_INPUT_INTERRUPT_TIMEOUT 
+from 10 seconds to 30 seconds because 10 seconds is far too little time 
+to read and understand the possibly unexpected UserInput() message 
+and then some more time to make a decision whether or not 
+the automated action is actually the right one.
+In default.conf make it clear that 
+BACKUP_PROG_ARCHIVE is the backup file basename for BACKUP=NETFS 
+but for BACKUP=RSYNC it is the backup log file basename and that 
+RSYNC_PREFIX is the destination prefix directory 
+where a 'backup' sub-directory will be created, see 
+https://github.com/rear/rear/issues/2978
+```
+&nbsp;
+```
+NFS4SERVER as new restore method (#2973) :
+Added new backup method NFS4SERVER for restore via NFSv4 export (restore only)
+Add ability to abort NFS4SERVER restore.
+```
+&nbsp;
+```
+Merge pull request #2878 :
+Exclusions for Veritas Cluster Filesystem, solving https://access.redhat.com/solutions/3214491 by default.
+```
+&nbsp;
+```
+Merge pull request #2963 :
+OBDR fixes for modern systems using hpsa driver:
+Add more details in comment why and how we need to better handle output from lsscsi.
+Previously we would search only on fixed character positions 2 4 6 8 in a line,
+which on some systems with larger nubmber of devices doesn't have to be correct.
+Search exactly only for 'cciss' and 'hpsa' modules. 
+We need ISO to be created already in /var/lib/rear/output/rear-${HOSTNAME}.iso,
+so add from ISO ../../ISO/Linux-i386/820_create_iso_image.sh.
+Subsequentlyt we'll need to rename writing of ISO to tape to later stage,
+so rename it from 810_write_image.sh to 840_write_image.sh.
+Refactor how we'll look for a device.
+In case of large number of connected devices f.x. [6:0:15:0] tape HP Ultrium 5-SCSI Y6PW /dev/st11
+devices might not be recognized properly.
+HP cciss driver was replaced by hpsa driver so consider it when checking tapes.
+```
+&nbsp;
+```
+Merge pull request #2965 :
+Add proper Python support / fix GALAXY11-related issues.
+Add Galaxy Home Dir to checklayout verification.
+Notice changes in GALAXY11 client to trigger recreation of rescue image.
+Use dynamically determined path where galaxy home dir is located.
+This is an example implementation for #2951 to run the complete prep stage
+for checklayout as the Galaxy client configuration is determined there.
+Include Python and dependencies.
+Handling symlinks for Python interpreter.
+Choose Python interpreter and stdlib only.
+Copy full site and dist packages as well.
+```
+&nbsp;
+```
+Update rear :
+In sbin/rear quoting is mandatory in test -d "$TMP_DIR" 
+otherwise 'test -d' falsely succeeds if $TMP_DIR is empty, cf. 
+https://github.com/rear/rear/issues/2966#issuecomment-1497825493
+```
+&nbsp;
+```
+Merge pull request #2950 :
+ReaR in Docker for development & fix package dependencies.
+Simple way to run a command via Docker in all, 
+some or specific distros that are relevant for ReaR.
+multi-arch support for run-in-docker
+```
+&nbsp;
+```
+Merge pull request #2907 :
+In rescue/GNU/Linux/310_network_devices.sh 
+use now output of 'ls /sys/class/net/' to select all available interfaces 
+regardless whether or not interfaces are configured / have an IP address 
+(to exclude unwanted interfaces use EXCLUDE_NETWORK_INTERFACES) 
+instead of before 'ip r' that defaults to 'ip -4 r' (so 'ip -6 r' was ignored) 
+in particular to make networking also work with IPv6 only NICs 
+see https://github.com/rear/rear/issues/2902 
+```
+&nbsp;
+```
+Merge pull request #2956 :
+New OpalPBA AuthToken feature: 
+Added AuthToken generation & disk-unlocking into OpalPBA image. 
+Currently encrypted tokens are stored on and read from 
+plain Linux block device (e.g. USB drive, SDCard, etc). 
+Supports TPM2-assisted encryption, so tokens can be made 
+secure and tightly bound to device/boot environment. 
+Supports 2FA authentication (additional password/pin to decrypt token) 
+with basic brute-force protection. 
+Allows for unattended cold booting optionally restricted 
+to SecureBoot-active environment only. 
+See https://github.com/rear/rear/pull/2956 
+```
+&nbsp;
+```
+Update default.conf :
+In default.conf added 'mt' command to REQUIRED_PROGS_OBDR 
+because 'mt' is required for restore (e.g. seek with fsf), see 
+https://github.com/rear/rear/issues/2637#issuecomment-1475690995
+```
+&nbsp;
+```
+Merge pull request #2909 :
+Inform the user when it could not umount something in certain cases: 
+In output/ISO/Linux-i386/700_create_efibootimg.sh 
+make umounting the EFI virtual image more fail-safe: 
+When normal 'umount' fails 'sleep 1' and retry normal 'umount' 
+and if it still fails log 'fuser' info and try 'umount --lazy' and if that 
+also fails show the user a LogPrintError and proceed bona fide 
+so the user can understand why later at the end 
+cleanup_build_area_and_end_program() may show 
+"Could not remove build area" 
+if lazy umount could not clean up things until then, 
+cf. https://github.com/rear/rear/issues/2908 
+In restore/NETFS/default/400_restore_backup.sh and 
+same also in restore/YUM/default/410_restore_backup.sh 
+it calls umount "$BUILD_DIR/outputfs" 
+because BUILD_DIR/outputfs is needed as mountpoint 
+to mount something (a medium that contains the backup) 
+so inform the user about an umounting failure 
+(if there was something mounted at BUILD_DIR/outputfs) 
+so he can understand why the subsequent mounting fails 
+or why several things got mounted stacked one over the other.
+```
+&nbsp;
+```
+Merge pull request #2937 :
+Add support for Commvault Galaxy 11
+New feature DISABLE_DEPRECATION_ERRORS to error out for deprecated code paths with option to override this.
+New variable USE_RAMDISK configures rescue system to use a ramdisk for tools that need to check for free disk space.
+Rework GALAXY11 to use ramdisk feature and set PATH globally.
+Use Ramdisk for older Galaxy versions too.
+Improve rear shell to stay in SHARE_DIR after using Source and add show helper.
+Support multiple -C options and log runtime configuration.
+Enable running from checkout and specify -C /etc/rear/local.conf to use host ReaR configuration.
+```
+&nbsp;
+```
+Update 100_include_partition_code.sh :
+In layout/prepare/GNU/Linux/100_include_partition_code.sh 
+verify we could read the intended 'disk /dev/sdX ' entry (with trailing space) 
+from disklayout.conf and BugError if that fails, cf. 
+https://github.com/rear/rear/issues/2958#issuecomment-1477963982
+```
+&nbsp;
+```
+Update 950_verify_disklayout_file.sh :
+In layout/save/default/950_verify_disklayout_file.sh 
+add 'dasd' to the error message because 'dasd' is 
+also an allowed partition label in disklayout.conf 
+since https://github.com/rear/rear/pull/2142
+```
+&nbsp;
+```
+Merge pull request #2954 :
+Better user messages for finalize/default/060_compare_files.sh 
+In particular show some keywords to trigger the right idea 
+in the user's mind what this stuff actually is about: 
+Consistency of what was recreated with his restored backup. 
+See https://github.com/rear/rear/issues/2952 
+and https://github.com/rear/rear/pull/2954
+```
+&nbsp;
+```
+Update 200_run_layout_code.sh :
+lsblk MOUNTPOINTS works on SLES15-SP4 but not on SLES15-SP3 
+(on SLES15-SP3 only MOUNTPOINT works)
+```
+&nbsp;
+```
+Merge pull request #2953 :
+New prep/default/990_verify_empty_rootfs.sh 
+to verify untouched ROOTFS_DIR at the end of 'prep' 
+plus enhanced prep/README to better explain 
+why ROOTFS_DIR must not be touched by 'prep' scripts, 
+see https://github.com/rear/rear/issues/2951
+```
+&nbsp;
+```
+Update 001_verify_config_arrays.sh :
+In init/default/001_verify_config_arrays.sh 
+do not check comment lines for falsely assigned array variables 
+cf. https://github.com/rear/rear/pull/2932 
+and https://github.com/rear/rear/issues/2930
+```
+&nbsp;
+```
+Merge pull request #2947 :
+In layout/save/GNU/Linux/240_swaps_layout.sh
+layout/save/GNU/Linux/230_filesystem_layout.sh
+layout/save/GNU/Linux/200_partition_layout.sh
+replaced the subshell that appends its stdout to DISKLAYOUT_FILE 
+by a group command with redirection: { ... } >> $DISKLAYOUT_FILE 
+see https://github.com/rear/rear/issues/2927#issuecomment-1440044143
+```
+&nbsp;
+```
+Merge pull request #2943 :
+s390x (IBM Z) disk formatting fixes
+Enable DASDs also during "rear mountonly".
+Add default value for FORMAT_DASDS to default.conf :
+The default value is "" and it means to format the DASDs by default, in
+an analogy with DISKS_TO_BE_WIPED.
+Allow the user to skip DASD formatting entirely :
+Allow to choose to skip DASD formatting from the DASD format script
+confrmation dialog. Can be also set by setting the FORMAT_DASDS variable
+to a false value.
+Use mapping hints for comparing and mapping disks :
+When disk mapping hints (DISK_MAPPING_HINTS) indicate we know the
+correct mapping for a disk, use them in preference to device name and
+size comparison. They are supposed to be more reliable and also they
+are set by the s390-specific code for disks (DASDs) that are not yet
+formatted and thus their size is not yet known, so guessing according to
+disk size does not work properly.
+Always let the user confirm the DASD format script :
+Reformatting is a dangerous operation, equivalent to wiping disks (which
+we also let the user always confirm).
+Adapt DASD activation and formatting :
+Move the DASD formatting code after the mapping code. Otherwise when
+device names change, the code would format the old names, not the new
+names.
+Generate the DASD formatting code as a separate script and let the
+user confirm it before it gets executed. Heavily inspired by the disk
+wiping code (it is similarly destructive), but executed during the
+"layout/prepare" stage and not during the "layout/recreate" stage. The
+reason is that unformatted DASDs do not have their size in bytes known
+(it depends on format), but other scripts in the "layout/prepare"
+stage need to know the disk sizes (e.g. for resizing partitions).
+The disk comparison and mapping script will now be less accurate,
+because it won't know the current sizes if disks are not formatted. To
+compensate, introduce a variable called DISK_MAPPING_HINTS that allows
+the DASD activation code to pass the information on changed disk names
+to the rest of the layout code (the identification is based on virtual
+device numbers).
+Layout changes and fixes for S/390 DASDs :
+Simplify syntax of dasd_channel directive. The previous syntax had
+some useless fields, like the major:minor number and status.
+Fix obtaining the entry from lsdasd output: "grep $blockd" did not
+work properly, because if $blockd == dasda and there also disks named
+dasdaa and dasdab (this will be the case with more than 26 DASDs), the
+command would print all three lines instead of just the correct one
+and break the resulting format.
+Eliminate the "dasdfmt" directive, merge its fields into
+the "disk" directive. This has the advantage that the exclusion code
+eliminates the "disk" lines for unused disks automatically.
+Previously, the "dasdfmt" lines for unused disks stayed in the layout
+file, which later caused the unused disks to be reformatted
+unconditionally (including disk with the backup itself on
+it if one used a local storage for backup).
+Unfortunately it means that the format of the "disk" directive now
+depends on the disk label type: dasd disks have extra fields that
+other disk types don't have.
+Add information about number of cylinders to the disk directive for
+DASDs, it is more stable than the size in bytes (which depends on
+the format). Currently unused.
+```
+&nbsp;
+```
+Update rear :
+In usr/sbin/rear show different messages for different things 
+(config file cannot be read versus config file cannot be sourced) 
+to avoid that the user gets two times the same message 
+which looks like an unintended duplicated output 
+but actually it is two messages for two similar things. 
+Triggered by https://github.com/rear/rear/issues/2936
+```
+&nbsp;
+```
+Merge pull request #2932 :
+check for wrong syntax of array assignments in user configs
+(disabled on ancient systems with bash 3)
+```
+&nbsp;
+```
+Update 330_find_isolinux.sh :
+In prep/ISO/Linux-i386/330_find_isolinux.sh 
+less misleading error message when isolinux.bin cannot be found 
+(no longer show a distribution specific software package name), 
+see https://github.com/rear/rear/issues/2921
+```
+&nbsp;
+```
+Update 230_filesystem_layout.sh :
+In layout/save/GNU/Linux/230_filesystem_layout.sh 
+add 'chattr' to REQUIRED_PROGS (and not only to PROGS) 
+because 'chattr' is called in diskrestore.sh 
+see https://github.com/rear/rear/issues/2927
+```
+&nbsp;
+```
+Update 420_autoresize_last_partitions.sh :
+Fixed fallback assignments of mandatory values 
+to not let them evaluate to nonsense commands, see 
+https://github.com/rear/rear/issues/2926
+```
+&nbsp;
+```
+Merge pull request #2915 :
+In lib/serial-functions.sh make the 
+get_serial_console_devices() function 
+fail-safe if no serial device node exists, see 
+https://github.com/rear/rear/issues/2914
+```
+&nbsp;
+```
+Merge pull request #2910 :
+In finalize/Linux-ppc64le/660_install_grub2.sh remove the 
+"mount --bind <proc|sys|dev> at TARGET_FS_ROOT" 
+section because that is meanwhile done generically in 
+finalize/default/110_bind_mount_proc_sys_dev_run.sh 
+since https://github.com/rear/rear/issues/2045 
+but there the file finalize/Linux-ppc64le/..._install_grub2.sh 
+was accidentally forgotten (see its initial description), 
+see https://github.com/rear/rear/pull/2910 
+```
+&nbsp;
+```
+Merge pull request #2905 :
+OUTPUT=USB: Use target=i386-pc for legacy BIOS GRUB2 install on EFI systems: 
+grub-install defaults to '--target=x86_64-efi' when the system is booted with EFI. 
+So setting a legacy BIOS target is needed when the system is booted with EFI. 
+See https://github.com/rear/rear/issues/2883
+```
+&nbsp;
+```
+Merge pull request #2904 :
+In output/USB/Linux-i386/850_make_USB_bootable.sh 
+install extlinux for OUTPUT=USB also for a vfat boot partition 
+because since SYSLINUX version 4.00 extlinux also works for vfat 
+see https://github.com/rear/rear/issues/2884
+```
+&nbsp;
+```
+Merge pull request #2903 :
+Protect against colons in pvdisplay output :
+LVM can be configured to show device names under /dev/disk/by-path
+in command output. These names often contain colons that separate fields
+like channel and target (for example /dev/disk/by-path/pci-*-scsi-0:0:1:0-*,
+similarly the pci-* part, which contains colon-separated PCI bus and
+device numbers). Since the "pvdisplay -c" output also uses colons as
+field separators and does not escape embedded colons in any way,
+embedded colons break parsing of this output.
+As a fix, use the pipe character '|' as the field separator in pvdisplay
+output. (This would break if a PV device has a '|' in its name, but this
+is very much less likely than having a ':' .)
+Also, configure explicitly what fields to output - "pvdisplay -c"
+prints many fields, but I have not found documentation about what fields
+is it using exactly, so one had to guess what the output means. Using
+"pvdisplay -C" and selecting the fields explicitly is much clearer.
+This also changes the PV size field to match documentation, the comment
+says that size is in bytes, but it actually was not in bytes. As nothing
+is actually using the PV size field, this inconsistency has not caused
+any problem in practice, and no code needs adjusting for the change.
+```
+&nbsp;
+```
+Merge pull request #2901 :
+BACKUP=BAREOS: fix bconsole CLI argument format in 
+prep/BAREOS/default/500_check_BAREOS_bconsole_results.sh 
+Bareos 22 introduced a breaking change how its CLI tools 
+(such as bconsole) parse the arguments. 
+Before it was "bconsole -xc" but since Bareos 22 it must be "bconsole --xc" 
+(otherwise it terminates with exit code 113 so "rear mkrescue" will fail). 
+Before "bconsole ...xc" is called, it now checks the bconsole version 
+and uses the new argument format '--xc' when version >= 22. 
+The backward compatible fallback is "bconsole -xc".
+```
+&nbsp;
+```
+Merge pull request #2894 :
+For BACKUP=SESAM with SESAM version 5.x two more directories 
+$SM_BIN_SESAM/python3/ and $SM_BIN_SMS are needed 
+in SESAM_LD_LIBRARY_PATH to avoid missing libraries 
+(SM_BIN_SMS is defined in the config file set in sesam2000ini_file). 
+The reason behind is that SEP has obsoleted python2 to python3, 
+and additional libraries are now included within the python3 subdirectory. 
+Additionally RTS components need additional libraries from the SMS subfolder. 
+See https://github.com/rear/rear/pull/2894 
+```
+&nbsp;
+```
+Update default.conf :
+In default.conf tell what gets stored in the ESP on a USB disk: 
+The ReaR recovery system kernel and initrd and BOOTX64.efi 
+cf. https://github.com/rear/rear/pull/2829#issuecomment-1168547117 
+and https://github.com/rear/rear/issues/2881
+In default.conf also tell that grub.cfg is stored in the ESP 
+on a USB disk to have that part of the description complete 
+cf. https://github.com/rear/rear/pull/2829#issuecomment-1168547117
+```
+&nbsp;
+```
+Merge pull request #2876 :
+Implement initial basic 'barrel' support as a first step 
+mainly in layout/recreate/default/200_run_layout_code.sh 
+and in the new layout/save/default/550_barrel_devicegraph.sh 
+Barrel is a command-line program for storage management 
+in particular for a SUSE specific storage layout 
+which is available since SLES15-SP4, see 
+https://github.com/aschnell/barrel 
+Barrel can save and recreate a whole storage layout, see 
+https://github.com/rear/rear/issues/2863 
+The current basic 'barrel' support is implemented as optional 
+and additional possibility when the 'barrel' program is there. 
+ReaR's native method via disklayout.conf and diskrestore.sh 
+is still used and working unchanged as before in parallel 
+so that when 'barrel' is used during "rear recover" but it fails, 
+the user can switch back to recreating with diskrestore.sh 
+which is the reason for some new choices during "rear recover", 
+in particular "Again wipe the disks in DISKS_TO_BE_WIPED" 
+to wipe what 'barrel' had setup before diskrestore.sh is run. 
+Additionally during "rear recover" it shows now 'lsblk' output 
+on the user's terminal to make it easier for the user to see 
+what disk layout got recreated to decide if that is right or wrong. 
+Furthermore there is now the new choice to 
+"Confirm what is currently on the disks and continue 'rear recover'" 
+so that the user can manually fix things (in particular smaller things) 
+by only using the ReaR shell and then confirm what he created 
+on his disks and continue with restoring the backup, see 
+https://github.com/rear/rear/pull/2876 
+```
+&nbsp;
+```
+Merge pull request #2873 :
+Fix initrd regeneration on s390x and Fedora/RHEL :
+For some reason, the 550_rebuild_initramfs.sh script was not included
+for s390x on Fedora/RHEL so the initrd was not regenerated after backup
+restore on this architecture.
+Since all other architectures were actually using the same script,
+let's just move it one level up to fix this bug and to also simplify
+the directory structure a bit.
+```
+&nbsp;
+```
+Merge pull request #2872 :
+In default.conf more accurate description of BACKUP=EXTERNAL 
+and PING to better match what is actually implemented, see 
+https://github.com/rear/rear/issues/2870#issuecomment-1261045942 
+plus some general improvements of all the comments 
+e.g. removed the colloquial word 'stuff' where not useful and 
+made blocks of config variables that belong together more clear 
+by using '####' as indicators where a block begins and ends. 
+```
+&nbsp;
+```
+Merge pull request #2868 :
+In the UserInput function drain stdin if stdin is a terminal (i.e. in interactive mode): 
+The primarily intended use case is to discard possibly already existing characters 
+(in particular ENTER keystrokes) from stdin to avoid that 
+when the user had accidentally hit ENTER more than once 
+in (or after) a previous UserInput dialog (or another dialog) 
+then those additional ENTER characters would be already in stdin 
+and let the next UserInput dialog proceed unintendedly automatically 
+without an explicit ENTER from the user for this current dialog, 
+see https://github.com/rear/rear/issues/2866 
+```
+&nbsp;
+```
+Merge pull request #2857 :
+In output/PXE/default/810_create_pxelinux_cfg.sh 
+insert missing '$pxe_link_prefix' for the IP case 
+also for the "if has_binary gethostip" part, see 
+https://github.com/rear/rear/pull/2851#issuecomment-1237939248 
+Additionally clean up the indentation in 
+output/PXE/default/810_create_pxelinux_cfg.sh 
+plus some more "cleanup" code and comments changes 
+(including minor bug fixes).
+```
+&nbsp;
+```
+Merge pull request #2859 :
+By default let "rear recover" wipe disks that get completely recreated 
+via DISKS_TO_BE_WIPED="" in default.conf 
+In ReaR 2.7 default.conf has DISKS_TO_BE_WIPED='false' 
+but now after ReaR 2.7 release this feature should be used 
+by default by users who use our GitHub master code 
+so that we could use it by default in ReaR 2.8. 
+See https://github.com/rear/rear/pull/2514 
+and https://github.com/rear/rear/issues/799
+```
+&nbsp;
+```
+Update _input-output-functions.sh :
+Since https://github.com/rear/rear/commit/74de0966a5f21fb41531e9d4711932b6df83856a 
+the default USER_INPUT_INTERRUPT_TIMEOUT is 10 seconds 
+so set the same default value in the UserInput() function.
+```
+&nbsp;
+```
+Merge pull request #2851 :
+In output/PXE/default/810_create_pxelinux_cfg.sh 
+insert missing '$pxe_link_prefix' for the MAC case 
+because PXE_CONFIG_GRUB_STYLE=y 
+did not work with PXE_CREATE_LINKS=MAC 
+see https://github.com/rear/rear/issues/2850
+```
+&nbsp;
+```
+Merge pull request #2846 :
+Implement a new config variable BORGBACKUP_IGNORE_WARNING 
+which ignores Borg warnings (see its description in default.conf). 
+Borg warnings can happen if a file changed while backing it up. 
+See https://github.com/rear/rear/pull/2846
+```
+&nbsp;
+```
+Merge pull request #2844 :
+Overhauled rescue/GNU/Linux/290_kernel_cmdline.sh 
+in particular to make it possible to add several already existing 
+kernel options by this script with same kernel option keyword 
+for example when /proc/cmdline contains 
+... console=ttyS0,9600 ... console=tty0 ... 
+then via COPY_KERNEL_PARAMETERS+=( console ) 
+cf. https://github.com/rear/rear/pull/2749#issuecomment-1197843273 
+```
+&nbsp;
+```
+Merge pull request #2839 :
+Pass -y to lvcreate instead of piping the output of yes
+```
+&nbsp;
+```
+Better description of COPY_KERNEL_PARAMETERS in default.conf, 
+cf. https://github.com/rear/rear/pull/2749#issuecomment-1197843273
+```
+&nbsp;
+
diff --git a/mkdocs.yml b/mkdocs.yml
index 88d56aba..3d28afac 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -48,6 +48,7 @@ nav:
     - 'Make a pull request with GitHub': 'development/github-pr.md'
   - RELEASE NOTES:
     - 'Release Notes': 'releasenotes/index.md'
+    - 'Release Notes ReaR 2.8': 'releasenotes/rear28.md'
     - 'Release Notes ReaR 2.7': 'releasenotes/rear27.md'
     - 'Release Notes ReaR 2.6': 'releasenotes/rear26.md'
     - 'Known Problems and Workarounds': 'releasenotes/knownproblems.md'