[SOLVED] Qemu 5.0.0 alien build crashes trying to boot Raspbian-Buster as a RPi3
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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()
/tmp/build/tmp-qemu/qemu-5.0.0/tcg/tci.c:597: tcg fatal error
A quick search online doesn't result in anything spectacular; posts as old as 10 years pop up with very non-specific explanations about 'hacky' fixes or patches for old versions.
Has anyone else encountered this, or can direct me to what I should be trying?
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.
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:
...and that's where it sits until I kill the qemu process.
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.
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.
Sorry, no experience with qemu, but wondering why are you not simply installing Slackware ARM on your Raspberry Pi 3 ?
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
