| rrq | tuxd3v: was that a native 32-bit, or 32bit install in 64bit? (I would be able trial the latter) | 01:42 |
|---|---|---|
| tuxd3v | rrq, its 32 bits x86, but its for debootstraping arm 32bits, the first stage goes well, when we run '/debootstrap/debootstrap --second-stage' in the chroot, it gives us that error | 02:10 |
| tuxd3v | /debootstrap - is arm 32 bits | 02:11 |
| tuxd3v | I am also using qemu-user-static to emulate arm 32bits.. | 02:12 |
| onefang | So you chroot into a system installed to run on ARM, but your chroot is still running on x86. You might want to try doing that on a VM that's translating ARM to x86. | 02:12 |
| * onefang goes back to resting up after grocery hunting. | 02:13 | |
| tuxd3v | SO I don't know if the error comes from debootstrap or if it somes from qemu-user-static, I really bet in the second, but don'tknow | 02:13 |
| tuxd3v | onefang, let the certify, but I believe all inside chroot is arm32 bits.. | 02:16 |
| tuxd3v | in debootstrap, I am using '--foreign' | 02:16 |
| onefang | And the chroot command itself? | 02:16 |
| onefang | And /proc? Etc. | 02:17 |
| tuxd3v | onefang, in beowulf it works ok, in cimaera amd64 also.. | 02:17 |
| tuxd3v | in Chimaera i686 it gives error | 02:17 |
| tuxd3v | onefang, yes those and bind mounted | 02:18 |
| onefang | OK, it's something else then. I debootstrap my installs, but never triad cross platform. | 02:18 |
| tuxd3v | for cross platform you need bin-fmt, and qemu-user-static, so that you can emulate the guest platform :) | 02:20 |
| onefang | My last debootstrap I did into a VM image, then booted that in qemu. | 02:21 |
| onefang | Oh wait, second last. lol | 02:21 |
| rrq | next trial should be a qemu install into a bare-metal partition and then boot the bare-metal with that... | 02:48 |
| rrq | tuxd3v: .. I'll see if I can repeat your problem.. | 02:51 |
| rrq | tuxd3v: btw wouldn't it also work (the same) with a multiarch setup ? | 02:58 |
| rrq | (though I suppose the multiarch setup wouldn't transcend chroot) | 02:59 |
| rrq | tuxd3v: is that qemu-user-binfmt or binfmt-tools or both? | 03:06 |
| rrq | I meant binfmt-support | 03:07 |
| rrq | yes: I got the issue.. in an i386 VM with chimaera, on chroot into the --foreign debootstrap of arm chimaera | 03:15 |
| rrq | armhf | 03:16 |
| rrq | but it seems to be due to i386 VM .. not the debootstrap | 03:20 |
| rrq | according to strace wrror happens during the pre-exec loading of the arm binary | 03:25 |
| rrq | w=e | 03:26 |
| tuxd3v | onefang, I execute: | 03:58 |
| tuxd3v | /usr/sbin/debootstrap --keyring /usr/share/keyrings/devuan-archive-keyring.gpg --variant=minbase --exclude='systemd,systemd-sysv,dialog,libsystemd0,openssh-server' --include='apt-transport-https,apt-utils,apt-file,ca-certificates,devuan-keyring,sysvinit,sysvinit-core,sysvinit-utils,lsb-release,parted,dbus,alsa-utils,rng-tools,eudev,locales,util-linux-locales,vim-tiny,sudo,openssh-client,mawk,whiptail,device-tree-compiler,u-boot-tools,con | 03:59 |
| tuxd3v | sole-setup' --arch=armhf --foreign --verbose beowulf /tmp/tmp.NrWnortP0L/rootfs http://deb.devuan.org/merged | 03:59 |
| rrq | tuxd3v: .. doesn't happen when running a static binary (/sbin/ldconfig) in the chroot .. something with /lib/arm-linux-gnueabihf/ld-2.31.so .. calling mmap2(0xffff1000,4096,...) | 03:59 |
| tuxd3v | its only on i686 Chimaera that the problem hapen.. | 04:01 |
| tuxd3v | in i686 beowulf, no problem | 04:01 |
| tuxd3v | in amd64 beowulf/Chimaera no problem | 04:02 |
| tuxd3v | I suspect of qemu-user-static.. | 04:02 |
| tuxd3v | this is the ooutput of a successful first and second crossdebootstrap stages( made in Chimaera amd64 - creating rootfs for armhf 32bits ): | 04:06 |
| tuxd3v | https://paste.debian.net/hidden/463e4afb/ | 04:06 |
| rrq | mmm stracing suggests it happends during the dynamic loading of the binary (eg /bin/bash) | 04:08 |
| tuxd3v | the "chRoot: Executing '/debootstrap/debootstrap --second-stage'" executes fine on amd64, but in i686 it gives us a 'commpage' failing to allocate memory.. | 04:09 |
| tuxd3v | rrq, many thanks, | 04:12 |
| tuxd3v | it could be dynamic linker related.. | 04:13 |
| tuxd3v | I need to create a first stage, and then by hand jump into the chroot, to execute by hand the second stage and see what hapens.. | 04:13 |
| tuxd3v | Ineed to create a first stage including inside strace:armhf and execute a strace on '/debootstrap/debootstrap --second-stage' :) | 04:26 |
| rrq | I made the i386 multiarch and strace outside of chroot when executing arm binaries | 04:39 |
| tuxd3v | I believe you made it right, the host is the problem, so I would need to do it ouside :) | 04:43 |
| rrq | the string "Allocating guest ..." does come from qemu-arm-static though | 04:51 |
| rrq | apparently originating in its "../../linux-user/elfload.c" source | 04:53 |
| tuxd3v | /usr/bin/qemu-arm-static is the one used for armhf indeed :) | 04:54 |
| rrq | hmm that source has a type cast "(unsigned long)" for a pointer that gets assigned to uint64_t variable(s) | 05:04 |
| rrq | tuxd3v: qemu-arm-static code wants to mmap(0xffff0000,4096,..) ... which is the BIOS ROM address space (for i386) ... does the i386 kernel refuse that? | 05:48 |
| rrq | .. or libc6 maybe ? | 05:49 |
| tuxd3v | probably that is the cause :) | 05:49 |
| rrq | probably: small test program returns 0xffff0000 on amd64 and 0xffffffff on i386 | 06:02 |
| rrq | i.e. success on amd64 and fail on i386 | 06:02 |
| tuxd3v | I believe it could be related with exausting the 32 bits address space.. | 06:05 |
| tuxd3v | qemu loads its own bios, but yes at that address or close to that 0xfffff000 | 06:06 |
| tuxd3v | it also has a software MMU to translate pages via a pointer to the OS.. | 06:07 |
| rrq | might be something new in libc=2.31-11 since it worked with i386/beowulf (=2.28-10) | 06:08 |
| rrq | I need to do something (else) for a few hours but I'll spin up an i386/beowulf later to check my test program... | 06:11 |
| tuxd3v | yeah, in beowulf it works, it could be the glibc, or by some reason I don't have enough address space, I noticed that my host cannot present the entire 4GB Ram | 06:11 |
| tuxd3v | it ends close but I cannot have the 4GB, but it gets better with lpae kernel | 06:11 |
| tuxd3v | without lpae, only ~3.5GB Ram | 06:12 |
| rrq | biab | 06:12 |
| rrq | btw the test program is just the single call: | 06:14 |
| rrq | mmap( (void*) 0xffff0000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,-1,0) | 06:14 |
| rrq | then print the void* return value | 06:14 |
| rrq | that's the failing call of quemu-arm-static | 06:15 |
| rrq | biab | 06:15 |
| tuxd3v | by some reason it cannot map the 4096 bytes there, the linux kernel should had provided an alternative map address space, but it seems that doesn't happen | 06:32 |
| rrq | it looks like qemu-arm-static source has changed between beowulf and chimaera wrt guest-to-host memory mapping (esp commpage) | 09:05 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!