Today I experienced a strange error of mount, see URL given above. I tracked it down to files belonging to 16777214:16777214 instead of root:root, e.g. /bin/mount. The oldest file is from March, /usr/bin/rsync. Reemerging an affected package creates the same problem. Something must be broken, but how to track that down to the source? Reproducible: Always
Created attachment 269389 [details] emerge.info
I found the reason for the error. I had extended my /var/tmp/portage directory by mounting it via bind with another directory from another harddisk: /etc/fstab: /dev/sdb1 /mnt/cool xfs noatime 0 2 /mnt/cool/portage /var/tmp/portage none defaults,bind 0 0 When umounting /var/tmp/portage, emerging goes well. When mounting /var/tmp/portage, the error occours. So, WTF is causing this? It had worked for months. Can one enlighten me, why and what is making trouble, when having /var/tmp/portage mounted via bind with another directory on at a sudden?
see what perms the file has in the image dir before it gets merged to /. i.e. use ebuild to build/install things. or use FEATURES=keepwork. also try running fsck on said filesystem.
(256 ^ 3) - 2
nothing really operates on multiples of 256, so really it would be: (2 ^ 24) - 2
Umounted /var/tmp/portage, umounted the partition serving it, have run checks on it: host ~ # xfs_check /dev/sdb1 host ~ # host ~ # xfs_repair /dev/sdb1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done host ~ # mount /mnt/cool/ host ~ # mount /var/tmp/portage/ host ~ # emerge -av sys-apps/util-linux An ls -lR /var/tmp/portage/sys-apps/util-linux-2.19/work/util-linux-2.19/ will be attached next, showing the contents right after ">>> Source prepared."
Created attachment 269561 [details] sys-apps.util-linux-2.19.ls-lR
Meanwhile I have more information. When mounting a directory of the same harddisk from another partition which has ext3 filesystem at /var/tmp/portage and compile things in there, everything is fine. It is only another harddisk which has xfs filesystem which makes trouble when doing the same. So, it seems to be an error depending on the xfs filesystem when mounting with bind. But, is it an error of mount or of the xfs filesystem? Or, does the ext3 filesystem have problems with foreign filesystem mounted with bind?
Have you tried booting more recent kernels?
No I hadn't but I have done so now. I am running 2.6.39 gentoo sources currently and it seems the issue has gone. Thanx for asking, I am shure we can close this, now. Do you agree?
Ok, closing, feel free to reopen if you encounter the problem again.
