bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41264: Bootstrap packages fail to build.


From: Mathieu Othacehe
Subject: bug#41264: Bootstrap packages fail to build.
Date: Fri, 15 May 2020 14:11:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]