You're little trick with touching a blank /proc/mounts works, FWIW. You're "--force" patch works even better however ;) Thanks!
.:Justin:. --- On Sun, 1/2/11, Goffredo Baroncelli <[email protected]> wrote: > From: Goffredo Baroncelli <[email protected]> > Subject: Re: Odd mkbtrfs behavior inside of chroot > To: "J G" <[email protected]> > Cc: [email protected] > Date: Sunday, January 2, 2011, 3:14 PM > On 01/02/2011 08:52 PM, J G 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. > > On the basis of the provided information, and on the code > it seems that > mkfs.btrfs tries hard to check that the user is not > formatting a mounted > disk (or loop). So mkfs.btrfs scan the /proc/mount file and > checks every > devices. To do the check it needs to access the original > file if this is > a "loop backend". This is reasonable. > > In this case in a chroot-ed environment the loop file is > not accessible. > > If you need a [dirty] "quick hack" to by-pass the problem > (not tested): > - unmount the proc filesystem > - create an empty file /proc/mounts > - run btrfs.fsck > - mount the proc filesystem (removing the fake mounts > file) > - perform a "btrfs device scan" > - mount the filesystem > > Of course the "right" solution is to add a "--force" switch > which > permits to by-pass these checks. Other mkfs.* tools have > this switch. > > From the mkfs.ext4 man page: > [...] > -F > Force mke2fs to create a filesystem, > even if > the specified device is not > > a partition on a > block special > device, or > if other parameters do > not > make sense. In order to force > mke2fs to > create a filesystem even > if > the filesystem appears to be in > use or is > mounted (a truly dangerous > > thing to do), this option must be > specified > twice. > > [...] > > > > > > .: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
