Re: "FATAL: kernel too old" when running mmdebootstrap'd riscv64 chroot
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Oct 23, 2018 at 5:24 PM James Clarke <jrtc27@debian.org> wrote:
>
> On 23 Oct 2018, at 17:13, 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.
> >
> > yep i'm getting the exact same "kernel too old" with this as well:
> > # strace -o log.txt -ff /usr/sbin/chroot sid-riscv64-sbuild
> > ./debootstrap/debootstrap --second-stage
>
> Does the chroot have the updated qemu? Is it called the right thing?
yes it does. it's been named usr/bin/qemu-riscv64-static. i found these:
https://wiki.debian.org/RISC-V#Creating_a_riscv64_chroot
https://wiki.debian.org/RISC-V#Qemu
so updated accordingly (to no avail). one observation:
log.txt.25422:openat(AT_FDCWD, "/etc/qemu-binfmt/riscv64",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
which is intriguing, i have no idea if it's relevant, and google
searches do not turn anything up.
> > question. why, if i am using the latest libc6 (2.27-6) from sid, and
> > it works perfectly with linux 4.13, is it specifically the case that
> > the riscv configuration sets a minimum of 4.15.0? it does not make
> > any sense.
>
> Because it can't possibly work on a pre-4.15 riscv64 kernel, and it's better to
> detect the old kernel rather than failing at some later point in an
> unintelligible way because a system call was missing.
even if debian-riscv64 is using the exact same 2.27 libc6? or is it
using a later version? i would totally get it if the version of
debian-riscv64 libc6 was greater than the one being used by other
arch's
> > https://packages.debian.org/sid/libc6
> >
> > i mean, if i installed an updated version of libc6 with an "apt-get
> > install libc6" which had the same hard mandatory requirement, on the
> > next boot i'd be absolutely f****d!
>
> Yes, and in fact, on most architectures, 3.8 is set as the minimum, so if
> you're running an old kernel you can have precisely this issue.
i remember from 3.2 a few years back. (thank you john for reminding me).
l.
Reply to: