Qemu 5.0.0 alien build crashes trying to boot Raspbian-Buster as a RPi3
Hi all,
As the subject suggests, I am trying to use Alien's slackbuild script to build & install Qemu 5.0.0 on my slackware-sorta-current machine (I painstakingly updated only what I needed to build qemu instead of doing a complete update to -current because of reasons involving not risking breaking some existing things on this machine; I know this may be dumb and possibly part of my issue). Qemu builds and installs fine. My problem is trying to run it to emulate a Raspberry Pi 3 to run Raspbian (or rather RaspberryOS) Buster to do some setup on it before running it on an actual RPi3. I've tried various instructions I've found online about how to accomplish this but most (all) fail at some point. In my most 'successful' attempts it seems like it begins to boot but then qemu itself aborts with this error: Code:
TODO /tmp/build/tmp-qemu/qemu-5.0.0/tcg/tci.c:597: tcg_qemu_tb_exec() Has anyone else encountered this, or can direct me to what I should be trying? Thanks! |
With Raspbian, you'll have a debian 32 bit soft float OS running on a 64bit A-53 Cortex Arm capable of running hard float operations.
Personally, I would give up. There is no easier OS to set up on a RazPi. Skip emulating. Just dd the image accross. Raspbian, btw is no longer, it's Raspberry Pi OS now. Just dd the image to an sd card, extend the second partition to full size, and boot it. It will bring you into Raspberrypi-config. Set things up there (network, password, video, package update), reboot, and you're done. OTOH, dd'ing an image to 2 partitions is a nightmare. |
So how then do these tutorials that I've been following seem to get it working?
Giving up on getting qemu to work significantly increases my workload by having to do it on physical hardware. I'm not looking for performance here; I just need to get in so I can do some updates and customization before deploying it to several (headless) Pi's. |
If the tutorials you're following seem to get it working, why not post the tutorial, along with your results, highlighting the point where things go off the rails?
To use qemu. You are faced with getting an unbootable binary image to boot, which is a powerful reason imho not to virtualize it.Booting a Pi is an awkward business. The images write 2 partitions (1 FAT, 1 ext4) and provide an fdisk type partition table overwriting any existing table. The boot process loads firmwares, sets up video and a ram/video ram split. You can't use grub or lilo. But knock yourself out. |
Okay, so I decided to review what I've been doing, try a few different things, and come back with details as suggested.
The short story is I've come across a handful of tutorials and forum posts online to help guide me. I've tried them all verbatim and I've tried variations of them to try and get something that at least starts to work. My apologies if it's against board rules to post links to other forums (stackexchange). https://azeria-labs.com/emulate-raspberry-pi-with-qemu/ https://blog.agchapman.com/using-qem...-raspberry-pi/ https://github.com/dhruvvyas90/qemu-rpi-kernel https://raspberrypi.stackexchange.co...u-kernel-panic https://raspberrypi.stackexchange.co...ster-with-qemu https://github.com/wimvanderbauwhede...y-Pi-3-on-QEMU I've extracted the kernel and dtb files from the Raspbian-Buster image, as was described in a few of the above-mentioned posts. I extracted kernel8.img and bcm2710-rpi-3-b.dtb; I could not find an initrd.img as suggested in the last link, nor did I extract cmdline.txt. I also modified the fstab file to ensure that 'sda2' is used for root instead of the default. The only other entry is for proc. References to the /boot partition have been commented-out since we are providing the kernel and dtb files to Qemu. The command I've pieced together that I've had the most success with is: Code:
qemu-system-aarch64 Qemu actually starts booting, and produces the following output: Code:
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] I should point out that the image file I'm providing Qemu is modified from the original downloaded from raspberrypi.org; I blow it up to 32GB, resize the 2nd partition and add a few other partitions. I hope that helps clarify my problem a bit. It seems like I'm on the right track but I'm missing something. TBH I can't recreate the problem I encountered in my original post; I've tinkered with it a bunch since then. I'd really appreciate any direction anyone might be able to provide to help me figure this out once and for all. Thanks! |
Quote:
|
So after much testing and searching, I've come up with a solution to this problem.
I'll document it here in the event that anyone else encounters this problem. There are a few things that resulted in success: - Building Qemu with the --disable-tcg-interpreter flag; Alien's slackbuild script uses the --enable-tcg-interpreter flag (approx line 341 of qemu.SlackBuild script) so this needs to be changed manually. Otherwise you will eventually encounter the 'tcg fatal error' mentioned in my original post. - Changing /etc/fstab entries for /boot and / to /dev/mmcblk0p1 and /dev/mmcblk0p2, respectively. This is instead of using /dev/sda1 & /dev/sda2, respectively as mentioned in some of the tutorials I posted in a previous post. Also do not use PARTUUID entries. - Changing root=/dev/mmcblk0p2 in the 'append' line for Qemu itself (see complete command below) - Note that Raspbian/RaspberrryPiOS's cmdline.txt in /boot provides the initial kernel 'append' used when booting the OS for the first time. It explicitly calls a script (/usr/lib/raspi-config/init_resize.sh) using an init= argument that does some checks and resizes the root filesystem to the available size of the disk/SD card it is installed on. The script also removes itself from the /boot/cmdline.txt file after it has (successfully) run so that it doesn't try and resize the root partition again every time you power on your Pi. I, however, made additional partitions on my image to my own custom specifications, and upon running init_resize.sh the script started complaining about unsupported partitions, so I tried booting without the script and it booted just fine. I would probably omit this from Qemu's append line. If run under Qemu, and if successful, it will remove it's invocation from cmdline.txt. As a result, once you flash the image to an SD card and run it on an actual Pi, this script won't be run and won't resize it's root partition to the available size of your SD card. - Also note that I had previously mounted the image locally and extracted both the kernel and dtb files from /boot and passed them to Qemu. - Somewhere along my travels I found a post suggesting to comment-out everything in /usr/lib/ld.so.preload, but doing that is what ultimately lead to the 'tcg fatal error' from my original post. I left it un-commented and after rebuilding Qemu with the tcg interpreter disabled, everything ran fine. My final Qemu command is: Code:
qemu-system-aarch64 \ Code:
/dev/mmcblk0p1 /boot vfat defaults 0 2 |
All times are GMT -5. The time now is 07:09 PM. |