On 4/14/11 5:26 AM, Markus Trippelsdorf wrote: > I trashed my system this morning when I installed coreutils-8.11. > > What happened is that coreutils compiles and links correctly, but > then the following command (during the installation phase): > > ./ginstall chroot hostid nice who users pinky stty df stdbuf [ base64 > basename cat chcon chgrp chmod chown cksum comm cp csplit cut date dd > dir dircolors dirname du echo env expand expr factor false fmt fold > head id join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv > nl nproc nohup od paste pathchk pr printenv printf ptx pwd readlink > rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum > shred shuf sleep sort split stat sum sync tac tail tee test timeout > touch tr true truncate tsort tty uname unexpand uniq unlink vdir wc > whoami yes arch > '/var/tmp/portage/sys-apps/coreutils-8.11/image//usr/bin' > > apparently produces files which have the length of the originals but > are full of zeros. (and these were then installed to my live system, > thereby trashing it). > > Now all the above is automated, because I use gentoo. But when I run > the command above (ginstall) later again by hand, everything is > copied just fine and the resulting binaries are all usable. > > The partition in question uses xfs. > > # xfs_info /var meta-data=/dev/sda1 isize=256 > agcount=4, agsize=12800000 blks = sectsz=4096 > attr=2 data = bsize=4096 blocks=51200000, > imaxpct=25 = sunit=0 swidth=0 blks naming > =version 2 bsize=4096 ascii-ci=0 log =internal > bsize=4096 blocks=25000, version=2 = > sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none > extsz=4096 blocks=0, rtextents=0 > > This is a 4kb hard drive (sectsz=4096). > > I'm running the lastest vanilla git kernel > (2.6.39-rc3-00087-gda768a4). > > Now my question is, could this be caused by the recent FIEMAP changes > in coreutils? Well damn. Looking into it ... -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
