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

[quokka]

I use tiny core quite a bit as a guest on a windows box via the use of qemu/kqemu.

When I changed from tiny core 1 to tinycore 2.4 I had difficulties getting xvesa to load properly. To get around this I had to load Xorg-7.4.tczl from a folder on a virtual drive (hda/tce) on boot ( http://forum.tinycorelinux.net/index.php?topic=1776.0 ).

Now I have changed from 2.4 to 2.7 and have noticed that my virtual drives are not mounted on boot. Consequently, Xorg-7.4 tczl is not loaded and I can't get to the desktop. I can get around this by typing at the prompt (which appears when x fails to load on boot):

sudo mkdir /mnt/hda
sudo mount /dev/hda /mnt/hda
tce-load -i /mnt/hda/tce/Xorg-7.4.tczl
startx


...but this is a hassle and other useful stuff in mydata.tgz is not loaded on boot either.


This is the batch file that I use to start my tiny core vm if that may be of any help:

net start kqemu

START ./qemu/qemu -L ./qemu -vga cirrus -kernel-kqemu -no-acpi -m 512 -boot d -cdrom ./tinycore_2.7.iso -hda ./vdisk1.img -hdb ./vdisk2.img -hdd h:/TINYCORE_NTFS/vdisk3.img

Hopefully someone out there can help solve this problem. I'm a bit of a linux noob....but slowly getting there.
Thanks!

[maro]

1. QEMU has gone through some changes from version to version, so to help you it's important to know which version of QEMU you're using under which version of Windows (some of the options you use indicate to me that you might be still using a rather old version).

2. Xvesa works fine for me since several QEMU versions (e.g. just did a quick test with an "ancient" v0.9.1). Please note that I'm not using "-vga cirrus". On a related thought: do you have any other reason (e.g. another TC application) that needs Xorg? What is the screen resolution of your host, and what screen resulution do you want to run your guest under?

3. What's the reason to use "-no-acpi"? I don't need it for my use of QEMU.

My hunch is that some of those options are maybe a requirement to operate Windows guests under QEMU, but might not be actually that helpful for running a TC guest.

Your mounting problems need some further troubleshooting, but to start it off I note that you want to mount /dev/hda (the whole disk) instead of a partition (e.g. /dev/hda1). I'm not (yet) sure whether that makes a difference in the automatic detection of the "tce" directory, but in any case it would be good if you could post your '/etc/fstab' file content here. BTW, please let us know what you use the three different (virtual) hard disks for.

Finally, I'd recommend to use at least v0.11.0 of QEMU and wonder what happens when you'd use a simplyfied version of your command like:
START ./qemu/qemu -m 512 -boot d -cdrom tinycore_2.7.iso -hda vdisk1.img -hdb vdisk2.img -hdd h:/TINYCORE_NTFS/vdisk3.img

As another rather personal note: Even though I still follow what's happening with QEMU relatively closely, I've changed to VirtualBox as my primary VM application. I still keep several versions of QEMU around and still use it regularly for certain tests. It's much easier to create a VM on-the-fly e.g. if I want to see as a one-off how TC behaves with four CD-ROM drives. Just a thought ...

[quokka]

Im using a binary of qemu 0.10.6 ( http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5147 ) with kqemu version 1.4.0pre1 on an XP host.

I'm not so fussy about screen resolution on my host or guest. With my tiny core 2.4 setup I have 1280x1024 on the host and 1024x768 on the guest.

The problems with xvesa (and the requirements for -no-acpi and -vga cirrus in the batch and subsequently the Xorg-7.4.tczl extension) only occur when i use the -kernel-kqemu option in my batch file to speed things up. Without it things work fine.

Upon being returned to the prompt after the desktop fails to load with tinycore 2.7 the /etc/fstab contains /dev/hdc and /mnt/hdc (which contains the tiny core os) but not /dev/hda,b, or d or /mnt/hda/,b, or d.

Yes ..its a little strange that i have no partitions on my drives. I use a completely portable program called vdk32 to mount and access my drives from windows...but have had trouble accessing individual partitions with it...hence this workaround.

I use various virtual drives for either essential files or trouble shooting and i also have a large virtual drive on an NTFS partition as fat32 cannot accomodate large files that i often need to work with.

Hope thats enough info to help sort this out.

Thanks.

[roberts]

I don't use Qemu, so I may be off here but, where is the -append section to tell Tiny Core about the virtual disk? Perhaps it is not possible with -cdrom option and only supported with the -kernel option?

[maro]

@roberts: As alternative to the QEMU options -boot d -cdrom tinycore_2.7.iso one could extract the kernel and the initrd from the ISO image and then use -kernel bzImage -initrd tinycore.gz -append "quiet max_loop=255". These two ways achieve as far as I can tell pretty much the same (the second one just circumvents the use of ISOLINUX to boot the CD-ROM). I'm fairly certain now that this is not an issue here. The use of something like -hda FILE1.img -hdb FILE2.img is fine in principle and should in theory work as intended.

As an update: I've now been able to reproduce at least the Xvesa failure for TC 2.x when using QEMU with -kernel-kqemu. I've also confirmed that TC 1.4.3 did not suffer from that issue. Doing 'Xvesa -listmodes' leads to a "Segmentation fault" for TC 2.x. My current theory is that libc (v2.9 in TC 2.x vs. v2.3.6 in TC 1.4.3) might cause the issue here, since the /usr/bin/Xvesa files seems to be identical when comparing TC 2.7 vs. TC 1.4.3.

Question for Robert here: Where on the web page would one find the link to the sources and the build script if one would want to rebuild Xvesa?

@quokka: I still have to test my hunch with the question of disk vs. partition inside the virtual disk images, but could you please supply the (full) results the following two commands from your VM: "blkid /dev/hd*" and "fdisk -l".

[maro]

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: [Select]

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

(2) I've started a QEMU VM with TC 2.7 (and those two new disk images), with:

Code: [Select]

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

(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: [Select]

# 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
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 ...]

[^thehatsrule^]

FYI: this is probably due to the stricter rules from 2.6.1

[curaga]

A bug in rebuildfstab IMHO...

[roberts]

Perhaps one of you can let me know if  such an imported virtual drive appears in:

find /sys/block/*/ -name dev | grep -v loop

If so, it would be a trival fix.

[maro]

@curaga: One persons "bug" is another persons "feature" ...

@Robert: As far as I can tell the difficulties are results from the fact that fdisk reports the following:

Code: [Select]

tc@box:~$ fdisk -l | grep 'hd[a-d]'
Disk /dev/hda: 36 MB, 36700160 bytes
Disk /dev/hda doesn't contain a valid partition table
Disk /dev/hdb: 36 MB, 36700160 bytes
/dev/hdb1   *           1           4       32098+ 83 Linux
And that leads to "FDISKL=/dev/hdb1", and therefore /dev/hda does not make it past the "case "$FDISKL" in *"$DEVROOT/$DEVNAME "*)" test.

But I digress, you wanted to know the result of the following (I've taken the liberty to filter out a few more ram devices):

Code: [Select]

tc@box:~$ find /sys/block/*/ -name dev | grep -vE '\/(ram|loop)[0-9][0-9]*\/'
/sys/block/hda/dev
/sys/block/hdb/dev
/sys/block/hdb/hdb1/dev
/sys/block/hdc/dev

[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: [Select]

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
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]

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: [Select]

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

(2) I've started a QEMU VM with TC 2.7 (and those two new disk images), with:

Code: [Select]

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

(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: [Select]

# 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
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 ...]

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: [Select]

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
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.