New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redhat recover failed: / cannot be remounted rw #3200
Comments
attempting to restore a RHEL7 system with an recovery iso that contains already an RHEL8 system will not work and is not supported. REAR itself does not setup any cronjobs, you should clarify how the recovery iso was created after update to RHEL8. I dont see how REAR is at fault here. One possible "dirty" solution would be:
It should then re-create disk partitions based on the information from the original system using the tools compatible to the RHEL7 backup. |
Only a guess but regarding "unknown (cron?) job" see @Framsfex |
On Thu 2024-04-11 (04:00), Johannes Meixner wrote:
Only a guess but regarding "unknown (cron?) job" see
#3199 (comment)
That's it!
We have the same time stamp of the new created ISO image!
This is what I have already assumed.
Too bad, our Redhat installation now is broken, we have had to reinstall it.
perhaps you also have an old cron job
as a leftover from ReaR 2.4 or before?
We have installed ReaR 2.4 from the RHEL 7.9 repo and then made the
upgrade to RHEL 8.3 (where the hidden cronjob run) which we tried to
recover with ReaR back to RHEL7
I do not know which ReaR version comes with RHEL 8.3
…--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@***.***
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
***@***.***>
|
Hi @Framsfex sorry to hear that. In RHEL 8.3 there is also ReaR 2.4, but the iso made on a different system may be incompatible.
I think this may work, if the disk layout is identical (therefore you don't need to worry about copying the disklayout from the original server). But there may be some issues when bringing up the network. The rescue system will ask you to map MAC addresses of the second system to the MAC addresses of the first system, and then use the IP addresses of the second server (unless your IP addresses are configured by DHCP). |
In RHEL 9 we deleted the cron job btw, thus users won't face this problem anymore. |
@pcahyna
cf.
there might be the cron file left even when an RPM package update |
Perhaps, we should add a %post action to remove the (old) cron entry in the spec file? |
@Framsfex Did you succeed in the recovery with the similar RHEL 7 ISO rescue? |
Unfortunately, in RHEL 8 this file is still considered wanted (it is shipped in the package), so this reasoning does not apply here (the problem was related to a RHEL 7 -> RHEL 8 upgrade) and no way of removing obsolete config files would have helped the user here. I will check how does newer RHEL and Fedora (where the file is not wanted anymore) behave in this respect. |
On Fri 2024-04-26 (02:05), gdha wrote:
@Framsfex Did you succeed in the recovery with the similar RHEL 7 ISO rescue?
We used a dd image from a second server (identical hardware) and did not
try it with ReaR again,.
…--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@***.***
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
***@***.***>
|
Relax-and-Recover 2.6 / 2020-06-17
(Installed on RHEL7 with "yum install rear")
NAME="Red Hat Enterprise Linux Server"
VERSION="7.9 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.9"
OUTPUT=ISO
OUTPUT_URL=nfs://129.69.2.11/spnfs_data0/sp_i/Rear
BACKUP=NETFS
BACKUP_URL=nfs://129.69.2.11/spnfs_data0/sp_i/Rear
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash' '/mnt')
NETFS_KEEP_OLD_BACKUP_COPY=
Cisco Systems Inc UCSC-C240-M5S A0
Intel(R) Xeon(R) Gold 6132 CPU @ 2.60GHz, 56 x 3700 MHz
x86
GRUB BIOS
Local harddisk, Hardware RAID
sp-i is a Cisco UCS server with RHEL7.
I did a backup with ReaR which seems successful.
Then I did an upgrade to RHEL8, which is a bit complicated with Redhat, but it worked. The server bootet successfully RHEL8.
(1 week pause)
To reproduce and test the upgrade process I wanted to go back to RHEL7. For this I booted the ReaR Rescue CD (rear-sp-i.iso) and selected "recover", which seems successfully, too. But after rebooting the recovered RHEL7 system it was not able to remount the / filesystem from ro to rw state:
https://fex.rus.uni-stuttgart.de/fop/NtoxIEXY/X-20240404231512.jpg
I looked in the NFS rear directory and found:
rear-sp-i.iso is much younger than backup! And it was created at 1:30, a time where I am not working!
My assumption: Some unknown (cron?) job has recreated rear-sp-i.iso with RHEL8 and its newer xfs is incompatible with RHEL7 xfs.
Any idea what I can do in this situation?
I have second server (sp-j) with identical configuration, still running with RHEL7
Shall I run ReaR there and use this rear-sp-j.iso?
The text was updated successfully, but these errors were encountered: