Hide Forgot
Description of problem: - In certain circumstances, rear does not update the UUID in /etc/fstab and also other files: ~~~ sed -i ';/7ADA-C08C/s/7ADA-C08C/0DB3-E018/g' /mnt/local/etc/default/grub ++ sed -i ';/7ADA-C08C/s/7ADA-C08C/0DB3-E018/g' etc/fstab ++ sed -i ';/7ADA-C08C/s/7ADA-C08C/0DB3-E018/g' etc/mtools.conf ++ sed -i ';/7ADA-C08C/s/7ADA-C08C/0DB3-E018/g' boot/efi/EFI/redhat/grub.cfg ~~~ This is certainly due to a mix of rescue ISO and updated files available in the backup. This must be clarified, but the issue here is that there is no error printed, the return code of sed does not say that the file has been patched. Version-Release number of selected component (if applicable): rear-2.6-3.el8.x86_64 How reproducible: always Steps to Reproduce: 1. make a rear backup/rescue 2. change the UUID of EFI partition 3. make the recover Actual results: No error is printed during the recover about the non updated UUID Expected results: at least a warning about wrong UUID Additional info: I submitted a PR upstream to check if files are really patched https://github.com/rear/rear/issues/2785 https://github.com/rear/rear/pull/2786
(In reply to Welterlen Benoit from comment #0) > Description of problem: > - In certain circumstances, rear does not update the UUID in /etc/fstab and > also other files: > > ~~~ > sed -i ';/7ADA-C08C/s/7ADA-C08C/0DB3-E018/g' /mnt/local/etc/default/grub > ++ sed -i ';/7ADA-C08C/s/7ADA-C08C/0DB3-E018/g' etc/fstab > ++ sed -i ';/7ADA-C08C/s/7ADA-C08C/0DB3-E018/g' etc/mtools.conf > ++ sed -i ';/7ADA-C08C/s/7ADA-C08C/0DB3-E018/g' boot/efi/EFI/redhat/grub.cfg > ~~~ 7ADA-C08C is an EFI UUID? It looks too short, isn't it rather the MS-DOS volume ID? > This is certainly due to a mix of rescue ISO and updated files available in > the backup. > This must be clarified, but the issue here is that there is no error > printed, the return code of sed does not say that the file has been patched. But what if fstab does not mount the partition by UUID at all? It could mount it by volume label, or by device name. In that case, it is entirely OK if sed fails. is the sed command generated only if the original ID is actually found in the particular file? > How reproducible: > always > > Steps to Reproduce: > 1. make a rear backup/rescue > 2. change the UUID of EFI partition > 3. make the recover I wonder how did the updated files get into the backup. I think the list of steps is missing a "rear mkbackuponly" or an external backup tool run between the UUID change and recovery attempt.
Yes, it's the UEFI partition. By default, it's identified by the UUID. I agree that we will have false warning because of this ... I think I identified the workflow that leads to this issue. Will share soon. Thank you ! Benoit
sorry, I have not understood originally that by "UUID of EFI partition" you meant the volume ID of the vfat filesystem on the EFI System Partition, I thought you meant the UUID in GPT partition table.
Has the particular case here happened with internal backup (rear mkbackup or mkbackuponly) or with an external backup method (like NetBackup or TSM)? If the latter, how is the backup triggered?
The pull request to detect inconsistencies after restore of files from backup using md5sums has been merged upstream. It is not yet the ideal solution (it warns about the problem instead of preventing it), but it is already an improvement.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (rear bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:7654