[Rear-users] ReaR and SLES 11

Schlomo Schapiro schlomo at schapiro.org
Tue Sep 8 11:35:27 CEST 2009


Hi,

I did a lot of testing with openSUSE 11.2 now (which also has a new
bash) and did not see any problem like you described.

Could it be something else? I would be very surprised if a new bash
would be so incompatible and if this incompatibility would hit only you
and then only in this single place (we use similar constructs in several
places).

Maybe you can check more the surroundings and also dry with a clean rear
and NETFS. Maybe some DP script accidentially garbled one of the variables?

As always, hard to tell without touching the keyboard...

Regards,
Schlomo

PS: Nasty little surprises: udev dropped vol_id since version 142.
Expect rear 1.7.21 real soon with blkid support :-)

Gratien D'haese wrote:
> Thank you Peter for your valuable input. We'll have a look into it
> (together with Schlomo).
> What exactly went wrong with rear in combination with HP Data Protector?
> Just curious.
> 
> best regards,
> Gratien
> 
>> Hi
>>
>> I am currently preparing the release of SLES 11 at a customer site.
>> Because ReaR is used for disaster recovery on SLES 9 and SLES 10 i gave
>> ReaR on SLES 11 with Tivoli Storage Manager (TSM) a try.
>>
>> It looked quite well on first glance. The recovery cd was built without
>> problems. Unfortunately booting the CD ended up in a kernel panic (no
>> root filesystem was found). Another colleague tested ReaR on SLES 11 and
>> HP Data Protector . In that combination the boot CD did actually boot
>> but had strange problems in recovery.
>>
>> Today i had some time to look into the problem and figured the recovery
>> cd wouldn't boot because /bin/init (and several other binaries and
>> libraries) were missing in the initrd.
>>
>> After digging a little deeper i found the problem in
>> build/GNU/Linux/39_copy_binaries_libraries.
>>
>> In SLES 9 and 10 (bash < 3.2) the expression
>>
>> c=0
>> for k in "${PROGS[@]}" "${REQUIRED_PROGS[@]}"; do
>>
>> iterated over the contents of array PROGS and REQUIRED_PROGS
>>
>> while in SLES 11 it only iterates over the contents of array
>> REQUIRED_PROGS. Thus all binaries referenced in PROGS aren't copied to
>> the initrd image.
>>
>> The following snipped solves the problem:
>>
>> c=0
>> local DEST=( ${PROGS[@]} ${REQUIRED_PROGS[@]} )
>> for k in ${DEST[@]} ; do
>>
>>
>> And the following for the libraries:
>>
>> LIBS64=()
>> for lib in ${LIBS[@]} $(SharedObjectFiles "${BINARIES[@]}" | sed -e
>> 's#^#/#' ) ; do
>>
>> will have to be changed to
>>
>> LIBS64=()
>> DEST=( ${LIBS[@]} $(SharedObjectFiles "${BINARIES[@]}" | sed -e 's#^#/#' )
>> )
>> for lib in ${DEST[@]} ; do
>>
>> With these changes in place the Recovery CD boots again. I have not yet
>> been able to test a recovery.
>>
>>
>> As I am not a shell expert I am not sure why behaviour changed. I am
>> assuming it might have to do with the new bash version. And i am not
>> sure wether the current code is flakey or not. At least the quoting
>> seems weird to me ...
>>
>>
>> Brgds
>> Peter
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Rear-users mailing list
>> Rear-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rear-users
>>
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Rear-users mailing list
> Rear-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rear-users




More information about the rear-users mailing list