problems getting tiny core 2.7 to mount virtual drive on boot with qemu.

General TC > Tiny Core on Virtual Machines

<< < (3/4) > >>

roberts:
Ok. These are then mapped to typical block major drive numbers which then because of the fdisk test fail. Otherwise we end up with bogus mountable for most, non-qemu users.

maro:
@Robert, I meant to also give you these details here:
--- Code: ---tc@box:~$ find /sys/block/*/ -name dev | grep -Ev '\/(ram|loop)[0-9][0-9]*\/' \
> | xargs head | grep .
==> /sys/block/hda/dev <==
3:0
==> /sys/block/hdb/dev <==
3:64
==> /sys/block/hdb/hdb1/dev <==
3:65
==> /sys/block/hdc/dev <==
22:0

--- End code ---
I guess that is what you are expecting ...

roberts:
Thanks for supplying the details to which I have no access.
I will stand with the requirement of needing at least one partition.

quokka:
Many thanks to everyone for their input on this one...particularly Maro...I haven't yet had time to put the suggested fix into practice yet....but see sufficient evidence to expect the best... :):):)

P.S ok I tested it now....the suggested fix works...i have also found that imdisk Virtual Disk Driver can be used on a windows host to acess partitions on virtual drives...so i will use that setup.....

bigpcman:

--- Quote from: maro on January 12, 2010, 04:00:55 PM ---Well, I believe to know what the problem might be. Following my hunch about the potentially different treatment of a whole disk vs. a partition inside a disk image I set up this little experiment here (the host being a Windows XP system):

(1) I've created two new disk images (of 35 MBytes each), with:
--- Code: ---X:\> qemu-0.10.6\qemu-img.exe create d1_35M.img 35M
Formatting 'd1_35M.img', fmt=raw, size=35840 kB

X:\> qemu-0.10.6\qemu-img.exe create d2_35M.img 35M
Formatting 'd2_35M.img', fmt=raw, size=35840 kB

--- End code ---

(2) I've started a QEMU VM with TC 2.7 (and those two new disk images), with:
--- Code: ---X:\> qemu-0.10.6\qemu -L qemu-0.10.6 -kernel-kqemu -boot d -cdrom tinycore_2.7.iso -hda d1_35M.img -hdb d2_35M.img

--- End code ---

(3) Inside this VM I created an "EXT3 disk" (without a partition table) on the first disk (i.e. /dev/hda). The second disk (i.e. /dev/hdb) was created containing just one primary EXT3 partition (i.e. /dev/hdb1). Here are the steps I used:
--- Code: ---# ensure that a vital extension is installed
which sfdisk > /dev/null || tce-load -wi sfdisk.tcz

# ensure that CD-ROM and hard disks are not mounted & mount points do not exist
sudo umount /dev/hdc 2> /dev/null
sudo umount /dev/hda 2> /dev/null
sudo umount /dev/hdb1 2> /dev/null
sudo rm -rf /mnt/hda
sudo rm -rf /mnt/hdb1

# create 1. disk: EXT3 for the whole disk
# wipe hard disk, and create file system
sudo dd if=/dev/zero of=/dev/hda
yes | sudo mkfs.ext3 /dev/hda

# create 2. disk: EXT3 for a single, primary partition
# wipe hard disk, create partition, and create file system
sudo dd if=/dev/zero of=/dev/hdb
echo '63,,,*' | sudo sfdisk -uS /dev/hdb
sudo mkfs.ext3 /dev/hdb1

# mount the two new disks
sudo mkdir /mnt/hda
sudo mkdir /mnt/hdb1
sudo mount -t ext3 /dev/hda /mnt/hda
sudo mount -t ext3 /dev/hdb1 /mnt/hdb1

# copy Xorg extension (and all dependencies) onto both disks
sudo mkdir -p /mnt/hda/tce
sudo mkdir -p /mnt/hdb1/tce
sudo chown tc:staff /mnt/hda/tce
sudo chown tc:staff /mnt/hdb1/tce
tce-load -w Xorg-7.4.tcz 2> /dev/null
cp -p $(cat /opt/.tce_dir)/optional/* /mnt/hda/tce
cp -p $(cat /opt/.tce_dir)/optional/* /mnt/hdb1/tce

--- End code ---
Note that the creation of an EXT3 file system on an entire disk requires confirmation to do so (done via 'yes | ').

(4) I then went on to re-boot the VM (using the same command as in (2), with the following result: Xorg (being present on each of the two disks in the respective '/tce' directories) was automatically started. As I was expecting, only /dev/hdb1 got mounted (resulting in the auto-detection and execution of the Xorg extension) whilst /dev/hda was completly ignored. Obviously these observations were reflected in the following entries (or lack thereof) in the /etc/fstab file:
/dev/hdb1 /mnt/hdb1 ext3 noauto,users,exec,relatime 0 0 # Added by TC
/dev/hdc /mnt/hdc auto noauto,users,exec 0 0 # Added by TC
and in the content of the /opt/.tce_dir file, being: /mnt/hdb1/tce

Analysis As part of this experiment I've done the same on a VirtualBox VM, and had the identical result (after adding the VBox-OSE-additions.tcz extension to the /tce directory of the disks of the VB VM). So your disk recognition problem is independent of the VM in use. As a further test I used TC 1.4.3 for comparison, which lead to a different result with regards to disk recognition:
/dev/hda /mnt/hda ext3 noauto,users,exec,relatime 0 0 # Added by TC
/dev/hdb /mnt/hdb auto noauto,users,exec 0 0 # Added by TC
/dev/hdb1 /mnt/hdb1 ext3 noauto,users,exec,relatime 0 0 # Added by TC
/dev/hdc /mnt/hdc iso9660 noauto,users,exec 0 0 # Added by TC
and now the content of the /opt/.tce_dir file showing: /mnt/hda/tce (The fact that Xorg did not start can be put down to the fact that TC 1.X does not "know" how to deal with SquashFS TCZ extensions created for TC 2.x)

Suggested fix: Convert your disk images from "whole disk" to "partitioned" and you should be fine for TC 2.x. The steps in (3) should give you a clue how a new disk image can be set up. Please note that 63 sectors/track (as used for the sfdisk command) works for disk images up to a certain size. IIRC for images larger than ca. 30 GBytes one should use a large value (e.g. 255).

[Edited: minor corrections and updates, and a few more ...]

--- End quote ---

I was hoping creating an ext3 partition "hda1" for ...tce/optional would solve the problems with Xvesa on "fully accelerated" qemu for windows xp but it doesn't as near as I can tell. It works great for Xorg-7.4.

Here's my qemu start cmd:

--- Code: ---qemu.exe -L . -no-acpi -kernel-kqemu -kernel bzImage -initrd microcore.gz -append "quiet max_loop=255 pause noswap tce=hda1 showapps debug" -hda tc.img
--- End code ---

I just tried it out on mc v2.9vrc2 using qemu.0.11.1 with kqemu-1.4.0pre1. The Xvesa general protection fault still occurs. I loaded all the mc files in /mnt/hda1/tce.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version