#3332 Issue closed: Unable to boot recover image on SuSE Linux ppc¶
Labels: support / question, fixed / solved / done,
special hardware or VM
tolimar opened issue at 2024-10-17 09:08:¶
- ReaR version ("/usr/sbin/rear -V"):
testhost:~> sudo rear -V
Relax-and-Recover 2.7 / 2022-07-13
-
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"):
NAME="SLES"
VERSION="15-SP5"
VERSION_ID="15.5"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP5"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp5"
- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OUTPUT=ISO
BACKUP=TSM
AUTOEXCLUDE_MULTIPATH=n
GRUB_RESCUE=y
#MODULES=( 'all_modules' )
#FIRMWARE_FILES='yes'
# required on SLES 12 for better working vi
COPY_AS_IS+=( /usr/share/vim )
# Reduce size of initrd (takes longer and uses more CPU but could help when booting PPC64 in POWERVM with TFTP)
REAR_INITRD_COMPRESSION=lzma
ONLY_INCLUDE_VG=( rootvg )
-
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
Source system is a Logical Partition on a IBM Power server running Power 9 CPU mode.
Target system is a new Logical Partition on an IBM Power 8 server. -
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
ppc64le -
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
Open Firmware.
Grub. -
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
disks mapped via vscsi from two Virtual IO servers to the LPAR. -
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
Full storage layout follow, but I would be happy to just recover the rootvg:
~> lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/sda /dev/sda
| disk LVM2_m 50G
`-/dev/mapper/mpathg /dev/dm-6
/dev/sda
mpath LVM2_m 50G
|-/dev/mapper/vg_hana_C10_sap-lv_sap_C10_base
| /dev/dm-19
| /dev/dm-6
| lvm xfs 25G /usr/sap
`-/dev/mapper/vg_hana_C10_sap-lv_sap_C10_home
/dev/dm-21
/dev/dm-6
lvm xfs 25G /usr/sap/C
/dev/sdb /dev/sdb
| disk mpath_ 50G
|-/dev/sdb1 /dev/sdb1
| /dev/sdb
| part none 6.8M
|-/dev/sdb2 /dev/sdb2
| /dev/sdb
| part LVM2_m 50G
`-/dev/mapper/mpatha /dev/dm-7
/dev/sdb
mpath 50G
|-/dev/mapper/mpatha-part1 /dev/dm-11
| /dev/dm-7
| part 6.8M
`-/dev/mapper/mpatha-part2 /dev/dm-12
/dev/dm-7
part LVM2_m 50G
|-/dev/mapper/rootvg-lv_swap /dev/dm-16
| /dev/dm-12
| lvm swap 20G [SWAP]
|-/dev/mapper/rootvg-lv_root /dev/dm-17
| /dev/dm-12
| lvm ext4 2G /
|-/dev/mapper/rootvg-lv_usr /dev/dm-18
| /dev/dm-12
| lvm ext4 6G /usr
|-/dev/mapper/rootvg-lv_home /dev/dm-24
| /dev/dm-12
| lvm ext4 1G /home
|-/dev/mapper/rootvg-lv_homeroot /dev/dm-25
| /dev/dm-12
| lvm ext4 1G /root
|-/dev/mapper/rootvg-lv_opt /dev/dm-26
| /dev/dm-12
| lvm ext4 2.5G /opt
|-/dev/mapper/rootvg-lv_tmp /dev/dm-27
| /dev/dm-12
| lvm ext4 3G /tmp
`-/dev/mapper/rootvg-lv_var /dev/dm-28
/dev/dm-12
lvm ext4 5G /var
/dev/sdc /dev/sdc
| disk LVM2_m 700G
`-/dev/mapper/mpathh /dev/dm-1
/dev/sdc
mpath LVM2_m 700G
`-/dev/mapper/vg_hana_C10_data-lv_hana_C10_data
/dev/dm-20
/dev/dm-1
lvm xfs 2.7T /hana/data
/dev/sdd /dev/sdd
| disk LVM2_m 700G
`-/dev/mapper/mpathi /dev/dm-2
/dev/sdd
mpath LVM2_m 700G
`-/dev/mapper/vg_hana_C10_data-lv_hana_C10_data
/dev/dm-20
/dev/dm-2
lvm xfs 2.7T /hana/data
/dev/sde /dev/sde
| disk LVM2_m 700G
`-/dev/mapper/mpathj /dev/dm-5
/dev/sde
mpath LVM2_m 700G
`-/dev/mapper/vg_hana_C10_data-lv_hana_C10_data
/dev/dm-20
/dev/dm-5
lvm xfs 2.7T /hana/data
/dev/sdf /dev/sdf
| disk LVM2_m 700G
`-/dev/mapper/mpathk /dev/dm-4
/dev/sdf
mpath LVM2_m 700G
`-/dev/mapper/vg_hana_C10_data-lv_hana_C10_data
/dev/dm-20
/dev/dm-4
lvm xfs 2.7T /hana/data
/dev/sdg /dev/sdg
| disk LVM2_m 128G
`-/dev/mapper/mpathl /dev/dm-8
/dev/sdg
mpath LVM2_m 128G
`-/dev/mapper/vg_hana_C10_log-lv_hana_C10_log
/dev/dm-22
/dev/dm-8
lvm xfs 512G /hana/log/
/dev/sdh /dev/sdh
| disk LVM2_m 128G
`-/dev/mapper/mpathm /dev/dm-13
/dev/sdh
mpath LVM2_m 128G
`-/dev/mapper/vg_hana_C10_log-lv_hana_C10_log
/dev/dm-22
/dev/dm-13
lvm xfs 512G /hana/log/
/dev/sdi /dev/sdi
| disk LVM2_m 128G
`-/dev/mapper/mpathn /dev/dm-14
/dev/sdi
mpath LVM2_m 128G
`-/dev/mapper/vg_hana_C10_log-lv_hana_C10_log
/dev/dm-22
/dev/dm-14
lvm xfs 512G /hana/log/
/dev/sdj /dev/sdj
| disk LVM2_m 128G
`-/dev/mapper/mpathb /dev/dm-3
/dev/sdj
mpath LVM2_m 128G
`-/dev/mapper/vg_hana_C10_log-lv_hana_C10_log
/dev/dm-22
/dev/dm-3
lvm xfs 512G /hana/log/
/dev/sdk /dev/sdk
| disk LVM2_m 256G
`-/dev/mapper/mpathc /dev/dm-15
/dev/sdk
mpath LVM2_m 256G
`-/dev/mapper/vg_hana_C10_shared-lv_hana_C10_shared
/dev/dm-23
/dev/dm-15
lvm xfs 1024G /hana/shar
/dev/sdl /dev/sdl
| disk LVM2_m 256G
`-/dev/mapper/mpathd /dev/dm-0
/dev/sdl
mpath LVM2_m 256G
`-/dev/mapper/vg_hana_C10_shared-lv_hana_C10_shared
/dev/dm-23
/dev/dm-0
lvm xfs 1024G /hana/shar
/dev/sdm /dev/sdm
| disk LVM2_m 256G
`-/dev/mapper/mpathe /dev/dm-10
/dev/sdm
mpath LVM2_m 256G
`-/dev/mapper/vg_hana_C10_shared-lv_hana_C10_shared
/dev/dm-23
/dev/dm-10
lvm xfs 1024G /hana/shar
/dev/sdn /dev/sdn
| disk LVM2_m 256G
`-/dev/mapper/mpathf /dev/dm-9
/dev/sdn
mpath LVM2_m 256G
`-/dev/mapper/vg_hana_C10_shared-lv_hana_C10_shared
/dev/dm-23
/dev/dm-9
lvm xfs 1024G /hana/shar
/dev/sdo /dev/sdo
| disk LVM2_m 50G
`-/dev/mapper/mpathg /dev/dm-6
/dev/sdo
mpath LVM2_m 50G
|-/dev/mapper/vg_hana_C10_sap-lv_sap_C10_base
| /dev/dm-19
| /dev/dm-6
| lvm xfs 25G /usr/sap
`-/dev/mapper/vg_hana_C10_sap-lv_sap_C10_home
/dev/dm-21
/dev/dm-6
lvm xfs 25G /usr/sap/C
/dev/sdp /dev/sdp
| disk mpath_ 50G
|-/dev/sdp1 /dev/sdp1
| /dev/sdp
| part none 6.8M
|-/dev/sdp2 /dev/sdp2
| /dev/sdp
| part LVM2_m 50G
`-/dev/mapper/mpatha /dev/dm-7
/dev/sdp
mpath 50G
|-/dev/mapper/mpatha-part1 /dev/dm-11
| /dev/dm-7
| part 6.8M
`-/dev/mapper/mpatha-part2 /dev/dm-12
/dev/dm-7
part LVM2_m 50G
|-/dev/mapper/rootvg-lv_swap /dev/dm-16
| /dev/dm-12
| lvm swap 20G [SWAP]
|-/dev/mapper/rootvg-lv_root /dev/dm-17
| /dev/dm-12
| lvm ext4 2G /
|-/dev/mapper/rootvg-lv_usr /dev/dm-18
| /dev/dm-12
| lvm ext4 6G /usr
|-/dev/mapper/rootvg-lv_home /dev/dm-24
| /dev/dm-12
| lvm ext4 1G /home
|-/dev/mapper/rootvg-lv_homeroot /dev/dm-25
| /dev/dm-12
| lvm ext4 1G /root
|-/dev/mapper/rootvg-lv_opt /dev/dm-26
| /dev/dm-12
| lvm ext4 2.5G /opt
|-/dev/mapper/rootvg-lv_tmp /dev/dm-27
| /dev/dm-12
| lvm ext4 3G /tmp
`-/dev/mapper/rootvg-lv_var /dev/dm-28
/dev/dm-12
lvm ext4 5G /var
/dev/sdq /dev/sdq
| disk LVM2_m 700G
`-/dev/mapper/mpathh /dev/dm-1
/dev/sdq
mpath LVM2_m 700G
`-/dev/mapper/vg_hana_C10_data-lv_hana_C10_data
/dev/dm-20
/dev/dm-1
lvm xfs 2.7T /hana/data
/dev/sdr /dev/sdr
| disk LVM2_m 700G
`-/dev/mapper/mpathi /dev/dm-2
/dev/sdr
mpath LVM2_m 700G
`-/dev/mapper/vg_hana_C10_data-lv_hana_C10_data
/dev/dm-20
/dev/dm-2
lvm xfs 2.7T /hana/data
/dev/sds /dev/sds
| disk LVM2_m 700G
`-/dev/mapper/mpathj /dev/dm-5
/dev/sds
mpath LVM2_m 700G
`-/dev/mapper/vg_hana_C10_data-lv_hana_C10_data
/dev/dm-20
/dev/dm-5
lvm xfs 2.7T /hana/data
/dev/sdt /dev/sdt
| disk LVM2_m 700G
`-/dev/mapper/mpathk /dev/dm-4
/dev/sdt
mpath LVM2_m 700G
`-/dev/mapper/vg_hana_C10_data-lv_hana_C10_data
/dev/dm-20
/dev/dm-4
lvm xfs 2.7T /hana/data
/dev/sdu /dev/sdu
| disk LVM2_m 128G
`-/dev/mapper/mpathl /dev/dm-8
/dev/sdu
mpath LVM2_m 128G
`-/dev/mapper/vg_hana_C10_log-lv_hana_C10_log
/dev/dm-22
/dev/dm-8
lvm xfs 512G /hana/log/
/dev/sdv /dev/sdv
| disk LVM2_m 128G
`-/dev/mapper/mpathm /dev/dm-13
/dev/sdv
mpath LVM2_m 128G
`-/dev/mapper/vg_hana_C10_log-lv_hana_C10_log
/dev/dm-22
/dev/dm-13
lvm xfs 512G /hana/log/
/dev/sdw /dev/sdw
| disk LVM2_m 128G
`-/dev/mapper/mpathn /dev/dm-14
/dev/sdw
mpath LVM2_m 128G
`-/dev/mapper/vg_hana_C10_log-lv_hana_C10_log
/dev/dm-22
/dev/dm-14
lvm xfs 512G /hana/log/
/dev/sdx /dev/sdx
| disk LVM2_m 128G
`-/dev/mapper/mpathb /dev/dm-3
/dev/sdx
mpath LVM2_m 128G
`-/dev/mapper/vg_hana_C10_log-lv_hana_C10_log
/dev/dm-22
/dev/dm-3
lvm xfs 512G /hana/log/
/dev/sdy /dev/sdy
| disk LVM2_m 256G
`-/dev/mapper/mpathc /dev/dm-15
/dev/sdy
mpath LVM2_m 256G
`-/dev/mapper/vg_hana_C10_shared-lv_hana_C10_shared
/dev/dm-23
/dev/dm-15
lvm xfs 1024G /hana/shar
/dev/sdz /dev/sdz
| disk LVM2_m 256G
`-/dev/mapper/mpathd /dev/dm-0
/dev/sdz
mpath LVM2_m 256G
`-/dev/mapper/vg_hana_C10_shared-lv_hana_C10_shared
/dev/dm-23
/dev/dm-0
lvm xfs 1024G /hana/shar
/dev/sdaa /dev/sdaa
| disk LVM2_m 256G
`-/dev/mapper/mpathe /dev/dm-10
/dev/sdaa
mpath LVM2_m 256G
`-/dev/mapper/vg_hana_C10_shared-lv_hana_C10_shared
/dev/dm-23
/dev/dm-10
lvm xfs 1024G /hana/shar
/dev/sdab /dev/sdab
| disk LVM2_m 256G
`-/dev/mapper/mpathf /dev/dm-9
/dev/sdab
mpath LVM2_m 256G
`-/dev/mapper/vg_hana_C10_shared-lv_hana_C10_shared
/dev/dm-23
/dev/dm-9
lvm xfs 1024G /hana/shar
- Description of the issue (ideally so that others can reproduce
it):
I try a "greenfield" recovery of a larger SuSE Linux 15 SP5 system hosted on an IBM Power server.
For that I did the following:- installed rear on the system on the SuSE server
- created a rescue image
- copied the resulting iso to the VIOS of the recovery server
- created a new lpar profile on the new hardware with identical
settings but the following:
- CPU mode of LPAR changed from Power9 CPU mode to Power8
- Some vlan IDs of network adapters changed in the recovery environment
- New LPAR has only one new disk for the rootvg
If start that system, I run into a kernel Panic as it is not able to mount the root fs:
[ 1.294475][ T1] List of all partitions:
[ 1.294478][ T1] No filesystem could mount root, tried:
[ 1.294478][ T1]
[ 1.294483][ T1] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 1.294488][ T1] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.21-150500.55.73-default #1 SLE15-SP5 31ad524062d2772a9189361b18629cd4c1e03baf
[ 1.294497][ T1] Call Trace:
[ 1.294499][ T1] [c00000d558337aa0] [c000000000894d98] dump_stack_lvl+0x8c/0xcc (unreliable)
[ 1.294509][ T1] [c00000d558337ae0] [c00000000015a9d4] panic+0x180/0x42c
[ 1.294516][ T1] [c00000d558337b70] [c0000000020058d0] mount_block_root+0x3cc/0x430
[ 1.294523][ T1] [c00000d558337c50] [c000000002005b88] prepare_namespace+0x1a8/0x1fc
[ 1.294529][ T1] [c00000d558337cc0] [c00000000200522c] kernel_init_freeable+0x3b4/0x410
[ 1.294535][ T1] [c00000d558337da0] [c000000000012b34] kernel_init+0x34/0x1c0
[ 1.294541][ T1] [c00000d558337e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
[ 1.306189][ T1] ------------[ cut here ]------------
[ 1.306196][ T1] WARNING: CPU: 1 PID: 1 at ../drivers/tty/vt/vt.c:4417 do_unblank_screen+0x1ac/0x240
[ 1.306208][ T1] Modules linked in:
[ 1.306215][ T1] Supported: Yes
[ 1.306220][ T1] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.21-150500.55.73-default #1 SLE15-SP5 31ad524062d2772a9189361b18629cd4c1e03baf
[ 1.306233][ T1] NIP: c0000000009a199c LR: c0000000009a197c CTR: c00000000003c450
[ 1.306241][ T1] REGS: c00000d5583377c0 TRAP: 0700 Not tainted (5.14.21-150500.55.73-default)
[ 1.306250][ T1] MSR: 8000000002021033 <SF,VEC,ME,IR,DR,RI,LE> CR: 24002282 XER: 0000000f
[ 1.306273][ T1] CFAR: c0000000001f8488 IRQMASK: 3
[ 1.306273][ T1] GPR00: c0000000009a197c c00000d558337a60 c000000002887f00 0000000000000000
[ 1.306273][ T1] GPR04: 0000000000000003 00000000000004b9 c00000d558337910 0000000000000000
[ 1.306273][ T1] GPR08: 0000000000000011 0000000000000000 0000000000000000 0000000000000001
[ 1.306273][ T1] GPR12: c00000000003c450 c00000001ec0ee80 c000000000012b08 0000000000000000
[ 1.306273][ T1] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 1.306273][ T1] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 1.306273][ T1] GPR24: c0000000010ddc60 c000000002934130 c00c000017633cc0 0000000000000000
[ 1.306273][ T1] GPR28: c00000000296eb20 0000000000000000 c0000000010ddbf0 0000000000000000
[ 1.306376][ T1] NIP [c0000000009a199c] do_unblank_screen+0x1ac/0x240
[ 1.306384][ T1] LR [c0000000009a197c] do_unblank_screen+0x18c/0x240
[ 1.306393][ T1] Call Trace:
[ 1.306397][ T1] [c00000d558337a60] [c00c000017633cc0] 0xc00c000017633cc0 (unreliable)
[ 1.306410][ T1] [c00000d558337ae0] [c00000000015aa40] panic+0x1ec/0x42c
[ 1.306422][ T1] [c00000d558337b70] [c0000000020058d0] mount_block_root+0x3cc/0x430
[ 1.306433][ T1] [c00000d558337c50] [c000000002005b88] prepare_namespace+0x1a8/0x1fc
[ 1.306445][ T1] [c00000d558337cc0] [c00000000200522c] kernel_init_freeable+0x3b4/0x410
[ 1.306456][ T1] [c00000d558337da0] [c000000000012b34] kernel_init+0x34/0x1c0
[ 1.306467][ T1] [c00000d558337e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
[ 1.306478][ T1] Instruction dump:
[ 1.306484][ T1] 60000000 7c0802a6 f8010090 4b856b01 60000000 2fa30000 409e002c 3d220017
[ 1.306504][ T1] 39294fa8 81290000 2f890000 409e0018 <0fe00000> e8010090 7c0803a6 4bfffe7c
[ 1.306525][ T1] ---[ end trace 46aae5ba8887dee8 ]---
[ 1.306533][ T1] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---
-
Workaround, if any:
I have an older rescue image from a nearly identical system, but running SuSE 15 SP3. That seems to work.Other things I tried:
- Using the rear27a package shipped by SuSe, or the rpm package provided via OBS
- Enabling / disablingAUTOEXCLUDE_MULTIPATH=n
- Enabling / disablingMODULES=( 'all_modules' )
- Enabling / disablingFIRMWARE_FILES='yes'
- DisablingCOPY_AS_IS+=( /usr/share/vim )(Some leftovers from tests with SLES12, that we set to have a better working editor; doesn't seem to be required on SLES15 anymore anyway)
- SettingREAR_INITRD_COMPRESSION=lzma(I read in some other ppc rear issues, that sometimes initrd got to large) -
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
rear-testhost.log
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
jsmeix commented at 2024-10-17 11:54:¶
@tolimar
FYI to avoid expectations that I cannot fulfill:
I am not a booting expert and I know basically nothing
about POWER architecure specific things - I only know
that low-level things when booting on POWER architecture
are rather different compared to booting on x86 architecture.
Currently we do not have an active ReaR upstream maintainer
who is an expert in POWER architecure specific things.
If you have a SUSE product/extension like the
SUSE Linux Enterprise High Availability Extension
where SUSE officially supports ReaR,
see the section "SUSE support for Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
I would recommend that you file an official support request
at SUSE via your official support contact at SUSE.
If you do that please provide an URL to this issue
in your SUSE support request.
I try to help you here as good as I can so to proceed here
I would recommend that you read through
https://github.com/rear/rear/issues/3189
which is also about BACKUP=TSM on POWER architecture
where booting also "just failed" with a kernel panic
and no reason was shown (i.e. not meaningful error
message) but the root cause was that the initrd
was too big.
In
https://github.com/rear/rear/issues/3189
in particular have a look at all what belongs
to the size of ReaR's initrd which contains
all the files of the ReaR recovery system
and with BACKUP=TSM defaults that could become
too big on POWER architecture because there are
rather low limits of the initrd maximum size.
As a result I did several ReaR upstream commits
in our GitHub master code (i.e. not in ReaR 2.7)
in particular
https://github.com/rear/rear/commit/7b2354e8a91306adeaf9228d79d13b23b5426011
that contains in particular in default.conf
# On POWER architecture (e.g. PowerVM LPAR) there is a maximum size of the initrd that can be booted
# cf. https://github.com/rear/rear/issues/3189
# That limit is 128 MiB minus about 4 MiB for some additional prep boot data
# so in practice the maximum remaining size for the initrd is about 123 MiB or even less.
and an example of COPY_AS_IS_EXCLUDE_TSM that could
reduce much what TSM needs inside the ReaR recovery system
so it could help to get the initrd small enough for POWER
and also
https://github.com/rear/rear/pull/3219
and
https://github.com/rear/rear/pull/3212
and
https://github.com/rear/rear/pull/3233
So I would recommend that you try out our latest
GitHub master code because the GitHub master code
is the only place where we at ReaR upstream can
fix things and if there are issues it helps when
you use exactly the code where we could fix things.
See the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
how you can try out our current ReaR GitHub master code
without conflicts with your already installed ReaR version.
tolimar commented at 2024-10-18 13:16:¶
@jsmeix
Many thanks for your answers! Even if you say you know nothing about
Power architecture you managed to point me to the right direction. Case
in point: While I was searching in the opposite direction - stuff that
might be missing in the initrd - it is in fact the size limit if the
initrd you refered me too.
If you have a SUSE product/extension like the SUSE Linux Enterprise High Availability Extension where SUSE officially supports ReaR, see the section "SUSE support for Relax-and-Recover" in https://en.opensuse.org/SDB:Disaster_Recovery I would recommend that you file an official support request at SUSE via your official support contact at SUSE. If you do that please provide an URL to this issue in your SUSE support request.
We do have SUSE support for SLES4HANA (which to my knowledge includes the HA extension). But sadly not on the hardware I try my recovery on - it is an older server, we use for some experiments.
However, I put it on my todo list, to reproduce the issue on hardware and open a support ticket there.
[..]
and an example of COPY_AS_IS_EXCLUDE_TSM that could reduce much what TSM needs inside the ReaR recovery system so it could help to get the initrd small enough for POWER and aee also #3219 and #3212 and #3233So I would recommend that you try out our latest GitHub master code because the GitHub master code is the only place where we at ReaR upstream can fix things and if there are issues it helps when you use exactly the code where we could fix things.
See the section "Testing current ReaR upstream GitHub master code" in https://en.opensuse.org/SDB:Disaster_Recovery how you can try out our current ReaR GitHub master code without conflicts with your already installed ReaR version.
Thanks for the pointer, trying the git version, I now get a warning from rear, if the initrd is getting too large :)
I experimented a bit with it, and was able to downsize the resulting size by using:
MODULES=('loaded_modules')
COPY_AS_IS_EXCLUDE_TSM=( /opt/tivoli/tsm/client/ba/bin/dsmc /opt/tivoli/tsm/client/ba/bin/dsm.sys /opt/tivoli/tsm/client/ba/bin/dsm.opt )
REAR_INITRD_COMPRESSION=lzma
But even with that, the resulting initrd was too large.
However, I when changing backup method from tsm to netfs, I was able to create a bootable rescue image again.
As said I have a working rescue image of a similar system created with SLES 15 SP3 including TSM, which worked. So I will definitely try to reproduce the issue with the suse supported hardware.
Again thanks for your hints!
jsmeix commented at 2024-10-18 13:54:¶
My pleasure!
I wish you a relaxed and recovering weekend.
jsmeix commented at 2024-10-18 13:58:¶
Did you try out the example of COPY_AS_IS_EXCLUDE_TSM
that could reduce much what TSM needs inside
the ReaR recovery system?
This COPY_AS_IS_EXCLUDE_TSM example is shown
in default.conf in our GitHub master code currently at
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L2433
# An alternative method to reduce the size of the TSM client in ReaR recovery system initrd is
# to exclude what is not needed from the above specified COPY_AS_IS_TSM via COPY_AS_IS_EXCLUDE_TSM
# to get a slim TSM client without reduced functionality of what can be used in the recovery system.
# So for example
# COPY_AS_IS_EXCLUDE_TSM=( /opt/tivoli/tsm/client/ba/bin/*.jar
# /opt/tivoli/tsm/client/ba/bin/*.log*
# /opt/tivoli/tsm/client/*/*/[A-Z][!N]_?? )
# excludes *.jar files which are only needed for the Java based GUI X11 client
# (but X11 is not available in the recovery system so this is no real restriction)
# and language file subdirectories except the EN_US language subdirectory
# (some language files are needed and EN_US is used per default)
# cf. https://github.com/rear/rear/issues/3189#issuecomment-2093032268
# and https://github.com/rear/rear/issues/3189#issuecomment-2093288555
cf. my above mentioned
https://github.com/rear/rear/commit/7b2354e8a91306adeaf9228d79d13b23b5426011
jsmeix commented at 2024-11-08 14:59:¶
I assume it is solved because "no news is good news".
(If not, reopen it with additional information.)
[Export of Github issue for rear/rear.]