mkfs.ubifs problem when output file really isn't in the UBIFS root directory

[Artem Bityutskiy]

On Fri, 2012-09-21 at 17:41 +0200, Marcus Prebble wrote:
> Hi,
> 
> We are working on a project using UBI/UBIFS and I have run into a
> problem with mkfs.ubifs which I am hoping someone can advise on.
> Apologies if I have already missed the answer to this in the archives
> somewhere.
> 
> A requirement of the project is to take an image of the root filesystem
> (/) which is implemented as a static UBI read only volume. Obviously its
> not possible to unmount /, but it seems to be possible to re-mount the
> UBI volume, read only, onto another location e.g. /tmp/mnt/new_rootfs.
> 
> The problem arises when running mkfs.ubifs is that it fails saying that
> the output file cannot be in the UBIFS root directory.
> This sounds like a reasonable constraint if the output file really was
> in the root, but this is not the case for us seeing root is mounted
> somewhere belowtmp. To give a concrete example of the command we are
> running:
> 
> mkfs.ubifs --output=/tmp/rootfs.img  --leb-size=129024
> --root=/tmp/rootfs_mnt --min-io-size=2048 --max-leb-cnt=147 
> 
> Where /dev/ubi0_11 is mounted read-only on both / and /tmp/rootfs_mnt/.
> 
> Having a look at the source for mkfs.ubifs it seems that the function
> in_path(..) is the problem - it works up the directory tree using ../
> until it either reaches the top_dir (/) or the inode number/dev match in
> which case it fails. It doesn't seem that this section of code has
> changed in the latest version of mtd-utils (we are running 1.4.3-2) and
> I wonder if this is a bug in in_path(..) or a genuine safeguard against
> screwing something up? I suspect the former for when I disabled this
> check in mkfs.ubifs.c the resulting image was completely OK.

Well, obviously this is a safeguard check. If your source FS is
in /a/path/, and the output image file is /a/path/image, then we will
loop forever reading /a/path/image and writing the output
to /a/path/image.

In your case 'tmp' is a tmpfs, right? This is obviously a bug then. You
should probably analyze it and send a fix.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20121004/17b23f9b/attachment.sig>