General TC > Tiny Core on Virtual Machines

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

<< < (2/4) > >>

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

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

A bug in rebuildfstab IMHO...

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.

@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: ---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

--- End code ---
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: ---tc@box:~$ find /sys/block/*/ -name dev | grep -vE '\/(ram|loop)[0-9][0-9]*\/'
--- End code ---


[0] Message Index

[#] Next page

[*] Previous page

Go to full version