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

Gratien D'haese gratien.dhaese at it3.be
Tue Nov 29 15:46:00 CET 2011

Forwarding this message to the list!
 -------- Original Message
Subject: Re: [Rear-users] openSuSE 12.1 / btrfs root on LVM
Tue, 29 Nov 2011 15:27:26 +0100
From: Gratien D'haese 
To: "Hubertus A.


Thanks! Removing the "--sparse" option from tar in
indeed resulted in a successful restore. Seems strange as
sparse files 
are supported on btrfs.

This is my fstab file of the
recovered system:
linux-6eww:~ # cat /etc/fstab
/dev/sda1 swap swap
0 0
UUID=cc406125-884e-455f-a124-337a5c0a6241 / btrfs 
defaults 1
/dev/sda2 /boot ext4 acl,user_xattr 
1 2
proc /proc proc defaults 
sysfs /sys sysfs noauto 
0 0
debugfs /sys/kernel/debug debugfs noauto 
devpts /dev/pts devpts mode=0620,gid=5 
0 0

I had no problem with grub
this time:
title Desktop -- openSUSE 12.1 RC 1 - 3.1.0-rc9-1
 root (hd0,1)

resume=/dev/sda1 splash=silent quiet showopts
vga=0x317 linuxrc=trace

initrd /initrd-3.1.0-rc9-1-desktop

An interesting pointer I found is the
following concerning

anyone has a clue or better insight on the --sparse option with tar
btrfs based filesystems?


On Mon, 28 Nov 2011 20:32:48
+0000, "Hubertus A. Haniel"
> 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
> 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
>> 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
>>>> me a "Bus Error" when trying to run it in the Rear recovery
>>>> it
>>>> looks like something that is part of grub may be
corrupted inside
>>>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pikachu.3ti.be/pipermail/rear-users/attachments/20111129/ee1641ef/attachment.html 

More information about the rear-users mailing list