On 4/12/20 2:48 PM, Rob Landley wrote:
Install debian to a block device to see why initramfs isn't working?
d-i uses a ramdisk so I assume that should be similar to what you are using.
I already downloaded and ran http://landley.net/aboriginal/downloads/binaries/system-image-m68k.tar.gz to make sure laurent's tip of tree qemu-m68k is working, and that booted to a shell prompt fine, but that's using a static initramfs instead of an external once, which is why I thought that was the issue. (It used to be back when I first made that work, which was something like 2014.)
Not sure I understand what your particular configuration is but I have never run into issues with an initramfs and the root filesystem in RAM on m68k, native or with qemu.
I also ran my toybox binary under qemu-m68k to smoketest that the compiler was making binaries that ran, but it turns out that I had two problems: 1) I'd run "make defconfig in the wrong directory and toybox switched the shell back off (because it's still in "pending" until I finish it), hence the not finding init. I stuck enough printk(KERN_ERR) into init/initramfs.c to list all the filenames it was extracting and figured that one out. 2) THEN the problem was that gcc is doing something in cd_main so that the "chdir ." at the start of the shell setup (to set $PWD and friends) is segfaulting, but it's a segfault that went away when I got near it with printf() calls, and even write(1, "", 0); right before it made it go away. Given that this code has run on 32 and 64 bit, big and little endian, glibc musl and bionic, and on a target that's both nommu and cares about alignment? Someday I might build gdb for m68k, but until then I should check it next time I upgrade compiler versions. (Or go through disabling every optimization one by one until I find the one that's making the registers go nuts the way sh4 had that https://landley.net/notes-2020.html#29-01-2020 thing.) Rob P.S: For context, I built a musl-cross-make toolchain and symlinked it into toybox, and then used "make root CROSS=m68k LINUX=~/linux" to build a system: git clone https://github.com/landley/musl-cross-make git clone https://github.com/landley/toybox cd musl-cross-make sed -Ei 's/(BINUTILS_VER =).*/\1 2.32/;s/(LINUX_VER =).*/\1 4.19.90/' Makefile ../toybox/scripts/mcm-buildall.sh i686:: m68k:: cd ../toybox ln -s ccc ../musl-cross-make/ccc make root CROSS=i686 LINUX=~/linux make root CROSS=m68k LINUX=~/linux If you (cd root/i686; ./qemu-*.sh) it boots to a shell prompt.... well, if you KARGS=rdinit=/bin/sh it does, running the init script still says: ln: cannot create symbolic link from '/proc/self/fdi/,*/}' to 'dev/i/*,/}': No y ln: cannot create symbolic link from '/proc/self/fdi/,*/}' to 'dev/i/*,/}': No y ln: cannot create symbolic link from '/proc/self/fdi/,*/}' to 'dev/i/*,/}': No y ln: cannot create symbolic link from '/proc/self/fdi/,*/}' to 'dev/i/*,/}': No y sh: exec /etc/rc/*: No such file or directory Type exit when done. oneit: /dev/CONSOLE:-console}: No such file or directory Because I'm still halfway through teaching toysh about all the ${} constructs. (Also, remind me to stick echo -e '\e[?7h' at the start of my init script to undo the STUPID wordwrap disable escape that qemu's bios outputs, which screws up bash's command line history too!) Anyway, at least it's known behavior. But in root/m68k I'm getting: Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b CPU: 0 PID: 1 Comm: init Not tainted 5.6.0 #1 Stack from 0f81bdfc:
So, do I understand correctly that this is buildroot with musl? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@xxxxxxxxxx `. `' Freie Universitaet Berlin - glaubitz@xxxxxxxxxxxxxxxxxxx `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
