update the issues pages

rear · Oct 4, 2024 · 7a847b2 · 7a847b2
1 parent 7937128
commit 7a847b2
Show file tree

Hide file tree

Showing 14 changed files with 1,494 additions and 0 deletions.
diff --git a/docs/issues/2024-09-05.3311.issue.closed.md b/docs/issues/2024-09-05.3311.issue.closed.md
@@ -0,0 +1,81 @@
+[\#3311 Issue](https://github.com/rear/rear/issues/3311) `closed`: Any thoughts why we can't use `find_device` here?
+====================================================================================================================
+
+**Labels**: `cleanup`
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) opened issue at [2024-09-05 15:13](https://github.com/rear/rear/issues/3311):
+
+              Any thoughts why we can't use `find_device` here?
+
+[https://github.com/rear/rear/blob/2073e77f1ed213653bbf846d67bef346a9f65da9/usr/share/rear/format/USB/default/200\_check\_usb\_layout.sh\#L12-L13](https://github.com/rear/rear/blob/2073e77f1ed213653bbf846d67bef346a9f65da9/usr/share/rear/format/USB/default/200_check_usb_layout.sh#L12-L13)
+
+It seems to me like our code simply doesn't handle the nvme use case
+yet, it assumes a sysfs device path like
+`/devices/pci0000:00/0000:00:10.0/host2/target2:0:1/2:0:1:0/block/sdb/sdb1`
+whereas in your example we have
+`devices/pci0000:c0/0000:c0:03.3/0000:c5:00.0/nvme/nvme0/nvme0n1`
+
+@xwhitebeltx have you tried creating a partition and specifying that
+instead of the whole disk?
+
+*Originally posted by @schlomo in
+[https://github.com/rear/rear/issues/3178\#issuecomment-2004477308](https://github.com/rear/rear/issues/3178#issuecomment-2004477308)*
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-09-05 15:21](https://github.com/rear/rear/issues/3311#issuecomment-2331998374):
+
+@schlomo To use the `find_disk` function in script
+`lib/layout-functions.sh` there is a problem in function
+`get_parent_components` on line `done < $LAYOUT_DEPS`  
+The $LAYOUT\_DEPS is empty.  
+When we add in the function
+`LAYOUT_DEPS="$VAR_DIR/layout/diskdeps.conf"` then it works better.  
+However, that being said it is better not to use `find_disk` function as
+it searches the diskdeps.conf file for the parent device. And, in this
+case (nvme0n1) it will not find it as it is skipped as an empty device
+(by savelayout).  
+The reason why LAYOUT\_DEPS variable is empty in above case (with
+treating nvme0n1 as an USB device) is because the initialization of
+these variables is only done in the savelayout workflow.  
+We need to find a better why.
+
+Therefore, I propose to remove the comments in
+[rear/usr/share/rear/format/USB/default/200\_check\_usb\_layout.sh](https://github.com/rear/rear/blob/2073e77f1ed213653bbf846d67bef346a9f65da9/usr/share/rear/format/USB/default/200_check_usb_layout.sh#L12-L13)
+as it is misleading info.
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-09-06 09:32](https://github.com/rear/rear/issues/3311#issuecomment-2333656365):
+
+Was able to get it to work - still need to test it with legacy USB
+devices.
+
+    #-> rear -v -d -D format -- --efi /dev/nvme7n1
+    Relax-and-Recover 2.6 / 2020-06-17
+    Running rear format (PID 2853731)
+    Using log file: /var/log/rear/rear-AWSABLIRLL000K.log
+    Running workflow format on the normal/original system
+    USB device /dev/nvme7n1 is not formatted with ext2/3/4 or btrfs filesystem
+    UserInput -I USB_DEVICE_CONFIRM_FORMAT needed in /usr/share/rear/format/USB/default/200_check_usb_layout.sh line 68
+    Type exactly 'Yes' to format /dev/nvme7n1 with ext3 filesystem
+    (default 'No' timeout 300 seconds)
+    Yes
+    UserInput: No choices - result is 'Yes'
+    Repartitioning '/dev/nvme7n1'
+    The --efi toggle was used with format - making an EFI bootable device '/dev/nvme7n1'
+    Creating GUID partition table (GPT) on '/dev/nvme7n1'
+    Creating EFI system partition with size 1024 MiB aligned at 8 MiB on '/dev/nvme7n1'
+    Creating ReaR data partition up to 100% of '/dev/nvme7n1'
+    Setting 'boot' flag on /dev/nvme7n1
+    Creating vfat filesystem on EFI system partition on '/dev/nvme7n1p1'
+    Creating ext3 filesystem with label 'REAR-000' on '/dev/nvme7n1p2'
+    Adjusting filesystem parameters on '/dev/nvme7n1p2'
+    Exiting rear format (PID 2853731) and its descendant processes ...
+    Running exit tasks
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-09-10 11:50](https://github.com/rear/rear/issues/3311#issuecomment-2340450543):
+
+With PR \#3312 merged we can close this issue. The comment has been
+removed.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-09-06.3312.pr.merged.md b/docs/issues/2024-09-06.3312.pr.merged.md
@@ -0,0 +1,30 @@
+[\#3312 PR](https://github.com/rear/rear/pull/3312) `merged`: \#3178 improve USB device detection
+=================================================================================================
+
+**Labels**: `enhancement`
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) opened issue at [2024-09-06 11:35](https://github.com/rear/rear/pull/3312):
+
+#### Relax-and-Recover (ReaR) Pull Request Template
+
+Please fill in the following items before submitting a new pull request:
+
+##### Pull Request Details:
+
+-   Type: **Enhancement**
+
+-   Impact: **Normal**
+
+-   Reference to related issue (URL): \#3178 and \#3311
+
+-   How was this pull request tested? On a system with nvme devices and
+    also tested with a normal legacy USB device
+
+-   Description of the changes in this pull request: To fix the error
+    'Unable to determine real USB device based on USB device
+    /dev/nvme?n1'
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-09-06.3313.issue.closed.md b/docs/issues/2024-09-06.3313.issue.closed.md
@@ -0,0 +1,112 @@
+[\#3313 Issue](https://github.com/rear/rear/issues/3313) `closed`: testing-farm:fedora-39-x86\_64 issue with the backup & recovery tests
+========================================================================================================================================
+
+**Labels**: `enhancement`, `ReaR Project`
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) opened issue at [2024-09-06 13:58](https://github.com/rear/rear/issues/3313):
+
+<!-- Relax-and-Recover (ReaR) Issue Template
+Fill in the following items when submitting a new issue.
+Use GitHub Markdown, see "Basic writing and formatting syntax" on
+https://docs.github.com/en/get-started/writing-on-github
+Support is voluntary without guarantee/warranty/liability -->
+
+-   ReaR version ("/usr/sbin/rear -V"): master branch
+
+-   OS version ("cat /etc/os-release" or "lsb\_release -a" or "cat
+    /etc/rear/os.conf"): Fedora 39
+
+-   ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+    /etc/rear/local.conf"):
+
+<!-- -->
+
+    OUTPUT=ISO
+    SSH_FILES=no
+    FIRMWARE_FILES=( no )
+    BACKUP=NETFS
+    BACKUP_URL=iso:///backup
+    OUTPUT_URL=null
+    USER_INPUT_TIMEOUT=10
+    # 4gb backup limit
+    PRE_RECOVERY_SCRIPT=("mkdir /tmp/mnt;" "mount /dev/nvme0n1p5 -o subvol=/root /tmp/mnt/;" "modprobe brd rd_nr=1 rd_size=2097152;" "dd if=/tmp/mnt/var/lib/rear/output/rear-ip-172-31-31-150.iso of=/dev/ram0;" "umount /tmp/mnt/;")
+    ISO_FILE_SIZE_LIMIT=4294967296
+    ISO_DEFAULT=automatic
+    ISO_RECOVER_MODE=unattended
+
+-   Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+    guest or PowerVM LPAR): vm
+
+-   System architecture (x86 compatible or PPC64/PPC64LE or what exact
+    ARM device): x86\_64
+
+-   Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or
+    ELILO or Petitboot): UEFI
+
+-   Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or
+    multipath (DM or NVMe): `nvme0n1`
+
+-   Storage layout ("lsblk -ipo
+    NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
+
+<!-- -->
+
+    NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
+    zram0       252:0    0  3.7G  0 disk [SWAP]
+    nvme0n1     259:0    0  100G  0 disk 
+    ├─nvme0n1p1 259:1    0    1M  0 part 
+    ├─nvme0n1p2 259:2    0 1000M  0 part /boot
+    ├─nvme0n1p3 259:3    0  100M  0 part /boot/efi
+    ├─nvme0n1p4 259:4    0    4M  0 part 
+    └─nvme0n1p5 259:5    0 98.9G  0 part /home
+                                         /
+
+-   Description of the issue (ideally so that others can reproduce it):
+    See log file of failed test
+    [https://artifacts.dev.testing-farm.io/65b3200a-9a0f-43fe-96f1-9e3131bbe274/](https://artifacts.dev.testing-farm.io/65b3200a-9a0f-43fe-96f1-9e3131bbe274/)
+
+-   Workaround, if any: please have package `grub2-efi-x64-modules`
+    installed on the test Fedora VM prior of running ReaR  
+    As @pcahyna is a RH person I assign this issue directly to you.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-09-06 15:58](https://github.com/rear/rear/issues/3313#issuecomment-2334367356):
+
+@gdha if the Fedora test VMs switched to UEFI, there is no way to make
+the tests work in them. I need to find a way to switch the VMs to BIOS
+booting instead.
+
+#### <img src="https://avatars.githubusercontent.com/u/48823770?v=4" width="50">[lzaoral](https://github.com/lzaoral) commented at [2024-09-06 17:38](https://github.com/rear/rear/issues/3313#issuecomment-2334528216):
+
+@pcahyna It is possible to schedule TF tests both for BIOS and UEFI? It
+shouldn't be that hard to extend the current tests and `rear` combined
+with EFI isn't that uncommon set-up. GRUB2 is able to mount ISO images
+and chainload EFI executables (hopefully, that is enough to simulate
+real EFI environment):
+[https://wiki.gentoo.org/wiki/GRUB/Chainloading\#Dual-booting\_Windows\_on\_UEFI\_with\_GPT](https://wiki.gentoo.org/wiki/GRUB/Chainloading#Dual-booting_Windows_on_UEFI_with_GPT)
+What do you think about this idea?
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-09-06 18:20](https://github.com/rear/rear/issues/3313#issuecomment-2334594911):
+
+@lzaoral
+
+> It is possible to schedule TF tests both for BIOS and UEFI?
+
+I am trying to do BIOS in \#3314 , so far no luck. I suppose one can
+find a way to test with UEFI, but this would require some new test
+development and I would like to fix the current test runs first.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-09-09 18:03](https://github.com/rear/rear/issues/3313#issuecomment-2338763441):
+
+As there is apparently no way currently to tell the infrastructure to
+give the test the environment that it needs, I am going to disable the
+problematic test (\#3317) . I also plan to merge the change in
+configuration that requests BIOS (
+[https://github.com/rear/rear/pull/3314](https://github.com/rear/rear/pull/3314)
+). It does not do anything yet, but it will make the tests ready when
+Testing Farm is enhanced to support that, plus it does not hurt to be
+more explicit about what the tests need.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-09-06.3314.pr.merged.md b/docs/issues/2024-09-06.3314.pr.merged.md
@@ -0,0 +1,43 @@
+[\#3314 PR](https://github.com/rear/rear/pull/3314) `merged`: Request BIOS for backup and restore tests
+=======================================================================================================
+
+**Labels**: `enhancement`, `ReaR Project`
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) opened issue at [2024-09-06 16:11](https://github.com/rear/rear/pull/3314):
+
+##### Pull Request Details:
+
+-   Type: **Enhancement**
+
+-   Impact: **Low**
+
+-   Reference to related issue (URL): \#3313
+
+-   How was this pull request tested?  
+    Not at all as it uses a feature that is not yet implemented in the
+    Testing Farm infrastructure.
+
+-   Description of the changes in this pull request:  
+    Request BIOS for backup and restore tests, they are very
+    BIOS-specific due to the way the boot ISO is loaded via
+    syslinux/memdisk. This change uses the documented syntax:
+    [https://tmt.readthedocs.io/en/stable/spec/hardware.html\#boot](https://tmt.readthedocs.io/en/stable/spec/hardware.html#boot)
+    , but it currently does not do anything as the Testing Farm
+    infrastructure does not use the information yet to select the
+    appropriate test VM. It thus merely prepares us for this feature
+    when it gets implemented in Testing Farm and serves as a declaration
+    of what the test needs.
+
+#### <img src="https://avatars.githubusercontent.com/u/26300485?u=9105d243bc9f7ade463a3e52e8dd13fa67837158&v=4" width="50">[pcahyna](https://github.com/pcahyna) commented at [2024-09-10 12:34](https://github.com/rear/rear/pull/3314#issuecomment-2340602659):
+
+I removed the last two commits:  
+"WIP: Point to my fork of tests for debugging" was for testing only, the
+changed tests that it refers to are now merged as
+[https://github.com/rear/rear-integration-tests/pull/6](https://github.com/rear/rear-integration-tests/pull/6)  
+"Try to specify Artemis provisioner explicitly" does not seem to be the
+correct approach.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]
diff --git a/docs/issues/2024-09-08.3315.issue.open.md b/docs/issues/2024-09-08.3315.issue.open.md
@@ -0,0 +1,65 @@
+[\#3315 Issue](https://github.com/rear/rear/issues/3315) `open`: ReaR BACKUP=BACULA director not responding but bacula works perfectly on ubuntu 20.04 how to resove
+====================================================================================================================================================================
+
+**Labels**: `waiting for info`, `support / question`, `ready-to-close?`
+
+#### <img src="https://avatars.githubusercontent.com/u/12408218?v=4" width="50">[WRice](https://github.com/WRice) opened issue at [2024-09-08 05:36](https://github.com/rear/rear/issues/3315):
+
+<!-- Relax-and-Recover (ReaR) Issue Template
+Fill in the following items when submitting a new issue.
+Use GitHub Markdown, see "Basic writing and formatting syntax" on
+https://docs.github.com/en/get-started/writing-on-github
+Support is voluntary without guarantee/warranty/liability -->
+
+-   ReaR version ("/usr/sbin/rear -V"):
+
+-   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"):
+
+-   ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat
+    /etc/rear/local.conf"):
+
+-   Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM
+    guest or PowerVM LPAR):
+
+-   System architecture (x86 compatible or PPC64/PPC64LE or what exact
+    ARM device):
+
+-   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):
+
+-   Storage layout ("lsblk -ipo
+    NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
+
+-   Description of the issue (ideally so that others can reproduce it):
+
+-   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
+
+#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2024-09-10 11:56](https://github.com/rear/rear/issues/3315#issuecomment-2340471644):
+
+@WRice It would be nice if you filled in the issue template. However,
+please use the latest
+[https://github.com/rear/rear/releases](https://github.com/rear/rear/releases)
+package for your distribution (use a debian one) and verify if that did
+not fix your issue. Thanks.
+
+------------------------------------------------------------------------
+
+\[Export of Github issue for
+[rear/rear](https://github.com/rear/rear).\]