Re: "FATAL: kernel too old" when running mmdebootstrap'd riscv64 chroot
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?
> 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?
> it's *really* a significant risk for me to use the spectre-related
> linux kernels on my laptop [my only avaialble machine]. i tried 4.16,
> it nearly destroyed my SSD.
I don't see what spectre has to do with SSDs, but ok, you know your own
machine best.
> if i get really stuck i'll embed the riscv64 chroot within a
> qemu-amd64 chroot, running a 4.18 kernel, and document how it's done.
That's a VM, not a chroot, if you're running a different kernel.
James
Reply to: