Bug 2072978

Summary:	Sometimes rear does not update the UUID in /etc/fstab to match the new partition but no error is shown
Product:	Red Hat Enterprise Linux 8	Reporter:	Welterlen Benoit <bwelterl>
Component:	rear	Assignee:	Pavel Cahyna <pcahyna>
Status:	CLOSED ERRATA	QA Contact:	David Jež <djez>
Severity:	medium	Docs Contact:	Šárka Jana <sjanderk>
Priority:	unspecified
Version:	8.5	CC:	djez, ovasik, pcahyna
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:	rear-2.6-5.el8	Doc Type:	Bug Fix
Doc Text:	.ReaR no longer fails to display an error message if it does not update the UUID in `/etc/fstab` Previously, ReaR did not display an error message during recovery when it failed to update the universally unique identifier (UUID) in `/etc/fstab` to match the UUID of the newly created partition in case the UUIDs were different. This could have happened if the rescue image was out of sync with the backup. With this update, an error message occurs during recovery if the restored basic system files do not match the recreated system.	Story Points:	---
Clone Of:
Clones:	2083272 (view as bug list)		Environment:
Last Closed:	2022-11-08 10:02:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2083272
Bug Blocks:

Description Welterlen Benoit 2022-04-07 11:56:50 UTC

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

Comment 1 Pavel Cahyna 2022-04-07 12:40:47 UTC

(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.

Comment 2 Welterlen Benoit 2022-04-07 12:53:07 UTC

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

Comment 3 Pavel Cahyna 2022-04-07 14:14:09 UTC

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.

Comment 5 Pavel Cahyna 2022-04-11 12:09:25 UTC

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?

Comment 6 Pavel Cahyna 2022-05-09 14:56:36 UTC

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.

Comment 16 errata-xmlrpc 2022-11-08 10:02:43 UTC

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