Binding /sys proved futile. .:Justin:.
--- On Sun, 1/2/11, Jérôme Poulin <[email protected]> wrote: > From: Jérôme Poulin <[email protected]> > Subject: Re: Odd mkbtrfs behavior inside of chroot > To: "J G" <[email protected]> > Cc: "[email protected]" <[email protected]> > Date: Sunday, January 2, 2011, 1:06 PM > Did you try using -o bind on /proc > and /sys as well? Just in case mkfs > uses /sys too, I'm not sure if /proc reacts differently to > multiple > mounts or bind neither? > > Envoyé de mon appareil mobile. > > Jérôme Poulin > Solutions G.A. > > On 2011-01-02, at 14:53, J G <[email protected]> > wrote: > > > I just encountered some odd behavior from mkbtrfs. > > The end goal is to restore a backup to newly created > BTRFS partitions while using the latest btrfs-tools. > > Here's the steps to what I did: > > * Booted SystemRescueCD > > * Partitioned the drives (two 750GB drives with 12 > partitions each) > > * Created an extra partition on sda as a temporary > holding place for the backed up files and so I can update > btrfs-tools > > * Formatted/mounted/restored backup files to the > temporary partition which I mounted on /mnt/backup > > * mount -t proc none /mnt/backup/proc; mount -o bind > /dev /mnt/backup/dev > > * chroot /mnt/backup /bin/bash > > * Updated btrfs-tools to the latest git pull from > today (v0.19-35-g1b444cd-dirty). > > * mkbtrfs /dev/sda5 /dev/sdb5 -L root > > > > mkbtrfs returned with: > > > > error checking /dev/sda5 mount status > > > > So I used strace to find out how it was checking for > the mount status. Now, I'm no expert here, but I'm confused > as to just why it failed. The last thing of note: > > > > lstat("/boot", {st_mode=S_IFDIR|0755, st_size=4096, > ...}) = 0 > > lstat("/boot/sysrcd.dat", 0x7fffb29681e0) = -1 ENOENT > (No such file or directory) > > close(3) > > = 0 > > munmap(0x7f11df372000, 4096) > = 0 > > write(2, "error checking /dev/sda5 mount s"..., > 38error checking /dev/sda5 mount status > > ) = 38 > > > > > > doesn't explain much. I see that it's checking > /proc/mounts to see what's mounted, and then it fails on > stating /boot/sysrcd.dat (which doesn't exist in the > non-chrooted FS, btw). > > > > To make this even weirder, if I format sda5/sdb5 using > the SysRescCD version of mkbtrfs (v0.19) and then format > sda5/sdb5 using the chroot version, it works fine. > > > > Any ideas here? I would expect that mkbtrfs would work > inside of a chroot without any assistance from the original > root. > > > > I have the full strace from the chrooted mkbtrfs > failing and from it succeeding, if that's helpful. > > > > > > .:Justin:. > > > > > > > > -- > > To unsubscribe from this list: send the line > "unsubscribe linux-btrfs" in > > the body of a message to [email protected] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
