Ticket #345 (closed defect: invalid)

Opened 10 years ago

Last modified 8 years ago

paludis fails with EXDEV when reinstalling a package (using aufs/unionfs)

Reported by: moonz Owned by: ciaranm
Priority: Sometime Milestone:
Component: core/paludis Version: 0.44.0
Keywords: Cc:
Blocked By: Blocking:
Distribution: Gentoo

Description

Background: My hard drive is slow. VERY slow. Installing a package is slow as hell. So, I used squashfs with aufs as explained in  http://forums.gentoo.org/viewtopic-t-401647.html to compress /usr/portage and /var/cache/pkg. $ mount /usr/squash/portage.s on /usr/portage type squashfs (rw,loop=/dev/loop0) none on /usr/portage type aufs (rw,xino=/var/tmp/squash/portage/.aufs.xino,br:/var/tmp/squash/portage=rw:/usr/portage=ro) /usr/squash/pkg.s on /var/db/pkg type squashfs (rw,loop=/dev/loop1) none on /var/db/pkg type aufs (rw,xino=/var/tmp/squash/pkg/.aufs.xino,br:/var/tmp/squash/pkg=rw:/var/db/pkg=ro)

Problem: now, paludis -i which (for example, but it's the same with every single package) fails for reinstallation (it works for downgrade, upgrade, installation or uninstallation) when which-2.16 is in the read-only branch of /var/cache/pkg, with this message:

Completed ebuild phases loadenv strip preinst saveenv Writing VDB entry to '/var/db/pkg/sys-apps/-checking-which-2.16'... Writing VDB entry keys ... Generating saved ebuild and environment... Finished writing VDB entry Checking whether we can merge to / .........

Unhandled exception:

  • In program paludis -i --preserve-world which:
  • When performing install action from command line:
  • When executing install task:
  • When installing 'sys-apps/which-2.16':
  • When merging 'sys-apps/which-2.16::gentoo' at '/var/tmp/paludis/sys-apps/which-2.16/image' to VDB repository 'installed':
  • rename('/var/db/pkg/sys-apps/which-2.16', '/var/db/pkg/sys-apps/-reinstalling-which-2.16') failed: Invalid cross-device link (paludis::FSError)

Workarounds:

  • Since the bug only appears if which-2.16 is in the read-only branch,

# find /var/db/pkg/sys-apps/which-2.16 -exec touch {} \; force aufs to put which-2.16 in the read-write branch, and everything's good :)

  • paludis -u which; paludis -i which. Well, not usable with paludis or glibc ;) (in fact, not with which since ebuild uses which)
  • copy /usr/portage/sys-apps/which into a local overlay (eg /usr/local/portage) and rename which-2.16.ebuild into which-2.16-r1.ebuild

Solution: Attached patch use system(3) to call mv(1) when the error EXDEV is returned by rename(2)

Attachments

paludis-0.24.6-exdev.patch Download (1.5 KB) - added by moonz 10 years ago.

Change History

Changed 10 years ago by moonz

comment:1 Changed 10 years ago by ciaranm

  • Status changed from new to closed
  • Resolution set to wontfix

This isn't a sane solution. Your /var/db/pkg needs to be on a single filesystem -- I'd really rather not include nasty hacks in Paludis to work around broken system configurations. Your best bet if you must do weird stuff to VDB is to use that touch hack inside a hook.

comment:2 Changed 8 years ago by madMAx43v3r

  • Status changed from closed to reopened
  • Distribution set to Gentoo
  • Resolution wontfix deleted

i think this should be fixed, because portage works in this case:  http://bugs.gentoo.org/show_bug.cgi?id=182964

comment:3 Changed 8 years ago by madMAx43v3r

  • Version changed from 0.24.5 to 0.44.0

changed version to 0.44.0

comment:4 Changed 8 years ago by madMAx43v3r

i forgot to add that this could still happen even if the source and target is on the same fs: from the aufs docs: To rename(2) directory may return EXDEV even if both of src and tgt are on the same aufs. When the rename-src dir exists on multiple branches and the lower dir has child(ren), aufs has to copyup all his children. It can be recursive copyup. Current aufs does not support such huge copyup operation at one time in kernel space, instead produces a warning and returns EXDEV. Generally, mv(1) detects this error and tries mkdir(2) and rename(2) or copy/unlink recursively. So the result is harmless. If your application which issues rename(2) for a directory does not support EXDEV, it will not work on aufs. Also this specification is applied to the case when the src directroy exists on the lower readonly branch and it has child(ren).

comment:5 Changed 8 years ago by ciaranm

  • Status changed from reopened to closed
  • Resolution set to invalid

Use a sane filesystem. A filesystem that can't handle a simple directory rename is too broken to be worth supporting.

Note: See TracTickets for help on using tickets.