#2917 Issue open: EL 9 after "rear recover" to different HW reboot hangs at "A Start Job is running for /dev/mapper/vg01-..."¶
Labels: bug
Steinefels opened issue at 2023-01-30 11:50:¶
Hello there,
I'm trying to do a test bare-metal-recovery of an HP DL360G9 with Oracle Linux 9.0 and LVM 2.03.16 installed. The ReaR version is 2.7 ( tried 2.6 as well). All goes well during the 'mkbackup' phase with only a few settings in local.conf:
OUTPUT=ISO
BACKUP=NETFS
OUTPUT_URL=null
BACKUP_URL=iso:///backup
ISO_DIR=/mnt/usb/rescue_system
USER_INPUT_BACKUP_URL_ISO_PROCEED_MKRESCUE=y
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media'
'/var/tmp' '/var/crash' '/mnt')
ISO_FILE_SIZE_LIMIT=8589934592
USE_SERIAL_CONSOLE='no'
The generated iso file ist booting flawlessly on new and identicaly
equipped HP DL360G9 hardware to this point:
a clouple of 'red' follow-up errors are thrown and the recovery image
gets stuck and won't boot up to a login-prompt.
Is this a bug? I tried to install the image to different hardware as well but the behavíour is still the same. Both machines got a HP 'Smart Array P440ar Controller' and a configured RAID1 logical drive. I switched the target controller to 'HBA' mode prior to recovery but without visible effect.
Regards, HG
jsmeix commented at 2023-01-31 09:08:¶
I assume this issue is because of special server hardware.
In particular bare-metal-recovery with specific server hardware
relatively often has such kind of hardware specific issues.
I cannot actually help in this specific case
because I am neither an Oracle Linux user
nor do I have experience with HPE ProLiant servers
and/or HP Smart Array Controllers.
Only a blind guess because your ISO is huge
(with up to 8GiB big files):
Can you boot when you make a small ISO via
# rear mkrescue
that contains only the ReaR recovery system but no backup.tar.gz
only as a test if the ISO size or the big backup causes trouble.
I assume it will also fail in the same way but in the past
we have had weird booting issues when something was "too big"
(without a boot error message that something was "too big").
I assume the real cause is that something is missing in the
ReaR recovery system to properly put the storage into operation.
Perhaps some specific kernel modules for the storage must be
specified to be loaded when they do not load automatically,
see MODULES_LOAD in usr/share/rear/conf/default.conf
online at
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L1598
and for an example see
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/examples/SLE12-SP2-btrfs-example.conf#L38
which also mentiones
https://github.com/rear/rear/issues/626
Steinefels commented at 2023-01-31 14:05:¶
Thanks for the investigation. The actual size of the boot image under test ist 4.2 G. The first boot with this image on an empty target system goes straight to the ReaR rescue prompt (after mapping the four NICs of the source system).
The boot parameters were
kernel initrd=initrd.cgz root/dev/ram0 vga=normal rw selinux=0 console=ttyS0,9600 console=tty0
Relax-and-Recover 2.7 / 2022-07-13
Relax-and-recover comes with ABSOLUTELY NO WARRANTY; for details see
the GNU General Public License at http://www.gnu.org/licenses/gpl.html
Host myhost.mydomain.com using Backup NETFS and Output ISO
Build date: Mon, 30 Jan 2023 10:30:02 +00:00
Oracle Linux Server 9.1
Kernel 5.15.0-6.80.3.1.el9uek.x86_64 on an x86_64
SSH fingerprint:
myhost login: root
Welcome to Relax-and Recover. Run "rear recover" to restore your system !
RESCUE myhost:~#
After
# rear -v recover
at the rescue prompt and doing and confirming the HD/LVM mappings the
system is restored.
The recovery process seems to execute smooth, everything is restored to
the mounted /mnt/local/....:
The restore message log file in /var/log/rear/ looks clean.
After resetting and POST, the machine boots into grub2s boot menue>
The problem finally pops up when trying to reboot the recovered system
5.15.0-6 (or any other):
and after a couple of minutes
and then the system reboots again. And of course fails again to start the storage subsystem, even when started in rescue-mode.
after annother reboot the picture slightly changes:
and
jsmeix commented at 2023-01-31 15:30:¶
Now it looks like an issue with SELinux
and/or the Oracle Linux security audit system
because the from scratch recreated system is
somewhat different compared to the original system
(at least the hardware is not exactly the same).
Again I cannot actually help in this area
because I have no experience with SELinux
and/or the Oracle or RHEL security audit system.
In this special case I would recommend to also
get in contact with Oracle and ask them what is needed
regarding SELinux and the Oracle security audit system
when an Oracle Linux system is recreated from scratch
on replacement hardware.
Additionally because of the message
[ TIME ] Timed out waiting for device /dev/mapper/vg01-var.
verify that the recreated storage layout
matches the storage layout on the original system.
To do that run a command like
# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT,UUID,WWN
and if needed also to get byte precise size values like
# lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT,UUID,WWN
on the original system and also
after "rear recover" finished (before reboot)
in the still running ReaR recovery system.
In the latter case the mountpoints will be below '/mnt/local'
because that is where the recreated target system filesystems
are mounted within the running ReaR recovery system.
Compare both in particular whether or not
the structure of the storage objects is the same.
The output of such an 'lsblk' command on the original system
gets stored during "rear mkrecue/mkbackup" as comment in
/var/lib/rear/layout/disklayout.conf
but not with size values in bytes (i.e. it is without -b).
Steinefels commented at 2023-02-06 12:26:¶
I just made the recommended comparison of disk layouts. The source system shows:
[root@gd-radius2 ~]# lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT,UUID,WWN
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT UUID WWN
/dev/sda /dev/sda sas disk 1000171331584 0x600508b1001cfc5fa0c4057066a338c2
|-/dev/sda1 /dev/sda1 /dev/sda part xfs 1073741824 /boot 6a5d4c28-53ed-49da-9dd7-8482bbd8d42f 0x600508b1001cfc5fa0c4057066a338c2
`-/dev/sda2 /dev/sda2 /dev/sda part LVM2_member 97718894592 UGfXyF-ET0V-qs1q-pZn2-v8yW-vDKt-gopoMj 0x600508b1001cfc5fa0c4057066a338c2
|-/dev/mapper/vg01-root /dev/dm-0 /dev/sda2 lvm xfs 10737418240 / e0903104-278f-45e5-96b5-4a57cb5a2e2e
|-/dev/mapper/vg01-swap /dev/dm-1 /dev/sda2 lvm swap 17179869184 [SWAP] 782f5d5a-d25c-4004-baf2-85b64114b805
|-/dev/mapper/vg01-usr /dev/dm-2 /dev/sda2 lvm xfs 10737418240 /usr ce9c35e5-f99c-4a90-ac81-dd13662f1842
|-/dev/mapper/vg01-opt /dev/dm-3 /dev/sda2 lvm xfs 16106127360 /opt 01ba316f-a095-47e3-8291-4b65590372f7
|-/dev/mapper/vg01-home /dev/dm-4 /dev/sda2 lvm xfs 21474836480 /home c1ce5c9e-6e0a-4e63-9e39-c49811881df7
|-/dev/mapper/vg01-tmp /dev/dm-5 /dev/sda2 lvm xfs 10737418240 /tmp 62e0abf1-5a8d-4a1e-a55e-df202b3672d1
`-/dev/mapper/vg01-var /dev/dm-6 /dev/sda2 lvm xfs 10737418240 /var c6ce48bc-aa75-40b1-8347-4886b6a56d73
/dev/sdb /dev/sdb usb disk 4000787027968
|-/dev/sdb1 /dev/sdb1 /dev/sdb part 134217728
`-/dev/sdb2 /dev/sdb2 /dev/sdb part xfs 4000650887168 914a753a-e3af-4a92-9b0c-577b99a53b29
and the target system shows after doing 'rear recover' on this box but prior to rebooting the restored image:
jsmeix commented at 2023-02-06 15:03:¶
@Steinefels
the values of the 'lsblk' columns in your screenshot
look truncated - e.g. 'LVM2_m' instead of 'LVM2_member'
so the MOUNTPOINT value '/mnt/local' of the filesystems
that are on LVM /dev/mapper/vg01-* could be truncated.
Could you try to get the lsblk output
in the running ReaR recovery system
with non-truncated values on non-wrapped lines?
E.g. login via 'ssh' into the running ReaR recovery system
and run the 'lsblk' command in a sufficiently wide terminal
or have the output in a file like
lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT,UUID,WWN >/tmp/lsblk.out
to get non-truncated values on non-wrapped lines
or try to use the '-w' option because "man lsblk" reads
(on my openSUSE Leap 15.4 system with lsblk from util-linux 2.37.2):
-w, --width number
Specifies output width as a number of characters.
The default is the number of the terminal columns,
and if not executed on a terminal, then output width
is not restricted at all by default.
This option also forces lsblk to assume that terminal
control characters and unsafe characters are not allowed.
FYI:
Related to that you may have a look at the part
You can run "rear recover" from remote via ssh as follows
...
at the end of the section
First steps with Relax-and-Recover
in
https://en.opensuse.org/SDB:Disaster_Recovery
Personally I always run "rear recover" from remote via ssh
because this way I can run "rear recover" in a terminal window
within my familiar working environment on my usual workstation
instead of the unfamiliar ReaR recovery system environment.
jsmeix commented at 2023-02-07 15:12:¶
FYI for comparison
how it works and looks for me with LVM on a KVM/QEMU test VM
with plain SLES 15 SP4 (i.e. without AppArmor or SELinux):
On my original VM:
# lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT,UUID,WWN
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT UUID WWN
/dev/sr0 /dev/sr0 sata rom 1073741312
/dev/vda /dev/vda disk 12884901888
|-/dev/vda1 /dev/vda1 /dev/vda part 8388608
`-/dev/vda2 /dev/vda2 /dev/vda part LVM2_member 12875447808 KIixRJ-1CUu-qTMS-ttW8-v0eq-2pO8-tVnXH4
|-/dev/mapper/system-swap /dev/dm-0 /dev/vda2 lvm swap 2147483648 [SWAP] a871f72e-13d7-4d5e-a136-ee461a141120
|-/dev/mapper/system-root /dev/dm-1 /dev/vda2 lvm ext4 4504682496 / 8a699d02-b3e0-412c-a153-9b1c1210d012
`-/dev/mapper/system-home /dev/dm-2 /dev/vda2 lvm xfs 6220152832 /home 2cb44622-9c97-437e-8e09-cdf195e9579a
On my replacement VM with virtual disk size of also exactly 12 GiB
inside the ReaR recovery system after "rear recover" finished:
RESCUE localhost:~ # lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT,UUID,WWN
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT UUID WWN
/dev/sr0 /dev/sr0 sata rom iso9660 REAR-ISO 77733888 2023-02-07-15-48-44-43
/dev/vda /dev/vda disk 12884901888
|-/dev/vda1 /dev/vda1 /dev/vda part 8388608
`-/dev/vda2 /dev/vda2 /dev/vda part LVM2_member 12875447808 KIixRJ-1CUu-qTMS-ttW8-v0eq-2pO8-tVnXH4
|-/dev/mapper/system-swap /dev/dm-0 /dev/vda2 lvm swap 2147483648 a871f72e-13d7-4d5e-a136-ee461a141120
|-/dev/mapper/system-home /dev/dm-1 /dev/vda2 lvm xfs 6220152832 /mnt/local/home 2cb44622-9c97-437e-8e09-cdf195e9579a
`-/dev/mapper/system-root /dev/dm-2 /dev/vda2 lvm ext4 4504682496 /mnt/local 8a699d02-b3e0-412c-a153-9b1c1210d012
Steinefels commented at 2023-02-08 17:37:¶
Thanks for the enduring support ;-) I finally made it to the ssh-prompt:
First and again the structure of the source system:
[root@myhost ~]# lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT,UUID,WWN
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT UUID WWN
/dev/sda /dev/sda sas disk 1000171331584 0x600508b1001cfc5fa0c4057066a338c2
|-/dev/sda1 /dev/sda1 /dev/sda part xfs 1073741824 /boot 6a5d4c28-53ed-49da-9dd7-8482bbd8d42f 0x600508b1001cfc5fa0c4057066a338c2
`-/dev/sda2 /dev/sda2 /dev/sda part LVM2_member 97718894592 UGfXyF-ET0V-qs1q-pZn2-v8yW-vDKt-gopoMj 0x600508b1001cfc5fa0c4057066a338c2
|-/dev/mapper/vg01-root /dev/dm-0 /dev/sda2 lvm xfs 10737418240 / e0903104-278f-45e5-96b5-4a57cb5a2e2e
|-/dev/mapper/vg01-swap /dev/dm-1 /dev/sda2 lvm swap 17179869184 [SWAP] 782f5d5a-d25c-4004-baf2-85b64114b805
|-/dev/mapper/vg01-usr /dev/dm-2 /dev/sda2 lvm xfs 10737418240 /usr ce9c35e5-f99c-4a90-ac81-dd13662f1842
|-/dev/mapper/vg01-opt /dev/dm-3 /dev/sda2 lvm xfs 16106127360 /opt 01ba316f-a095-47e3-8291-4b65590372f7
|-/dev/mapper/vg01-home /dev/dm-4 /dev/sda2 lvm xfs 21474836480 /home c1ce5c9e-6e0a-4e63-9e39-c49811881df7
|-/dev/mapper/vg01-tmp /dev/dm-5 /dev/sda2 lvm xfs 10737418240 /tmp 62e0abf1-5a8d-4a1e-a55e-df202b3672d1
`-/dev/mapper/vg01-var /dev/dm-6 /dev/sda2 lvm xfs 10737418240 /var c6ce48bc-aa75-40b1-8347-4886b6a56d73
/dev/sdb /dev/sdb usb disk 4000787027968
|-/dev/sdb1 /dev/sdb1 /dev/sdb part 134217728
`-/dev/sdb2 /dev/sdb2 /dev/sdb part xfs 4000650887168 914a753a-e3af-4a92-9b0c-577b99a53b29
[root@myhost ~]#
and here the matching output from the rescue shell on the target system:
RESCUE myhost:~ # lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT,UUID,WWN
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT UUID WWN
/dev/sda /dev/sda sas disk 1000171331584 0x600508b1001c4611de46533678cdf56c
|-/dev/sda1 /dev/sda1 /dev/sda part xfs 1073741824 /mnt/local/boot 6a5d4c28-53ed-49da-9dd7-8482bbd8d42f 0x600508b1001c4611de46533678cdf56c
`-/dev/sda2 /dev/sda2 /dev/sda part LVM2_member 97718894592 UGfXyF-ET0V-qs1q-pZn2-v8yW-vDKt-gopoMj 0x600508b1001c4611de46533678cdf56c
|-/dev/mapper/vg01-usr /dev/dm-0 /dev/sda2 lvm xfs 10737418240 /mnt/local/usr ce9c35e5-f99c-4a90-ac81-dd13662f1842
|-/dev/mapper/vg01-opt /dev/dm-1 /dev/sda2 lvm xfs 16106127360 /mnt/local/opt 01ba316f-a095-47e3-8291-4b65590372f7
|-/dev/mapper/vg01-root /dev/dm-2 /dev/sda2 lvm xfs 10737418240 /mnt/local e0903104-278f-45e5-96b5-4a57cb5a2e2e
|-/dev/mapper/vg01-home /dev/dm-3 /dev/sda2 lvm xfs 21474836480 /mnt/local/home c1ce5c9e-6e0a-4e63-9e39-c49811881df7
|-/dev/mapper/vg01-swap /dev/dm-4 /dev/sda2 lvm swap 17179869184 782f5d5a-d25c-4004-baf2-85b64114b805
|-/dev/mapper/vg01-tmp /dev/dm-5 /dev/sda2 lvm xfs 10737418240 /mnt/local/tmp 62e0abf1-5a8d-4a1e-a55e-df202b3672d1
`-/dev/mapper/vg01-var /dev/dm-6 /dev/sda2 lvm xfs 10737418240 /mnt/local/var c6ce48bc-aa75-40b1-8347-4886b6a56d73
/dev/sr0 /dev/sr0 usb rom iso9660 REAR-ISO 4358033408 2023-02-08-15-19-57-00
RESCUE myhost:~ #
Steinefels commented at 2023-02-08 17:38:¶
false click to 'closure', sorry ;-)
jsmeix commented at 2023-02-09 10:33:¶
I don't see a relevant difference
so from my current point of view
your disk layout was perfectly well recreated.
The only things that differ are expected:
The /dev/dm-N kernel device node numbers and
the WWN of the original and replacement /dev/sda disks.
@Steinefels
because you can access the ReaR recovery system from remote via ssh
you can now get a full debug log file of a "rear -D recover" run
and other relevant files out of the ReaR recovery system
which we need for further analysis what might have went wrong
in your specific case during "rear recover".
For what files we need and how to do that see the section
"Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
To avoid false expectations:
There is no guarantee that we can see the root cause of your issue
from those files of your recovery system but we will have a look.
Caution with possible secrets in a full debug log file:
When 'rear' is run via '-D' in debugscript mode
it logs executed commands via the bash command 'set -x'
that print commands and their arguments as they are executed
so in particular when arguments contain secret values
(e.g. something like a password or whatever else)
such secret values may appear in the log file.
Also secrets may be stored in some other files
like /var/lib/rear/layout/disklayout.conf
or /var/lib/rear/layout/diskrestore.sh
cf. [password=<password>] in the section
"Disk layout file syntax" in
doc/user-guide/06-layout-configuration.adoc
online at
https://github.com/rear/rear/blob/rear-2.7/doc/user-guide/06-layout-configuration.adoc
So before you attach your full debug log file and other files
here (GitHub is a public accessible place) inspect your files
and verify that they do not accidentally contain secrets.
Steinefels commented at 2023-02-09 16:54:¶
Just made the recommended trial with 'rear -d -D mkbackup' on the source
side and 'rear -d -D recover' on the target machine, for your further
investigations Please find the attached logs and the
'/etc/rear/local.conf' related to this test. If you'd like to see
anything else from the source or target system please let me know...
rear-myhost-recovery.zip
jsmeix commented at 2023-02-10 13:57:¶
@Steinefels
I had a first look at your rear-myhost-target.log
As far as I see the diskrestore.sh script
+ source /usr/share/rear/layout/recreate/default/200_run_layout_code.sh
...
++ source /var/lib/rear/layout/diskrestore.sh
...
2023-02-09 15:13:36.340941206 Start system layout restoration.
...
2023-02-09 15:14:04.800434951 Disk layout created.
did run without issues which matches that I didn't see
a relevant difference in the 'lsblk' outputs so again
it seems your disk layout was perfectly well recreated.
I.e. curently I have no idea what could cause the
Timed out waiting for device /dev/mapper/vg01-var
because all filesystems on LVs can be mounted
without issues within the ReaR recovery system
++ source /var/lib/rear/layout/diskrestore.sh
...
+++ mount -o rw,relatime,attr2,inode64,logbufs=8,logbsize=256k,sunit=512,swidth=512,noquota /dev/mapper/vg01-root /mnt/local/
...
+++ mount -o rw,relatime,attr2,inode64,logbufs=8,logbsize=256k,sunit=512,swidth=512,noquota /dev/mapper/vg01-home /mnt/local/home
...
+++ mount -o rw,relatime,attr2,inode64,logbufs=8,logbsize=256k,sunit=512,swidth=512,noquota /dev/mapper/vg01-opt /mnt/local/opt
...
+++ mount -o rw,relatime,attr2,inode64,logbufs=8,logbsize=256k,sunit=512,swidth=512,noquota /dev/mapper/vg01-tmp /mnt/local/tmp
...
+++ mount -o rw,relatime,attr2,inode64,logbufs=8,logbsize=256k,sunit=512,swidth=512,noquota /dev/mapper/vg01-usr /mnt/local/usr
...
+++ mount -o rw,relatime,attr2,inode64,logbufs=8,logbsize=256k,sunit=512,swidth=512,noquota /dev/mapper/vg01-var /mnt/local/var
After the backup was restored I spotted two possible issues:
The root login shell may not work sufficiently well:
+ source /usr/share/rear/restore/default/900_create_missing_directories.sh
...
++ chroot /mnt/local /bin/bash --login -c 'chown -v root:root media'
basename: missing operand
...
++ chroot /mnt/local /bin/bash --login -c 'chown -v root:root mnt'
basename: missing operand
...
++ chroot /mnt/local /bin/bash --login -c 'chown -v root:root var/tmp'
basename: missing operand
I wonder where that 'basename: missing operand'
comes from when the called command is 'chown'.
Because a root login shell is run in 'chroot /mnt/local'
I guess there is some bash profile or other stuff that
calls 'basename' which does not work.
In general a root login shell should work reliably
and fail safe in any case.
In the past we had some weird issues with ReaR when
a root login shell did not work within 'chroot /mnt/local'.
It failed to create an initrd
for kernel version 5.14.0-70.13.1.0.3.el9_0.x86_64:
+ source /usr/share/rear/finalize/Fedora/i386/550_rebuild_initramfs.sh
...
++ for INITRD_IMG in $( ls $TARGET_FS_ROOT/boot/initramfs-*.img $TARGET_FS_ROOT/boot/initrd-*.img | egrep -v '(kdump|rescue|plymouth)' )
...
++ INITRD=/boot/initramfs-5.14.0-162.12.1.el9_1.x86_64.img
++ LogPrint 'Running dracut...'
...
++ LogPrint 'Updated initrd with new drivers for kernel 5.14.0-162.12.1.el9_1.x86_64.'
...
++ INITRD=/boot/initramfs-5.14.0-162.6.1.el9_1.x86_64.img
++ LogPrint 'Running dracut...'
...
++ LogPrint 'Updated initrd with new drivers for kernel 5.14.0-162.6.1.el9_1.x86_64.'
...
++ INITRD=/boot/initramfs-5.14.0-70.13.1.0.3.el9_0.x86_64.img
++ LogPrint 'Running dracut...'
...
++ LogPrint 'WARNING:
Failed to create initrd for kernel version '\''5.14.0-70.13.1.0.3.el9_0.x86_64'\''.
Check '\''/var/log/rear/rear-myhost.log'\'' to see the error messages in detail
and decide yourself, whether the system will boot or not.
...
++ INITRD=/boot/initramfs-5.15.0-0.30.19.el9uek.x86_64.img
++ LogPrint 'Running dracut...'
...
++ LogPrint 'Updated initrd with new drivers for kernel 5.15.0-0.30.19.el9uek.x86_64.'
...
++ INITRD=/boot/initramfs-5.15.0-5.76.5.1.el9uek.x86_64.img
++ LogPrint 'Running dracut...'
...
++ LogPrint 'Updated initrd with new drivers for kernel 5.15.0-5.76.5.1.el9uek.x86_64.'
...
++ INITRD=/boot/initramfs-5.15.0-6.80.3.1.el9uek.x86_64.img
++ LogPrint 'Running dracut...'
...
++ LogPrint 'Updated initrd with new drivers for kernel 5.15.0-6.80.3.1.el9uek.x86_64.'
Both issues don't look really serious
but I cannot tell if one could really ignore them.
Again:
I recommend to also get in contact with Oracle
and ask them what is needed regarding SELinux
together with the Oracle security audit system
when an Oracle Linux system is recreated
from scratch on replacement hardware.
github-actions commented at 2023-04-12 02:18:¶
Stale issue message
pcahyna commented at 2023-04-25 09:28:¶
Hi @Steinefels , sorry for the late reply - if you still have the system
in question, can you try to remove /etc/lvm/devices/system.devices in
the restored system? (If doing it from the ReaR rescue system after
backup restoration, the restored system is mounted under /mnt/local .)
Steinefels commented at 2023-04-26 14:38:¶
Hi @pcahyna thanks for getting back to me and this weird issue. I'll give your advice a chance this evening :-)
Steinefels commented at 2023-04-26 14:40:¶
Btw: I tried to get some feedback on this from Oracle, but no reply so far.
Steinefels commented at 2023-04-26 16:20:¶
Hi @pcahyna, congratulations!! This was definetly the advice to make the backup system running!! No more error-messages during boot-up after removing 'system.devices'.
cheers and many thanks again!
:-)
pcahyna commented at 2023-04-26 17:12:¶
@Steinefels thanks for testing and glad that it helped!
Reopening the issue because it is a quite serious problem when recovering to different hardware.
[Export of Github issue for rear/rear.]