[aasami](https://github.com/aasami) opened issue at [2019-09-27 13:59](https://github.com/rear/rear/issues/2241):
+
+#### Relax-and-Recover (ReaR) Issue Template
+
+Fill in the following items before submitting a new issue
+(quick response is not guaranteed with free support):
+
+- ReaR version ("/usr/sbin/rear -V"):
+ Relax-and-Recover 2.5 / Git
+
+- OS version ("cat /etc/rear/os.conf" or "lsb\_release -a" or "cat
+ /etc/os-release"):
+
+
+
+ $ lsb_release -a
+ LSB Version: n/a
+ Distributor ID: ManjaroLinux
+ Description: Manjaro Linux
+ Release: 18.1.0
+ Codename: Juhraya
+
+- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+ /etc/rear/local.conf"):
+
+
+
+ $ cat /etc/rear/site.conf
+ TIMESYNC=NTP
+
+ $ cat /etc/rear/local.conf
+ OUTPUT=RAWDISK
+ OUTPUT_URL=nfs://nfs.tu/srv/bkp
+ BACKUP=NETFS
+ BACKUP_URL=nfs://nfs.tu/srv/bkp
+ BACKUP_TYPE=differential
+ FULLBACKUP_OUTDATED_DAYS=92
+ BACKUP_PROG_COMPRESS_OPTIONS=("--zstd")
+ BACKUP_PROG_COMPRESS_SUFFIX=".zst"
+ KERNEL_FILE="/boot/vmlinuz-$( uname -r|cut -d\. -f1-2 )-x86_64"
+
+- Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM
+ guest or PoverVM LPAR):
+
+
+
+ $ dmidecode -t1
+ \# dmidecode 3.2
+ Getting SMBIOS data from sysfs.
+ SMBIOS 2.8 present.
+
+ Handle 0x000F, DMI type 1, 27 bytes
+ System Information
+ Manufacturer: LENOVO
+ Product Name: 20ET004BXS
+ Version: ThinkPad E460
+ Serial Number: PF0ISVA2
+ UUID: 37a370cc-2181-11b2-a85c-e2db9b721f93
+ Wake-up Type: Power Switch
+ SKU Number: LENOVO_MT_20ET_BU_Think_FM_ThinkPad E460
+ Family: ThinkPad E460
+
+- System architecture (x86 compatible or PPC64/PPC64LE or what exact
+ ARM device):
+
+
+
+ $ uname -m
+ 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):
+ local SSD
+
+- Description of the issue (ideally so that others can reproduce
+ it):
+ When using option BACKUP\_PROG\_COMPRESS\_OPTIONS=("--zstd")
+ recovery is not possible due to missing zstd binaries in recovery
+ image.
+ (The same might be true for options --lzip --lzma and --lzop but I
+ haven't tested it)
+
+- Workaround, if any:
+ Possible: copy missing binary from other location when in recovery
+ mode (not tested)
+
+- Attachments, as applicable ("rear -D mkrescue/mkbackup/recover"
+ debug log files):
+
+#### 
[maslo64](https://github.com/maslo64) commented at [2023-03-20 06:26](https://github.com/rear/rear/issues/2637#issuecomment-1475690995):
+
+@pcahyna tests were performed with 2.7.1 RPM and in order to restore,
+here are changes which were done to rear.
+
+Here we need to update config file with `""` and `()` because of tar
+behavior ,mentioned also in
+[https://github.com/rear/rear/issues/2911](https://github.com/rear/rear/issues/2911)
+[https://github.com/rear/rear/blob/7ce864210fc7a7c95a131ea8c933f543b6e3b9cb/usr/share/rear/verify/OBDR/NETFS/default/540\_set\_backup\_compression.sh](https://github.com/rear/rear/blob/7ce864210fc7a7c95a131ea8c933f543b6e3b9cb/usr/share/rear/verify/OBDR/NETFS/default/540_set_backup_compression.sh)
+
+ BACKUP_PROG_COMPRESS_OPTIONS=()
+ BACKUP_PROG_COMPRESS_SUFFIX=""
+
+Here we are missing 'mt' program in order to perform restore , f.x. seek
+with fsf command
+
+[https://github.com/rear/rear/blob/7ce864210fc7a7c95a131ea8c933f543b6e3b9cb/usr/share/rear/conf/default.conf\#L1283](https://github.com/rear/rear/blob/7ce864210fc7a7c95a131ea8c933f543b6e3b9cb/usr/share/rear/conf/default.conf#L1283)
+
+what was also needed for restore was to execute script
+
+ bash /usr/share/rear/skel/OBDR/etc/scripts/system-setup.d/43-init-cciss.sh
+
+and afterwards update `TAPE_DEVICE=/dev/nstX` in config file.
+
+Thanks
+
+#### 
[mdbr000](https://github.com/mdbr000) commented at [2022-05-27 16:37](https://github.com/rear/rear/issues/2810#issuecomment-1139783197):
+
+@jsmeix
+Thanks much for the response and helpful information. I was indeed able
+to run `rear mkbackup` successfully after reverting to the commit just
+prior to your \#2804 PR when no memory card was present in /dev/sdb.
+
+It sounds like this might be a change/fix that you'll want to make in
+mainline. For now, I will compile a version that comments out the `test`
+line you call out above.
+
+I am still having issues with recovery, but that is a separate topic.
+
+Again, thank you.
+
+#### 
[jsmeix](https://github.com/jsmeix) commented at [2022-05-30 12:50](https://github.com/rear/rear/issues/2810#issuecomment-1141120476):
+
+@mdbr000
+please attach your recent var/lib/rear/layout/disklayout.conf
+because I need to know how all entries related to `sdb`
+look therein in your particular case.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-05-30 13:07](https://github.com/rear/rear/issues/2810#issuecomment-1141138162):
+
+I did a test with a manually modified
+var/lib/rear/layout/disklayout.conf
+as follows (excerpt):
+
+ disk /dev/sda 12884901888 gpt
+ disk /dev/sdb 5368709120
+
+i.e. I removed the partition type label `gpt` from `sdb`
+and I also removed any other entry for `sdb` so
+
+ disk /dev/sdb 5368709120
+
+is the only entry related to `sdb` in
+var/lib/rear/layout/disklayout.conf
+
+Then I did a "rear -D recover" which worked.
+
+Except from var/lib/rear/layout/diskrestore.sh
+regarding `sdb`:
+
+ if create_component "/dev/sdb" "disk" ; then
+ # Create /dev/sdb (disk)
+
+ #
+ # Code handling disk '/dev/sdb'
+ #
+
+ ### Disks should be block devices.
+ [ -b "/dev/sdb" ] || BugError "Disk /dev/sdb is not a block device."
+
+ Log "Stop mdadm"
+ if grep -q md /proc/mdstat 2>/dev/null; then
+ mdadm --stop -s >&2 || echo "stop mdadm failed"
+ # Prevent udev waking up mdadm later.
+ # Reasoning: At least on RHEL6 when parted created a raid partition on disk,
+ # udev (via /lib/udev/rules.d/65-md-incremental.rules) wakes up mdadm which locks the disk,
+ # so further parted commands with the disk will fail since the disk is busy now.
+ # The /lib/udev/rules.d/65-md-incremental.rules detects anaconda (the Red Hat installer),
+ # and if it find itself running under anaconda, it will not run.
+ # Accordingly also for other installers (in particular the ReaR installer)
+ # this rule should not be there (and other Linux distros probably do not have it)
+ # which means removing it is the right solution to make ReaR work also for RHEL6:
+ if [ -e /lib/udev/rules.d/65-md-incremental.rules ] ; then
+ rm -f /lib/udev/rules.d/65-md-incremental.rules || echo "rm 65-md-incremental.rules failed"
+ fi
+ fi
+ Log "Erasing MBR of disk /dev/sdb"
+ dd if=/dev/zero of=/dev/sdb bs=512 count=1
+ sync
+
+ # Make sure device nodes are visible (eg. in RHEL4)
+ my_udevtrigger
+ my_udevsettle
+
+ # Clean up transient partitions and resize shrinked ones
+ delete_dummy_partitions_and_resize_real_ones
+
+ #
+ # End of code handling disk '/dev/sdb'
+ #
+
+ component_created "/dev/sdb" "disk"
+ else
+ LogPrint "Skipping /dev/sdb (disk) as it has already been created."
+ fi
+
+So it works in the special case when there is
+only a 'disk' entry without partition type label value
+but nothing else for this disk exists in disklayout.conf
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-05-30 13:28](https://github.com/rear/rear/issues/2810#issuecomment-1141161670):
+
+Via
+[https://github.com/rear/rear/commit/0a1d634ed15500bb21f37ac1bbb11c8a4bb11545](https://github.com/rear/rear/commit/0a1d634ed15500bb21f37ac1bbb11c8a4bb11545)
+we do no longer error out when there is no partition label type value
+for a 'disk' entry in disklayout.conf because "rear recover" works
+in a special case without partition label type value when there is
+only a 'disk' entry but nothing else for this disk exists in
+disklayout.conf
+which can happen when /dev/sdX is an empty SD card slot without medium.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-05-30 13:42](https://github.com/rear/rear/issues/2810#issuecomment-1141176019):
+
+@mdbr000
+I would appreciate it if you could test our current
+ReaR upstream GitHub master code, see the section
+"Testing current ReaR upstream GitHub master code" in
+[https://en.opensuse.org/SDB:Disaster\_Recovery](https://en.opensuse.org/SDB:Disaster_Recovery)
+
+With our current ReaR upstream GitHub master code
+you should get the message
+
+ No partition label type for 'disk /dev/sdb' (may cause 'rear recover' failure)
+
+because usually a missing partition label type value
+will cause a 'rear recover' failure.
+
+Here "'rear recover' failure" also means when a disk gets
+partitioned with a fallback partition type via the code in
+layout/prepare/GNU/Linux/100\_include\_partition\_code.sh
+when the original disk partition type was different
+but somehow not detected/stored in disklayout.conf.
+
+#### 
[pcahyna](https://github.com/pcahyna) commented at [2022-05-30 14:55](https://github.com/rear/rear/issues/2810#issuecomment-1141249655):
+
+Interesting - when testing \#2804 & \#2803 I tested cases with drives
+without partition tables, but not drives with missing media. I wonder
+how to test this without a physical drive that supports removable media?
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-05-31 07:22](https://github.com/rear/rear/issues/2810#issuecomment-1141759827):
+
+I was also wondering how I could somehow reproduce
+the behaviour that is described in this issue here.
+
+I am not a SD card user (I don't have a SD card medium).
+My homeoffice laptop has an (empty) SD card slot
+but I see no block device node for it.
+
+So I guess the SD card reader in this issue here
+is some unusual hardware that shows up as block device
+even when there is no medium so its block device node
+is basically useless and misleading.
+
+I played around with an artificial "dangling" block device node
+
+ # mknod /dev/sdq b 8 99
+
+ # file /dev/sdq
+ /dev/sdq: block special (8/99)
+
+ # find /sys/block/
+ /sys/block/
+ /sys/block/dm-1
+ /sys/block/sr0
+ /sys/block/dm-0
+ /sys/block/sda
+
+ # lsblk /dev/sdq
+ lsblk: /dev/sdq: failed to get sysfs name: No such file or directory
+
+ # blockdev --report /dev/sdq
+ RO RA SSZ BSZ StartSec Size Device
+ blockdev: cannot open /dev/sdq: No such device or address
+
+and /dev/sdq was just ignored by "rear mkrescue" (as it should).
+
+So I manually modified a 'disk' entry in disklayout.conf
+in the ReaR recovery system before "rear recover"
+to be able to at least partially reproduce this issue here.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2022-05-31 10:01](https://github.com/rear/rear/issues/2810#issuecomment-1141930711):
+
+The difference with a "dangling" device node is that opening it will
+report `ENXIO` "No such device or address", while an existing but empty
+device reports `ENOMEDIUM` "No medium found". I don't think the device
+is necessarily "useless and misleading" - the physical device (card
+reader) is here, only its slot is empty. This is the usual behavior with
+removable media devices like floppies or optical media (not USB flash
+"disks" though, because in their case you remove the entire device, not
+only the medium).
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-05-31 11:55](https://github.com/rear/rear/issues/2810#issuecomment-1142036377):
+
+With "basically useless and misleading" I meant how it behaves
+in practice in particular compared to "normal" disks.
+
+With a "normal" disk when e.g. /dev/sda is there
+one can access "the whole disk data" via /dev/sda
+
+In contrast removable media devices behave different because
+when e.g. /dev/sdb is there it does not necessarily mean
+one can access "the whole disk data" via /dev/sdb
+but only when a medium is inserted.
+
+I wonder for what /dev/sdb could be useful without medium?
+My offhanded guess is that a removable media device
+without medium is as useful as a "normal" disk device where
+its built-in medium was mechanically removed by a technician
+or as useful as a USB mass storage device that is disconnected.
+But I am not at all an expert here so I only do some
+offhanded thinking from an ignorant end-user point of view.
+
+In the end for ReaR this issue means:
+We will have to implement special case handling
+for removable media devices in ReaR.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-05-31 12:04](https://github.com/rear/rear/issues/2810#issuecomment-1142045466):
+
+FYI
+how my CD/DVD device behaves on my homeoffice laptop
+without medium
+
+ # cat /sys/block/sr0/removable
+ 1
+
+ # lsblk /dev/sr0
+ NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
+ sr0 11:0 1 1024M 0 rom
+
+ # blockdev --report /dev/sr0
+ RO RA SSZ BSZ StartSec Size Device
+ rw 1024 512 512 0 1073741312 /dev/sr0
+
+ # parted -s /dev/sr0 print
+ Error: Error opening /dev/sr0: No medium found
+
+and with medium (which got automatically mounted)
+
+ # lsblk /dev/sr0
+ NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
+ sr0 11:0 1 3.8G 0 rom /run/media/johannes/openSUSE-Leap...
+
+ # blockdev --report /dev/sr0
+ RO RA SSZ BSZ StartSec Size Device
+ rw 1024 2048 2048 0 4056940544 /dev/sr0
+
+ # parted -s /dev/sr0 print
+ Error: Can't have a partition outside the disk!
+ Model: hp DVDRAM GU70N (scsi)
+ Disk /dev/sr0: 4057MB
+ Sector size (logical/physical): 2048B/2048B
+ Partition Table: unknown
+ Disk Flags:
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2022-05-31 12:32](https://github.com/rear/rear/issues/2810#issuecomment-1142073982):
+
+> I wonder for what /dev/sdb could be useful without medium?
+
+You can ask for its manufacturer and capabilities, for example. With the
+device node, it is easier to map what devices you have. If the device
+has a loadable tray, you can also issue commands like open/close the
+tray and load the medium (this is the case for optical and similar
+media), which would be difficult without a device node.
+
+It seems that the empty DVD drive behaves similarly to the empty SD card
+reader, but that's probably not so useful for ReaR testing, because I
+suppose that ReaR ignores CD/DVD drives (would it help to create a
+symlink `/dev/sdb` -> `/dev/sr0`?)
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-05-31 12:46](https://github.com/rear/rear/issues/2810#issuecomment-1142089461):
+
+With a /dev/sdq -> /dev/sr0 symlink:
+
+ # ln -s /dev/sr0 /dev/sdq
+
+ # ls -l /dev/sr0 /dev/sdq
+ lrwxrwxrwx 1 root root 8 May 31 14:38 /dev/sdq -> /dev/sr0
+ brw-rw----+ 1 root cdrom 11, 0 May 31 14:10 /dev/sr0
+
+ # usr/sbin/rear -D mkrescue
+ ...
+ Creating disk layout
+ Overwriting existing disk layout file /root/rear.github.master/var/lib/rear/layout/disklayout.conf
+ Excluding component fs:/other in EXCLUDE_RECREATE
+ Marking component 'fs:/other' as done in /root/rear.github.master/var/lib/rear/layout/disktodo.conf
+ Disabling excluded components in /root/rear.github.master/var/lib/rear/layout/disklayout.conf
+ Disabling component 'fs ... /other' in /root/rear.github.master/var/lib/rear/layout/disklayout.conf
+ Using sysconfig bootloader 'grub2' for 'rear recover'
+ Verifying that the entries in /root/rear.github.master/var/lib/rear/layout/disklayout.conf are correct
+ Created disk layout (check the results in /root/rear.github.master/var/lib/rear/layout/disklayout.conf)
+ ...
+
+ # grep sdq var/lib/rear/layout/disklayout.conf
+ [no output]
+
+ # grep sdq var/log/rear/rear-linux-h9wr.log
+ [no output]
+
+ # grep sr0 var/lib/rear/layout/disklayout.conf
+ # /dev/sr0 /dev/sr0 sata rom 3.8G
+ [this is only the 'lsblk' comment line in disklayout.conf]
+
+ # grep sr0 var/log/rear/rear-linux-h9wr.log
+ ++ ID_NEW=sr0
+ ++ [[ sr0 =~ ^dm- ]]
+ ++ echo ata-hp_DVDRAM_GU70N_M49CBQG2454 /dev/sr0
+ ++ ID_NEW=sr0
+ ++ [[ sr0 =~ ^dm- ]]
+ ++ echo wwn-0x5001480000000000 /dev/sr0
+ ++ blockd=sr0
+ ++ [[ sr0 = hd* ]]
+ ++ [[ sr0 = sd* ]]
+ ++ [[ sr0 = cciss* ]]
+ ++ [[ sr0 = vd* ]]
+ ++ [[ sr0 = xvd* ]]
+ ++ [[ sr0 = dasd* ]]
+ ++ [[ sr0 = nvme* ]]
+ ++ [[ sr0 = mmcblk* ]]
+
+Without /dev/sdq -> /dev/sr0 symlink:
+
+ # grep sr0 var/lib/rear/layout/disklayout.conf
+ # /dev/sr0 /dev/sr0 sata rom 3.8G
+ [this is only the 'lsblk' comment line in disklayout.conf]
+
+ # grep sr0 var/log/rear/rear-linux-h9wr.log
+ ++ ID_NEW=sr0
+ ++ [[ sr0 =~ ^dm- ]]
+ ++ echo ata-hp_DVDRAM_GU70N_M49CBQG2454 /dev/sr0
+ ++ ID_NEW=sr0
+ ++ [[ sr0 =~ ^dm- ]]
+ ++ echo wwn-0x5001480000000000 /dev/sr0
+ ++ blockd=sr0
+ ++ [[ sr0 = hd* ]]
+ ++ [[ sr0 = sd* ]]
+ ++ [[ sr0 = cciss* ]]
+ ++ [[ sr0 = vd* ]]
+ ++ [[ sr0 = xvd* ]]
+ ++ [[ sr0 = dasd* ]]
+ ++ [[ sr0 = nvme* ]]
+ ++ [[ sr0 = mmcblk* ]]
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-05-31 13:03](https://github.com/rear/rear/issues/2810#issuecomment-1142108453):
+
+@pcahyna
+thank you for your explanation
+for what /dev/sdX is useful without medium
+e.g. to open/close a tray and things like that
+i.e. what is needed to load or unload a medium.
+Now I understand.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2022-05-31 13:41](https://github.com/rear/rear/issues/2810#issuecomment-1142152951):
+
+I am trying to create `/dev/sdq` with the same device major/minor
+numbers as `/dev/sr0` (`cp -a /dev/sr0 /dev/sdq` does the job) and trick
+ReaR into believing that it is a disk, but so far I have not been
+successful.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2022-05-31 13:46](https://github.com/rear/rear/issues/2810#issuecomment-1142157784):
+
+looking at the output here, `/dev/sdb` is a USB mass storage device. I
+remember having seen (external) USB card readers, but it was a long time
+ago. Some laptops apparently have built-in memory card readers on USB,
+so one might be successful with some of those, but I currently do not
+have one. @mdbr000 what device is it? (I think a `lsusb` output would
+help.)
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-06-01 06:46](https://github.com/rear/rear/issues/2810#issuecomment-1143181042):
+
+@pcahyna
+thanks for trying with an artificial /dev/sdq device node
+with same major/minor numbers as /dev/sr0.
+That would have been my next attempt for today.
+
+FYI:
+My built-in SD card reader is:
+
+ # lspci -k
+ ...
+ 05:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
+ RTS5227 PCI Express Card Reader (rev 01)
+ Subsystem: Hewlett-Packard Company Device 1940
+ Kernel driver in use: rtsx_pci
+ Kernel modules: rtsx_pci
+
+I have nothing about 'rtsx' in `dmesg` - there is only
+
+ # dmesg | egrep -i '05:00\.0|mmc'
+
+ [ 0.036434] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
+ [ 0.036434] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
+ ...
+ [ 2.514760] pci 0000:05:00.0: [10ec:5227] type 00 class 0xff0000
+ [ 2.514861] pci 0000:05:00.0: reg 0x10: [mem 0xb0500000-0xb0500fff]
+ [ 2.515180] pci 0000:05:00.0: supports D1 D2
+ [ 2.515182] pci 0000:05:00.0: PME# supported from D1 D2 D3hot D3cold
+ ...
+ [ 7.722075] sr 5:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
+
+There is no device node for it (neither /dev/sd\* nor /dev/mmc\*)
+
+ # udisksctl status
+
+ MODEL REVISION SERIAL DEVICE
+ ---------------------------------------------------------------
+ TOSHIBA MQ01ABF050 AM002C Y2PLP02CT sda
+ hp DVDRAM GU70N U703 M49CBQG2454 sr0
+
+I assume this is expected because I do not have a SD card.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2022-06-01 11:49](https://github.com/rear/rear/issues/2810#issuecomment-1143504272):
+
+@jsmeix I have a similar device and it behaves the same way. I decided I
+will not try further to emulate an empty `sd` drive with an empty `sr`
+drive, because it seems that the code is smart enough to distinguish
+between CD-ROM drives and usual SCSI disks. I now prefer reproducing the
+issue with the actual problematic hardware.
+
+@mdbr000 can you please send the `lsusb` output identifying your card
+reader?
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-06-02 07:25](https://github.com/rear/rear/issues/2810#issuecomment-1144536800):
+
+I postponed this issue to ReaR 2.8 because
+it does not need to be solved for ReaR 2.7
+because since
+[https://github.com/rear/rear/commit/0a1d634ed15500bb21f37ac1bbb11c8a4bb11545](https://github.com/rear/rear/commit/0a1d634ed15500bb21f37ac1bbb11c8a4bb11545)
+"rear mkrescue" works again even when there is
+no partition label type value for a 'disk' entry in disklayout.conf
+
+#### 
[github-actions](https://github.com/apps/github-actions) commented at [2022-08-02 03:53](https://github.com/rear/rear/issues/2810#issuecomment-1201984947):
+
+Stale issue message
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-08-10 06:11](https://github.com/rear/rear/issues/2810#issuecomment-1210205720):
+
+Because I have no removable media device
+I cannot do anything actually useful here
+so I leave this issue closed.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-03-21 12:56](https://github.com/rear/rear/issues/2810#issuecomment-1477790517):
+
+Reopening because of
+[https://github.com/rear/rear/issues/2958](https://github.com/rear/rear/issues/2958)
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2023-05-21 02:27](https://github.com/rear/rear/issues/2810#issuecomment-1556066684):
+
+Stale issue message
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2023-07-23 02:27](https://github.com/rear/rear/issues/2810#issuecomment-1646726869):
+
+Stale issue message
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-09-13 10:47](https://github.com/rear/rear/issues/2810#issuecomment-1717392490):
+
+should be fixed by
+[https://github.com/rear/rear/pull/3047](https://github.com/rear/rear/pull/3047)
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2022-07-26.2843.issue.closed.md b/docs/issues/2022-07-26.2843.issue.closed.md
new file mode 100644
index 00000000..d8062a12
--- /dev/null
+++ b/docs/issues/2022-07-26.2843.issue.closed.md
@@ -0,0 +1,312 @@
+[\#2843 Issue](https://github.com/rear/rear/issues/2843) `closed`: No recovery system startup messages (inappropriate kernel 'console' setting)
+===============================================================================================================================================
+
+**Labels**: `fixed / solved / done`, `minor bug`
+
+#### [jsmeix](https://github.com/jsmeix) opened issue at [2022-07-26 10:33](https://github.com/rear/rear/issues/2843):
+
+- ReaR version ("/usr/sbin/rear -V"):
+ 2.7 but I noticed it already earlier since some time during 2.6
+ (it had "just worked" by default everywhere before for me)
+
+- OS version ("cat /etc/os-release" or "lsb\_release -a" or "cat
+ /etc/rear/os.conf"):
+ SLES15 SP3 and SP4
+
+- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+ /etc/rear/local.conf"):
+
+
+
+ OUTPUT=ISO
+ BACKUP=NETFS
+ BACKUP_OPTIONS="nfsvers=3,nolock"
+ BACKUP_URL=nfs://192.168.122.1/nfs
+ FIRMWARE_FILES=( 'no' )
+
+Intentionally I have all kernel modules included by default.
+
+- Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+ guest or PowerVM LPAR):
+ virtual QEMU KVM machines on an openSUSE Leap 15.3 host system
+
+- System architecture (x86 compatible or PPC64/PPC64LE or what exact
+ ARM device):
+ x86
+
+- Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or
+ ELILO or Petitboot):
+ BIOS
+
+- Description of the issue (ideally so that others can reproduce it):
+
+When I boot the ReaR recovery system on my KVM VMs I get
+
+ ...
+ Loading kernel.....................
+ Loading initrd.cgz..........................ready.
+ Probing EDD (edd=off to disable)... ok
+
+and then no further messages are shown
+so in particular no recovery system startup messages are shown
+but after a short time (only a few seconds)
+the video mode changes (which keeps the above messages shown)
+(but there are no recovery system startup messages shown)
+and after another short time (some more seconds)
+the screen blanks and shows the recovery system login screen
+where then all works normal.
+
+I tried the kernel command line parameters
+
+- `edd=off` but likely this issue has nothing to do with BIOS Enhanced
+ Disk Drive Services (EDD)
+- `nomodeset` makes no difference
+- removing `vga=normal` makes no difference
+- I tried some modes with `vga=ask` but found none that helps
+- replacing `vga=normal` with `nomodeset` makes no real difference
+ (i.e. still no recovery system startup messages are shown) but then
+ there is no video mode change
+
+I tried all available VGA settings in "Virtual Machine Manager 3.2.0"
+`QXL` (the default), `Bochs`, `Ramfb`, `VGA`, `Virtio`
+but found none that helps
+
+In contrast when I boot another ReaR recovery system made with
+
+ OUTPUT=USB
+ USB_DEVICE_PARTED_LABEL="gpt"
+ USB_BOOT_PART_SIZE=1024
+ USB_DEVICE_BOOT_LABEL="MY-BOOT"
+ USB_BOOTLOADER="grub"
+ OUTPUT_URL=usb:///dev/disk/by-label/MY-BOOT
+ USB_DEVICE_FILESYSTEM_PERCENTAGE=10
+ USB_DEVICE_FILESYSTEM_LABEL="MY-DATA"
+ BACKUP=NETFS
+ BACKUP_URL=usb:///dev/disk/by-label/MY-DATA
+ FIRMWARE_FILES=( 'no' )
+ MODULES=( 'loaded_modules' )
+
+from my USB disk on my older BIOS laptop
+all the usual messages are shown
+including the recovery system startup messages.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-07-26 13:03](https://github.com/rear/rear/issues/2843#issuecomment-1195455332):
+
+@rear/contributors
+do you perhaps have some ideas what I might try out
+to determine the root cause or even solve the issue?
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-07-27 06:59](https://github.com/rear/rear/issues/2843#issuecomment-1196337765):
+
+Got it!
+
+It has nothing to do with video mode.
+
+The reason is the kernel 'console' setting which is
+by default `console=ttyS0,9600` (at least for OUTPUT=ISO).
+
+Removing `console=ttyS0,9600` makes it work:
+All recovery system startup messages are shown.
+The kernel startup messages, the init (systemd) startup messages,
+and the ReaR recovery system startup scripts messages are shown.
+
+Also `console=ttyS0,9600 console=tty0` works same for me.
+
+In contrast with `console=tty0 console=ttyS0,9600`
+only the kernel startup messages are shown in my case.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-07-27 07:02](https://github.com/rear/rear/issues/2843#issuecomment-1196340596):
+
+This helped me to see the actual root cause:
+[https://serverfault.com/questions/708447/probing-edd-boot-message-stays-for-ten-minutes-on-centos-6-6](https://serverfault.com/questions/708447/probing-edd-boot-message-stays-for-ten-minutes-on-centos-6-6)
+
+Therein this answer:
+
+ I had the same symptoms but the problem was
+ that the vmware console wasn't showing the boot output
+ (after the EDD line and a few minutes,
+ the login prompt suddelny appeared)
+ I added
+
+ console=tty0 console=ttyS0,115200
+
+ ..to the grub and next boot all was fine
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-07-27 07:10](https://github.com/rear/rear/issues/2843#issuecomment-1196347278):
+
+It seems the "Overhauled serial console support code"
+cf.
+[https://github.com/rear/rear/pull/2699](https://github.com/rear/rear/pull/2699)
+in ReaR 2.7 caused some regression in some cases.
+
+At least there is (at least usually) an easy workaround:
+Adjust the kernel 'console' parameter setting in the
+ReaR recovery system bootloader menu.
+And normally (i.e. when there are no failures)
+the recovery system startup messages are not needed.
+So it is only a "minor bug".
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2022-07-27 08:23](https://github.com/rear/rear/issues/2843#issuecomment-1196414295):
+
+it is also related to the change done by @lzaoral recently. If a working
+serial console is detected on your machine, it is used as
+`/dev/console`.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2022-07-27 08:24](https://github.com/rear/rear/issues/2843#issuecomment-1196415073):
+
+[https://github.com/rear/rear/blob/edbe2ee9de54ed4e98424094c71bf4a7ba6bd69a/usr/share/rear/lib/serial-functions.sh\#L47-L54](https://github.com/rear/rear/blob/edbe2ee9de54ed4e98424094c71bf4a7ba6bd69a/usr/share/rear/lib/serial-functions.sh#L47-L54)
+
+#### 
[hpannenb](https://github.com/hpannenb) commented at [2022-07-27 09:41](https://github.com/rear/rear/issues/2843#issuecomment-1196502824):
+
+@jsmeix You were faster than I could write my comment :-)
+
+I recognised this during my short VM testing with CentOS7, AlmaLinux 8
+and 9. I thought it was a change by decision/intention I could not
+follow. It is different compared to at least ReaR 2.6.
+IMHO this leads to cumbersome situations especially in migration mode
+where one cannot find the dialogues on the console but on the serial
+port only.
+Unfortunately those dialogues only appear on the primary used device
+(e.g. the console) even when there is a serial port attached.
+
+Edit: In my case "migration mode" means a V2V, P2V etc. migration not
+setting this mode manually.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-07-27 10:24](https://github.com/rear/rear/issues/2843#issuecomment-1196547061):
+
+@hpannenb
+could you describe more percisely what exactly you experience?
+
+For me with ReaR 2.7 defaults I only do not see
+the recovery system startup messages
+but all works normally as soon as the
+recovery system login screen shows up.
+
+Then I can log in normally and enter
+
+ # export MIGRATION_MODE='true'
+
+ # rear -D recover
+
+and all migration mode dialogs work normally for me.
+I use `export MIGRATION_MODE='true'` here only
+to simulate a migration so I could see
+how it behaves in migration mode.
+
+I do not use a serial console.
+
+#### [hpannenb](https://github.com/hpannenb) commented at [2022-07-27 10:34](https://github.com/rear/rear/issues/2843#issuecomment-1196556049):
+
+The minimal `site.conf`I use is
+
+ # ReaR - site.conf
+ export TMPDIR="/var/tmp"
+
+ USE_STATIC_NETWORKING=yes
+ USE_RESOLV_CONF=no
+
+ ISO_PREFIX="rear-testing-$HOSTNAME"
+
+ USER_INPUT_TIMEOUT=15
+
+ SSH_ROOT_PASSWORD='root'
+
+I create a rescue image on VM1 and boot this image in VM2. During the
+startup I will be asked in `55-migrate-network-devices.sh` about to
+provide the proper network mapping. With ReaR 2.7 this dialog is present
+on e.g. `ttyS0` (serial) only; with ReaR 2.6 this dialog was shown on
+`tty0` (console).
+
+Edit: The login prompt thereafter is present on (virtual) console AND on
+(virtual) serial port.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-07-27 11:03](https://github.com/rear/rear/issues/2843#issuecomment-1196583690):
+
+@hpannenb
+thank you!
+Now I understand what dialog(s) you mean.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-07-27 11:08](https://github.com/rear/rear/issues/2843#issuecomment-1196588256):
+
+For me (as not a serial console user)
+all works well with explicit
+
+ USE_SERIAL_CONSOLE='no'
+
+in etc/rear/local.conf (during "rear mkrescue/mkbackup)
+because then there is no longer any 'console' setting
+for the recovery system kernel
+(at least no longer for OUTPUT=ISO).
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-07-27 11:12](https://github.com/rear/rear/issues/2843#issuecomment-1196592017):
+
+@hpannenb
+when you use a serial console you may experiment with the
+
+ USE_SERIAL_CONSOLE
+ SERIAL_CONSOLE_DEVICES
+ SERIAL_CONSOLE_DEVICES_KERNEL
+ SERIAL_CONSOLE_DEVICE_SYSLINUX
+ SERIAL_CONSOLE_DEVICE_GRUB
+
+config variables what works best for your case.
+
+#### [hpannenb](https://github.com/hpannenb) commented at [2022-07-27 11:13](https://github.com/rear/rear/issues/2843#issuecomment-1196593500):
+
+@jsmeix As already mentioned by You: Due to "power to the user" I
+determined many new settings for CONSOLE parameters in the default.conf
+of ReaR 2.7 compared to 2.6. In my test setup the described situation is
+the more obvious change.
+
+Edit: The reason why I test with virtual serial console on my QEMU/KVM
+is a) it is configured by default and b) the HPE servers I use in the
+company are all setup with a virtual serial port (VSP) to be used as a
+means to login via iLO.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2022-09-19 10:30](https://github.com/rear/rear/issues/2843#issuecomment-1250843183):
+
+This issue should be fixed
+(by me - as time permits)
+as I described in
+[https://github.com/rear/rear/pull/2844\#issuecomment-1202307444](https://github.com/rear/rear/pull/2844#issuecomment-1202307444)
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2022-11-19 02:59](https://github.com/rear/rear/issues/2843#issuecomment-1320767138):
+
+Stale issue message
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2023-01-21 02:28](https://github.com/rear/rear/issues/2843#issuecomment-1399154362):
+
+Stale issue message
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2023-03-25 02:19](https://github.com/rear/rear/issues/2843#issuecomment-1483684006):
+
+Stale issue message
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-03-28 12:28](https://github.com/rear/rear/issues/2843#issuecomment-1486797132):
+
+[https://github.com/rear/rear/pull/2961](https://github.com/rear/rear/pull/2961)
+is a currently work in progress attempt to fix it
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2023-05-28 02:32](https://github.com/rear/rear/issues/2843#issuecomment-1565812529):
+
+Stale issue message
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2023-07-30 02:13](https://github.com/rear/rear/issues/2843#issuecomment-1656997508):
+
+Stale issue message
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2023-09-30 02:01](https://github.com/rear/rear/issues/2843#issuecomment-1741628507):
+
+Stale issue message
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-10-20 12:46](https://github.com/rear/rear/issues/2843#issuecomment-1772677815):
+
+With
+[https://github.com/rear/rear/pull/2961](https://github.com/rear/rear/pull/2961)
+merged
+this issue should be fixed.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2023-09-27.3050.issue.closed.md b/docs/issues/2023-09-27.3050.issue.closed.md
new file mode 100644
index 00000000..7aab4028
--- /dev/null
+++ b/docs/issues/2023-09-27.3050.issue.closed.md
@@ -0,0 +1,148 @@
+[\#3050 Issue](https://github.com/rear/rear/issues/3050) `closed`: ReaR and NFS version 4
+=========================================================================================
+
+**Labels**: `support / question`, `fixed / solved / done`
+
+#### 
[exfarmer](https://github.com/exfarmer) opened issue at [2023-09-27 14:51](https://github.com/rear/rear/issues/3050):
+
+Can rear run with NFS V4?
+
+- ReaR version ("/usr/sbin/rear -V"):
+ Relax-and-Recover 2.6 / 2020-06-17
+
+- If your ReaR version is not the current version, explain why you
+ can't upgrade:
+ No reason
+
+- OS version ("cat /etc/os-release" or "lsb\_release -a" or "cat
+ /etc/rear/os.conf"):
+ LSB Version: :core-4.1-amd64:core-4.1-noarch
+ Distributor ID: RedHatEnterprise
+ Description: Red Hat Enterprise Linux release 8.8 (Ootpa)
+ Release: 8.8
+ Codename: Ootpa
+
+- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+ /etc/rear/local.conf"):
+ OUTPUT=ISO
+ BACKUP\_OPTIONS="nfsvers=3,nolock"
+ BACKUP=NETFS
+ BACKUP\_URL=nfs://edlusxo001.oneabbott.com/data/col1/usxo\_linux\_bu\_image
+ BACKUP\_PROG\_EXCLUDE=("${BACKUP\_PROG\_EXCLUDE\[@\]}" '/media'
+ '/var/tmp' '/var/crash' '/var/log' '/usr/openv' '/srv' '/tmp/\*')
+ ONLY\_INCLUDE\_VG=( "vgos" )
+ NETFS\_KEEP\_OLD\_BACKUP\_COPY=
+ SYSLINUX\_MODULES\_DIR="/usr/share/syslinux"
+ NETFS\_PREFIX="$HOSTNAME-`date +%Y%m%d%H%M%S 2>/dev/null`"
+ OUTPUT\_PREFIX="$HOSTNAME.ReaRbkup.$( date +%Y%m%d%H%M%S
+ 2>/dev/null )"
+ NETFS\_PREFIX="$HOSTNAME.ReaRbkup.$( date +%Y%m%d%H%M%S
+ 2>/dev/null )"
+ PROGRESS\_WAIT\_SECONDS="10"
+
+- Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+ guest or PowerVM LPAR):
+ Dell PowerEdge R650
+
+- System architecture (x86 compatible or PPC64/PPC64LE or what exact
+ ARM device):
+ X86
+
+- Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or
+ ELILO or Petitboot):
+
+- Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or
+ multipath (DM or NVMe):
+ SAN
+
+- Storage layout ("lsblk -ipo
+ NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
+
+- Description of the issue (ideally so that others can reproduce
+ it):
+ It's not an issue, more of a question, Can rear backup use NFS V4?
+
+- Workaround, if any:
+
+- Attachments, as applicable ("rear -D mkrescue/mkbackup/recover"
+ debug log files):
+
+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
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-10-05 06:53](https://github.com/rear/rear/issues/3050#issuecomment-1748197886):
+
+@exfarmer
+I am not at all an NFS expert so I cannot provide
+authoritative information in this area.
+
+I think in general ReaR should also work with NFS V4
+because otherwise I would expect many issues from users
+who use BACKUP=NETFS without BACKUP\_OPTIONS="nfsvers=3,nolock"
+
+From my (limited) experience with NFS issues in ReaR
+I think when ReaR had issues with NFS the root cause
+was in most cases something outside of ReaR
+like improper NFS setup on the NFS server or
+improper NFS things on the client where ReaR runs.
+
+In conf/default.conf I found
+
+ # BACKUP=RBME
+ ##
+ # This mode allows restoring a RBME backup from NFS shares.
+ # As NFSv4 is not fully supported with ReaR (yet) it is safer to
+ # use BACKUP_OPTIONS="nfsvers=3,nolock" in the local.conf file.
+ # Note: You may have to open appropriate TCP/UDP ports on the NFS server (iptables).
+
+According to `git log --follow -p usr/share/rear/conf/default.conf`
+this is from @gdha more than 10 years ago in 2012
+[https://github.com/rear/rear/commit/7033653993fb08aa938a09b6395f02ded2821778](https://github.com/rear/rear/commit/7033653993fb08aa938a09b6395f02ded2821778)
+
+I don't know if this comment is still relevant nowadays.
+
+By searching for 'nfs' in doc/rear-release-notes.txt
+[https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt\#L3492](https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt#L3492)
+I found
+[https://github.com/rear/rear/issues/754](https://github.com/rear/rear/issues/754)
+which leads to
+[https://github.com/rear/rear/commit/fdcaf7ad58a181b7dd1e535e78acf94addf62062](https://github.com/rear/rear/commit/fdcaf7ad58a181b7dd1e535e78acf94addf62062)
+
+So NFS version 4 specific things are (mostly) implemented in
+prep/NETFS/default/100\_check\_nfs\_version.sh
+[https://github.com/rear/rear/blob/master/usr/share/rear/prep/NETFS/default/100\_check\_nfs\_version.sh](https://github.com/rear/rear/blob/master/usr/share/rear/prep/NETFS/default/100_check_nfs_version.sh)
+which is run during "rear mkrescue/mkbackup"
+and in
+verify/NETFS/default/050\_start\_required\_nfs\_daemons.sh
+[https://github.com/rear/rear/blob/master/usr/share/rear/verify/NETFS/default/050\_start\_required\_nfs\_daemons.sh](https://github.com/rear/rear/blob/master/usr/share/rear/verify/NETFS/default/050_start_required_nfs_daemons.sh)
+which is run during "rear recover".
+
+#### 
[gdha](https://github.com/gdha) commented at [2023-10-05 07:14](https://github.com/rear/rear/issues/3050#issuecomment-1748226221):
+
+@exfarmer Yes, we use ReaR in combination with NFS version 4.0 all the
+time.
+If the NFS server has to pass many hops make sure that the MTU values
+are the same everywhere, as otherwise, too many packet drops may be
+possible.
+We are also switching from gzip to zstd as compression algorithm as it
+much faster and it provides lossless compression that is splittable
+(gzip is not splittable).
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-10-05 08:38](https://github.com/rear/rear/issues/3050#issuecomment-1748383871):
+
+Via
+[https://github.com/rear/rear/pull/3053](https://github.com/rear/rear/pull/3053)
+I propose to update the RBME description in default.conf
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2023-12-05 02:10](https://github.com/rear/rear/issues/3050#issuecomment-1839879508):
+
+Stale issue message
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2023-11-01.3062.pr.closed.md b/docs/issues/2023-11-01.3062.pr.closed.md
new file mode 100644
index 00000000..9a9bebff
--- /dev/null
+++ b/docs/issues/2023-11-01.3062.pr.closed.md
@@ -0,0 +1,196 @@
+[\#3062 PR](https://github.com/rear/rear/pull/3062) `closed`: Bump redhat-plumbers-in-action/differential-shellcheck from 4.2.2 to 5.0.1
+========================================================================================================================================
+
+**Labels**: `won't fix / can't fix / obsolete`, `dependencies`
+
+#### 
[dependabot](https://github.com/apps/dependabot) opened issue at [2023-11-01 11:47](https://github.com/rear/rear/pull/3062):
+
+Bumps
+[redhat-plumbers-in-action/differential-shellcheck](https://github.com/redhat-plumbers-in-action/differential-shellcheck)
+from 4.2.2 to 5.0.1.
+
+
+
+Release notes
+Sourced from redhat-plumbers-in-action/differential-shellcheck's releases.
+++v5.0.1
+What's Changed
+Bug Fixes
++
+- Drop support for DEBUG in grep :bug: (#322)
+@jamacku- Fix incorrect log about fixed issues :wood: (#323)
+@jamackuFull Changelog: https://github.com/redhat-plumbers-in-action/differential-shellcheck/compare/v5.0.0...v5.0.1
+v5.0.0
+What's Changed
+Breaking
++
+- drop:
+ignored-codesinput :no_entry_sign: (#290)@jamacku- drop:
+shell-scriptsinput :no_entry_sign: (#288)@jamackuNew
++
+- Show more context for ShellCheck defects and fixes in console output :floppy_disk: (#300)
+@jamacku- Add support for subdirectory scanning :file_folder: (#294)
+@jamacku- Add Statistics of defect severities :bar_chart: (#233)
+@jamacku- Show scanned files in console by default 📜 (#285)
+@jamackuBug Fixes
++
+- Fix autodetection of shell scripts in DEBUG mode :kiwi_fruit: (#299)
+@jamacku- Always gather defect statistics :chart_with_downwards_trend: (#298)
+@jamacku- Fix count of scanned files in job Summary when running on push event :1234: (#297)
+@jamacku- Set correct version of ShellCheck in SARIF :coconut: (#296)
+@jamacku- fix: detection of changed files that might cause failure on some paths :lollipop: (#286)
+@jamackuMaintenance
++
+- Make the version of the used GHA more visible :eyes: (#320)
+@jamacku- Update
+csutils(csdiffandcsgrep) to 3.0.4 (#319)@jamacku- Update
+csutils(csdiff) to 3.0.3 (#293)@jamackuDocumentation
++
+- Improve documentation examples and update feature showcase :camera: (#301)
+@jamacku- Add section documenting VS Code integration :woman_technologist: (#311)
+@jamacku- doc: Explain format of path list options (#310)
+@VladimirSlavikAutomation and CI changes
+ +Dependency Updates
+ +
... (truncated)
+
+
+Changelog
+Sourced from redhat-plumbers-in-action/differential-shellcheck's changelog.
+++Changelog
+Next release
+v5.0.0
++
+- Added defect statistics based on severity levels. They are available in the console output and in the job Summary page.
+- New option
+scan-directory. Allows to specify directories that will be scanned. By default Differential ShellCheck scans the whole repository.- Show more context for ShellCheck defects and fixes in console output. The defect is now shown in the context of the surrounding code.
+- Fix autodetection of shell scripts in DEBUG mode
+- Fix detection of changed files that might cause failure on paths with special characters.
+- Fix count of scanned files in job Summary when running on push event.
+- Drop support for
+shell-scriptsinput- Drop support for
+ignored-codesinput- Update
+csutils(csdiff) to 3.0.4v4.2.2
++
+- Container images now based on Fedora 38 +
++
+- +
ShellCheck-0.8.0 -> 0.9.0- +
csutils-3.0.0 -> 3.0.2v4.2.1
++
+- Handle multiple include/exclude paths with newlines
+v4.2.0
++
+- New option
+exclude-path. Allows to specify list of paths excluded from ShellCheck scanning. It supports globbing and brace expansion. e.g.test/{test1,test2}/**- New option
+include-path. Similar toexclude-path, it allows specifying the list of paths that will be included into scanning. No further checks are performed. +It supports globbing and brace expansion. e.g.fixture/**.fixturev4.1.0
++
+- +
grep- do not escape#and!in patterns- Utilize
+DEBUGto rungrepwithout--silentoption- Update
+csutils(csdiff) to 3.0.0v4.0.2
++
+- Correctly handle character escaping in filenames (e.g.
+␣and&)- Improve documentation and more tests
+v4.0.0
++
+ +- +
+Tag
+latestis no longer available. Use major tags instead (e.g.v3orv4).- +
+Action can be triggered using GitHub
+pushevent+on: +
... (truncated)
+
+
+Commits
+-
+
aa647ecv5.0.1
+3dfdfcffix: uninitialized variable RUNNER_DEBUG
+98b3935fix: drop support for DEBUG in grep
+c9cc531fix: incorrect log about fixed issues
+0b37fe0v5.0.0
+b392c11deps: use the correct version of super-linter
+9988647deps: add comment with pinned version
+a58af3bdeps: updatecsutils(csdiffandcsgrep) to 3.0.4
+dc2f863doc: fix format of warning message
+e0416c5doc: addexample.shfor testing purposes
+- Additional commits viewable in compare view +
+ +[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) + +Dependabot will resolve any conflicts with this PR as long as you don't +alter it yourself. You can also trigger a rebase manually by commenting +`@dependabot rebase`. + +------------------------------------------------------------------------ + +
+
+ +You can trigger Dependabot actions by commenting on this PR: + +- `@dependabot rebase` will rebase this PR +- `@dependabot recreate` will recreate this PR, overwriting any edits + that have been made to it +- `@dependabot merge` will merge this PR after your CI passes on it +- `@dependabot squash and merge` will squash and merge this PR after + your CI passes on it +- `@dependabot cancel merge` will cancel a previously requested merge + and block automerging +- `@dependabot reopen` will reopen this PR if it is closed +- `@dependabot close` will close this PR and stop Dependabot + recreating it. You can achieve the same result by closing it + manually +- `@dependabot show ignore conditions` will show all
+ of the ignore conditions of the specified dependency
+- `@dependabot ignore this major version` will close this PR and stop
+ Dependabot creating any more for this major version (unless you
+ reopen the PR or upgrade to it yourself)
+- `@dependabot ignore this minor version` will close this PR and stop
+ Dependabot creating any more for this minor version (unless you
+ reopen the PR or upgrade to it yourself)
+- `@dependabot ignore this dependency` will close this PR and stop
+ Dependabot creating any more for this dependency (unless you reopen
+ the PR or upgrade to it yourself)
+
+
+
+#### Dependabot commands and options
++ +You can trigger Dependabot actions by commenting on this PR: + +- `@dependabot rebase` will rebase this PR +- `@dependabot recreate` will recreate this PR, overwriting any edits + that have been made to it +- `@dependabot merge` will merge this PR after your CI passes on it +- `@dependabot squash and merge` will squash and merge this PR after + your CI passes on it +- `@dependabot cancel merge` will cancel a previously requested merge + and block automerging +- `@dependabot reopen` will reopen this PR if it is closed +- `@dependabot close` will close this PR and stop Dependabot + recreating it. You can achieve the same result by closing it + manually +- `@dependabot show
[dependabot](https://github.com/apps/dependabot) commented at [2023-12-01 11:53](https://github.com/rear/rear/pull/3062#issuecomment-1835995842):
+
+Superseded by \#3097.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2023-11-06.3067.issue.closed.md b/docs/issues/2023-11-06.3067.issue.closed.md
new file mode 100644
index 00000000..99c20980
--- /dev/null
+++ b/docs/issues/2023-11-06.3067.issue.closed.md
@@ -0,0 +1,229 @@
+[\#3067 Issue](https://github.com/rear/rear/issues/3067) `closed`: Trying to build rescue ISO for Bacula backup
+===============================================================================================================
+
+**Labels**: `support / question`, `fixed / solved / done`
+
+#### 
[ZENAdmin-Ops](https://github.com/ZENAdmin-Ops) opened issue at [2023-11-06 05:44](https://github.com/rear/rear/issues/3067):
+
+
+
+- ReaR version ("/usr/sbin/rear -V"): 2.7
+
+- 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"): Debian 11
+
+- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+ /etc/rear/local.conf"):
+
+
+
+ OUTPUT=ISO
+ OUTPUT_URL=file:///home/zen/debian11-recovery.iso
+ BACKUP=BACULA
+ BACULA_CONF_DIR=”/opt/bacula/etc”
+ BACULA_BIN_DIR=”/opt/bacula/bin”
+ USE_STATIC_NETWORKING="Yes"
+ IP=192.168.200.41
+ NM=255.255.255.0
+ GW=192.168.200.200
+
+- Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+ guest or PowerVM LPAR): Hyper-V VM
+
+- Description of the issue (ideally so that others can reproduce
+ it):
+ Hello,
+
+Attempting to create a ReaR recovery environment to perform a restore
+using Bacula
+
+Latest output from sudo rear mkrescue -v
+
+ 2023-11-05 12:25:07.005672167 Including prep/BACULA/default/450_check_BACULA_client_configured.sh
+ 2023-11-05 12:25:07.008836829 Including prep/default/490_store_write_protect_settings.sh
+ 2023-11-05 12:25:07.011793294 Including prep/GNU/Linux/500_EFISTUB_check_kernel.sh
+ 2023-11-05 12:25:07.015053855 Including prep/BACULA/default/500_check_BACULA_bconsole_results.sh
+ 2023-11-05 12:25:07.029257686 ERROR: Bacula director debian11-DR6 is not responding.
+ ===== Stack trace =====
+ Trace 0: /usr/sbin/rear:696 main
+ Trace 1: /usr/share/rear/lib/mkrescue-workflow.sh:12 WORKFLOW_mkrescue
+ Trace 2: /usr/share/rear/lib/framework-functions.sh:129 SourceStage
+ Trace 3: /usr/share/rear/lib/framework-functions.sh:59 Source
+ Trace 4: /usr/share/rear/prep/BACULA/default/500_check_BACULA_bconsole_results.sh:21 source
+
+I think this is likely to be a configuration error as this system has
+Bacula installed and operational.
+
+After troubleshooting suggestions.
+
+Thank you.
+
+#### [ZENAdmin-Ops](https://github.com/ZENAdmin-Ops) commented at [2023-11-06 05:50](https://github.com/rear/rear/issues/3067#issuecomment-1794131801):
+
+Hello,
+
+Possibly the issue might be that I need to define a 'client' that the
+ReaR recovery environment will use when performing the restore.
+
+I must admit that I'm not entirely clear on this aspect of the
+configuration at present.
+
+#### [ZENAdmin-Ops](https://github.com/ZENAdmin-Ops) commented at [2023-11-07 23:12](https://github.com/rear/rear/issues/3067#issuecomment-1800350102):
+
+Hello,
+
+I've attempted some troubleshooting and this error appears to be a bug
+
+ sudo rear mkrescue -v
+ Relax-and-Recover 2.7 / 2022-07-13
+ Running rear mkrescue (PID 405169 date 2023-11-08 10:07:54)
+ Using log file: /var/log/rear/rear-debian11-DR6.log
+ Running workflow mkrescue on the normal/original system
+ Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
+ Using autodetected kernel '/boot/vmlinuz-5.10.0-26-amd64' as kernel in the recovery system
+ ERROR: Bacula director debian11-DR6 is not responding.
+
+ 2023-11-08 10:07:55.104444475 Including prep/BACULA/default/500_check_BACULA_bconsole_results.sh
+ 2023-11-08 10:07:55.134400311 ERROR: Bacula director debian11-DR6 is not responding.
+
+Here is the relevant code
+
+ # is the director server present? Fetch from $BACULA_CONF_DIR/bconsole.conf file
+ BACULA_DIRECTOR=$(grep -i address $BACULA_CONF_DIR/bconsole.conf | awk '{ print $3 }')
+ [ "${BACULA_DIRECTOR}" ] || Error "Director not defined in $BACULA_CONF_DIR/bconsole.conf"
+
+ # check if the director is responding?
+ if has_binary nc; then
+ DIRECTOR_RESULT=$(nc -vz "${BACULA_DIRECTOR}" 9101 2>&1 | grep -i connected | wc -l)
+ [[ $DIRECTOR_RESULT -eq 0 ]] && Error "Bacula director ${BACULA_DIRECTOR} is not responding."
+ fi
+
+ # does the director allow connections from this client? bconsole knows!
+ #
+ # We want these two lines to show that we can connect to the director
+ # and that the director can connect to the file daemon on this system.
+ # "Connecting to Director 'director_name-fd:9101'"
+ # "Connecting to Client 'bacula_client_name-fd at FQDN:9102"
+ BACULA_CLIENT=$(grep $(hostname -s) $BACULA_CONF_DIR/bacula-fd.conf | grep "\-fd" | awk '{print $3}' | sed -e "s/-fd//g")
+ [ "${BACULA_CLIENT}" ] || Error "Client $(hostname -s) not defined in $BACULA_CONF_DIR/bacula-fd.conf"
+
+ BACULA_RESULT=( $(echo -e " status client=${BACULA_CLIENT}-fd" | bconsole | grep Connect) )
+
+ director=${BACULA_RESULT[3]}
+ client=${BACULA_RESULT[9]}
+
+Here is the address from bconsole.conf
+
+ address = debian11-DR6
+
+Here is the output from the nc command
+
+ nc -vz debian11-dr6 9101
+ debian11-DR6.zen.local [192.168.200.40] 9101 (bacula-dir) opensudo
+
+#### [gdha](https://github.com/gdha) commented at [2023-11-08 06:21](https://github.com/rear/rear/issues/3067#issuecomment-1801162987):
+
+What is the return code of the command:
+
+ nc -vz debian11-dr6 9101
+ debian11-DR6.zen.local [192.168.200.40] 9101 (bacula-dir) opensudo
+
+Perhaps, we could use this instead of looking for "connected"?
+
+#### [ZENAdmin-Ops](https://github.com/ZENAdmin-Ops) commented at [2023-11-08 21:33](https://github.com/rear/rear/issues/3067#issuecomment-1802714651):
+
+Hello,
+
+Can you check the syntax of the 2nd line
+
+ nc -vz debian11-dr6 9101
+ debian11-DR6.zen.local [192.168.200.40] 9101 (bacula-dir) open
+ zen@debian11-DR6:~$ debian11-DR6.zen.local [192.168.200.40] 9101 (bacula-dir) opensudo
+ bash: syntax error near unexpected token `('
+
+#### [gdha](https://github.com/gdha) commented at [2023-11-09 07:06](https://github.com/rear/rear/issues/3067#issuecomment-1803270422):
+
+@ZENAdmin-Ops What you need to do is:
+
+> $ nc -vz debian11-dr6 9101
+> debian11-DR6.zen.local [192.168.200.40] 9101 (bacula-dir) open
+
+ echo $?
+
+#### [ZENAdmin-Ops](https://github.com/ZENAdmin-Ops) commented at [2023-11-09 09:23](https://github.com/rear/rear/issues/3067#issuecomment-1803457789):
+
+ nc -vz debian11-dr6 9101
+ debian11-DR6.zen.local [192.168.200.40] 9101 (bacula-dir) open
+ zen@debian11-DR6:~$ echo $?
+ 0
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-11-16 18:17](https://github.com/rear/rear/issues/3067#issuecomment-1814993866):
+
+Hi, is the check using "nc" even needed? Isn't the subsequent check
+using `bconsole` enough?
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-11-16 18:20](https://github.com/rear/rear/issues/3067#issuecomment-1814997545):
+
+I mean, doesn't answering the latter question
+
+ # does the director allow connections from this client? bconsole knows!
+
+also implicitly answer the question
+
+ # check if the director is responding?
+
+above it? presumably, if the director allow connections from this
+client, it is also responding.
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2024-01-16 02:10](https://github.com/rear/rear/issues/3067#issuecomment-1892968294):
+
+Stale issue message
+
+#### [ZENAdmin-Ops](https://github.com/ZENAdmin-Ops) commented at [2024-01-16 02:11](https://github.com/rear/rear/issues/3067#issuecomment-1892969285):
+
+This ticket can be closed
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-16 10:42](https://github.com/rear/rear/issues/3067#issuecomment-1893488536):
+
+@ZENAdmin-Ops for future users: what was the problem? And how was it
+solved?
+
+#### [ZENAdmin-Ops](https://github.com/ZENAdmin-Ops) commented at [2024-01-16 17:10](https://github.com/rear/rear/issues/3067#issuecomment-1894164406):
+
+I never really got that problem fixed, since I switched fairly quickly
+to running the restore from a bash script instead of trying to use the
+(very minimal) built in bacula support in rear. With that said from
+looking at the errors and the source code it looks like the problem is
+that Rear is searching for "connected" in the output of "nc" to check if
+the director is available, only nc doesn't ever actually say
+"connected". I'm guessing this code was written for an earlier version
+of nc that always had "connected" in its output if it was able to
+connect. Currently that nc command gives output like this:
+Connection to localhost (127.0.0.1) 9101 port \[tcp/bacula-dir\]
+succeeded!
+So it should really be searching for "succeeded" instead of "connected".
+
+Probably the issue could be fixed by changing
+DIRECTOR\_RESULT=$(nc -vz "${BACULA\_DIRECTOR}" 9101 2>&1 | grep -i
+connected | wc -l)
+to
+DIRECTOR\_RESULT=$(nc -vz "${BACULA\_DIRECTOR}" 9101 2>&1 | grep -i
+succeeded | wc -l)
+
+Although if nc ever changes its output it would break again... so it
+would seem like there should be a better way for it to check the
+connection rather than trying to parse nc's output. Also, a few lines
+down it checks the connection again using bconsole... so the first check
+is kind of unnecessary.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2023-11-12.3075.issue.closed.md b/docs/issues/2023-11-12.3075.issue.closed.md
new file mode 100644
index 00000000..547a05e8
--- /dev/null
+++ b/docs/issues/2023-11-12.3075.issue.closed.md
@@ -0,0 +1,185 @@
+[\#3075 Issue](https://github.com/rear/rear/issues/3075) `closed`: Add new BACKUP=VEEAM method
+==============================================================================================
+
+**Labels**: `enhancement`, `sponsored`, `no-issue-activity`
+
+#### 
[schlomo](https://github.com/schlomo) opened issue at [2023-11-12 19:16](https://github.com/rear/rear/issues/3075):
+
+### Discussed in [https://github.com/rear/rear/discussions/3071](https://github.com/rear/rear/discussions/3071)
+
+
+
+Originally posted by **idna38** November 7, 2023
+Hello,
+
+We like to request a Veeam Linux Client disaster recovery integration
+option with relax and recover.
+Our approach is to create a small PXE configuration for each single
+client, upload it to an NFS/PXE server and restore those
+systems with PXE and the Veeam Backup agent for Linux.
+
+Here is our procedure to run a successful backup and recovery with relax
+and recover:
+
+Client-side configuration
+=========================
+
+File /etc/rear/local.conf:
+
+OUTPUT=PXE
+OUTPUT\_PREFIX\_PXE=$HOSTNAME
+BACKUP=NETFS
+BACKUP\_URL=nfs://192.168.0.1/var/lib/tftpboot
+PXE\_TFTP\_URL=nfs://192.168.0.1/var/lib/tftpboot/
+PXE\_CONFIG\_URL=nfs://192.168.0.1/var/lib/tftpboot/pxelinux.cfg
+PXE\_RECOVER\_MODE="unattended"
+
+PXE\_CONFIG\_GRUB\_STYLE=y
+PXE\_TFTP\_IP=192.168.0.1
+SSH\_ROOT\_PASSWORD=changeme
+USING\_UEFI\_BOOTLOADER=1
+COPY\_AS\_IS+=( /usr/share/rear/\* /etc/veeam/\* /usr/bin/veeam\*
+/usr/lib/veeam/\* /usr/sbin/veeam\* /usr/share/veeam/\*
+/usr/share/doc/veeam/\* )
+
+Backup procedure
+================
+
+rear -v mkbackup
+
+After the backup task is completed, it should have created a PXE
+configuration file with initrd, vmlinuz kernel files on the NFS/PXE
+server.
+
+**Example:**
+\[root@rhel8-veeam-rear tftp\]\# cat 01-02-a7-18-00-00-13
+default hd
+prompt 1
+timeout 300
+
+label hd
+localboot -1
+say ENTER - boot local hard disk
+say
+--------------------------------------------------------------------------------
+display /rhel8-veeam-rear.message
+say ----------------------------------------------------------
+say rear = disaster recover this system with Relax-and-Recover
+label rear
+kernel /rhel8-veeam-rear.kernel
+append initrd=/rhel8-veeam-rear.initrd.cgz root=/dev/ram0 vga=normal rw
+selinux=0 console=ttyS0,9600 console=tty0
+\[root@rhel8-veeam-rear tftp\]\#
+
+Restore Procedure
+=================
+
+- Boot the system with network boot/PXE
+- Login with root user and the password which was provided in the
+ local.conf file from the client to restore.
+- Start the initial restore for disk, filesystem partitions, hostname
+ and original network configuration like DHCP/STATIC
+- Start Veeam Service
+- Recover Data with Veeam Agent for Linux
+- Rewrite Grub Bootloader
+- SELinux (Optionally)
+- Reboot the system
+- Verify functionality
+
+Commands to use
+===============
+
+- rear recover
+
+- systemctl start veeamservice
+
+- 'veeamconfig vbrServer add --name --address
+ --domain --login Administrator (IP und
+ Hostname von Veeam Server) --password '
+
+- veeamconfig backup list --all (Always use the last backup ID
+ Example:
+
+- veeamconfig backup mount --id {Use same the mount-id which was
+ provided from the previous command)}
+
+: Info:
+This could raise an error, because the software want´s to mount the
+device in read/write mode, which is not allowed.
+
+:The device was only mounted as veeamloop device and needs to be
+remounted agains as read-only device for recovery
+
+- veeammount -d /tmp/veeamflr//FileLevelBackup\_0 -p /mnt/backup
+ -o ro -m (-d und -p können per mount command gesucht werden)
+
+Final recovery procedure
+========================
+
+Recover the files from /mnt/backup to /mnt/local
+================================================
+
+shopt -s dotglob
+cp -rpva /mnt/backup/\* /mnt/local/ \# Copyjob time can depend of the
+amount of data :)
+
+Chroot and rewrite the GRUB Bootloader
+======================================
+
+chroot /mnt/local
+sudo dnf reinstall shim-\* grub2-\*
+exit (von rear console)
+
+Did you restore the backup to /mnt/local ? Are you ready to continue
+recovery ? yes
+
+After this "umount -a" and "reboot"
+SELinux will be relabeled if necessarry
+
+Last Post Task:
+Add the client/server back to an Veeam Protection Group with an XML
+file:
+-- veeamconfig mode setVbrSettings --cfg
+
+Please let us know, how we can proceed on this or if we can get some
+help from the community.
+Any answer is kindly appreciated.
+
+Thanks and best regards,
+Andreas
+
+#### [schlomo](https://github.com/schlomo) commented at [2023-11-12 19:34](https://github.com/rear/rear/issues/3075#issuecomment-1807218361):
+
+@idna38 just to clarify how Veeam works: it mounts a virtual file system
+that we can use to copy all files and folders back onto the freshly
+formatted disks? How does it handle multiple file systems on the
+original server, extended file attributes and stuff like that? What
+about sparse files and hard links?
+
+Is it important to stop this mount (see
+[https://helpcenter.veeam.com/docs/agentforlinux/userguide/files\_restore\_cmd\_backup\_umount.html?ver=60](https://helpcenter.veeam.com/docs/agentforlinux/userguide/files_restore_cmd_backup_umount.html?ver=60))
+or OK to leave it open?
+
+I'm also wondering why just mounting the backup as described in
+[https://helpcenter.veeam.com/docs/agentforlinux/userguide/files\_restore\_cmd\_backup\_mount.html?ver=60](https://helpcenter.veeam.com/docs/agentforlinux/userguide/files_restore_cmd_backup_mount.html?ver=60)
+is not enough.
+
+Is there maybe another command that would simply extract (like `tar -x`)
+this Veeam backup to a directory, without mounting it first? That might
+give us more control over the process and it might be faster, too.
+
+#### [schlomo](https://github.com/schlomo) commented at [2023-11-12 21:25](https://github.com/rear/rear/issues/3075#issuecomment-1807244344):
+
+@idna38 would it be worth exploring these "recovery tokens" as a way to
+facilitate authentication for the agent without granting full access to
+credentials stored on the rescue media?
+
+
+#### [github-actions](https://github.com/apps/github-actions) commented at [2024-01-12 02:10](https://github.com/rear/rear/issues/3075#issuecomment-1888304232):
+
+Stale issue message
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2023-11-21.3089.pr.merged.md b/docs/issues/2023-11-21.3089.pr.merged.md
new file mode 100644
index 00000000..33bcb4a0
--- /dev/null
+++ b/docs/issues/2023-11-21.3089.pr.merged.md
@@ -0,0 +1,376 @@
+[\#3089 PR](https://github.com/rear/rear/pull/3089) `merged`: New RECOVERY\_COMMANDS array
+==========================================================================================
+
+**Labels**: `enhancement`, `fixed / solved / done`
+
+#### [jsmeix](https://github.com/jsmeix) opened issue at [2023-11-21 14:26](https://github.com/rear/rear/pull/3089):
+
+New RECOVERY\_COMMANDS array that specifies 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.
+
+- Type: **Enhancement**
+
+- Impact: **Normal**
+
+- Reference to related issue (URL):
+ [https://github.com/rear/rear/issues/2942](https://github.com/rear/rear/issues/2942)
+ [https://github.com/rear/rear/pull/3070\#discussion\_r1397363473](https://github.com/rear/rear/pull/3070#discussion_r1397363473)
+
+- How was this pull request tested?
+
+Seems to work OK for me so far
+with the defaults (in default.conf)
+and also with (excerpt)
+
+ ISO_RECOVER_MODE=unattended
+ ISO_DEFAULT=automatic
+ RECOVERY_COMMANDS=( "echo 'rear -Dn recover' in $USER_INPUT_INTERRUPT_TIMEOUT seconds" "sleep $USER_INPUT_INTERRUPT_TIMEOUT" "rear -Dn recover" )
+ RECOVERY_COMMANDS_LABEL="rear -Dn recover"
+ REBOOT_COMMANDS=( "echo poweroff in $USER_INPUT_UNATTENDED_TIMEOUT seconds" "sleep $USER_INPUT_UNATTENDED_TIMEOUT" "poweroff" )
+ REBOOT_COMMANDS_LABEL="poweroff"
+
+- Description of the changes in this pull request:
+
+In skel/default/etc/scripts/system-setup
+added RECOVERY\_COMMANDS (plus RECOVERY\_COMMANDS\_LABEL)
+and in default.conf set and describe defaults
+so that manual "rear recover" behaves as before.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-11-22 15:55](https://github.com/rear/rear/pull/3089#issuecomment-1823035601):
+
+At least for me my current code in
+\[skel/default\]/etc/scripts/system-setup
+seems to work rather well (likely not yet perfect).
+
+Because currently there is nothing in default.conf
+for RECOVERY\_COMMANDS I test with things like (excerpt)
+
+ #ISO_RECOVER_MODE=unattended
+ #ISO_DEFAULT=automatic
+ RECOVERY_COMMANDS=( 'echo rear $rear_options recover in $USER_INPUT_INTERRUPT_TIMEOUT seconds'
+ 'sleep $USER_INPUT_INTERRUPT_TIMEOUT'
+ 'rear $rear_options recover' )
+ RECOVERY_COMMANDS_LABEL='rear $rear_options recover'
+ REBOOT_COMMANDS=( 'echo poweroff in $USER_INPUT_UNATTENDED_TIMEOUT seconds'
+ 'sleep $USER_INPUT_UNATTENDED_TIMEOUT'
+ 'poweroff' )
+ REBOOT_COMMANDS_LABEL='poweroff'
+ #USER_INPUT_INTERRUPT_TIMEOUT=11
+ #USER_INPUT_UNATTENDED_TIMEOUT=7
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-11-23 15:30](https://github.com/rear/rear/pull/3089#issuecomment-1824618613):
+
+@jsmeix your PR should add a default value for `RECOVERY_COMMANDS` to
+default.conf, I suspect that that's why the CI tests are failing.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-11-23 15:42](https://github.com/rear/rear/pull/3089#issuecomment-1824635680):
+
+I believe this will be very useful especially for automated testing. One
+will be able to inject flags like -D or -d, and even test another
+recovery system commands, like `rear mountonly`, or perform examination
+of the recovery system (saving logs etc).
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-11-27 06:35](https://github.com/rear/rear/pull/3089#issuecomment-1827205162):
+
+@pcahyna
+currently there is nothing in default.conf for RECOVERY\_COMMANDS
+because currently this pull request is a work in progress draft.
+Soon I will add defaults for RECOVERY\_COMMANDS
+and RECOVERY\_COMMANDS\_LABEL together with
+a description what that thingy is good for...
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-11-27 11:39](https://github.com/rear/rear/pull/3089#issuecomment-1827666718):
+
+I will test with the defaults and if this works OK for me
+I change it from "Draft" to "Ready for review".
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-11-29 06:35](https://github.com/rear/rear/pull/3089#issuecomment-1831301454):
+
+I tested with the defaults and it works well for me.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-01 10:23](https://github.com/rear/rear/pull/3089#issuecomment-1835839323):
+
+@rear/contributors
+I would like to merge it next Monday afternoon
+unless there are objections.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-01 13:04](https://github.com/rear/rear/pull/3089#issuecomment-1836088264):
+
+@jsmeix please squash commits e7467178ce91b552b3d2d455f4f04a0406156903
+and 2aba2a38860cbc27802eb01c34398a87800d9206 and force push, it is
+confusing in the history (for example in the `git log -u` output if
+there is addition of new code and then deletion of the old code).
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-04 13:14](https://github.com/rear/rear/pull/3089#issuecomment-1838622840):
+
+@rear/contributors
+of course I will not merge it
+until the comments were properly addressed
+which I will do as time permits...
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-06 12:40](https://github.com/rear/rear/pull/3089#issuecomment-1842786614):
+
+A final test with
+
+ ISO_RECOVER_MODE=unattended
+ ISO_DEFAULT=automatic
+ OUTPUT=ISO
+
+and the default RECOVERY\_COMMANDS and REBOOT\_COMMANDS
+worked well for me
+so I will merge it.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-06 13:09](https://github.com/rear/rear/pull/3089#issuecomment-1842847838):
+
+@jsmeix please see the note about rebase and squash.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-06 13:12](https://github.com/rear/rear/pull/3089#issuecomment-1842852393):
+
+maybe you can actually squash all the commits together because the
+latter commits merely fix problems with the earlier commits and we don't
+need all the commits in the history?
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-06 13:16](https://github.com/rear/rear/pull/3089#issuecomment-1842860274):
+
+> A final test with
+>
+> ISO_RECOVER_MODE=unattended
+> ISO_DEFAULT=automatic
+> OUTPUT=ISO
+>
+> and the default RECOVERY\_COMMANDS and REBOOT\_COMMANDS
+
+That's what the CI test actually does, so you maybe don't need to spend
+time on this kind of test (unless you want to test specifically on SUSE
+distributions, the CI runs on Fedora and CentOS).
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-06 13:40](https://github.com/rear/rear/pull/3089#issuecomment-1842911293):
+
+I squashed all the commits together.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-07 10:18](https://github.com/rear/rear/pull/3089#issuecomment-1845066143):
+
+A further side note regarding
+[https://github.com/rear/rear/pull/3089\#discussion\_r1413862335](https://github.com/rear/rear/pull/3089#discussion_r1413862335)
+(i.e. using 'eval echo')
+and
+[https://github.com/rear/rear/pull/3089\#discussion\_r1414329071](https://github.com/rear/rear/pull/3089#discussion_r1414329071)
+(i.e. using 'envsubst')
+to evaluate nested variable values:
+
+Neither 'eval' nor 'envsubst' properly evaluate
+even deeper nested variable values:
+
+ # export toplevel='toplevel with $indirection1'
+
+ # export indirection1='indirection1 with $indirection2'
+
+ # export indirection2='no further indirection'
+
+ # echo $toplevel
+ toplevel with $indirection1
+
+ # eval echo $toplevel
+ toplevel with indirection1 with $indirection2
+
+ # eval eval echo $toplevel
+ toplevel with indirection1 with no further indirection
+
+ # echo $toplevel | envsubst
+ toplevel with indirection1 with $indirection2
+
+ # echo $toplevel | envsubst | envsubst
+ toplevel with indirection1 with no further indirection
+
+When one knows the varaiable names one could do
+
+ # indirection1_evaluated="${toplevel//'$indirection1'/$indirection1}"
+
+ # indirection2_evaluated="${indirection1_evaluated//'$indirection2'/$indirection2}"
+
+ # echo $indirection2_evaluated
+ toplevel with indirection1 with no further indirection
+
+Perhaps I should do the latter for 'rear\_options' like
+
+ # command='rear $rear_options workflow'
+
+ # rear_options='-v'
+
+ # echo "Running '${command//\$rear_options/$rear_options}' automatically"
+ Running 'rear -v workflow' automatically
+
+I don't know what is better:
+
+ # echo "... '${var//'$nested'/$nested}' ..."
+
+or
+
+ # echo "... '${var//\$nested/$nested}' ..."
+
+To me the latter code looks more clear.
+
+'${parameter//pattern/string}' is old bash functionality
+(I tested it also on SLES 10 SP4 with GNU bash 3.1.17).
+
+The 'rear\_options' value is safe because we set it in
+\[usr/share/rear/skel/default\]/etc/scripts/system-setup
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-07 10:46](https://github.com/rear/rear/pull/3089#issuecomment-1845112303):
+
+> A further side note regarding [\#3089
+> (comment)](https://github.com/rear/rear/pull/3089#discussion_r1413862335)
+> (i.e. using 'eval echo') and [\#3089
+> (comment)](https://github.com/rear/rear/pull/3089#discussion_r1414329071)
+> (i.e. using 'envsubst') to evaluate nested variable values:
+>
+> Neither 'eval' nor 'envsubst' properly evaluate even deeper nested
+> variable values:
+
+But this is proper behavior! Shell itself does not evaluate this. As
+shown in your first example, below. So `eval`, which evaluates the
+string as interpreted by the shell, should not do it either. It would be
+very unsafe if the shell interpreted variable references recursively.
+
+> # export toplevel='toplevel with $indirection1'
+>
+> # export indirection1='indirection1 with $indirection2'
+>
+> # export indirection2='no further indirection'
+>
+> # echo $toplevel
+> toplevel with $indirection1
+
+(...)
+
+> When one knows the varaiable names one could do
+>
+> # indirection1_evaluated="${toplevel//'$indirection1'/$indirection1}"
+>
+> # indirection2_evaluated="${indirection1_evaluated//'$indirection2'/$indirection2}"
+>
+> # echo $indirection2_evaluated
+> toplevel with indirection1 with no further indirection
+>
+> Perhaps I should do the latter for 'rear\_options' like
+
+What is the problem you are trying to solve? We don't have any nested
+variable references like this currently. The `rear_options` value does
+not contain any variable reference. So, what would you need evaluation
+of deeply nested variable references for?
+
+> # command='rear $rear_options workflow'
+>
+> # rear_options='-v'
+>
+> # echo "Running '${command//\$rear_options/$rear_options}' automatically"
+> Running 'rear -v workflow' automatically
+>
+> I don't know what is better:
+>
+> # echo "... '${var//'$nested'/$nested}' ..."
+>
+> or
+>
+> # echo "... '${var//\$nested/$nested}' ..."
+>
+> To me the latter code looks more clear.
+>
+> '${parameter//pattern/string}' is old bash functionality (I tested it
+> also on SLES 10 SP4 with GNU bash 3.1.17).
+>
+> The 'rear\_options' value is safe because we set it in
+> \[usr/share/rear/skel/default\]/etc/scripts/system-setup
+
+I thought you wanted to keep the code simple, i.e. no attempts at
+variable replacement in the displayed string? Anyway, if you want to
+perform replacement anyway, I think the latter code is clearer. Too many
+single quotes in the former.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-07 10:58](https://github.com/rear/rear/pull/3089#issuecomment-1845130303):
+
+A remark regarding squashing commits:
+
+While squashing commits makes the history
+of the master branch look cleaner
+it seems it causes that the squashed commits
+(i.e. commits "inside" a pull request)
+become somewhat "dangling" or "orphaned" to some extent
+because e.g. for
+[https://github.com/rear/rear/commit/b131e473807f28c051f1c019d17d63c245a406da](https://github.com/rear/rear/commit/b131e473807f28c051f1c019d17d63c245a406da)
+the GitHub web frontend shows
+
+ This commit does not belong to any branch on this repository,
+ and may belong to a fork outside of the repository.
+
+Walking back the chain of parents finally leads to
+[https://github.com/rear/rear/commit/09c81c9f93fe6a76e9e35122e2ff45f1427c1e8f](https://github.com/rear/rear/commit/09c81c9f93fe6a76e9e35122e2ff45f1427c1e8f)
+which points to the wrong pull request,
+i.e. not the one where
+[https://github.com/rear/rear/commit/b131e473807f28c051f1c019d17d63c245a406da](https://github.com/rear/rear/commit/b131e473807f28c051f1c019d17d63c245a406da)
+belongs to (which is this pull request here).
+
+In contrast without squashing commits
+for a commit "inside" a pull request like
+[https://github.com/rear/rear/commit/4960ca8b4bbc5d8346470f54be289d7482e3eaf4](https://github.com/rear/rear/commit/4960ca8b4bbc5d8346470f54be289d7482e3eaf4)
+the GitHub web frontend shows `master (#3070)` with links
+
+ [master](https://github.com/rear/rear) ([#3070](https://github.com/rear/rear/pull/3070))
+
+so without squashing for commits "inside" a pull request
+it is still visible to what pull request they belong.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-07 11:04](https://github.com/rear/rear/pull/3089#issuecomment-1845140868):
+
+> A remark regarding squashing commits:
+>
+> While squashing commits makes the history of the master branch look
+> cleaner it seems it causes that the squashed commits (i.e. commits
+> "inside" a pull request) become somewhat "dangling" or "orphaned" to
+> some extent because e.g. for
+> [b131e47](https://github.com/rear/rear/commit/b131e473807f28c051f1c019d17d63c245a406da)
+> the GitHub web frontend shows
+>
+> This commit does not belong to any branch on this repository,
+> and may belong to a fork outside of the repository.
+
+I see. The problem seems to be that the WebUI
+[https://github.com/rear/rear/pull/3089/commits](https://github.com/rear/rear/pull/3089/commits)
+still shows b131e473807f28c051f1c019d17d63c245a406da, but it is
+dangling, which is not intuitive.
+
+IMO, the right solution is to squash the commits yourself locally and
+force push. Then merge in the WebUI without using the squash option.
+This will update
+[https://github.com/rear/rear/pull/3089/commits](https://github.com/rear/rear/pull/3089/commits)
+with the new commits that also the merged history will contain.
+b131e473807f28c051f1c019d17d63c245a406da would not be visible at all,
+instead of it you would see the squashed commit(s) under
+[https://github.com/rear/rear/pull/3089/commits](https://github.com/rear/rear/pull/3089/commits).
+Would that work?
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-07 11:15](https://github.com/rear/rear/pull/3089#issuecomment-1845156130):
+
+Regarding properly evaluating nested variables:
+
+I only liked to show that there is no proper way to
+evaluate (possibly even deeper) nested variables
+so in general it is useless to try to do that.
+
+Only under known restricted/controlled conditions
+nested variables can be properly evaluated.
+
+Currently I don't know if I will ever implement
+
+ ${command//\$rear_options/$rear_options}
+
+but at least I know that this specific case is feasible.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2023-11-23.3091.pr.merged.md b/docs/issues/2023-11-23.3091.pr.merged.md
new file mode 100644
index 00000000..4d6b3aa6
--- /dev/null
+++ b/docs/issues/2023-11-23.3091.pr.merged.md
@@ -0,0 +1,72 @@
+[\#3091 PR](https://github.com/rear/rear/pull/3091) `merged`: Let is\_write\_protected() report devices without device node as not write protected
+==================================================================================================================================================
+
+**Labels**: `enhancement`, `bug`, `cleanup`, `fixed / solved / done`
+
+#### [jsmeix](https://github.com/jsmeix) opened issue at [2023-11-23 10:00](https://github.com/rear/rear/pull/3091):
+
+- Type: **Bug Fix** / **Enhancement**
+
+- Impact: **Normal**
+
+- Reference to related issue (URL):
+ [https://github.com/rear/rear/issues/3085](https://github.com/rear/rear/issues/3085)
+
+- How was this pull request tested?
+
+I don't know how I could test it.
+I cannot reproduce the matching issue
+because I don't have a system with /sys/block/nvme0c0n1
+or something similar - i.e. where a /sys/block/device
+does not have a matching /dev/device.
+
+- Description of the changes in this pull request:
+
+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](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.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-11-23 10:17](https://github.com/rear/rear/pull/3091#issuecomment-1824128136):
+
+@pcahyna
+could you please have a look here (as time permits)
+because I don't know how to test it as I don't have a system
+with /sys/block/nvme0c0n1 or something similar
+i.e. where a /sys/block/device does not have a matching /dev/device
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-11-23 16:21](https://github.com/rear/rear/pull/3091#issuecomment-1824686831):
+
+Oops - I did it again ;-)
+
+Because I got confused by the former helper functions
+where all used `$device` but with changed meanings
+I needed to clean up things so that at least I can
+better understand what goes on to be able to fix
+issues that I can neither reproduce nor test
+with a higher probability that my fix actually works.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-11-23 16:23](https://github.com/rear/rear/pull/3091#issuecomment-1824689599):
+
+I did some tests on my test system
+and things worked so far at least for me
+so it is now (hopefully) not totally broken.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-18 10:34](https://github.com/rear/rear/pull/3091#issuecomment-1898217234):
+
+I wanted to test it more but I don't find time for that so
+[https://github.com/rear/rear/pull/3091\#issuecomment-1824689599](https://github.com/rear/rear/pull/3091#issuecomment-1824689599)
+must suffice and I like to merge it tomorrow afternoon
+unless there are objections from other @rear/contributors
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2023-12-01.3097.pr.merged.md b/docs/issues/2023-12-01.3097.pr.merged.md
new file mode 100644
index 00000000..bcfc8df5
--- /dev/null
+++ b/docs/issues/2023-12-01.3097.pr.merged.md
@@ -0,0 +1,185 @@
+[\#3097 PR](https://github.com/rear/rear/pull/3097) `merged`: Bump redhat-plumbers-in-action/differential-shellcheck from 4.2.2 to 5.0.2
+========================================================================================================================================
+
+**Labels**: `fixed / solved / done`, `dependencies`
+
+#### [dependabot](https://github.com/apps/dependabot) opened issue at [2023-12-01 11:53](https://github.com/rear/rear/pull/3097):
+
+Bumps
+[redhat-plumbers-in-action/differential-shellcheck](https://github.com/redhat-plumbers-in-action/differential-shellcheck)
+from 4.2.2 to 5.0.2.
+
+
+
+Release notes
+Sourced from redhat-plumbers-in-action/differential-shellcheck's releases.
+++v5.0.2
+What's Changed
+Dependency Updates
++
+ +- Update csutils to
+3.1.0(#339)@jamacku- build(deps): bump fedora from
+38to39(#332)@dependabot+
+ +- build(deps): bump test/bats from
+f1f5115toe9fd17a(#333)@dependabot- build(deps): bump redhat-plumbers-in-action/advanced-issue-labeler from 2.0.7 to 2.1.0 (#334)
+@dependabot- build(deps): bump ossf/scorecard-action from 2.2.0 to 2.3.1 (#335)
+@dependabot- build(deps): bump docker/build-push-action from 5.0.0 to 5.1.0 (#336)
+@dependabot- build(deps): bump github/codeql-action from 2.22.5 to 2.22.8 (#337)
+@dependabot- build(deps): bump super-linter/super-linter from 5.6.0 to 5.7.1 (#338)
+@dependabot- build(deps): bump github/codeql-action from 2.21.9 to 2.22.5 (#325)
+@dependabot- build(deps): bump actions/checkout from 4.1.0 to 4.1.1 (#326)
+@dependabot- build(deps): bump super-linter/super-linter from 5.3.1 to 5.6.0 (#327)
+@dependabot- build(deps): bump release-drafter/release-drafter from 5.24.0 to 5.25.0 (#328)
+@dependabot- build(deps): bump redhat-plumbers-in-action/advanced-issue-labeler from 2.0.6 to 2.0.7 (#329)
+@dependabot- build(deps): bump test/bats from
+360c1eatof1f5115(#330)@dependabotFull Changelog: https://github.com/redhat-plumbers-in-action/differential-shellcheck/compare/v5.0.1...v5.0.2
+v5.0.1
+What's Changed
+Bug Fixes
++
+- Drop support for DEBUG in grep :bug: (#322)
+@jamacku- Fix incorrect log about fixed issues :wood: (#323)
+@jamackuFull Changelog: https://github.com/redhat-plumbers-in-action/differential-shellcheck/compare/v5.0.0...v5.0.1
+v5.0.0
+What's Changed
+Breaking
++
+- drop:
+ignored-codesinput :no_entry_sign: (#290)@jamacku- drop:
+shell-scriptsinput :no_entry_sign: (#288)@jamackuNew
+ + +
... (truncated)
+
+
+Changelog
+Sourced from redhat-plumbers-in-action/differential-shellcheck's changelog.
+++Changelog
+Next release
+v5.0.2
++
+- Container images now based on Fedora 39
+- Update
+csutils(csdiff) to 3.1.0v5.0.0
++
+- Added defect statistics based on severity levels. They are available in the console output and in the job Summary page.
+- New option
+scan-directory. Allows to specify directories that will be scanned. By default Differential ShellCheck scans the whole repository.- Show more context for ShellCheck defects and fixes in console output. The defect is now shown in the context of the surrounding code.
+- Fix autodetection of shell scripts in DEBUG mode
+- Fix detection of changed files that might cause failure on paths with special characters.
+- Fix count of scanned files in job Summary when running on push event.
+- Drop support for
+shell-scriptsinput- Drop support for
+ignored-codesinput- Update
+csutils(csdiff) to 3.0.4v4.2.2
++
+- Container images now based on Fedora 38 +
++
+- +
ShellCheck-0.8.0 -> 0.9.0- +
csutils-3.0.0 -> 3.0.2v4.2.1
++
+- Handle multiple include/exclude paths with newlines
+v4.2.0
++
+- New option
+exclude-path. Allows to specify list of paths excluded from ShellCheck scanning. It supports globbing and brace expansion. e.g.test/{test1,test2}/**- New option
+include-path. Similar toexclude-path, it allows specifying the list of paths that will be included into scanning. No further checks are performed. +It supports globbing and brace expansion. e.g.fixture/**.fixturev4.1.0
++
+- +
grep- do not escape#and!in patterns- Utilize
+DEBUGto rungrepwithout--silentoption- Update
+csutils(csdiff) to 3.0.0v4.0.2
++
+- Correctly handle character escaping in filenames (e.g.
+␣and&)- Improve documentation and more tests
+v4.0.0
+ +
... (truncated)
+
+
+Commits
+-
+
91e2582v5.0.2
+7057a68deps: update csutils to 3.1.0
+03a5e6bbuild(deps): bump fedora from38to39
+ae5c394build(deps): bump test/bats fromf1f5115toe9fd17a
+d9b742abuild(deps): bump redhat-plumbers-in-action/advanced-issue-labeler
+ad4e382build(deps): bump ossf/scorecard-action from 2.2.0 to 2.3.1
+d2737b9build(deps): bump docker/build-push-action from 5.0.0 to 5.1.0
+96315e2build(deps): bump github/codeql-action from 2.22.5 to 2.22.8
+789ffb6build(deps): bump super-linter/super-linter from 5.6.0 to 5.7.1
+94126cbbuild(deps): bump github/codeql-action from 2.21.9 to 2.22.5
+- Additional commits viewable in compare view +
+ +[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) + +Dependabot will resolve any conflicts with this PR as long as you don't +alter it yourself. You can also trigger a rebase manually by commenting +`@dependabot rebase`. + +------------------------------------------------------------------------ + +
+
+ +You can trigger Dependabot actions by commenting on this PR: + +- `@dependabot rebase` will rebase this PR +- `@dependabot recreate` will recreate this PR, overwriting any edits + that have been made to it +- `@dependabot merge` will merge this PR after your CI passes on it +- `@dependabot squash and merge` will squash and merge this PR after + your CI passes on it +- `@dependabot cancel merge` will cancel a previously requested merge + and block automerging +- `@dependabot reopen` will reopen this PR if it is closed +- `@dependabot close` will close this PR and stop Dependabot + recreating it. You can achieve the same result by closing it + manually +- `@dependabot show ignore conditions` will show all
+ of the ignore conditions of the specified dependency
+- `@dependabot ignore this major version` will close this PR and stop
+ Dependabot creating any more for this major version (unless you
+ reopen the PR or upgrade to it yourself)
+- `@dependabot ignore this minor version` will close this PR and stop
+ Dependabot creating any more for this minor version (unless you
+ reopen the PR or upgrade to it yourself)
+- `@dependabot ignore this dependency` will close this PR and stop
+ Dependabot creating any more for this dependency (unless you reopen
+ the PR or upgrade to it yourself)
+
+
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2023-12-01.3098.issue.closed.md b/docs/issues/2023-12-01.3098.issue.closed.md
new file mode 100644
index 00000000..cef0bc5f
--- /dev/null
+++ b/docs/issues/2023-12-01.3098.issue.closed.md
@@ -0,0 +1,245 @@
+[\#3098 Issue](https://github.com/rear/rear/issues/3098) `closed`: OUTPUT\_URL=file://... conflicts with OUTPUT=USB but ReaR does not error out appropriately
+=============================================================================================================================================================
+
+**Labels**: `bug`, `fixed / solved / done`
+
+#### Dependabot commands and options
++ +You can trigger Dependabot actions by commenting on this PR: + +- `@dependabot rebase` will rebase this PR +- `@dependabot recreate` will recreate this PR, overwriting any edits + that have been made to it +- `@dependabot merge` will merge this PR after your CI passes on it +- `@dependabot squash and merge` will squash and merge this PR after + your CI passes on it +- `@dependabot cancel merge` will cancel a previously requested merge + and block automerging +- `@dependabot reopen` will reopen this PR if it is closed +- `@dependabot close` will close this PR and stop Dependabot + recreating it. You can achieve the same result by closing it + manually +- `@dependabot show
[malvinas2](https://github.com/malvinas2) opened issue at [2023-12-01 22:27](https://github.com/rear/rear/issues/3098):
+
+- ReaR version ("/usr/sbin/rear -V"):
+ `Relax-and-Recover 2.7-git.5333.0fd8a77a.master / 2023-12-01` (last
+ master)
+
+- OS version ("cat /etc/os-release" or "lsb\_release -a" or "cat
+ /etc/rear/os.conf"):
+ `Ubuntu 22.04.3 LTS`
+
+- 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
+ BACKUP_PROG_EXCLUDE=( "${BACKUP_PROG_EXCLUDE[@]}" '/meinesachen/*')
+ EXCLUDE_MOUNTPOINTS=(/media/disc)
+ EXCLUDE_MD=("/dev/md0" "/dev/md1" "/dev/md2" "/dev/md3" "/dev/md4")
+ EXCLUDE_VG=(lvraid)
+
+- Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+ guest or PowerVM LPAR):
+ `PC, Motherboard Gigabyte B560M DS3H V2`
+
+- System architecture (x86 compatible or PPC64/PPC64LE or what exact
+ ARM device):
+ `Intel Pentium Gold G6400`
+
+- Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or
+ ELILO or Petitboot):
+ `GRUB using UEFI`
+
+- Storage layout ("lsblk -ipo
+ NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
+ [https://pastebin.com/raw/1g1SpQwm](https://pastebin.com/raw/1g1SpQwm)
+
+- Description of the issue (ideally so that others can reproduce it):
+
+1. Plug in an USB-stick
+2. Format it using `rear format -- --efi /dev/sdg`
+3. Start ReaR using `/usr/sbin/rear -v mkbackup`
+4. Abort due to an error:
+
+
+
+ BUG in /usr/share/rear/output/USB/Linux-i386/850_make_USB_bootable.sh line 63:
+ 'Filesystem where the booting related files are on /dev/sdg could not be found'
+
+See complete output:
+[https://pastebin.com/raw/rRdvnQDs](https://pastebin.com/raw/rRdvnQDs)
+
+- What I have tried:
+
+1. tried two different USB-Sticks, fresh out-of-the box
+
+2.
+
+
+
+ mkdir -p /mnt/rear_test
+ mount /dev/disk/by-label/REAR-000 /mnt/rear_test
+ cat /proc/mounts
+
+shows
+`/dev/sdg2 /mnt/rear_test ext3 rw,relatime 0 0`
+so I don't understand why the case conditional statement
+"$usb\_filesystem" in line 32 of file
+`/usr/share/rear/output/USB/Linux-i386/850_make_USB_bootable.sh` doesn't
+find "ext3". I inserted a "sleep 2" before the definition of
+usb\_filesystem, no change
+
+- Attachments, as applicable ("rear -D mkrescue/mkbackup/recover"
+ debug log files):
+ Log of /var/log/rear/rear-jammy.log at
+ [https://pastebin.com/raw/1MFiqdd1](https://pastebin.com/raw/1MFiqdd1)
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-04 11:59](https://github.com/rear/rear/issues/3098#issuecomment-1838490741):
+
+`usb_filesystem` gets assigned here:
+
+[https://github.com/rear/rear/blob/0fd8a77add3d5c4dec44393abca847e33b2f47fe/usr/share/rear/output/USB/Linux-i386/850\_make\_USB\_bootable.sh\#L31](https://github.com/rear/rear/blob/0fd8a77add3d5c4dec44393abca847e33b2f47fe/usr/share/rear/output/USB/Linux-i386/850_make_USB_bootable.sh#L31)
+
+please show the output of
+`grep " /var/tmp/rear.xDPgkw0v4eTr9Dy/outputfs " /proc/mounts` -
+hopefully we will see what is the problem from there.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-04 12:11](https://github.com/rear/rear/issues/3098#issuecomment-1838508697):
+
+I see something suspect in the log:
+
+ 2023-12-01 22:55:26.566790320 Including prep/NETFS/default/980_umount_NETFS_dir.sh
+ 2023-12-01 22:55:26.571158792 Unmounting '/var/tmp/rear.xDPgkw0v4eTr9Dy/outputfs'
+
+I would expect to see outputfs mounted again, but there is just
+
+ 2023-12-01 22:57:06.984775757 Including output/default/100_mount_output_path.sh
+
+and no log message from it.
+
+I suspect outputfs is not mounted at this point.
+
+Can you please rerun `rear mkrescue` with `-D` and provide the complete
+output?
+
+#### [malvinas2](https://github.com/malvinas2) commented at [2023-12-04 22:39](https://github.com/rear/rear/issues/3098#issuecomment-1839636945):
+
+Outputs and debug logs of mkrescue and mkbackup:
+[output\_mkrescue.txt](https://github.com/rear/rear/files/13552165/output_mkrescue.txt)
+[rear-jammy\_\_mkrescue\_d.log](https://github.com/rear/rear/files/13552167/rear-jammy__mkrescue_d.log)
+[output\_mkbackup.txt](https://github.com/rear/rear/files/13552168/output_mkbackup.txt)
+[rear-jammy\_\_mkbackup\_d.log](https://github.com/rear/rear/files/13552166/rear-jammy__mkbackup_d.log)
+
+#### [malvinas2](https://github.com/malvinas2) commented at [2023-12-04 22:41](https://github.com/rear/rear/issues/3098#issuecomment-1839641861):
+
+> please show the output of
+> `grep " /var/tmp/rear.xDPgkw0v4eTr9Dy/outputfs " /proc/mounts` -
+> hopefully we will see what is the problem from there.
+
+Well, there is no output...
+
+ root@jammy:~# grep "/var/tmp/rear.sp5QVNiZuk6Ml7v/outputfs/" /proc/mounts
+ root@jammy:~# grep " /var/tmp/rear.sp5QVNiZuk6Ml7v/outputfs " /proc/mounts
+ root@jammy:~# grep "/var/tmp/rear.sp5QVNiZuk6Ml7v/outputfs" /proc/mounts
+
+ root@jammy:~# lsa /var/tmp/rear.sp5QVNiZuk6Ml7v
+ insgesamt 20
+ drwx------ 5 root root 4096 Dez 4 23:26 .
+ drwxrwxrwt 9 root root 4096 Dez 4 23:26 ..
+ drwx------ 4 root root 4096 Dez 4 23:26 outputfs
+ drwxr-xr-x 16 root root 4096 Dez 4 23:24 rootfs
+ drwxr-xr-x 4 root root 4096 Dez 4 23:26 tmp
+
+ root@jammy:~# lsa /var/tmp/rear.sp5QVNiZuk6Ml7v/outputfs/
+ insgesamt 16
+ drwx------ 4 root root 4096 Dez 4 23:26 .
+ drwx------ 5 root root 4096 Dez 4 23:26 ..
+ drwx------ 3 root root 4096 Dez 4 23:26 boot
+ drwx------ 3 root root 4096 Dez 4 23:26 rear
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-05 10:44](https://github.com/rear/rear/issues/3098#issuecomment-1840492771):
+
+Your debug log shows that you also have /etc/rear/site.conf with this
+content:
+
+OUTPUT=ISO
+BACKUP=NETFS
+**OUTPUT\_URL=file:///media/relax**
+BACKUP\_URL=iso://
+BACKUP\_PROG\_EXCLUDE=("${BACKUP\_PROG\_EXCLUDE\[@\]}"
+'/meinesachen/\*')
+EXCLUDE\_MOUNTPOINTS=(/media/disc)
+EXCLUDE\_MD=("/dev/md0" "/dev/md1" "/dev/md2" "/dev/md3" "/dev/md4")
+EXCLUDE\_VG=(lvraid)
+
+Since OUTPUT\_URL is not set in your local.conf, this setting persists,
+and since it uses `file://`, ReaR expects that the output filesystem is
+already mounted there, which it is not.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-05 10:47](https://github.com/rear/rear/issues/3098#issuecomment-1840497690):
+
+See above:
+
+> - ReaR configuration files (**"cat /etc/rear/site.conf"** and/or
+> "cat /etc/rear/local.conf"):
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-05 13:33](https://github.com/rear/rear/issues/3098#issuecomment-1840803504):
+
+There should be some detection and early exit with a meaningful error
+message when such condition occurs, but when investinating the code, I
+could not understand it and it seems like a mess. In particular, it does
+not seem to take into account the possibility that OUTPUT\_URL can be
+different from BACKUP\_URL for OUTPUT=USB, although this seems to me a
+perfectly legal combination (create bootable USB, but put backup
+somewhere else). The code uses USB\_DEVICE, but it is determined
+preferably from BACKUP\_URL, although it would be more logical to
+determine it from OUTPUT\_URL.
+
+#### [malvinas2](https://github.com/malvinas2) commented at [2023-12-05 22:12](https://github.com/rear/rear/issues/3098#issuecomment-1841704199):
+
+I don't even remember ever using `site.conf` - my little cheat sheet
+only has `local.conf` and `default.conf` written down - but in fact this
+file was there with my usual entries.
+After deleting it, the backup is smoothly created on the USB stick.
+Thank you very much!
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-07 15:09](https://github.com/rear/rear/issues/3098#issuecomment-1845519067):
+
+@malvinas2 thanks for the verification!
+
+It would be the best to add more code to the `prep` stage to verify the
+consistency of `BACKUP_URL`, `OUTPUT_URL` and `USB_DEVICE`, but I don't
+have the energy to untangle all this and this problem does not arise
+very often, so I am adding only one check that there is something
+mounted at `$BUILD_DIR/outputfs`: \#3102
+
+#### [malvinas2](https://github.com/malvinas2) commented at [2023-12-08 12:16](https://github.com/rear/rear/issues/3098#issuecomment-1847074614):
+
+Why are there multiple configuration files anyway? In my opinion there
+should just be the default configuration (`default.conf`) and a custom
+configuration (`local.conf`).
+If further user-defined configurations are required, these must be
+specified explicitly (e.g. as command line parameters).
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-08 13:48](https://github.com/rear/rear/issues/3098#issuecomment-1847191357):
+
+@malvinas2
+site.conf is (optionally) for site specific configuration,
+see "man rear" (excerpts):
+
+ FILES
+ ...
+ /etc/rear/local.conf
+ System specific configuration can be set here.
+
+ /etc/rear/site.conf
+ Site specific configuration can be set here
+ (not created by default).
+ ...
+ /usr/share/rear/conf/default.conf
+ Relax-and-Recover default values.
+ Contains a complete set of parameters and its explanation.
+ Do not edit or modify things therein but use
+ local.conf or site.conf for specific settings.
+
+e.g. online via
+[https://github.com/rear/rear/blob/master/doc/rear.8.adoc](https://github.com/rear/rear/blob/master/doc/rear.8.adoc)
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-12 07:36](https://github.com/rear/rear/issues/3098#issuecomment-1851447524):
+
+@pcahyna
+thank you for debugging and for your fix!
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2023-12-05.3100.pr.open.md b/docs/issues/2023-12-05.3100.pr.open.md
new file mode 100644
index 00000000..8c40ebfd
--- /dev/null
+++ b/docs/issues/2023-12-05.3100.pr.open.md
@@ -0,0 +1,1555 @@
+[\#3100 PR](https://github.com/rear/rear/pull/3100) `open`: OUTPUT=PXE: Support for downloading kernel and initrd by http
+=========================================================================================================================
+
+**Labels**: `enhancement`
+
+#### 
[robertdahlem](https://github.com/robertdahlem) opened issue at [2023-12-05 15:40](https://github.com/rear/rear/pull/3100):
+
+##### Pull Request Details:
+
+- Type: **Enhancement**
+
+- Impact: **Low**
+
+- How was this pull request tested?
+ By using it in production.
+
+- Description of the changes in this pull request:
+
+This patch adds support for downloading kernel and initrd by http
+(instead of tftp) when using PXE. It was motivated by long download
+times for 700 MB initrds over tftp. Tftp uses UDP and doesn't have a
+send window like TCP, meaning TCP can send packets up to the size of the
+send window without having received acknowledges for previous packets
+und thus is much better at saturating the wire compared to UDP, where
+each packet has to be acknowledged before the next packet can be sent.
+
+Obviously you need a http server for this and mkrescue must be able to
+write there. Details of the configuration are 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
+
+A requirement is switching from pxelinux.0 to lpxelinux.0. It is a drop
+in replacement for pxelinux.0 which supports http downloads and should
+be included in any recent pxelinux package. Recent meaning "after 2019".
+:-)
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-06 13:58](https://github.com/rear/rear/pull/3100#issuecomment-1842944852):
+
+@robertdahlem
+thank you for your contribution to improve ReaR!
+
+I am not a PXE user but I will have a look
+at your pull request tomorrow (as time permits).
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-06 14:05](https://github.com/rear/rear/pull/3100#issuecomment-1842956022):
+
+@robertdahlem thank you for you contribution! Unfortunately I am not a
+PXE user so I can not test it not have much specific comments.
+From looking at the code, I see
+
+> It's compatible, just replace pxeconfig.0 in your TFTP directory or
+> set bootfile-name to lpxeconfig.0 in your DHCP server.
+
+but in your description, you write:
+
+> A requirement is switching from pxelinux.0 to lpxelinux.0.
+
+Is the difference intentional?
+
+Also, why the `PXE_SCHEME` option name? To me it does not look
+descriptive. For me, "scheme" is the `http` part of the URL.
+
+Regarding the unfinished RPM builds in CI, don't worry, that's some
+general Fedora COPR issue.
+[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RANEB44PFVY3C2LCUAT2LSTQ3QXB7Y5C/\#RANEB44PFVY3C2LCUAT2LSTQ3QXB7Y5C](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RANEB44PFVY3C2LCUAT2LSTQ3QXB7Y5C/#RANEB44PFVY3C2LCUAT2LSTQ3QXB7Y5C)
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-06 14:28](https://github.com/rear/rear/pull/3100#issuecomment-1842996729):
+
+@pcahyna
+
+> From looking at the code, I see
+>
+> > It's compatible, just replace pxeconfig.0 in your TFTP directory or
+> > set bootfile-name to lpxeconfig.0 in your DHCP server.
+
+> but in your description, you write:
+>
+> > A requirement is switching from pxelinux.0 to lpxelinux.0.
+
+> Is the difference intentional?
+
+It don't see a difference. http downloads require lpxeconfig.0. You can
+switch to that in at least two ways:
+
+1. Copy lpxeconfig.0 over pxeconfig.0 in /var/lib/tftpboot of the TFTP
+ server. It is a compatible pxeconfig.0 replacement, just enhanced
+ with http
+2. Use the DHCP option "bootfile name (67)" to request lpxeconfig.0
+ instead of pxeconfig.0
+
+The former is a bit more intrusive because it affects all PXE boots.
+Shouldn't be a problem because it is compatible (according to what the
+SYSLINUX/PXELINUX people say and what I tested).
+
+The latter typically affects only single hosts and you need to replace
+this option for all affected hosts. Could be more work.
+
+> Also, why the `PXE_SCHEME` option name? To me it does not look
+> descriptive. For me, "scheme" is the `http` part of the URL.
+
+You are right, only "http://" is actually a scheme. It came to my mind
+because it supports a scheme change (from implicit tftp to explicit
+http). My heart is not attached to this specific name. It could very
+well be something like PXE\_HTTP\_PREFIX or anything else you propose.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2023-12-06 14:44](https://github.com/rear/rear/pull/3100#issuecomment-1843029113):
+
+> @pcahyna
+>
+> > From looking at the code, I see
+> >
+> > > It's compatible, just replace pxeconfig.0 in your TFTP directory
+> > > or set bootfile-name to lpxeconfig.0 in your DHCP server.
+>
+> > but in your description, you write:
+> >
+> > > A requirement is switching from pxelinux.0 to lpxelinux.0.
+>
+> > Is the difference intentional?
+>
+> It don't see a difference. http downloads require lpxeconfig.0. You
+> can switch to that in at least two ways:
+>
+> 1. Copy lpxeconfig.0 over pxeconfig.0 in /var/lib/tftpboot of the TFTP server. It is a compatible pxeconfig.0 replacement, just enhanced with http
+>
+> 2. Use the DHCP option "bootfile name (67)" to request lpxeconfig.0 instead of pxeconfig.0
+
+I see a difference between pxelinux.0 (PR description) and pxeconfig.0
+(code comment).
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-06 15:03](https://github.com/rear/rear/pull/3100#issuecomment-1843069570):
+
+@pcahyna
+
+> I see a difference between pxelinux.0 (PR description) and pxeconfig.0
+> (code comment).
+
+Oops, sorry! Replace everything I ever said about (l)pxeconfig.0 with
+(l)pxelinux.0
+
+I'll send an update.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-07 12:35](https://github.com/rear/rear/pull/3100#issuecomment-1845266992):
+
+@robertdahlem
+perhaps a dumb question (but as non PXE user
+I know basically nothing how PXE works):
+
+Could you explain how far
+[https://github.com/rear/rear/pull/2738](https://github.com/rear/rear/pull/2738)
+"Support for http sources when using PXE"
+is related ro unrelated to this issue here?
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-07 14:08](https://github.com/rear/rear/pull/3100#issuecomment-1845406259):
+
+@jsmeix
+
+> @robertdahlem perhaps a dumb question (but as non PXE user I know
+> basically nothing how PXE works):
+> Could you explain how far \#2738 "Support for http sources when using
+> PXE" is related ro unrelated to this issue here?
+
+Perhaps first some words how PXE works (basically, not all the gory
+details).
+
+The system boots and when requested to, instead of reading what is on
+the disk it sends a DHCP request ("network boot" or "PXE boot"). It
+should get a DHCP reply with IP/netmask, default gateway, perhaps DNS
+and NTP servers.
+
+For PXE to work DHCP also needs to send a "next server" (the TFTP
+server) and a "boot file". The boot file usually is pxelinux.0 from the
+SYSLINUX project. PXE downloads this file with TFTP and starts it.
+pxelinux.0 tries to download several things from the TFTP servers
+subdirectory pxelinux.cfg: a file with its UUID, a file with its MAC
+address, a file with its IP address (in hex) and so on. At least one of
+these should be a symbolic link to a configuration file which happens to
+be a GRUB menu configuration file. pxelinux.0 downloads this file and
+presents the user with the GRUB menu.
+
+The user then requests something from the menu which leads to GRUB
+configuration items like kernel and initrd (with parameters). pxelinux.0
+downloads both with TFTP from the "next server" and starts them. System
+running, job done. In the case of ReaR you get a system with pretty much
+the same as what is in an ISO: all the things you need to run "rear
+recover".
+
+ReaR supports this by uploading a configuration and symbolic links to
+PXE\_CONFIG\_URL and kernel/initrd to PXE\_TFTP\_URL.
+
+Unfortunately, nowadays initrd is typically a 700+ MB thing because it
+includes all available kernel modules to support recovery on different
+hardware. TFTP is very slow because it uses UDP and needs to acknowledge
+Every. Single. Packet. before downloading the next packet. I see initrd
+download times of 6 up to 8 minutes in a 10 Gbits/s environment (where
+you would expect a second or two).
+
+HTTP is faster because it uses TCP and can send packages without waiting
+for acknowledgement of all previous packets.
+
+So, if you prefix the kernel and initrd arguments with http://... you
+can download both a lot faster. pxelinux.0 does not understand
+http://.., thus the need to switch to lpxelinux.0. \#2738 both and
+\#3100 both support this.
+
+Now for your question:
+
+I have not been aware of \#2738 because in my production environment I
+use what RHEL 8 delivers and that is ReaR 2.6 plus Red Hat fairy dust.
+Sorry for not checking upstream beforehand.
+
+\#2738 pretty much does the same as my \#3100: it enhances the kernel
+and initrd configuration lines with what is in a variable: my
+PXE\_SCHEME in \#3100 demands a trailing slash, PXE\_HTTP\_URL in \#2738
+gets the slash from the code.
+
+Also, \#2738 enhances the GRUB menu with additional options
+(rear-automatic-http, rear-unattended-http and rear-http) while \#3100
+changes the existing options.
+
+Personally I do not tend to enhancing the menu: PXE\_TFTP\_URL either
+points to the TFTP server download directory or the HTTP server download
+directory (assuming they are not the same). So with \#2738 half the
+options won't work and the other half will work. You can't say from
+looking because you don't know where kernel and initrd have been
+uploaded. With \#3100 there are no wrong choices (assuming
+PXE\_TFTP\_URL was set correctly).
+
+\#2738 did not make an attempt to download PXE\_MESSAGE from the correct
+server and \#3100 is a bit better regarding documentation in
+default.conf.
+
+I would change my PR to use PXE\_HTTP\_URL (without trailing slash)
+instead of PXE\_SCHEME. This has been discussed before). Also I would
+change it to undo the menu enhancement and instead modify the existing
+kernel/initrd paths. That would resurrect PXE\_MESSAGE too. This would
+render it into a non-breaking change.
+
+I would be interested in what @Flunkyball might have to say.
+
+#### 
[Flunkyball](https://github.com/Flunkyball) commented at [2023-12-07 20:45](https://github.com/rear/rear/pull/3100#issuecomment-1846087166):
+
+Good to see another fellow using PXE ;-)
+
+> I would change my PR to use PXE\_HTTP\_URL (without trailing slash)
+> instead of PXE\_SCHEME. This has been discussed before). Also I would
+> change it to undo the menu enhancement and instead modify the existing
+> kernel/initrd paths. That would resurrect PXE\_MESSAGE too. This would
+> render it into a non-breaking change.
+
+This was actually also my first approach. The reason why I chose to add
+the additional option in the boot menu was due to the fact that there
+are still many systems around with a bios that does not support booting
+from HTTP.
+With your configuration I have to choose exclusively HTTP on a rear
+config level loosing any chance to boot an older system.
+
+> So with
+> [https://github.com/rear/rear/pull/2738](https://github.com/rear/rear/pull/2738)
+> half the options won't work and the other half will work. You can't
+> say from looking because you don't know where kernel and initrd have
+> been uploaded. With
+> [https://github.com/rear/rear/pull/3100](https://github.com/rear/rear/pull/3100)
+> there are no wrong choices (assuming PXE\_TFTP\_URL was set
+> correctly).
+
+In my environment for the reason described before PXE is provided via
+HTTP **and** TFTP. Therefore both boot options are working fine.
+
+In the end you could extend
+[https://github.com/rear/rear/pull/3100](https://github.com/rear/rear/pull/3100)
+with an option to choose whether to create an additional grub option for
+TFTP. I did it the other way round.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-08 07:56](https://github.com/rear/rear/pull/3100#issuecomment-1846722977):
+
+@Flunkyball
+
+> This was actually also my first approach. The reason why I chose to
+> add the additional option in the boot menu was due to the fact that
+> there are still many systems around with a bios that does not support
+> booting from HTTP.
+
+I would like to understand this better: the difference whether a system
+can download kernel and initrd from my understanding does not come from
+the BIOS. The BIOS only downloads the "boot file" (typically pxelinux.0)
+by using TFTP. Even the pxelinux.cfg files are downloaded by TFTP
+(because there is no configuration yet saying otherwise).
+
+Only when the configuration file has been read something else
+(kernel/initrd) can be downloaded by HTTP. And that is possible only if
+you have a pxelinux.0 which understands HTTP (i.e. by copying
+lpxelinux.0 over pxelinux.0 on the TFTP server or by reuesting
+lpxelinux.0 as "boot file"). But I did not yet see a dependency to a
+specific BIOS function for HTTP.
+
+Could you please explain how you came to the conclusion that there is a
+dependency in the BIOS for HTTP downloads?
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-08 08:16](https://github.com/rear/rear/pull/3100#issuecomment-1846744326):
+
+@Flunkyball
+
+> In my environment for the reason described before PXE is provided via
+> HTTP **and** TFTP. Therefore both boot options are working fine.
+
+I have another question: where do you upload kernel/initrd to? To the
+TFTP server or to the HTTP server? Or do they use the same directory? In
+this case: how do you handle the SELinux implications (tftpdir\_rw\_t
+vs. httpd\_sys\_content\_t)?
+
+#### [Flunkyball](https://github.com/Flunkyball) commented at [2023-12-08 14:59](https://github.com/rear/rear/pull/3100#issuecomment-1847331010):
+
+> I would like to understand this better: the difference whether a
+> system can download kernel and initrd from my understanding does not
+> come from the BIOS. The BIOS only downloads the "boot file" (typically
+> pxelinux.0) by using TFTP. Even the pxelinux.cfg files are downloaded
+> by TFTP (because there is no configuration yet saying otherwise).
+>
+> Only when the configuration file has been read something else
+> (kernel/initrd) can be downloaded by HTTP. And that is possible only
+> if you have a pxelinux.0 which understands HTTP (i.e. by copying
+> lpxelinux.0 over pxelinux.0 on the TFTP server or by reuesting
+> lpxelinux.0 as "boot file"). But I did not yet see a dependency to a
+> specific BIOS function for HTTP.
+>
+> Could you please explain how you came to the conclusion that there is
+> a dependency in the BIOS for HTTP downloads?
+
+The PXE boot mechanism is a BIOS feature and therefore comes in a
+certain release version included with the BIOS.
+Original PXE was not HTTP capable, this was introduced later. There is
+e.g. a free PXE implementation [https://ipxe.org/](https://ipxe.org/)
+offering a slim chance to flash the rom of your network adapter or
+mainboard with an http compatible PXE version.
+
+Otherwise no matter what initial information via TFTP is provided
+nothing will be downloaded.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-19 14:18](https://github.com/rear/rear/pull/3100#issuecomment-1862845487):
+
+@jsmeix
+
+> What the most reasonable way is how to implement HTTP support for PXE
+> must be addressed before merging.
+
+Absolutely. I'm involved in another project at the moment but will come
+back to this before end of month.
+
+I'm pretty unhappy with the choice of variable name (PXE\_HTTP\_URL) in
+\#2738: The well known PXE\_TFTP\_URL points to an **upload** path while
+the new PXE\_HTTP\_URL (as implemented in \#2738) points to a
+**download** path. I consider that confusing.
+
+How do you think about an incompatible change? This would be
+PXE\_HTTP\_URL pointing to another **upload** path (to the HTTP servers
+directory, the default being what PXE\_TFTP\_URL points to). In this
+case we still need an HTTP **download** path, which I (here) configured
+in PXE\_SCHEME. How about something like PXE\_HTTP\_DOWNLOAD?
+
+Also I think offering TFTP and HTTP both (as in \#2738) is reasonable.
+This should stay.
+
+I disagree with what has been written about PXE BIOSes being able to do
+HTTP downloads. From my point of view this is not backed by the
+[Wikipedia PXE
+article](https://en.wikipedia.org/wiki/Preboot_Execution_Environment).
+But actually that doesn't matter for our purposes. Either the client
+actually has this HTTP enabled PXE BIOS or one uses lpxelinux.0 instead
+of pxelinux.0.
+
+#### [Flunkyball](https://github.com/Flunkyball) commented at [2023-12-19 18:43](https://github.com/rear/rear/pull/3100#issuecomment-1863300646):
+
+> How do you think about an incompatible change? This would be
+> PXE\_HTTP\_URL pointing to another **upload** path (to the HTTP
+> servers directory, the default being what PXE\_TFTP\_URL points to).
+> In this case we still need an HTTP **download** path, which I (here)
+> configured in PXE\_SCHEME. How about something like
+> PXE\_HTTP\_DOWNLOAD?
+
+I do not see in what way this is confusing as the HTTP path is for
+download only. In what scenario would this be an upload path ?
+
+> I disagree with what has been written about PXE BIOSes being able to
+> do HTTP downloads. From my point of view this is not backed by the
+> [Wikipedia PXE
+> article](https://en.wikipedia.org/wiki/Preboot_Execution_Environment).
+> But actually that doesn't matter for our purposes. Either the client
+> actually has this HTTP enabled PXE BIOS or one uses lpxelinux.0
+> instead of pxelinux.0.
+
+The wikipedia article does not mention the HTTP path since it was not
+originally part of PXE. However, as you mentioned, not important for the
+solution if we keep both options.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-19 19:08](https://github.com/rear/rear/pull/3100#issuecomment-1863330513):
+
+> I do not see in what way this is confusing as the HTTP path is for
+> download only. In what scenario would this be an upload path ?
+
+Don't you think that if you have an existing variable PXE\_TFTP\_URL,
+which points to an upload directory for TFTP that it is confusing to
+invent a variable PXE\_HTTP\_URL, which does **not** point to an upload
+directory for HTTP?
+
+#### [Flunkyball](https://github.com/Flunkyball) commented at [2023-12-19 19:16](https://github.com/rear/rear/pull/3100#issuecomment-1863341189):
+
+> > I do not see in what way this is confusing as the HTTP path is for
+> > download only. In what scenario would this be an upload path ?
+>
+> Don't you think that if you have an existing variable PXE\_TFTP\_URL,
+> which points to an upload directory for TFTP that it is confusing to
+> invent a variable PXE\_HTTP\_URL, which does **not** point to an
+> upload directory for HTTP?
+
+No because PXE is by default a one way street in terms of HTTP and
+therefore does not confuse me.
+So in the end you propose a breaking change to resolve your personal
+confusion ?
+
+[https://github.com/rear/rear/pull/2738](https://github.com/rear/rear/pull/2738)
+has been introduced 2 years ago. Probably some people used the feature
+since successfully and are forced to change their configuration after
+that, most likely finding out about it the hard way.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-19 19:31](https://github.com/rear/rear/pull/3100#issuecomment-1863359164):
+
+> I'm pretty unhappy with the choice of variable name (PXE\_HTTP\_URL)
+> in \#2738: The well known PXE\_TFTP\_URL points to an **upload** path
+> while the new PXE\_HTTP\_URL (as implemented in \#2738) points to a
+> **download** path. I consider that confusing.
+
+@jsmeix Do you have an opinion about this?
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-20 10:24](https://github.com/rear/rear/pull/3100#issuecomment-1864222606):
+
+Offhandedly and as non PXE user I can only speak
+in general about user config variable names:
+
+In general I think backward compatibility
+has higher value in practice for our users
+than backward incompatibe improvements, cf.
+[https://github.com/rear/rear/wiki/Coding-Style\#maintain-backward-compatibility](https://github.com/rear/rear/wiki/Coding-Style#maintain-backward-compatibility)
+as far as possible with reasonable effort for us.
+For example when a real bug cannot be fixed without
+backward incompatibe changes then it is better
+to have the bug fixed than to keep things wrong.
+
+In particular regarding user config variable names:
+Basically we cannot change existing user config variable names
+to avoid regressions for users who use existing config variable names
+regardless how awkward existing config variable names are, cf.
+[https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf\#L907](https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L907)
+which points to
+[https://github.com/rear/rear/pull/2293\#issuecomment-564439509](https://github.com/rear/rear/pull/2293#issuecomment-564439509)
+
+When we have unclear existing config variable names
+we can explain things properly in default.conf and
+inform the user about possible misunderstandings
+even if that leads to longer explanations
+which could be sometimes even long-winded.
+
+In contrast to insufficient information in default.conf
+long-winded explanations are not a serious problem
+because that can be easily improved by contributors
+who can contribute more helpful explanation texts.
+
+By the way:
+Compare traditional Unix command names,
+for example 'time' versus 'date'
+and 'cancel' versus 'kill' ;-)
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-20 13:56](https://github.com/rear/rear/pull/3100#issuecomment-1864518360):
+
+@jsmeix
+
+In this case (backward compatibility has higher value than fixing
+awkward variable names) I propose something like PXE\_HTTP\_UPLOAD\_URL,
+which **MAY** be set and then points to a second/different upload
+location. I would offer this because it is perfectly possible to need to
+upload the files for TFTP to another server than the files for HTTP,
+especially in enterprise environments, where you can't just let both
+servers point to the same directory: SELinux prevents you from doing so.
+
+Then there is the point of the `display` action in PXE\_CONFIG\_FILE. It
+is ignored by \#2738 (probably because this PR is intended for an
+environment where TFTP and HTTP server use the same directory). I
+propose to let it point to $PXE\_HTTP\_URL if this variable is set is
+set. In this case you download it from the TFTP server unless you
+explicitly state there is an HTTP server by setting PXE\_HTTP\_URL.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2023-12-22 13:23](https://github.com/rear/rear/pull/3100#issuecomment-1867684824):
+
+As non PXE user I cannot help much with PXE specific things
+but I try my best (and bear with me when I write nonsense):
+
+Ideally when we need to distinguish between
+the protocols TFTP versus HTTP and distinguish between
+upload (i.e. wherefrom ReaR runs up to the PXE server) and
+download (i.e. from the PXE server down to the booting computer)
+the variable names should contain
+both the protocol plus
+UPLOAD and DOWNLOAD like
+
+ PXE_TFTP_UPLOAD_URL
+ PXE_TFTP_DOWNLOAD_URL
+ PXE_HTTP_UPLOAD_URL
+ PXE_HTTP_DOWNLOAD_URL
+
+Unfortunately whe have already
+PXE\_TFTP\_URL for upload and
+PXE\_HTTP\_URL for download
+which is confusing.
+I think it is only confusing when both protocols are used
+because when only one protocol is used for upload and download
+then
+either PXE\_TFTP\_URL for upload and download with TFTP
+or PXE\_HTTP\_URL for upload and download with HTTP
+would be consistent.
+
+But when both the protocol and the direction (up vs down)
+can be freely combined then specific variables are needed
+so the current
+PXE\_TFTP\_URL for upload with TFTP and
+PXE\_HTTP\_URL for download with HTTP
+cannot work
+because a user cannot specify the opposite
+PXE\_TFTP\_URL for download with TFTP and
+PXE\_HTTP\_URL for upload with HTTP
+i.e. the current variable naming is a bug
+(when protocol and direction can be freely combined).
+
+If we have this bug in current ReaR we have to fix it,
+but not this year ;-)
+
+@robertdahlem @Flunkyball
+I wish you Merry Christmas and a happy New Year!
+
+#### [Flunkyball](https://github.com/Flunkyball) commented at [2023-12-22 13:48](https://github.com/rear/rear/pull/3100#issuecomment-1867709078):
+
+> PXE_TFTP_UPLOAD_URL
+> PXE_TFTP_DOWNLOAD_URL
+> PXE_HTTP_UPLOAD_URL
+> PXE_HTTP_DOWNLOAD_URL
+>
+> Unfortunately whe have already PXE\_TFTP\_URL for upload and
+> PXE\_HTTP\_URL for download which is confusing. I think it is only
+> confusing when both protocols are used because when only one protocol
+> is used for upload and download then either PXE\_TFTP\_URL for upload
+> and download with TFTP or PXE\_HTTP\_URL for upload and download with
+> HTTP would be consistent.
+>
+> But when both the protocol and the direction (up vs down) can be
+> freely combined then specific variables are needed so the current
+> PXE\_TFTP\_URL for upload with TFTP and PXE\_HTTP\_URL for download
+> with HTTP cannot work because a user cannot specify the opposite
+> PXE\_TFTP\_URL for download with TFTP and PXE\_HTTP\_URL for upload
+> with HTTP i.e. the current variable naming is a bug (when protocol and
+> direction can be freely combined).
+
+Well... that is partly correct.
+The thing is, that PXE originally had only TFTP for up and download and
+later added HTTP for download only.
+-> PXE\_TFTP is Up and Download where HTTP is Download only if it is
+used since it is optional.
+
+Things get even messier if you look at my current rear config for PXE
+
+ PXE_TFTP_IP=192.xx.xx.xx
+ PXE_TFTP_URL="sshfs://pxe@pxe-ssh/tftp"
+ PXE_CONFIG_URL="sshfs://pxe@pxe-ssh/tftp/pxelinux.cfg"
+ PXE_HTTP_URL="http://$PXE_TFTP_IP:8000"
+
+So in my case I even use SFTP for uploading to the PXE server through
+the TFTP\_URL variable... .
+In the end with
+[https://github.com/rear/rear/pull/2738](https://github.com/rear/rear/pull/2738)
+this did not bother me because the same upload target does later on
+provide the TFTP download which makes it plausible for me.
+However the HTTP\_URL is added as additional download option thus the
+explicit additional variable.
+
+In order to come clean you would need to rename "PXE\_TFTP\_URL" to
+"PXE\_UPLOAD\_URL" to be used with whatever protocol you want for upload
+and to have for each additional download option a seperate variable
+"PXE\_PROTXX\_DOWNLOAD"
+
+@jsmeix @robertdahlem
+Wish you Merry Christmas and a Happy New Year, too !
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-29 15:51](https://github.com/rear/rear/pull/3100#issuecomment-1872183807):
+
+@jsmeix
+
+> PXE_TFTP_UPLOAD_URL
+> PXE_TFTP_DOWNLOAD_URL
+> PXE_HTTP_UPLOAD_URL
+> PXE_HTTP_DOWNLOAD_URL
+
+Now that you introduced a complete new name space things got very easy:
+we can deprecate the old variable names, but still allow to use them. In
+this case warnings are generated, but the values of the old variables
+get assigned to the new variables. No breaking changes until someone
+decides to delete the deprecated variables (maybe in 3.0?).
+
+I'll submit a change to introduce:
+
+ PXE_TFTP_URL -> PXE_TFTP_UPLOAD_URL
+ PXE_TFTP_DOWNLOAD_URL isn't needed because it is the default and the value would always be ""
+ PXE_HTTP_UPLOAD_URL (new variable)
+ PXE_HTTP_URL -> PXE_HTTP_DOWNLOAD_URL
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2023-12-29 15:54](https://github.com/rear/rear/pull/3100#issuecomment-1872185424):
+
+Obviously I f\*cked things up and now commits from other people show up
+between my commits. I might need a little help here.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-01 09:39](https://github.com/rear/rear/pull/3100#issuecomment-1873247917):
+
+> Obviously I f\*cked things up and now commits from other people show
+> up between my commits. I might need a little help here.
+
+I seem to have been able to repair my f\*ckup:
+
+ git checkout master
+ git merge
+ git checkout http-download
+ git reset --hard master
+ re-apply patches (vi/git add/git commit)
+ git push --force
+
+I know see my intended commits here.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-02 12:12](https://github.com/rear/rear/pull/3100#issuecomment-1873952282):
+
+@robertdahlem
+when I look at your current changes via the GitHub web frontend
+[https://github.com/rear/rear/pull/3100/files](https://github.com/rear/rear/pull/3100/files)
+it shows that there is still PXE\_SCHEME implemented.
+I thought PXE\_HTTP\_DOWNLOAD\_URL is meant to replace PXE\_SCHEME?
+
+Regarding "commits from other people show up between my commits":
+This happened also to me some longer time ago.
+I don't remember the details and I am not a git expert
+to imagine what goes on behind the surface in such cases.
+I guess it may happen when one rebases his own branch on master
+that then the newest commits of others from the master branch appear
+intermixed with one's own commits (at least via the GitHub web
+frontend)
+which is confusing because I want my branch to contain only my commits.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-02 12:51](https://github.com/rear/rear/pull/3100#issuecomment-1873989193):
+
+> Regarding "commits from other people show up between my commits":
+> This happened also to me some longer time ago.
+> I don't remember the details and I am not a git expert
+> to imagine what goes on behind the surface in such cases.
+> I guess it may happen when one rebases his own branch on master
+> that then the newest commits of others from the master branch appear
+> intermixed with one's own commits (at least via the GitHub web
+> frontend)
+> which is confusing because I want my branch to contain only my
+> commits.
+
+No, IMO it happened because of merging the branch instead of rebasing
+it: see merge commits
+[https://github.com/rear/rear/commit/c7885a854e19b1bbc4187ebe389fdeeb296ddf50](https://github.com/rear/rear/commit/c7885a854e19b1bbc4187ebe389fdeeb296ddf50)
+and
+[https://github.com/rear/rear/commit/17c34baf781c0c6caf20193828d9c9659a787a7c](https://github.com/rear/rear/commit/17c34baf781c0c6caf20193828d9c9659a787a7c)
+. Rebase would have been fine.
+
+@robertdahlem instead of manually re-applying desired patches, you could
+use `git rebase --interactive` or `git cherry-pick`.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-03 17:44](https://github.com/rear/rear/pull/3100#issuecomment-1875740074):
+
+@jsmeix
+
+> @robertdahlem when I look at your current changes via the GitHub web
+> frontend
+> [https://github.com/rear/rear/pull/3100/files](https://github.com/rear/rear/pull/3100/files)
+> it shows that there is still PXE\_SCHEME implemented. I thought
+> PXE\_HTTP\_DOWNLOAD\_URL is meant to replace PXE\_SCHEME?
+
+You are right. This was a remnant from previous code. I eliminated that
+now.
+
+Do you think we can merge that now? @Flunkyball ?
+
+@pcahyna
+My workflow after having made my changes locally in `mybranch` seems
+stable now:
+In **my** GitHub and my fork: Branch master > Sync fork > Update
+branch
+Locally:
+
+ # git checkout master
+ # git pull
+ # git checkout mybranch
+ # git merge master
+ # git push
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-03 18:16](https://github.com/rear/rear/pull/3100#issuecomment-1875776497):
+
+@robertdahlem there is still a needless merge commit in the history now:
+[https://github.com/rear/rear/pull/3100/commits/11f4e0284c7b757444de94feecec56295b013114](https://github.com/rear/rear/pull/3100/commits/11f4e0284c7b757444de94feecec56295b013114)
+Would it work for you to use
+
+ # git rebase master
+ # git push -f
+
+instead of
+
+ # git merge master
+ # git push
+
+?
+Alternatively, since you changes do not seem to conflict with any of the
+new development code, you could avoid merging or rebasing your branch
+entirely (this can not be relied on in general, of course).
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-03 18:51](https://github.com/rear/rear/pull/3100#issuecomment-1875816919):
+
+@pcahyna
+
+> @robertdahlem there is still a needless merge commit in the history
+> now:
+> [11f4e02](https://github.com/rear/rear/commit/11f4e0284c7b757444de94feecec56295b013114)
+
+Yes, I see. But it doesn't show up in the files changed by this PR. Also
+it doesn't show up in `git diff master http-download`. So I thought it
+is fine.
+
+> Would it work for you to use
+>
+> # git rebase master
+> # git push -f
+
+It might. It did not try that. I am still confused about the rebase
+stuff. Also rebase and force push drove me into the f\*ckup.
+Additionally I think that the merge commit is not needless. It proves
+that my patches don't conflict with master.
+
+The history of all that is:
+
+- I push a PR
+- Discussion ensues, further local development happens
+- Meanwhile people commit other stuff to master
+- To prove that my locally developed stuff does not conflict I need to
+ merge my branch with master before pushing. Also I shy away from
+ doing anything with `--force`.
+- Or don't I merge? What do people do at this point (aka "another push
+ to a branch while master has moved on")?
+
+> ? Alternatively, since you changes do not seem to conflict with any of
+> the new development code, you could avoid merging or rebasing your
+> branch entirely (this can not be relied on in general, of course).
+
+Exactly. There must be some workflow that makes everybody happy.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-04 09:53](https://github.com/rear/rear/pull/3100#issuecomment-1876808412):
+
+@pcahyna
+
+> Exactly. There must be some workflow that makes everybody happy.
+
+Ok. I tried (in another project):
+
+ # git rebase master
+ # git push --force
+
+and after merging that I see my commits and one last commit
+`Merge pull request #2 from robertdahlem/mybranch`.
+
+I am still slightly frightened about `--force` but if that is the
+workflow it will be ok for me.
+
+@jsmeix Do I need to re-issue my PR or can we go on with the way it is
+yet?
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-04 10:33](https://github.com/rear/rear/pull/3100#issuecomment-1876866258):
+
+@robertdahlem
+regarding your
+
+ I think that the merge commit is not needless.
+ It proves that my patches don't conflict with master.
+
+Normally I don't update my branches with master.
+I only do the changes that I need in my branches
+and finally I merge those changes into master.
+Only if there are merge conflicts I adapt the changes in my branch.
+But normally there are no merge conflicts even if
+common files (like default.conf) were changed in master
+because usually changes in master are for different parts
+in a file so that the git three-way merge can still merge
+my changes from my branch without merge conflicts.
+
+When I am logged in at GitHub I can see whether or not
+the changes in a pull request can be merged without conflicts.
+E.g. in this pull request here the GitHub web frontend shows
+
+ This branch has no conflicts with the base branch
+ Merging can be performed automatically.
+
+This is not visible unless one is logged in at GitHub.
+But I don't know if this is visible to every user who is
+logged in at GitHub or if this is only visible to users
+who have the right to merge pull requests (like me).
+
+So bottom line from my point of view:
+Don't worry in advance about possible merge conflicts.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-04 11:35](https://github.com/rear/rear/pull/3100#issuecomment-1876951537):
+
+@pcahyna
+I would like your opinion regarding the new
+usr/share/rear/init/default/002\_pxe\_sanity\_checks.sh
+
+My current thoughts regarding the new
+usr/share/rear/init/default/002\_pxe\_sanity\_checks.sh
+
+Up to now we do not have any `_sanity_` named script.
+But we have usr/share/rear/init/default/010\_EFISTUB\_check.sh
+so usr/share/rear/init/default/020\_PXE\_check.sh
+could be a better name?
+
+In general I wonder if feature specific check scripts
+should be always run in the general 'init' stage?
+Wouldn't be a feature specific sub-directory better?
+E.g. something like
+usr/share/rear/prep/NETFS/default/050\_check\_NETFS\_requirements.sh
+with its symbolic link
+usr/share/rear/verify/NETFS/default/050\_check\_NETFS\_requirements.sh
+On the other hand such symbolic links look awkward
+when a check is basically always needed (where "basically always"
+means it is in particular needed during 'mkrescue' and 'recover').
+But the general 'init' stage is always run
+so for generic checks - even when feature specific - the
+general 'init' stage could be the best place in practice.
+
+I think the messages should be shorter,
+in particular without the word "warning", cf.
+[https://schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html](https://schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html)
+and without separator lines `--------` that we normally don't use.
+E.g. for comparison see the "deprecated" messages in
+usr/share/rear/lib/borg-functions.sh
+(that is rather old code before LogPrintError was introduced)
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-04 16:05](https://github.com/rear/rear/pull/3100#issuecomment-1877354672):
+
+> @pcahyna
+>
+> > @robertdahlem there is still a needless merge commit in the history
+> > now:
+> > [11f4e02](https://github.com/rear/rear/commit/11f4e0284c7b757444de94feecec56295b013114)
+>
+> Yes, I see. But it doesn't show up in the files changed by this PR.
+> Also it doesn't show up in `git diff master http-download`. So I
+> thought it is fine.
+
+It is not a big problem for sure, it just complicates and clutters the
+history a bit for those that are going to look at it later. Also, I
+suspected that your 'commits from other people show up between my
+commits' problem was caused by such merge commits, where GitHub got
+confused by the too complicated history. But as the problem does not
+appear anymore, I am not sure. Maybe it was something else.
+
+> > Would it work for you to use
+> >
+> > # git rebase master
+> > # git push -f
+>
+> It might. It did not try that. I am still confused about the rebase
+> stuff. Also rebase and force push drove me into the f\*ckup.
+> Additionally I think that the merge commit is not needless. It proves
+> that my patches don't conflict with master.
+>
+> The history of all that is:
+>
+> * I push a PR
+>
+> * Discussion ensues, further local development happens
+>
+> * Meanwhile people commit other stuff to master
+>
+> * To prove that my locally developed stuff does not conflict I need to merge my branch with master before pushing. Also I shy away from doing anything with `--force`.
+>
+> * Or don't I merge? What do people do at this point (aka "another push to a branch while master has moved on")?
+
+I admit I am usually sloppy with that, just like @jsmeix. I keep my
+branch not updated and keep pushing to it, despite that checking that
+the branch does not conflict with new changes as you do is for sure the
+right thing to do. Merely merging with the updated master branch and
+pushing the merge commit does not itself prove it, though. It only
+proves that a merge is possible (i.e. that there is no textual
+conflict), not that the merge will actually work. There could be a
+semantic conflict. Consider using a shared function which in the
+meantime gets renamed. Since the rename occurs in a different file than
+you are editing, it appears to merge fine, but the result will not work.
+So, it is not enough to merge the branches, you need to re-test the
+merge result. Merging the branches by itself does not prove much, it is
+good as the first step for testing the updated result. Rebasing on top
+of the current master does have the same effect though. If you don't
+like `--force`, merging is probably the best option. Note though that
+force pushes should show in the web UI, see
+
+> @[robertdahlem](https://github.com/robertdahlem)
+> [force-pushed](https://github.com/rear/rear/compare/6725d987d5bc8b7997e3b2b772be9412445368c3..104858f1aa8ca4827a67a004df551568c551be48)
+> the http-download branch from[ 6725d98
+> ](https://github.com/rear/rear/commit/6725d987d5bc8b7997e3b2b772be9412445368c3)to
+> 104858f
+
+in the PR history. This should allow you to go back when the force push
+messes up something.
+
+If you are just interested in whether the merge is possible, the GitHub
+UI should tell you without attempting the merge itself, as @jsmeix
+mentioned. For example see
+[https://github.com/rear/rear/pull/3041](https://github.com/rear/rear/pull/3041).
+Do you see the 'This branch has conflicts that must be resolved' message
+at the bottom?
+
+Anyway, all this is not very important. Thank you a lot for you
+contribution, I will switch to reviewing the content of it instead of
+nitpicking about the Git process.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-04 16:07](https://github.com/rear/rear/pull/3100#issuecomment-1877357714):
+
+> in particular without the word "warning"
+
+I would not be afraid of it. IMO, deprecation messages are a good use of
+the word 'warning'. It is something that is not a problem now, but it
+will be a problem in the future.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-04 16:20](https://github.com/rear/rear/pull/3100#issuecomment-1877382079):
+
+@jsmeix
+
+> I think the messages should be shorter,
+> in particular without the word "warning", cf.
+> [https://schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html](https://schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html)
+
+Schlomo is a man of strong opinions. :-)
+
+I dare to disagree with him in this particular case, especially where he
+states "ERROR means that I as a human should take action. Everything
+else is irrelevant for me."
+
+Most of these warnings end with "Please fix your configuration" which is
+pretty much the same as "human, you should take action". No bad things
+will happen (for now) when you ignore them, so they are not ERROR. Bad
+things WILL happen when sometime in the future "deprecated" turns into
+"gone", that makes them relevant.
+
+You should see this, you should act on it, but they are not ERROR.
+
+As for the name and position of `002_pxe_sanity_checks.sh` in the
+directory structure: I just used what looked practical.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-04 16:46](https://github.com/rear/rear/pull/3100#issuecomment-1877429794):
+
+> Up to now we do not have any `_sanity_` named script. But we have
+> usr/share/rear/init/default/010\_EFISTUB\_check.sh so
+> usr/share/rear/init/default/020\_PXE\_check.sh could be a better name?
+
+There are many other scripts with `check` in their name in the `prep`
+stage and they also check the consistency of the variables, so `check`
+seems good choice indeed. For another possibility see
+[https://github.com/rear/rear/blob/master/usr/share/rear/prep/default/020\_translate\_url.sh](https://github.com/rear/rear/blob/master/usr/share/rear/prep/default/020_translate_url.sh)
+(it also contains many deprecation messages that could serve as another
+inspiration).
+
+> In general I wonder if feature specific check scripts should be always
+> run in the general 'init' stage? Wouldn't be a feature specific
+> sub-directory better? E.g. something like
+> usr/share/rear/prep/NETFS/default/050\_check\_NETFS\_requirements.sh
+> with its symbolic link
+> usr/share/rear/verify/NETFS/default/050\_check\_NETFS\_requirements.sh
+> On the other hand such symbolic links look awkward when a check is
+> basically always needed (where "basically always" means it is in
+> particular needed during 'mkrescue' and 'recover'). But the general
+> 'init' stage is always run so for generic checks - even when feature
+> specific - the general 'init' stage could be the best place in
+> practice.
+
+That's the point - I don't think that this needs to run during recovery
+(and bother the user with deprecation messages), right? So it could be
+just under `prep`, without any symlinks. Moreover, it probably does not
+need to be under `default` to run for every `OUTPUT`, `PXE` directory
+should be enough. So I would put it under `prep/PXE/default`.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-05 07:49](https://github.com/rear/rear/pull/3100#issuecomment-1878261816):
+
+@pcahyna @jsmeix
+
+> So it could be just under `prep`, without any symlinks. Moreover, it
+> probably does not need to be under `default` to run for every
+> `OUTPUT`, `PXE` directory should be enough. So I would put it under
+> `prep/PXE/default`.
+
+Done: 9a9e9df7a60182a38fef79e69ded25084eb4c1d2
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-05 08:13](https://github.com/rear/rear/pull/3100#issuecomment-1878283424):
+
+@Flunkyball @pcahyna @rear/contributors
+please have a look here as time permits
+and ideally test it if possible for you.
+Thank you in advance!
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-05 08:23](https://github.com/rear/rear/pull/3100#issuecomment-1878294450):
+
+Currently the GitHub web frontend for this pull request shows
+
+ 1 workflow awaiting approval
+ This workflow requires approval from a maintainer.
+ 4 neutral, and 11 successful checks
+ [Approve and run]
+
+How could "a maintainer" act on this when it does not tell him
+what specific workflow "This workflow" actually is?
+
+The generic GitHub information
+[https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks](https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks)
+only tells vaguely why that approval is needed
+
+ Although workflows from forks do not have
+ access to sensitive data such as secrets,
+ they can be an annoyance for maintainers
+ if they are modified for abusive purposes.
+
+But I cannot know if and how "This workflow"
+was modified for abusive purposes
+and what abusive purposes are possible here
+so how could one make a decision in this specific case?
+
+@pcahyna
+do you perhaps know what "This workflow" actually is
+and if and how "This workflow" could have been modified
+for abusive purposes and what abusive purposes
+might be possible with "This workflow"?
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-05 09:42](https://github.com/rear/rear/pull/3100#issuecomment-1878388332):
+
+@jsmeix
+
+> But I cannot know if and how "This workflow"
+> was modified for abusive purposes
+> and what abusive purposes are possible here
+> so how could one make a decision in this specific case?
+
+It specifically addresses the `.github/workflow` directory which
+probably does automated quality assurance stuff. Because it is automated
+it could clog resources or overwrite stuff, so there might be dragons.
+As I made no changes in this directory I think you can switch to YOLO
+mode and hit "Approve and run". :-)
+
+Most changes in `.github/workflow` were made by @schlomo and @gdha.
+Maybe they can sched some light?
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-05 10:18](https://github.com/rear/rear/pull/3100#issuecomment-1878435728):
+
+@jsmeix
+
+> Currently the GitHub web frontend for this pull request shows
+>
+> 1 workflow awaiting approval
+> This workflow requires approval from a maintainer.
+> 4 neutral, and 11 successful checks
+> [Approve and run]
+>
+> How could "a maintainer" act on this when it does not tell him what
+> specific workflow "This workflow" actually is?
+>
+> The generic GitHub information
+> [https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks](https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks)
+> only tells vaguely why that approval is needed
+>
+> Although workflows from forks do not have
+> access to sensitive data such as secrets,
+> they can be an annoyance for maintainers
+> if they are modified for abusive purposes.
+>
+> But I cannot know if and how "This workflow" was modified for abusive
+> purposes and what abusive purposes are possible here so how could one
+> make a decision in this specific case?
+>
+> @pcahyna do you perhaps know what "This workflow" actually is and if
+> and how "This workflow" could have been modified for abusive purposes
+> and what abusive purposes might be possible with "This workflow"?
+
+mentioning "This workflow" without telling which is really very
+annoying. I go to the "Files changed" section and check that no workflow
+files (under `.github`) were modified, the changes should then be safe.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-05 10:19](https://github.com/rear/rear/pull/3100#issuecomment-1878437494):
+
+In practice, when I approve the workflow, the only thing that runs is
+Differential ShellCheck.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-05 10:33](https://github.com/rear/rear/pull/3100#issuecomment-1878455931):
+
+@robertdahlem
+I see that you are changing some variables to lowercase, because they
+are local to the script. Which is good (assuming that they are really
+not used anywhere else - I have not checked). But I think that you
+should also declare them as `local` then.
+[https://github.com/rear/rear/wiki/Coding-Style\#variables](https://github.com/rear/rear/wiki/Coding-Style#variables)
+.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-05 13:54](https://github.com/rear/rear/pull/3100#issuecomment-1878699421):
+
+@pchayna
+
+> @robertdahlem I see that you are changing some variables to lowercase,
+> because they are local to the script. Which is good (assuming that
+> they are really not used anywhere else - I have not checked).
+
+I have. :-)
+
+> But I think that you should also declare them as `local` then.
+> [https://github.com/rear/rear/wiki/Coding-Style\#variables](https://github.com/rear/rear/wiki/Coding-Style#variables)
+> .
+
+Fixed: 405d9fa9da2229299299c84a1bae7437383416ed
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-05 14:18](https://github.com/rear/rear/pull/3100#issuecomment-1878754087):
+
+@schlomo
+
+> I put in a bunch of fixes around the use of positive logic and
+> quoting.
+
+Commited: a2e383495c83eef12140845fa008aa54a19aa41d
+
+> Do you see a way to merge both copy scripts (for TFTP and for HTTP)
+> into one? They seem to be doing nearly the same.
+
+I'm not too happy with implementing that idea. They have more different
+than common lines and adding logic to tell these apart would only
+complicate things. I'm not actually opposed to the idea but would leave
+that as exercise to interested parties.
+
+> Another thought that keeps me wondering is the following: If putting
+> the boot files onto a TFTP *or* HTTP server requires file system
+> access, then why do we need to differentiate so much between TFTP and
+> HTTP?
+
+In an SELinux environment you can't (easily) resort to one common
+directory. `/var/lib/tftpboot` has `tftpdir_rw_t` and can't be accessed
+by `httpd`. `/var/www/whatever` has `httpd_sys_content_t` and can't be
+accessed by `tftpd`.
+
+If you use an environment where you can mix them, you can configure
+`PXE_HTTP_UPLOAD_URL="$PXE_TFTP_UPLOAD_URL"` and be done with one
+directory. But I wouldn't default to this because it triggers SELinux
+debugging and that is not everybody's cup of tea. Even die hard RHEL
+guys like to maneuver around that. :-)
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-08 23:23](https://github.com/rear/rear/pull/3100#issuecomment-1881976595):
+
+@jsmeix I have lost track a little bit ... are all discussion points,
+suggested changes etc. resolved? Or do you still need me to fix
+something before we can merge?
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-09 09:45](https://github.com/rear/rear/pull/3100#issuecomment-1882734142):
+
+@robertdahlem
+when you tested the current final state
+and this state works well for you,
+then I would like to merge it "bona fide"
+with one or two days delay so that others
+like @Flunkyball could also have a look
+and ideally test it in their environment.
+
+Currently we are in ReaR 2.8 development phase
+and there is not yet a ReaR 2.8 release date planned
+(i.e there is plenty of time until ReaR 2.8 release)
+so others who are interested could test things
+after it was merged and if issues appear
+we have time to fix them properly.
+
+By the way:
+Since a long time it is on my private todo list
+to learn PXE booting but I never found time for it.
+Perhaps this issue will finally let me do that.
+But no promises. It all depends on whether or not
+other stuff takes attention with higher priority,
+in particular issues of SUSE customers who pay my salary.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-12 12:51](https://github.com/rear/rear/pull/3100#issuecomment-1889111286):
+
+@robertdahlem
+did you test the current final state
+and does this state work well for you?
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-12 16:43](https://github.com/rear/rear/pull/3100#issuecomment-1889626698):
+
+> @robertdahlem did you test the current final state and does this state
+> work well for you?
+
+@jsmeix I've been busy with other stuff, sorry. Paying customers, you
+know the drill. :-)
+
+I've just built a current RPM and delivered it to my workplace. I have
+installed that RPM on several bare metal test machines. They are
+backupped with Rubrik (BACKUP=CDM/OUTPUT=PXE) and I have to wait until
+Monday when the next backup cycle is through. My colleagues will do a
+regression test with BACKUP=NETFS/OUTPUT=ISO.
+
+I will report.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-17 12:09](https://github.com/rear/rear/pull/3100#issuecomment-1895679167):
+
+@jsmeix
+
+> I've just built a current RPM and delivered it to my workplace. I have
+> installed that RPM on several bare metal test machines. They are
+> backupped with Rubrik (BACKUP=CDM/OUTPUT=PXE) and I have to wait until
+> Monday when the next backup cycle is through. My colleagues will do a
+> regression test with BACKUP=NETFS/OUTPUT=ISO.
+
+I can report that BACKUP=CDM/OUTPUT=PXE works with TFTP and HTTP
+download protocols. Also there have been no regressions with our
+standard BACKUP=NETFS/OUTPUT=ISO.
+
+Colleagues now are eager to switch to BACKUP=NETFS/OUTPUT=PXE. :-)
+
+So yes, we did test the final state and it worked well for us.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-17 12:26](https://github.com/rear/rear/pull/3100#issuecomment-1895706945):
+
+@robertdahlem thanks for the contribution and the thorough testing! I
+think you should edit the PR description as you have changed
+`PXE_SCHEME` to something else. Otherwise the code now looks good to me.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-17 12:26](https://github.com/rear/rear/pull/3100#issuecomment-1895708118):
+
+@rear/contributors @Flunkyball
+I intend to merge it on Friday (19 Jan. 2024) afternoon
+unless there are objections.
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-17 13:02](https://github.com/rear/rear/pull/3100#issuecomment-1895768046):
+
+I would like to add a comment
+about the variable names
+PXE\_TFTP\_UPLOAD\_URL
+PXE\_HTTP\_UPLOAD\_URL
+PXE\_HTTP\_DOWNLOAD\_URL
+
+The example in default.conf
+
+ # PXE_TFTP_UPLOAD_URL=nfs://tftp-server/var/lib/tftpboot
+ # PXE_HTTP_UPLOAD_URL=nfs://web-server/var/www/html
+ # PXE_HTTP_DOWNLOAD_URL=http://web-server
+
+shows that for the TFTP and HTTP \*\_UPLOAD\_URL variables
+the actually used protocol ('nfs' in this case)
+does not match the protocol in the variable name
+which might be confusing at first glance.
+
+The reason is that actually the \*\_UPLOAD\_URL variables
+could be named with full explanatory names like
+PXE\_UPLOAD\_URL\_FOR\_TFTP\_DOWNLOAD
+PXE\_UPLOAD\_URL\_FOR\_HTTP\_DOWNLOAD
+but I think such names are oververbose
+so for me the shorter names are fine.
+
+Perhaps it could be explained in default.conf
+that also for PXE\_TFTP\_UPLOAD\_URL and PXE\_HTTP\_UPLOAD\_URL
+"nfs or any other mountable scheme" must be used
+(i.e. same as already for PXE\_CONFIG\_URL)
+but I think the example in default.conf is good enough.
+
+For the fun of it:
+Listing variable names in default.conf with their length:
+
+ # grep -o '^[A-Z][A-Z][^=]*' usr/share/rear/conf/default.conf | awk '{ print length, $0 }' | sort -n
+
+ 2 OS
+ 4 ARCH
+ 4 LIBS
+ ...
+ 37 AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE
+ 39 NON_FATAL_BINARIES_WITH_MISSING_LIBRARY
+ 43 AUTOINCREASE_DISK_SIZE_THRESHOLD_PERCENTAGE
+
+So the winner of the "longest config variable name contest"
+is me ;-)
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-17 14:02](https://github.com/rear/rear/pull/3100#issuecomment-1895876211):
+
+> @robertdahlem thanks for the contribution and the thorough testing! I
+> think you should edit the PR description as you have changed
+> `PXE_SCHEME` to something else. Otherwise the code now looks good to
+> me.
+
+@pcahyna Fixed.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-17 14:51](https://github.com/rear/rear/pull/3100#issuecomment-1895971635):
+
+> Perhaps it could be explained in default.conf that also for
+> PXE\_TFTP\_UPLOAD\_URL and PXE\_HTTP\_UPLOAD\_URL "nfs or any other
+> mountable scheme" must be used (i.e. same as already for
+> PXE\_CONFIG\_URL) but I think the example in default.conf is good
+> enough.
+
+@jsmeix
+For PXE\_HTTP\_UPLOAD\_URL it already says so:
+
+ # PXE_HTTP_UPLOAD_URL must be set and point to your
+ # web server "DocumentRoot" (httpd) or "root" (nginx) directory
+ # using nfs or any other mountable scheme.
+
+For PXE\_TFTP\_UPLOAD\_URL I added an explanation.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-17 15:20](https://github.com/rear/rear/pull/3100#issuecomment-1896031823):
+
+@robertdahlem something bad has happened with your merge (with uptodate
+master) and push. What did you do?
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-17 17:47](https://github.com/rear/rear/pull/3100#issuecomment-1896300795):
+
+> @robertdahlem something bad has happened with your merge (with
+> uptodate master) and push. What did you do?
+
+@pcahyna
+What exactly is "something bad"? My git log reads:
+
+ commit ccb9d9a9d95c19872abc9d416a34e9863cd0c72e
+ Merge: ebbad506 3e876e1f
+ Author: Robert Dahlem [pcahyna](https://github.com/pcahyna) commented at [2024-01-17 18:59](https://github.com/rear/rear/pull/3100#issuecomment-1896452228):
+
+@robertdahlem
+[https://github.com/rear/rear/pull/3100/commits](https://github.com/rear/rear/pull/3100/commits)
+suddenly shows 29 commits and there are duplicates (like
+[https://github.com/rear/rear/pull/3100/commits/d751b64c5523e78e306a75b606cfb777d109f170](https://github.com/rear/rear/pull/3100/commits/d751b64c5523e78e306a75b606cfb777d109f170)
+and
+[https://github.com/rear/rear/pull/3100/commits/655eb8d1bed9ca48784a354108c4c5980223b4c5](https://github.com/rear/rear/pull/3100/commits/655eb8d1bed9ca48784a354108c4c5980223b4c5)
+) I will check out your branch and examine it locally.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-17 19:05](https://github.com/rear/rear/pull/3100#issuecomment-1896460434):
+
+ commit ccb9d9a9d95c19872abc9d416a34e9863cd0c72e
+ Merge: ebbad506 3e876e1f
+ Author: Robert Dahlem [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-17 19:23](https://github.com/rear/rear/pull/3100#issuecomment-1896492473):
+
+@pcahyna
+
+> that's the problem - it should not be a merge, the parent commit
+> [3e876e1](https://github.com/rear/rear/commit/3e876e1fb0d88ceff24e6601d9955ad1b366c67b)
+> adds another copy of the history. Try `gitk` to visualize it.
+
+Bloody git. :-( I synced in GitHub, then
+
+ git checkout master
+ git pull
+ git checkout http-download
+ git rebase master
+ git pull # I think here might have been a merge
+ vi ./usr/share/rear/conf/default.conf
+ git add ./usr/share/rear/conf/default.conf
+ gcm "add some explanation for PXE_TFTP_UPLOAD_URL"
+ git push
+
+Anyway. The "files changed" tab looks good to me. Do you need me to do
+something?
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-17 19:56](https://github.com/rear/rear/pull/3100#issuecomment-1896590665):
+
+> I synced in GitHub
+
+Meaning, you did a merge it in the GitHub WebUI?
+
+> git pull \# I think here might have been a merge
+
+Yes. git pull = git fetch + git merge.
+
+The rebased version (after `git rebase master` - rev.
+ebbad506e033962867c876e74f69a822ba1302f9 ) was already fine, so the
+`git pull` was not needed. Compare
+ebbad506e033962867c876e74f69a822ba1302f9 and
+3e876e1fb0d88ceff24e6601d9955ad1b366c67b - they are identical.
+
+> gcm "add some explanation for PXE\_TFTP\_UPLOAD\_URL"
+
+what is "gcm" ? (Looks like git commit --amend)
+
+> Anyway. The "files changed" tab looks good to me. Do you need me to do
+> something?
+
+Please, in your `http-download` branch, do
+`git reset --hard ebbad506` - this will reset your branch to the
+revision after `git rebase`
+`git cherry-pick -m1 ccb9d9a9d95c19872abc9d416a34e9863cd0c72e` - this
+will reapply your "add some explanation for PXE\_TFTP\_UPLOAD\_URL"
+commit
+`git push --force`
+
+To verify that this procedure did not introduce any file changes, do
+`git diff ccb9d9a9d95c19872abc9d416a34e9863cd0c72e` - it should return
+nothing.
+
+#### [robertdahlem](https://github.com/robertdahlem) commented at [2024-01-18 08:40](https://github.com/rear/rear/pull/3100#issuecomment-1898030753):
+
+@pcahyna
+
+> > I synced in GitHub
+> > Meaning, you did a merge it in the GitHub WebUI?
+
+I clicked on "Sync fork" in the WebUI.
+
+> The rebased version (after `git rebase master` - rev.
+> [ebbad50](https://github.com/rear/rear/commit/ebbad506e033962867c876e74f69a822ba1302f9)
+> ) was already fine, so the `git pull` was not needed.
+
+I took an additional note in my documentation. "Do Never. Ever. use git
+pull when git rebase is sufficient". :-)
+But how would I get commits which have been made remote (not in master,
+but in my branch)?
+
+> > gcm "add some explanation for PXE\_TFTP\_UPLOAD\_URL"
+> > what is "gcm" ? (Looks like git commit --amend)
+
+`alias gcm='git commit -m'`
+
+> Please, in your `http-download` branch, do `git reset --hard ebbad506`
+> - this will reset your branch to the revision after `git rebase`
+> `git cherry-pick -m1 ccb9d9a9d95c19872abc9d416a34e9863cd0c72e` - this
+> will reapply your "add some explanation for PXE\_TFTP\_UPLOAD\_URL"
+> commit `git push --force`
+
+I did as you wrote. Is it ok now?
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-18 16:11](https://github.com/rear/rear/pull/3100#issuecomment-1898784463):
+
+> @pcahyna
+>
+> > > I synced in GitHub
+> > > Meaning, you did a merge it in the GitHub WebUI?
+>
+> I clicked on "Sync fork" in the WebUI.
+
+I see. I think it is preferable to avoid that and leave the branch
+descending from an older state. See jsmeix's
+[https://github.com/rear/rear/pull/3100\#issuecomment-1876866258](https://github.com/rear/rear/pull/3100#issuecomment-1876866258)
+:
+
+> So bottom line from my point of view:
+> Don't worry in advance about possible merge conflicts.
+
+> > The rebased version (after `git rebase master` - rev.
+> > [ebbad50](https://github.com/rear/rear/commit/ebbad506e033962867c876e74f69a822ba1302f9)
+> > ) was already fine, so the `git pull` was not needed.
+>
+> I took an additional note in my documentation. "Do Never. Ever. use
+> git pull when git rebase is sufficient". :-) But how would I get
+> commits which have been made remote (not in master, but in my branch)?
+
+Yes, to update your branch to the uptodate master branch one would use
+`git rebase` or `git merge` (performed implicitly by `git pull`) but not
+both.
+
+Usually there would not be any commits made in your branch at the remote
+side. But here I see that you needed to get the additional commit that
+was created by accepting the review suggestions in the WebUI. For this,
+I would use "git pull" first, before I use anything that changes my
+local history (`git rebase`, `git reset`). Or for better control
+`git fetch` followed by `git merge`. This would merely get the new
+commit(s) without merging anything (to enforce this, add `--ff-only` to
+`git merge`). Only when the local branch is in sync with the remote
+version, rebase if you want, and then force-push. But I think it may be
+better to not worry about updating to the current master branch code, so
+I would even skip that (I only rarely rebase).
+
+> > > gcm "add some explanation for PXE\_TFTP\_UPLOAD\_URL"
+> > > what is "gcm" ? (Looks like git commit --amend)
+>
+> `alias gcm='git commit -m'`
+>
+> > Please, in your `http-download` branch, do
+> > `git reset --hard ebbad506` - this will reset your branch to the
+> > revision after `git rebase`
+> > `git cherry-pick -m1 ccb9d9a9d95c19872abc9d416a34e9863cd0c72e` -
+> > this will reapply your "add some explanation for
+> > PXE\_TFTP\_UPLOAD\_URL" commit `git push --force`
+>
+> I did as you wrote. Is it ok now?
+
+Yes, it is good now. I think you can click on "compare" in the message
+about force-push above and see that your force-push did not introduce
+any content changes. The commit history looks good now.
+
+#### [pcahyna](https://github.com/pcahyna) commented at [2024-01-22 18:49](https://github.com/rear/rear/pull/3100#issuecomment-1904603368):
+
+@jsmeix ready to merge?
+
+#### [jsmeix](https://github.com/jsmeix) commented at [2024-01-23 06:33](https://github.com/rear/rear/pull/3100#issuecomment-1905374086):
+
+@pcahyna
+I was ready to merge since
+[https://github.com/rear/rear/pull/3100\#issuecomment-1895679167](https://github.com/rear/rear/pull/3100#issuecomment-1895679167)
+but then I waited until the subsequent things got fixed.
+I think in
+[https://github.com/rear/rear/pull/3100\#issuecomment-1898784463](https://github.com/rear/rear/pull/3100#issuecomment-1898784463)
+I missed your final "it is good now".
+So, yes it should be ready to merge now.
+I will merge it today afternoon unless someone objects.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2023-12-07.3101.issue.closed.md b/docs/issues/2023-12-07.3101.issue.closed.md
new file mode 100644
index 00000000..2d5ca85a
--- /dev/null
+++ b/docs/issues/2023-12-07.3101.issue.closed.md
@@ -0,0 +1,246 @@
+[\#3101 Issue](https://github.com/rear/rear/issues/3101) `closed`: ReaR 2.7 Ignores loop partition type Disks
+=============================================================================================================
+
+**Labels**: `support / question`, `fixed / solved / done`
+
+#### 
[ramzcode](https://github.com/ramzcode) opened issue at [2023-12-07 13:58](https://github.com/rear/rear/issues/3101):
+
+- ReaR version ("/usr/sbin/rear -V"):
+ 2.7
+
+- OS version ("cat /etc/os-release" or "lsb\_release -a" or "cat
+ /etc/rear/os.conf"):
+ Amazon Linux 2 & Mostly for other Distros too
+
+- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+ /etc/rear/local.conf"):
+ AUTOEXCLUDE\_DISKS=n added to include extra disks
+
+- Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+ guest or PowerVM LPAR):
+ VM KVM / AWS EC2
+
+- System architecture (x86 compatible or PPC64/PPC64LE or what exact
+ ARM device):
+ x86
+
+- 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):
+ SSD
+
+- Storage layout ("lsblk -ipo
+ NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
+
+
+
+ NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
+ /dev/nvme1n1 /dev/nvme1n1 nvme disk ext4 8G /disk-a
+ /dev/nvme2n1 /dev/nvme2n1 nvme disk 23G
+ `-/dev/nvme2n1p1 /dev/nvme2n1p1 /dev/nvme2n1 nvme part ext4 23G /disk-b
+ /dev/nvme0n1 /dev/nvme0n1 nvme disk 8G
+ |-/dev/nvme0n1p1 /dev/nvme0n1p1 /dev/nvme0n1 nvme part xfs / 8G /
+ `-/dev/nvme0n1p128 /dev/nvme0n1p128 /dev/nvme0n1 nvme part 1M
+
+- Description of the issue (ideally so that others can reproduce it):
+
+When a disk is formatted directly
+with out a partition table like, GPT, MBR or DOS,
+then the disk partition type is set to loop.
+ex: `mkfs.ext4 /dev/nvme1n1`.
+Due to the Type ReaR excludes the disk / partitions and FS.
+
+- Workaround, if any:
+
+Reformat the disk with Partition table like GPT
+or remove the loop type from the EXCLUDED List
+in the ReaR default conf file.
+
+#### [ramzcode](https://github.com/ramzcode) commented at [2023-12-07 14:00](https://github.com/rear/rear/issues/3101#issuecomment-1845394043):
+
+[jsmeix](https://github.com/jsmeix) commented at [2023-12-11 12:44](https://github.com/rear/rear/issues/3101#issuecomment-1850008540):
+
+I can reproduce the "rear mkrescue" part with a USB disk /dev/sdb
+
+ # dd if=/dev/zero of=/dev/sdb count=64 bs=1M
+ 64+0 records in
+ 64+0 records out
+ 67108864 bytes (67 MB, 64 MiB) copied, 1.94995 s, 34.4 MB/s
+
+ # lsblk -ipo KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
+ KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
+ ...
+ /dev/sdb usb disk 465.8G
+
+ # parted -s /dev/sdb unit GiB print
+ Error: /dev/sdb: unrecognised disk label
+ Model: TOSHIBA External USB 3.0 (scsi)
+ Disk /dev/sdb: 466GiB
+ Sector size (logical/physical): 512B/512B
+ Partition Table: unknown
+ Disk Flags:
+
+ # mkfs.ext4 /dev/sdb
+ mke2fs 1.46.4 (18-Aug-2021)
+ Creating filesystem with 122096645 4k blocks and 30531584 inodes
+ Filesystem UUID: e1fe595f-0d9f-4d10-a152-45864d5ece07
+ Superblock backups stored on blocks:
+ 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
+ 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
+ 102400000
+ Allocating group tables: done
+ Writing inode tables: done
+ Creating journal (262144 blocks): done
+ Writing superblocks and filesystem accounting information: done
+
+ # lsblk -ipo KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
+ KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
+ ...
+ /dev/sdb usb disk ext4 465.8G
+
+ # parted -s /dev/sdb unit GiB print
+ Model: TOSHIBA External USB 3.0 (scsi)
+ Disk /dev/sdb: 466GiB
+ Sector size (logical/physical): 512B/512B
+ Partition Table: loop
+ Disk Flags:
+ Number Start End Size File system Flags
+ 1 0.00GiB 466GiB 466GiB ext4
+
+ # mkdir /mountpoint_sdb
+
+ # mount -v /dev/sdb /mountpoint_sdb
+ mount: /dev/sdb mounted on /mountpoint_sdb.
+
+ # lsblk -ipo KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
+ KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
+ ...
+ /dev/sdb usb disk ext4 465.8G /mountpoint_sdb
+
+ # usr/sbin/rear -D mkrescue
+ ...
+
+
+ # less var/lib/rear/layout/disklayout.conf
+ ...
+ # Disk /dev/sdb
+ # Format: disk