Re: Building without network devices
Talha, > On Dec 5, 2023, at 07:31, Talha Khan wrote: > > Hello all, > I want to build an instance of qemu(x86-64) without any network devices in > the emulator (no nic,no netdev or anything). Im new to all these, any help > and leads would be usefull. If you are planning to start the qemu instance from the qemu command line, just don't include these options. It sounds like maybe you were going to start it in some other way that was already including these options? HTH, --FC > Yours Talha
Re: VFS: Unable to mount root fs on unknown-block(0,0)
> On Nov 30, 2023, at 05:08, 泰宇周 wrote: > > Hi Peter > Thanks you so much. > I tried to specify corresponding initramfs to QEMU as following > qemu-system-x86_64 \ >-kernel /boot/vmlinuz-`uname -r` \ > -m 4G \ > -initrd /boot/initramfs-`uname -r`.img \ >-sda centos79.img \ >-append "root=/dev/sda console=ttyS0" \ >-enable-kvm -nographic > > It worked for me to boot the kernel. > However, I still can’t enter the system. > Qemu reported following information > > > [ OK ] Reached target System Initialization. > Starting dracut initqueue hook... > Starting Show Plymouth Boot Screen... > [ OK ] Started Show Plymouth Boot Screen. > [ OK ] Reached target Paths. > [ OK ] Reached target Basic System. > [ 181.930451] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 182.449479] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 182.968450] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 183.487482] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 184.006435] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 184.525464] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 185.04] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 185.563430] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 186.082448] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 186.601681] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 187.120630] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 187.639579] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 188.158458] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 188.677459] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 189.196840] dracut-initqueue[284]: Warning: dracut-initqueue timeout - > starting timeout scripts > [ 189.197064] dracut-initqueue[284]: Warning: Could not boot. > [ 189.279572] dracut-initqueue[284]: Warning: /dev/sda does not exist > Starting Dracut Emergency Shell... > Warning: /dev/sda does not exist > > Generating "/run/initramfs/rdsosreport.txt" > > > Entering emergency mode. Exit the shell to continue. > Type "journalctl" to view system logs. > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or > /boot > after mounting them and attach it to a bug report. > > > dracut:/# ls > bin dracut-state.sh init lib64 root sbin systmp var > dev etc lib proc run shutdown sysroot usr > dracut:/# ls dev/ > autofs mcelogstdout tty2 tty32 tty45 tty58 udmabuf > char mem tty tty20 tty33 tty46 tty59 urandom > console null tty0tty21 tty34 tty47 tty6 usbmon0 > core nvram tty1tty22 tty35 tty48 tty60 vcs > cpu port tty10 tty23 tty36 tty49 tty61 vcs1 > cpu_dma_latency ptmx tty11 tty24 tty37 tty5 tty62 vcsa > dma_heap pts tty12 tty25 tty38 tty50 tty63 vcsa1 > fd randomtty13 tty26 tty39 tty51 tty7 vcsu > full rtc tty14 tty27 tty4 tty52 tty8 vcsu1 > hpet rtc0 tty15 tty28 tty40 tty53 tty9 vga_arbiter > hwrng shm tty16 tty29 tty41 tty54 ttyS0 zero > input snapshot tty17 tty3 tty42 tty55 ttyS1 > kmsg stderrtty18 tty30 tty43 tty56 ttyS2 > log stdin tty19 tty31 tty44 tty57 ttyS3 > > I can't find the sda or hda in the /dev directory inside qemu. > > What should I do to fix this problem? You'll need to edit the initramfs and mknod the device you need. From a quick look at one of my systems with a sda it's major 8 minor 0. I don't believe I've used dracut, which is what you appear to be using to build your initramfs, so I can't tell you what you need to do to modify the creation of the initramfs. You'll want to look for where you can add the mknod, likely you'll find a directory where you can add scripts to run at certain times during the creation of the image. HTH --FC > > Sincerely!
Re: qemu modifies host audio sample rate with coreaudio backend to 44.1khz on startup
Greetings all, Thank you Thomas for bringing this to the attention of folks who are in the know. Thank you, Christian for explaining. What I am finding is that qemu sets the host to 44.1k even though alsa dmix in the guest is set to 48k. What I wanted was to set the host to 96k and the guest to 96k. When I do that, by using audio midi setup for the host, and changing alsa dmix rate to 96k, after starting the guest, audio midi setup shows that the host is set to 44.1k. When using the parameter Thomas mentioned, the host sample rate is changed to the designated. Seems like alsa has a problem. I'll use Thomas's suggestion as a workaround, for now. Thank you, --FC > On Mar 24, 2023, at 08:04, Christian Schoenebeck > wrote: > > On Friday, March 24, 2023 8:54:35 AM CET Thomas Huth wrote: >> On 23/03/2023 21.03, Frank Carmickle wrote: >>> Greetings all, >>> >>> Every time a qemu instance is run, the host systems audio hardware sample >>> rate is set to 44.1khz. Is it possible to change this behavior, and if so, >>> how? >> >> Hi, >> >> not sure if I've got the question right, and I'm not an expert when it comes >> to QEMU audio, but I think you can set the playback frequency like this for >> example: >> >> qemu-system-x86_64 --audiodev alsa,id=a1,out.frequency=48000 >> >> ... but seems like the QEMU documentation is really lacking here, so I might >> be wrong. Maybe Christian, Gerd or Marc-André could correct me in that case >> (now on CC:). > > By default host's audio backend is opened with audio parameters requested by > guest. So if guest requests 44.1 kHz then host's audio system is opened with > 44.1 kHz as well (if supported by host's audio system that is). > > By supplying out.frequency=x you can override host's sample rate, but as guest > apparently requested 44.1 kHz before, guest would probably still use 44.1 kHz > and QEMU would resample the audio stream to the requested host's sample rate. > > So the question is what you really want to achieve. Maybe it would be better > to force guest using the desired sample rate instead. > > Best regards, > Christian Schoenebeck > >
qemu modifies host audio sample rate with coreaudio backend to 44.1khz on startup
Greetings all, Every time a qemu instance is run, the host systems audio hardware sample rate is set to 44.1khz. Is it possible to change this behavior, and if so, how? Thank you, --FC
audio performance running Linux arm64 on Macos arm64
Greetings Qemu users, I've been fighting with audio support for a Linux guest on Macos. I am currently using the UTM wrapper, which I see has forked Qemu, so apologies if I need to run mainline Qemu to provide the right feedback to the mailing list. I'd like to run the Debian kernel, if possible. The only audio drivers that UTM has that are also in the Debian kernel are ich6 and ich9, hda_intel. After some time the audio stops playing and usually the following is found in kmsg. snd_hda_intel :00:02.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. I've played with setting different module parameters. Currently I have options snd-hda-intel enable_msi=1 bdl_pos_adj=8,8 \ position_fix=2 \ align_buffer_size=0 \ beep_mode=1 power_save=0 With those settings, I seem to not loose the audio, but the latency is so high that it's difficult to use the system. I need the latency to be low, as I am using a screen reader in the virtual machine. Can anyone make some recommendations on module parameters or qemu options to use to get stable low latency audio from a arm64 Linux virt on an arm64 Macos system? Thanks so very much for any help. --FC
