General TC > Tiny Core on Virtual Machines
Setting up Qemu
nick65go:
New tests were done in win10 with qemu 5.1, with an EMPTY ext2 [raw image] abc.img 10 MB, and vmlinuz + core.gz from TC13.
case1: in abc.img there is NOT a /tce folder;
A: qemu without -append tce=sda" will not mount /mnt/sda
B: qemu with -append tce=sda" will mount /mnt/sda AND will populate it with folders /tce/optional /tce/ondemand and file tce/onboot.lst. OK!
case2: in abc.img WITH an empty /tce folder;
A: qemu without -append tce=sda/tce" will mount /mnt/sda. OK!
Summary: (/tce inside abc.img) OR "qemu -append tce=/sda" to mount /dev/sda and to see /mnt/sda/tce
case3: in abc.img WITHOUT a /tce folder;
--- Code: ---qemu-system-i386.exe -m 128M -kernel vmlinuz -initrd core.gz \
-drive file=abc.img,if=virtio,media=disk
--- End code ---
A: qemu without -append tce=..." will not mount /mnt/vda, same as case 1.A
B: qemu with -append tce=vda" will NOT mount /mnt/vda. !?
C. case 3.B plus "-append waitusb=3". Finaly /dev/vda is mounted, and I am like in case 1.B, with new auto-created folders /tce/optional /tce/ondemand and file tce/onboot.lst
Summary: for virtio, "qemu -append tce=vda waitusb=3", it does not matter with/wihout folder /tce inside abc.img, to mount /dev/vda and to see /mnt/vda/tce.
Rich, thank you! You highlighted two main things (I missed waitusb=):
1. tce= must be on -append line, to auto-create folder "/tce" IF it did not existed.
2. waitusb=3 must be on -append line, to wait for virtio disk to show-up
PS: it is a race condition in qemu, the kvm emulation for a very fast CPU (running tc-config) versus the slow read of the abc.img from the host disk.
curaga:
Oh, a slow disk, wouldn't have expected that when SATA disks don't need the wait. Use the label/uuid additions to waitusb to have a fast boot.
nick65go:
@curaga: Thanks!
in win10 I have both a fast CPU (Intel i5-8350U), and a fast SSD (solid state disk). But unfortunately NO acceleration (I am not admin, and no acceleration drivers can be installed); qemu using tcg translator x86 qemu-cpu into x86_64 real-CPU, so is still faster than I/O reading a file from SSD disk.
In linux I have a slow CPU (AMD APU A6-6300) but KVM acceleration; CPU is still faster than I/O reading a file from rotational SATA disk.
For files from TC13, waitusb=3 was enough; but for files from TC14 I need waitusb=5+.
So, yes, unbelievable, I did not expected these in qemu inner logic, and I did not used waitusb=; my mistake, sorry.
Rich:
Hi nick65go
Use this for fastest response:
--- Code: ---tc@box:~/Qemu$ blkid -s UUID diskfile.img
diskfile.img: UUID="f0fb31eb-8b59-4091-a381-93bf508a83e7"
tc@box:~/Qemu$
tc@box:~/Qemu$ qemu-system-i386 -enable-kvm -m 1G -kernel vmlinuz -initrd core.gz -append "quiet waitusb=20:UUID=f0fb31eb-8b59-4091-a381-93bf508a83e7" -drive file=diskfile.img,if=virtio,media=disk,format=raw
--- End code ---
tc-config checks for the presence of that UUID 4 times per second and continues as soon as it finds it.
nick65go:
@Rich: Thanks! Because I could change any /both of LABEL or UUID, then:
1. Which is faster: waitusb=seconds:LABEL=TCVM or waitusb=seconds:UUID=12345678-aaaa-bbbb-cccc-12346789012 ?
2. What difference / reduction (in seconds) should we expect? from your experience: like [0.5 ... 1.0] seconds? or less than 2 seconds?
3. Could I use a short and personalized UUID,, like UUID=1234 ? Or is any mandatory template-format with 32 characters?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version