Setting up Qemu

[nick65go]

@Rich, I found the answer myself, by try and error:
from tc I see: /dev/vda: LABEL="QCOW2" UUID="69b2bd7f-5108-43b9-94d8-da4800b53851" BLOCK_SIZE="1024" TYPE="ext2"

case 1: waitusb=10:LABEL=QCOW2 => countdown stop at 7, so it starts in 3 seconds

case 2: waitusb=10:UUID=69b2bd7f-5108-43b9-94d8-da4800b53851 => countdown stop at 7, so it starts in 3 seconds

if all upercase UUID (as I see in 7zip) it still successfully finished, but:
case3 : waitusb=10:UUID=69B2BD7F-5108-43B9-94D8-DA4800B53851, countdown stop at zero.
so blkid UUID is case sensitive, prone to error if manually input; so LABEL= will be.

So it is the same speed 3 seconds (before staring to load tcz), as with simple  waitusb=3; Maybe qemu has a bug.

[Rich]

Hi nick65go

... so blkid UUID is case sensitive, prone to error if manually input; so LABEL= will be. ...

That's why I ran  blkid  on the image file directly and then copy/pasted the result.

... So it is the same speed 3 seconds (before staring to load tcz), as with simple  waitusb=3; Maybe qemu has a bug.

Or it could have been 2.25 seconds. tc-config uses integer math to compute the
countdown you see and the result displayed can be off by about 1 second.
There is no downside to using  waitusb=seconds:LABEL=TCVM  and setting  seconds
to a large number like 30.

[mocore]

idk how relevant this might be  , just ftr 

I concatenated rootfs.gz + modules.gz into MyCore,gz (because I can not have multiple -initrd parameters in qemu  ).

https://bugs.launchpad.net/qemu/+bug/393569/comments/6

Looking through old bug tickets... If I've got that right, there is multiboot support in QEMU nowadays, and we also have the possibility to load multiple files with the "loader" device ... is that enough, or is still something to be done here?

digging around abit i  an  example using "-device loader"
 
https://support.xilinx.com/s/question/0D54U00005VTWwTSAX/using-an-initramfs-with-qemu-does-not-run-uboot-is-this-intentional-also-what-is-linuxbootelf?language=en_US

as yet untested 

[nick65go]

@mocore: thanks!, when/if/after you tested it could you please copy/paste here the full command line
in the mean time I will waste my hdd space with concatenation (in 3 seconds).
PS: I am interested also in qemu 3.0 test (it has less dependencies) as it does a nice (& sufficient for me) job for small virtual-I/O kernel devices.

[aus9]

Hi

Are any of you guys running qemu on host RPi piCore64 14.x?

[nick65go]

regarding https://forum.tinycorelinux.net/index.php/topic,27274.0.html as "boot multi initrd (on qemu)" by @mocore

Following below is some old info, but not touched until now on this subject of using a "root image" as an init-tmpfs.
https://virtio-fs.gitlab.io/howto-boot.html about How to boot from virtiofs
and https://virtio-fs.gitlab.io/howto-qemu.html

It seams that we could boot a VM (virtual machine) with a qemu, even without a root+modules grouped in a core.gz the files from core.gz could stay in a folder of the host

Code: [Select]

Start the virtiofs daemon:
# virtiofsd --socket-path=/tmp/vhostqemu -o source=virtio-fs-root -o cache=none

The following QEMU options are required:
The path to the guest kernel:
    -kernel path/to/bzImage
 Guest kernel parameters:
 -append "rootfstype=virtiofs root=myfs rw"FYI: I "discovered" this info reading documentation about "Docker Desktop for Linux" (which runs in a VM and use VirttioFS),
but normal Docker version (without VM, just kernel name-space, etc) can coexist installed in parallel, as server and client, if you like CLI commands only.