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

Hubertus A. Haniel hubba at unixcook.com
Tue Nov 29 17:34:15 CET 2011


Hmm - is your / filesystem on a logical volume? - If I have /dev/disk/by-uuid in
grub and /etc/fstab it will not work as the uuid of /dev/rootvg/rootlv changes
when rear rebuilds it.

So running blkid on the running system gives me:
/dev/sda1: UUID="c19e8510-96d4-45d6-b1d0-796545d81dc5" TYPE="ext4"
/dev/sda2: UUID="8hRFQs-t3Lh-06Uq-kESV-8YDc-NJC1-jU0201" TYPE="LVM2_member"
/dev/mapper/rootvg-rootlv: UUID="996f2f57-5656-4df2-b583-0f8eda206558"
UUID_SUB="203558be-59d8-468a-b49f-db86220871f4" TYPE="btrfs"
/dev/mapper/rootvg-swaplv: UUID="91d4c8b3-e967-4675-8b80-bd2ed890b22f" TYPE="swap"

After the restore I get:
/dev/sda1: UUID="c19e8510-96d4-45d6-b1d0-796545d81dc5" TYPE="ext4"
/dev/sda2: UUID="8hRFQs-t3Lh-06Uq-kESV-8YDc-NJC1-jU0201" TYPE="LVM2_member"
/dev/mapper/rootvg-rootlv: UUID="156775e7-f579-463e-b088-2e680450df5e"
UUID_SUB="5f8b67bc-76ba-47df-9313-27376cdd1f58" TYPE="btrfs"
/dev/mapper/rootvg-swaplv: UUID="91d4c8b3-e967-4675-8b80-bd2ed890b22f" TYPE="swap"

And grub is looking for root=/dev/disk/by-uuid/996f2f57-5656-4df2-b583-0f8eda206558:
###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 12.1 - 3.1.0-1.2
    root (hd0,0)
    kernel /vmlinuz-3.1.0-1.2-default
root=/dev/disk/by-uuid/996f2f57-5656-4df2-b583-0f8eda206558 load_ramdisk=1
highres=off nomodeset resume=/dev/rootvg/swaplv splash=silent quiet showopts
    initrd /initrd-3.1.0-1.2-default


In regards to grub - I can not figure out what the issue is with /etc/ld.so.cache
and grub with its "Bus error" - I can even reproduce it by etracting the initrd on
the running system and chrooting into the extracted initrd.

Best regards
Hubba



On Tue, 29 Nov 2011 15:46:00 +0100, Gratien D'haese wrote
> Forwarding this message to the list!
> Gratien
>  -------- Original Message
> --------
> Subject: Re: [Rear-users] openSuSE 12.1 / btrfs root on LVM
> Date:
> Tue, 29 Nov 2011 15:27:26 +0100
> From: Gratien D'haese 
> To: "Hubertus A.
> Haniel"
> 
> Hi,
> 
> Thanks! Removing the "--sparse" option from tar in
> 50_make_backup.sh
> 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
> defaults 
> 0 0
> UUID=cc406125-884e-455f-a124-337a5c0a6241 / btrfs 
> defaults 1
> 1
> /dev/sda2 /boot ext4 acl,user_xattr 
> 1 2
> proc /proc proc defaults 
> 0
> 0
> sysfs /sys sysfs noauto 
> 0 0
> debugfs /sys/kernel/debug debugfs noauto 
> 0
> 0
> 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)
> 
> kernel
> /vmlinuz-3.1.0-rc9-1-desktop
> root=/dev/disk/by-uuid/cc406125-884e-455
> f-a124-337a5c0a6241
> 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
> grub:
> http://lists.gnu.org/archive/html/grub-devel/2011-02/msg00011.html
> 
> Does
> anyone has a clue or better insight on the --sparse option with tar
> on
> btrfs based filesystems?
> 
> regards,
> Gratien
> 
> On Mon, 28 Nov 2011 20:32:48
> +0000, "Hubertus A. Haniel"
>  wrote:
> > 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.





More information about the rear-users mailing list