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: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.
> > 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.
now, what i can't work out is *why* that file has been loaded (or where from).
> > 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.
the machine's an extremely costly high-end gaming laptop that
unfortunately was prior to the various skylake-related bugfixes
deployed on similarly-spec'd hardware from more commonly known
manufacturers such as dell. i have to be *really* extra cautious,
because if an excessive amount of power is drawn, the entire PCIe bus
drops offline. yes, really! it's taken a couple of years to triage.
> > 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.
it may be the route i'll have to go, here.
l.
Reply to: