I've managed to set up almost everything in order, and I decided (yet again) to build a completely custom initramfs.
For some reason Linux, the kernel, cannot execute /init on my initramfs, so I extracted the image and tried to chroot into it.
Whatever I pass to chroot as the command I get "no such file or directory" -error.
So I started to dig deeper:
Code: Select all
# strace chroot /home/zucca/initramfstest /bin/bb
execve("/usr/bin/chroot", ["chroot", "/home/zucca/initramfstest", "/bin/bb"], 0x7ffe7011d220 /* 49 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7eff32cb7358) = 0
set_tid_address(0x7eff32cb4d88) = 5383
brk(NULL) = 0x55d0fa79d000
brk(0x55d0fa79f000) = 0x55d0fa79f000
mmap(0x55d0fa79d000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x55d0fa79d000
mprotect(0x7eff32cb3000, 4096, PROT_READ) = 0
mprotect(0x55d0dbf1e000, 4096, PROT_READ) = 0
readlink("/home", 0x7ffee236af40, 1023) = -1 EINVAL (Invalid argument)
readlink("/home/zucca", 0x7ffee236af40, 1023) = -1 EINVAL (Invalid argument)
readlink("/home/zucca/initramfstest", 0x7ffee236af40, 1023) = -1 EINVAL (Invalid argument)
chroot("/home/zucca/initramfstest") = 0
chdir("/") = 0
execve("/bin/bb", ["/bin/bb"], 0x7ffee236b4e8 /* 49 vars */) = -1 ENOENT (No such file or directory)
fcntl(1, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
writev(2, [{iov_base="chroot: ", iov_len=8}, {iov_base=NULL, iov_len=0}], 2chroot: ) = 8
writev(2, [{iov_base="", iov_len=0}, {iov_base="failed to run command \342\200\230/bin/bb"..., iov_len=35}], 2failed to run command ‘/bin/bb’) = 35
writev(2, [{iov_base=": No such file or directory", iov_len=27}, {iov_base=NULL, iov_len=0}], 2: No such file or directory) = 27
writev(2, [{iov_base="", iov_len=0}, {iov_base="\n", iov_len=1}], 2
) = 1
close(1) = 0
close(2) = 0
exit_group(127) = ?
+++ exited with 127 +++Anyway. For the tests I've included every file musl package owns (qfile musl >> filelist). So I should have at least all the musl related dependencies there.
Any pointers?
Yes. My busybox and bash, etc aren't static. This same method has been working on my amd64/glibc/gcc boxes, so suspect llvm and/or musl bring something other to the table which I haven't noticed.



