No code has been generated to recreate pv:/dev/mapper/mpathc_part2 (lvmdev) #1796
Comments
|
PPC and MULTIPATH (plus TSM and a special way to boot |
|
@bern66 |
|
Thanks jsmeix! I didn't know about the details for btrfs and SLES12. I'll add those elements of configuration in my environment. |
|
@bern66 can you also show your just for reference, here is an example of a configuration file that is working for me (Power8 LPAR, SLES12, TSM, PXE boot server instead of ISO) |
|
Of course I can do that even more if it can help you helping me. The disklayout.conf below is from a test server. Our production servers will more LUNs, just in case it could matter somehow. Here it is: Thanks, |
|
@bern66 try again with |
|
I think I begin to understand what happen here.... but don't have the root cause yet. |
|
@schabrolles Thanks |
|
@schabrolles For example: |
|
Switching to to: |
|
@bern66 If it is the case, this mean the problem is during the "mkrescue" part and not during the restore. |
|
Attached is the log of Thanks a lot for your assistance! |
|
My mistake ... it was |
|
No problem... here it is! Thanks again for your assitance! |
|
@bern66, |
|
@schabrolles Since SLES12 it should be usually I am not a multipath user so that all what I know about /dev/mapper/foo => /dev/mapper/foo-part1 @bern66 In your initial comment here you wrote Relax-and-Recover 2.3 / 2018-04-20 but #1765 was committed In general regardless if your particular issue (unexpected SUSE multipath partition name) To use our current ReaR upstream GitHub master code Basically "git clone" it into a separated directory and then # git clone https://github.com/rear/rear.git # mv rear rear.github.master # cd rear.github.master # vi etc/rear/local.conf # usr/sbin/rear -D mkbackup Note the relative paths "etc/rear/" and "usr/sbin/". If the issue also happens with current ReaR upstream GitHub master code If it perhaps "just works" with current ReaR upstream GitHub master code |
|
@bern66 /dev/mapper/mpathc2 and not in the usual SLES12 form which is /dev/mapper/mpathc-part2 #1765 (comment) RUN+="/sbin/kpartx -u -p -part /dev/$name" does not work as it should on your particular SLES12 system. |
|
I think the problem here is the presence of device because of that multipathed partition are recorded like I think it should also solve the issue here because it will find the dm-X device as partition and then find the real name (instead of trying to guess from device name + [1-9]* , or -part[1-9]* .... ) If @bern66 or @badarmontassar confirm it solves their issue, I will make a PR. |
|
@bern66 On my SLES12-SP3 installed form an original SLES12 installation medium I get # rpm -qf /usr/lib/udev/rules.d/66-kpartx.rules
kpartx-0.7.1+7+suse.3edc5f7d-1.26.x86_64
# rpm -e --test kpartx
error: Failed dependencies:
kpartx is needed by (installed) dmraid-1.0.0.rc16-34.3.x86_64
kpartx is needed by (installed) multipath-tools-0.7.1+7+suse.3edc5f7d-1.26.x86_64
# rpm -e --test dmraid
error: Failed dependencies:
dmraid is needed by (installed) os-prober-1.61-29.1.x86_64
# rpm -e --test multipath-tools
error: Failed dependencies:
multipath-tools is needed by (installed) patterns-sles-base-12-77.8.x86_64
i.e. one cannot have kpartx not installed without breaking |
|
I think the presence of a multipath device Nevertheless if you can make the ReaR multipath code to even "just work" |
|
Hello everyone, There is so many things in your previous comments, I'll need some times to reply to all your questions and suggestions. But a first few points:
Also, a SuSE consultant came to help us with many aspects of our environment and didn't mention anything wrong with our multipath setting. But he mention that we should not use friendly names specifically to support DR configurations. Regarding the naming of the multipath, here is what I have when using friendly names: And here is what I have when not using friendly names: The version of my system is 12.2: Thanks for your assistance, you are amazing! |
|
I compiled the latest version of ReaR and ended up with the same problem as initially described except that I use no friendly names: One thing I do not understand, @schabrolles you said in a comment that XXXX_part2 was not there but it is. See below: tstinf02:~ # grep part2 disklayout.conf I attach the |
|
The issue is you have As explained in a previous comment, could you give a try to the patch I prepared for issue #1766. I think it could help here. |
|
@schabrolles I attached the disklayout.conf and the log of I'll now take a look at your message regarding 1802. Thanks for your help |
|
@bern66, |
|
@bern66, here is the output I got on my system (LPAR on POWER - SLES12SP2) |
|
I would have been really surprised if the kind of underlying block-device The following shows - as far as I can reproduce it - that the btrfs structure When I install a SLES12-GA/SP0 system # cat /etc/issue Welcome to SUSE Linux Enterprise Server 12 (x86_64) - Kernel \r (\l). # findmnt -a -o SOURCE,TARGET,FSTYPE -t btrfs SOURCE TARGET FSTYPE /dev/mapper/system-root[/@] / btrfs /dev/mapper/system-root[/@/.snapshots] |-/.snapshots btrfs /dev/mapper/system-root[/@/var/lib/mailman] |-/var/lib/mailman btrfs /dev/mapper/system-root[/@/var/spool] |-/var/spool btrfs /dev/mapper/system-root[/@/tmp] |-/tmp btrfs /dev/mapper/system-root[/@/var/tmp] |-/var/tmp btrfs /dev/mapper/system-root[/@/home] |-/home btrfs /dev/mapper/system-root[/@/var/opt] |-/var/opt btrfs /dev/mapper/system-root[/@/var/lib/pgsql] |-/var/lib/pgsql btrfs /dev/mapper/system-root[/@/var/lib/named] |-/var/lib/named btrfs /dev/mapper/system-root[/@/var/log] |-/var/log btrfs /dev/mapper/system-root[/@/var/crash] |-/var/crash btrfs /dev/mapper/system-root[/@/usr/local] |-/usr/local btrfs /dev/mapper/system-root[/@/srv] |-/srv btrfs /dev/mapper/system-root[/@/opt] |-/opt btrfs /dev/mapper/system-root[/@/boot/grub2/x86_64-efi] |-/boot/grub2/x86_64-efi btrfs /dev/mapper/system-root[/@/boot/grub2/i386-pc] `-/boot/grub2/i386-pc btrfs # file /dev/mapper/system-root /dev/mapper/system-root: symbolic link to `../dm-1' # readlink -e /dev/mapper/system-root /dev/dm-1 # file /dev/dm-1 /dev/dm-1: block special (254/1) # lsblk -i -p -o NAME,KNAME,PKNAME,MAJ:MIN,TYPE,FSTYPE,SIZE /dev/sda NAME KNAME PKNAME MAJ:MIN TYPE FSTYPE SIZE /dev/sda /dev/sda 8:0 disk 20G `-/dev/sda1 /dev/sda1 /dev/sda 8:1 part LVM2_member 20G |-/dev/mapper/system-swap /dev/dm-0 /dev/sda1 254:0 lvm swap 1.5G `-/dev/mapper/system-root /dev/dm-1 /dev/sda1 254:1 lvm btrfs 18.5G # pvdisplay --- Physical volume --- PV Name /dev/sda1 VG Name system PV Size 20.00 GiB / not usable 3.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 5119 Free PE 2 Allocated PE 5117 PV UUID hyUS23-Gd2Y-YR70-kLlZ-22BQ-n4ee-AneoHm # vgdisplay --- Volume group --- VG Name system System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size 20.00 GiB PE Size 4.00 MiB Total PE 5119 Alloc PE / Size 5117 / 19.99 GiB Free PE / Size 2 / 8.00 MiB VG UUID tejprz-WpZp-jLD1-JSKc-fTcK-16W9-DCyfw4 # lvdisplay --- Logical volume --- LV Path /dev/system/root LV Name root VG Name system LV UUID YPFEHh-VedF-fm2Y-rtwT-dCFO-z2fk-SSfgMv LV Write Access read/write LV Creation host, time (none), 2018-05-17 08:39:24 +0200 LV Status available # open 1 LV Size 18.53 GiB Current LE 4744 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 254:1 --- Logical volume --- LV Path /dev/system/swap LV Name swap VG Name system LV UUID 3GWaTs-1IKN-OEen-mh3s-RBEY-PQNx-mO2mMJ LV Write Access read/write LV Creation host, time (none), 2018-05-17 08:39:25 +0200 LV Status available # open 2 LV Size 1.46 GiB Current LE 373 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 254:0 When I install a SLES12-SP3 system # cat /etc/issue Welcome to SUSE Linux Enterprise Server 12 SP3 (x86_64) - Kernel \r (\l). # findmnt -a -o SOURCE,TARGET,FSTYPE -t btrfs SOURCE TARGET FSTYPE /dev/mapper/system-root[/@/.snapshots/1/snapshot] / btrfs /dev/mapper/system-root[/@/usr/local] |-/usr/local btrfs /dev/mapper/system-root[/@/var/lib/named] |-/var/lib/named btrfs /dev/mapper/system-root[/@/srv] |-/srv btrfs /dev/mapper/system-root[/@/var/lib/mariadb] |-/var/lib/mariadb btrfs /dev/mapper/system-root[/@/var/lib/pgsql] |-/var/lib/pgsql btrfs /dev/mapper/system-root[/@/var/cache] |-/var/cache btrfs /dev/mapper/system-root[/@/boot/grub2/i386-pc] |-/boot/grub2/i386-pc btrfs /dev/mapper/system-root[/@/home] |-/home btrfs /dev/mapper/system-root[/@/var/tmp] |-/var/tmp btrfs /dev/mapper/system-root[/@/var/spool] |-/var/spool btrfs /dev/mapper/system-root[/@/.snapshots] |-/.snapshots btrfs /dev/mapper/system-root[/@/var/lib/mailman] |-/var/lib/mailman btrfs /dev/mapper/system-root[/@/opt] |-/opt btrfs /dev/mapper/system-root[/@/var/lib/mysql] |-/var/lib/mysql btrfs /dev/mapper/system-root[/@/var/lib/machines] |-/var/lib/machines btrfs /dev/mapper/system-root[/@/var/log] |-/var/log btrfs /dev/mapper/system-root[/@/var/crash] |-/var/crash btrfs /dev/mapper/system-root[/@/var/lib/libvirt/images] |-/var/lib/libvirt/images btrfs /dev/mapper/system-root[/@/tmp] |-/tmp btrfs /dev/mapper/system-root[/@/boot/grub2/x86_64-efi] |-/boot/grub2/x86_64-efi btrfs /dev/mapper/system-root[/@/var/opt] `-/var/opt btrfs # file /dev/mapper/system-root /dev/mapper/system-root: symbolic link to `../dm-1' # readlink -e /dev/mapper/system-root /dev/dm-1 # file /dev/dm-1 /dev/dm-1: block special (254/1) # lsblk -i -p -o NAME,KNAME,PKNAME,MAJ:MIN,TYPE,FSTYPE,SIZE /dev/sda NAME KNAME PKNAME MAJ:MIN TYPE FSTYPE SIZE /dev/sda /dev/sda 8:0 disk 20G `-/dev/sda1 /dev/sda1 /dev/sda 8:1 part LVM2_member 20G |-/dev/mapper/system-swap /dev/dm-0 /dev/sda1 254:0 lvm swap 1.5G `-/dev/mapper/system-root /dev/dm-1 /dev/sda1 254:1 lvm btrfs 18.6G # pvdisplay --- Physical volume --- PV Name /dev/sda1 VG Name system PV Size 20.00 GiB / not usable 3.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 5119 Free PE 2 Allocated PE 5117 PV UUID wKSGQ9-VyTZ-8vCv-t0gL-elPF-5d7u-h0nr5y # vgdisplay --- Volume group --- VG Name system System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size 20.00 GiB PE Size 4.00 MiB Total PE 5119 Alloc PE / Size 5117 / 19.99 GiB Free PE / Size 2 / 8.00 MiB VG UUID nw0UCG-WT1G-3cv1-AA73-nMC7-i1cd-nDRZPm # lvdisplay --- Logical volume --- LV Path /dev/system/root LV Name root VG Name system LV UUID pcAtC2-nFQf-RtLx-wNFs-10r6-W6cm-97LIDR LV Write Access read/write LV Creation host, time install, 2018-05-17 09:32:47 +0200 LV Status available # open 1 LV Size 18.54 GiB Current LE 4746 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 254:1 --- Logical volume --- LV Path /dev/system/swap LV Name swap VG Name system LV UUID 01GXgu-AxQv-TfzR-Pitr-OwHL-Pat9-nc5X2M LV Write Access read/write LV Creation host, time install, 2018-05-17 09:32:47 +0200 LV Status available # open 2 LV Size 1.45 GiB Current LE 371 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 254:0 |
|
Should I understand there is a fix for my problem? If there is a fix, is it available so I could test it in my environment? Thanks, |
|
No, I know about no SLES12 btrfs where its root subvolume What is mounted at the root of the filesystem tree |
…k_again_related_to_issue_1796 Make SLES12-GA/SP0 btrfs recovery work again (related to issue 1796): In layout/save/GNU/Linux/230_filesystem_layout.sh the code that excludes/disables/comments btrfs subvolumes that belong to snapper in disklayout.conf is now conditionally run only if there is a SLES12-SP1 (and later) btrfs subvolumes setup (i.e. when the default subvolume path contains '@/.snapshots/'), cf. #1796 (comment)
|
With #1813 merged it should work again |
|
Thanks @jsmeix I'll give it a try today. |
|
@bern66 # findmnt -a -o SOURCE,TARGET -t btrfs SOURCE TARGET /dev/mapper/system-root[/@] / ... or the one of a SLES12-SP1-or-later system # findmnt -a -o SOURCE,TARGET -t btrfs SOURCE TARGET /dev/mapper/system-root[/@/.snapshots/1/snapshot] / ... If you can you should try to get a SLES12-SP1-or-later 2.2.9 Installing into a Snapper-Controlled Btrfs Subvolume Prior to SUSE Linux Enterprise 12 SP1, after the first rollback of the system the original root volume was no longer reachable and would never be removed automatically. This resulted in a disk space leak. Starting with SP1, YaST installs the system into a subvolume controlled by Snapper. |
|
@jsmeix @schabrolles In a Power environment: For which I understand I have a standard btrfs structure: I then did a rear backup with |
|
@bern66 could you please check the following into your "recovery system" Did you add the SLES12SP2 addtional configuration lines into your |
|
Damn! I forgot this line and another one. Now it works for a normal btrfs structure under IBM Power Systems. I now have to find out if I can fix the anomaly in our actual btrfs systems. Thanks! |
|
@bern66 In general regarding btrfs and how to find out what its actual structure is Regarding what subvolume is mounted at the For some very initial basics about btrfs on SLES12 you may also have a look at |
|
@bern66 # Btrfs default subvolume for /dev/mapper/system-root at / # Format: btrfsdefaultsubvol <device> <mountpoint> <btrfs_subvolume_ID> <btrfs_subvolume_path> btrfsdefaultsubvol /dev/mapper/system-root / 5 / which is not what matches an original SLES12 btrfs stucture. On SLES12-GA/SP0 the btrfs default subvolume is # btrfs subvolume get-default / ID 257 gen 601 top level 5 path @ # grep ^btrfsdefaultsubvol var/lib/rear/layout/disklayout.conf btrfsdefaultsubvol /dev/mapper/system-root / 257 @ On SLES12-SP1-or-later the btrfs default subvolume is # btrfs subvolume get-default / ID 259 gen 654 top level 258 path @/.snapshots/1/snapshot # grep ^btrfsdefaultsubvol var/lib/rear/layout/disklayout.conf btrfsdefaultsubvol /dev/mapper/system-root / 259 @/.snapshots/1/snapshot |
|
As far as I understand it, the btrfs structure is ok. The / seems mounted at a normal place. Now that I know rear can do the job, I'll have to find a way to fix our systems in problem. Thanks for your assistance. |
|
@bern66 An addedum FYI which could be also of interest for @schabrolles I asked a colleague at SUSE about He told me that SLES_SAP-12-SP2 consists of a pristine SLES12-SP2 But this is not fully true because actually there are differences. It is expected that the disk space makes a difference What is unexpected is that even with exactly same disk space When I install SLES12-SP2 # findmnt -a -o SOURCE,TARGET -t btrfs SOURCE TARGET /dev/mapper/system-root[/@/.snapshots/1/snapshot] / ... I also get that btrfs setup with enabled snapshots When I install SLES_SAP-12-SP2 # lsblk -i -p -o NAME,KNAME,TYPE,FSTYPE,SIZE /dev/sda NAME KNAME TYPE FSTYPE SIZE /dev/sda /dev/sda disk 20G `-/dev/sda1 /dev/sda1 part LVM2_member 20G |-/dev/mapper/system-swap /dev/dm-0 lvm swap 636M `-/dev/mapper/system-root /dev/dm-1 lvm btrfs 19.4G # findmnt -a -o SOURCE,TARGET -t btrfs SOURCE TARGET /dev/mapper/system-root[/@] / /dev/mapper/system-root[/@/home] |-/home /dev/mapper/system-root[/@/opt] |-/opt /dev/mapper/system-root[/@/var/lib/machines] |-/var/lib/machines /dev/mapper/system-root[/@/boot/grub2/i386-pc] |-/boot/grub2/i386-pc /dev/mapper/system-root[/@/var/crash] |-/var/crash /dev/mapper/system-root[/@/boot/grub2/x86_64-efi] |-/boot/grub2/x86_64-efi /dev/mapper/system-root[/@/var/lib/pgsql] |-/var/lib/pgsql /dev/mapper/system-root[/@/var/lib/mailman] |-/var/lib/mailman /dev/mapper/system-root[/@/var/lib/libvirt/images] |-/var/lib/libvirt/images /dev/mapper/system-root[/@/var/cache] |-/var/cache /dev/mapper/system-root[/@/var/lib/mysql] |-/var/lib/mysql /dev/mapper/system-root[/@/var/lib/mariadb] |-/var/lib/mariadb /dev/mapper/system-root[/@/var/opt] |-/var/opt /dev/mapper/system-root[/@/tmp] |-/tmp /dev/mapper/system-root[/@/var/lib/named] |-/var/lib/named /dev/mapper/system-root[/@/srv] |-/srv /dev/mapper/system-root[/@/var/tmp] |-/var/tmp /dev/mapper/system-root[/@/var/spool] |-/var/spool /dev/mapper/system-root[/@/var/log] |-/var/log /dev/mapper/system-root[/@/usr/local] `-/usr/local I tested "rear mkbackup" plus "rear recover" on that system When I install SLES_SAP-12-SP2 # lsblk -i -p -o NAME,KNAME,TYPE,FSTYPE,SIZE /dev/sda NAME KNAME TYPE FSTYPE SIZE /dev/sda /dev/sda disk 40G `-/dev/sda1 /dev/sda1 part LVM2_member 40G |-/dev/mapper/system-swap /dev/dm-0 lvm swap 2G `-/dev/mapper/system-root /dev/dm-1 lvm btrfs 38.1G # findmnt -a -o SOURCE,TARGET -t btrfs SOURCE TARGET /dev/mapper/system-root[/@/.snapshots/1/snapshot] / /dev/mapper/system-root[/@/var/lib/mysql] |-/var/lib/mysql /dev/mapper/system-root[/@/boot/grub2/x86_64-efi] |-/boot/grub2/x86_64-efi /dev/mapper/system-root[/@/var/lib/machines] |-/var/lib/machines /dev/mapper/system-root[/@/opt] |-/opt /dev/mapper/system-root[/@/tmp] |-/tmp /dev/mapper/system-root[/@/var/lib/mariadb] |-/var/lib/mariadb /dev/mapper/system-root[/@/usr/local] |-/usr/local /dev/mapper/system-root[/@/var/opt] |-/var/opt /dev/mapper/system-root[/@/var/crash] |-/var/crash /dev/mapper/system-root[/@/var/spool] |-/var/spool /dev/mapper/system-root[/@/var/lib/mailman] |-/var/lib/mailman /dev/mapper/system-root[/@/var/lib/named] |-/var/lib/named /dev/mapper/system-root[/@/var/cache] |-/var/cache /dev/mapper/system-root[/@/var/log] |-/var/log /dev/mapper/system-root[/@/home] |-/home /dev/mapper/system-root[/@/var/tmp] |-/var/tmp /dev/mapper/system-root[/@/srv] |-/srv /dev/mapper/system-root[/@/.snapshots] |-/.snapshots /dev/mapper/system-root[/@/var/lib/libvirt/images] |-/var/lib/libvirt/images /dev/mapper/system-root[/@/var/lib/pgsql] |-/var/lib/pgsql /dev/mapper/system-root[/@/boot/grub2/i386-pc] `-/boot/grub2/i386-pc which is the same as when I install SLES12-SP2 |
|
@jsmeix |
|
@bern66 FYI (also @schabrolles ): |
|
@jsmeix @schabrolles It is that easy to fix this problem. Thanks for your time. Now I am on intensive ReaR testing. |
|
After a rear recover the system show a snapshot of 1. |
|
I mark this one as fixed as the problem described in the title is solved by the different patches referenced into this thread. |
|
The fact the the snapshot is now 1 looks good to me. ReaR doesn't backup the snapshots layer. it backups the system as it is when you run the |
|
Ok, that is what I understood. Thanks! |
|
FYI regarding # Regarding btrfs snapshots: # Recovery of btrfs snapshot subvolumes is not possible. # Only recovery of "normal" btrfs subvolumes is possible. # On SLE12-SP1 and SP2 the only exception is the btrfs snapshot subvolume # that is mounted at '/' but that one is not recreated but instead # it is created anew from scratch during the recovery installation with the # default first btrfs snapper snapshot subvolume path "@/.snapshots/1/snapshot" # by the SUSE tool "installation-helper --step 1" (cf. below). # Other snapshots like "@/.snapshots/234/snapshot" are not recreated. |
I am in the process to test ReaR. To test the restore, I use the same machine where "rear mkrescue" was run. In the below output of "rear -D recover" you can see the following messages:
Do I really have to add code to complete a restore? Or did I missed something while configuring the site.conf for my environment?
I really hope I will not have to add code at restore because we have hundreds of systems. In a situation of DR it would be another problem on the pile.
RESCUE tstinf01:~ # rear -V
Relax-and-Recover 2.3 / 2018-04-20
tstinf01:~ # arch
ppc64le
Booting via SMS
tstinf01:~ # lsb_release -a
LSB Version: n/a
Distributor ID: SUSE
Description: SUSE Linux Enterprise Server for SAP Applications 12 SP2
Release: 12.2
Codename: n/a
tstinf01:~ # cat site.conf
OUTPUT=ISO
OUTPUT_URL=nfs://tstinf02/exports/rear/iso
ISO_PREFIX="$HOSTNAME-rear-$( date "+%y%m%d" )"
ISO_VOLID=$HOSTNAME
REAR_INITRD_COMPRESSION=lzma
AUTOEXCLUDE_MULTIPATH=n
BOOT_OVER_SAN=y
BACKUP=TSM
COPY_AS_IS_TSM=( /etc/$HOSTNAME /opt/tivoli/tsm/client/ba/bin/dsmc /opt/tivoli/tsm/client/ba/bin/tsmbench_inclexcl /opt/tivoli/tsm/client/ba/bin/dsm.sys /opt/tivoli/tsm/client/ba/bin/dsm.opt /opt/tivoli/tsm/client/api/bin64/libgpfs.so /opt/tivoli/tsm/client/api/bin64/libdmapi.so /opt/tivoli/tsm/client/ba/bin/EN_US/dsmclientV3.cat /usr/local/ibm/gsk8* )
COPY_AS_IS_EXCLUDE_TSM=( )
PROGS_TSM=(dsmc)
TSM_LD_LIBRARY_PATH="/opt/tivoli/tsm/client/ba/bin:/opt/tivoli/tsm/client/api/bin64:/opt/tivoli/tsm/client/api/bin:/opt/tivoli/tsm/client/api/bin64/cit/bin"
TSM_RESULT_FILE_PATH=/opt/tivoli/tsm/rear
TSM_RESULT_SAVE=n
TSM_ARCHIVE_MGMT_CLASS=qaasba
TSM_RM_ISOFILE=y
Thanks,
The text was updated successfully, but these errors were encountered: