Cross-compiling qemu for aarch64 failed, damaged system

[nameiwillforget]

The script I've been using to chroot is a modified form of that on the wiki:

[pingtoo]

nameiwillforget,

Yes, this is what I was looking for, thank you very much.

small critique about the chroot script. you should use "rbind" instead "bind" for dev and sys because there are sub-mount in those file system that should be carry over to chroot environment. when unmounting at the end use umount -R option to recursive down to sub-mounts.

Since the ldd python given me expected result. I am not sure about those "command not found" error any more.

So in your chroot environment, please verify you have PATH setup correctly And once you verified please test if the system search executable is functional for example if you do "type ldconfig" does it return something meaningful?

I think it may take sometime to understand what is going on. I hope you have time for debugging this.

[nameiwillforget]

So the internal PATH is set to

[pingtoo]

nameiwillforget,

I feel I lost focus (or at least got idea wrong) on what to do. I think it may have to do with the whole thing was going for long time with different issues so I went to wrong direction and forgot about the original goal.

So let's get in sync on what to target

I go back to the first post of this thread and found that you start of by trying to setup QEMU for arm (the 32bits) and doing crossdev together, this is OK. but I think I got confused because the crossdev side create issues that reference to ARM64 (aarch64) so I went focus on the building process as opposite to getting system setup.

Can you help me get back to focus on what is current state?

• Do you have QEMU support for ARM64(aarch64) build ready?
  
• Do you just want a ARM(32bits) environment?
  
• I just want to be sure, your chroot environment is /usr/aarch64-unknown-linux-gnu right?
  
• What is your chroot environment current portage profile? is it point to embedded?
  
• What is your final target profile for your target system?
  
• Did you modified /usr/aarch64-unknown-linux-gnu/etc/ld.so.conf or ld.so.conf.d/*
  
• Finally what is your goal of do this?
  • Are you trying to learn the process?
  • Are you want to have distcc helper for your target system?
  • something else?
  • all of above?

[nameiwillforget]

Pingtoo,

Yes, I think so. I have an aarch64 system for my Raspberry Pi on an SD card and can chroot into that system and use portage there and everything works.

No, I don't want an ARM environment.

Yes, this is the location of the aarch64-system I'm trying to build.

I haven't set the profile within the environment yet as it wasn't in the wiki instructions. If I'm asking for a profile, I get an error:

[pingtoo]

[nameiwillforget]

pingtoo,

yes, that sounds good. But you'll have to guide me through that because I don't really know what to do.

[pingtoo]

[pingtoo]

nameiwillforget,

I hope this still in time for you to use. If you already got something working, then this is just for your information.

* * *
Please note this is not complete tested. especially those at bottom that did cross compiler build stuff in to chroot.
* * *

[nameiwillforget]

Pingtoo,

Thanks, I'll try it out soon, maybe tomorrow!

[nameiwillforget]

Pingtoo,

Sorry I only got to trying it out now, but thanks so much for putting that together, it seems to work for the most part! And I think I understand for the most part what is going on, but I have some questions:

1. So as I understand it, we've made a chroot-directory where we basically installed an aarch64-system that I can chroot into, but when I build packages in the chroot, I'm doing that using QEMU, which has a performance impact compared to cross-compiling. So in the last section, we're using the cross-compile-environment I've set up to cross-compile from outside the chroot to the system we've set up. So if I build packages from the outside, it's faster. Right?

2. When I started emerging packages in the chroot, I got the error message

[pingtoo]

nameiwillforget,

Such long time passed, I am not entirely sure my original idea

But from reading my posted script, I think the idea is use crossdev most of time, only when some packages that have build problem due to require rpi native binary as part of build process than you need to switch into chroot and build the package.

My posted script propose use TWO environments, One is /usr/aarch64-unknown-linux-gnu (this is the crossdev setup), Second one is /chroot (or whatever location you choose).

In my script I have copy the qemu-aarch64 into chroot, this should allow execute rpi native binary in the chroot environment. Assume you have the binfmt setup correctly.

[nameiwillforget]

I've compiled some more by now, and so far, it seems to work. But I have another question and an issue. The issue first, as it is somewhat concerning: I have had it two times now that my host system suddenly told me that I hadn't started the system using systemd and thus it couldn't shutdown or suspend. Each time (somewhat stupidly the second time) I tried changing to another TTY to see if the problem would persist, and was greeted by a black screen and an unresponsive computer. Of course, I have booted completely normally, and when I try using systemd-functions after booting, they work. My explanation would have been that somehow setting the system root as in your emerge command would have confused the system, but I tried using a systemd-command while setting both ROOT and SYSROOT to / and still got the same error. After the second time rebooting I also tried both to chroot into the /chroot environment and to emerge a package from the outside using the script I prepared for outside emerging:

[pingtoo]

[Phoenix591]