[Rear-users] openSuSE 12.1 / btrfs root on LVM

Hubertus A. Haniel hubba at unixcook.com
Mon Nov 28 21:32:48 CET 2011


OK - now I should really give this a rest for today but here are some 
further findings as I have managed to do a successful recovery:

In /usr/share/rear/backup/NETFS/default/50_make_backup.sh I have taken 
out the --sparse option to tar which seems to be the culprit in turning 
all the ASCII files into data files on btrfs

After the restore completed I removed /etc/ld.so.cache and run the grub 
shell manually to do the "root (hd0,0)" and setup "(hd0)" so the grub 
thing is a separate issue as during the creation of initrd tar does not 
use the --sparse option as far as I can see.

Please note that I am currently running openSuSE 12.1 without systemd as 
it introduces just more problems which where getting in the way to debug 
this.

I also changed the entries in /etc/fstab and /boot/grub/menu.lst to 
address the filesystems traditionally rather then by /dev/disk/by-uuid 
stuff - especially for /dev/rootvg/rootlv as the uuid changes during 
restore and grub would not find rootlv so rear propably needs some 
clever way of updating these if they are in use. I don't actually see 
the benefit of these anyway but I am not aware of switching that stuff 
off during the installation so I guess we have to put up with it in the 
future somehow.

Best regards
Hubba


On 28/11/2011 19:01, Hubertus A. Haniel wrote:
>    Right - I did not realize that COPY_AS_IS uses tar as well.
>
> Interestingly removing /etc/ld.so.cache fixes grub when booted in the
> recovery shell and when I copied in ldconfig to try to regenerate the
> file it created the file the same size and grub goes back to "Bus error"
>
>
> On 28/11/2011 17:52, Gratien D'haese wrote:
>> On Mon, 28 Nov 2011 17:14:35 +0000, "Hubertus A. Haniel"  wrote:
>>>   In regards to grub not being configured is because grub actually gives
>>>   me a "Bus Error" when trying to run it in the Rear recovery shell so it
>>>   looks like something that is part of grub may be corrupted inside the
>>>   initrd as well but it is not grub itself as the md5sum matches.
>>
>> Don't focus on grub itself, the problem has to be found in the way tar
>> works (or doesn't) with btrfs.
>> The coming days I don't have the time to troubleshoot it myself...
>>
>>>   On 28/11/2011 17:03, Hubertus A. Haniel wrote:
>>>>
>>>>
>>>>   That looks good to me. - I will try to do some more debugging around the
>>>>   btrfs stuff tommorrow if I get a chance and if I find anything I will
>>>>   let you know.
>>
>>
>> --
>> Gratien D'haese
>> IT3 Consultants bvba
>> Vennestraat 15, B-2560 Nijlen
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>>
>>
>>
>> _______________________________________________
>> Rear-users mailing list
>> Rear-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rear-users
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> 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