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

Re: "FATAL: kernel too old" when running mmdebootstrap'd riscv64 chroot



On Tue, Oct 23, 2018 at 10:50 PM Karsten Merker <merker@debian.org> wrote:
>
> On Tue, Oct 23, 2018 at 08:56:54PM +0100, Luke Kenneth Casson Leighton wrote:
>
> > the mmdebootstrap chroot i may retry (it's not working at present,
>       ^^^^^^^^^^^^^
> debootstrap or mmdebstrap?

 mmdebstrap.  just trying it now.

> > now libffi.7.so is missing, so /usr/lib/apt/methods/http doesn't
> > start: that's easily fixed by manually downloading the relevant .deb.
>
> This sounds very much like you are either using debootstrap
> instead of mmdebstrap to build the chroot, or you are using
> mmdebstrap but don't pass it a repository line for the
> "unreleased" suite.

 i believe so: in addition, the dpkg line had failed due to the 4.15
issue, so it was borked anyway.

>   sudo mmdebstrap --architectures=riscv64 --include="debian-ports-archive-keyring" sid /tmp/riscv64-chroot "deb http://deb.debian.org/debian-ports/ sid main" "deb http://deb.debian.org/debian-ports/ unreleased main"

 ok so, i tried that, just now, and i got exactly the same "failed dpkg" issue:

 sudo mmdebstrap --architectures=riscv64
--include="debian-ports-archive-keyring" sid debian-riscv64-chroot
"deb http://deb.debian.org/debian-ports/ sid main" "deb
http://deb.debian.org/debian-ports/ unreleased main"
I: riscv64 cannot be executed, falling back to qemu-user
I: automatically chosen mode: root
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing packages...
done
/usr/sbin/chroot: failed to run command ‘dpkg’: Permission denied
env --unset=APT_CONFIG /usr/sbin/chroot
/home/lkcl/src/libreriscv/debian-riscv64-chroot dpkg --install
--force-depends failed at /usr/bin/mmdebstrap line 480.

so i went, "hmmm.... i bet that's because qemu-riscv64-system isn't in
the chroot".

so i re-deleted the chroot directory, and pre-created it, placing
qemu-riscv64-system in its usr/bin directory.  *that* failed, because
it assumed that the chroot directory would be empty.

so... i cheated: started the command, ctrl-z backgrounded it, copied
the git-latest-built qemu-riscv64-system command into the chroot's
usr/bin directory, and i now have a successfully-completed chroot.

however... the usr/bin/qemu-riscv64-static command is missing from it,
which is fine, it probably got deleted by mmdebstrap, so i put it
back.  and:

# chroot debian-riscv64-chroot/
chroot: failed to run command ‘/bin/bash’: Exec format error

which is really odd, given that the other one - the sid one that uses
debootstrap - worked (works) absolutely fine.

i'm attaching two straces (one from chroot sid-riscv64-sbuild (with
debootstrap), the other from debian-riscb64-chroot (with mmdebstrap).

weirdly, if you look at a diff of the two files, the read on the front
of the file which _should_ in both cases be pointing at /bin/bash
gives *different* contents:

+openat(AT_FDCWD, "/bin/bash", O_RDONLY) = 3
 lseek(3, 0, SEEK_SET)                   = 0
-read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\363\0\1\0\0\0PQ\0\0\0\0\0\0"...,
64) = 64
+read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\363\0\1\0\0\0\2444\3\0\0\0\0\0"...,
64) = 64
 lseek(3, 0, SEEK_SET)                   = 0

yet if i do a hexdump -C sid-riscv64-sbuild/bin/bash and likewise on
debian-riscv64-chroot/bin/bash and compare the two, they're identical
contents.

really, really odd!

l.

Attachment: logsid.txt.29261
Description: Binary data

Attachment: log.txt.28580
Description: Binary data


Reply to: