Re: "FATAL: kernel too old" when running mmdebootstrap'd riscv64 chroot
On 23 Oct 2018, at 17:45, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>
> On Tue, Oct 23, 2018 at 5:14 PM James Clarke <jrtc27@debian.org> wrote:
>>
>> On 23 Oct 2018, at 16:59, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>>> On Tue, Oct 23, 2018 at 12:00 PM James Clarke <jrtc27@debian.org> wrote:
>>>>
>>>> On 23 Oct 2018, at 11:56, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
>>>>>
>>>>> On 10/23/18 12:31 PM, James Clarke wrote:
>>>>>> Unless I'm missing something, this argument is false? Sure you need a 4.15
>>>>>> kernel if you want to run riscv64 natively, but this is using qemu-user on
>>>>>> amd64; all the system calls will be translated to the amd64 versions that have
>>>>>> existed for years. If not, qemu-user itself would be imposing a minimum kernel
>>>>>> version.
>>>>>
>>>>> Yes, I wanted to outline that as well.
>>>>>
>>>>>> NB: This is coming from glibc as it sets arch_minimum_kernel=4.15.0 in
>>>>>> sysdeps/unix/sysv/linux/riscv/configure.ac.
>>>>>
>>>>> I usually bootstrap with:
>>>>>
>>>>> $ debootstrap --foreign --no-check-gpg --variant=buildd --include=debian-ports-archive-keyring --arch=riscv64 unstable sid-riscv64-sbuild http://ftp.ports.debian.org/debian-ports
>>>>>
>>>>> Then build a fresh qemu-user from git, copy it into the chroot to usr/bin/qemu-riscv64-static,
>>>>> then change into the chroot and run ./debbootstrap/debbootstrap --second-stage.
>>>>>
>>>>> Never had any issues.
>>>
>>> ok i'll give that alternative a shot, currently using mmbootstrap....
>>>
>>>> That would be because recent qemu-user lies to the world specifically to fix this:
>>>> https://github.com/qemu/qemu/commit/b02ebad1dc3132672a2a1ade2997c78441947e77.
>>>>
>>>> So, Luke, use qemu-user v3.0.0 or greater and everything should be fine.
>>>
>>> ok, that looks like it'd work... drat:
>>>
>>> this was the command that failed, i re-ran it as this:
>>> # strace -o log.txt -ff env --unset=APT_CONFIG /usr/sbin/chroot
>>> /home/lkcl/src/libreriscv/debian-riscv64-chroot dpkg --install
>>> --force-depends
>>>
>>> and got this:
>>> openat(AT_FDCWD, "/lib/ld-linux-riscv64-lp64d.so.1", O_RDONLY) = 3
>>
>> So it opened the dynamic linker as file descriptor 3. Your point?
>
> sorry, i minimised. the program that opened that file descriptor was
> one which critically depends on that library. it was *not*
> qemu-riscv64-static.
>
> therefore, fixing qemu-riscv64-static doesn't help.
Yes, it does, stop trying to tell us we're wrong, otherwise you can go fix your problem yourself. There's a reason you're here asking us for help.
>>> which i believe is inside the chroot.
>>>
>>> the configure i used for qemu was this:
>>> $ ./configure --target-list="riscv32-softmmu,riscv64-softmmu,riscv32-linux-user,riscv64-linux-user"
>>> --static --disable-glusterfs --disable-gtk --disable-usb-redir
>>>
>>> and followed it up with cp ./riscv64-linux-user/qemu-riscv64 /tmp (and
>>> then to the chroot).
>>>
>>> so i believe although qemu may have been fixed, ld-linux hasn't.
>>
>> What do you mean, ld-linux hasn't been fixed? You haven't demonstrated a
>> problem with it?
>
> the dynamic ld-linux is still being accessed, and it is one of three
> files in the chroot that contains the string "FATAL: kernel too old".
> therefore by logical deductive reasoning, we may surmise that, the
> qemu one having been sorted, the loading of this file followed
> immediately by a message "FATAL: kernel too old", it is probably
> caused by this file.
No, your understanding is completely wrong. The problem is *not* that the
string exists in ld-linux; go look at your amd64 one and you'll find it there
too:
jrtc27@master:~$ strings /lib64/ld-linux-x86-64.so.2 | grep FATAL:\ kernel\ too\ old
FATAL: kernel too old
The *problem* is that the qemu your chroot ends up using does not pretend to be
4.15. Either you've built the wrong version of qemu, or your static qemu-user
binary is in the wrong place. Stop blaming glibc, glibc is as it should be, get
glibc out of your head, and work out why your chroot is not using the right
qemu version.
James
Reply to: