From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 08:11:48 2020 Received: (at 41264) by debbugs.gnu.org; 15 May 2020 12:11:48 +0000 Received: from localhost ([127.0.0.1]:36140 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZZBs-0002Il-38 for submit@debbugs.gnu.org; Fri, 15 May 2020 08:11:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZZBq-0002IZ-Kc for 41264@debbugs.gnu.org; Fri, 15 May 2020 08:11:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39104) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZZBk-00079Z-Ta for 41264@debbugs.gnu.org; Fri, 15 May 2020 08:11:40 -0400 Received: from [2a01:cb18:832e:5f00:5cdd:cc67:a2e1:e2f0] (port=35580 helo=meru) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZZBg-0004Ww-6x for 41264@debbugs.gnu.org; Fri, 15 May 2020 08:11:40 -0400 From: Mathieu Othacehe To: 41264@debbugs.gnu.org Subject: Re: bug#41264: Bootstrap packages fail to build. References: <87h7wik0kk.fsf@gnu.org> Date: Fri, 15 May 2020 14:11:34 +0200 In-Reply-To: <87h7wik0kk.fsf@gnu.org> (Mathieu Othacehe's message of "Thu, 14 May 2020 17:17:47 +0200") Message-ID: <87v9kxe6tl.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41264 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hello, > fstat(3, 0xffad5874) = -1 EOVERFLOW (Value too large for defined data type) > fstat64(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 > fstat64(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 > > So I think somehow, bootstrap packages use the legacy "fstat" syscall, > which may overflow on a 64 bits system. More info on that one. Linux syscall "newstat", will call "cp_compat_stat". This function starts by checking the device id: --8<---------------cut here---------------start------------->8--- struct compat_stat tmp; if (!old_valid_dev(stat->dev) || !old_valid_dev(stat->rdev)) return -EOVERFLOW; --8<---------------cut here---------------end--------------->8--- Here, stat->dev is 66308 (major: 259, minor 4). "old_valid_dev" checks that: --8<---------------cut here---------------start------------->8--- static inline bool old_valid_dev(dev_t dev) { return MAJOR(dev) < 256 && MINOR(dev) < 256; }--8<---------------cut here---------------end--------------->8--- Which is false here, because my NVME disk has a BLOCK_EXT_MAJOR (259). So stat, lstat, and all other related function will return -EOVERFLOW unless their 64 bits stat64, lstat64 counterpart is used. So I think this means that one cannot build the Guix bootstrap toolchain on an NVME disk. Thanks, Mathieu