Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: bsquared on December 10, 2010, 01:35:01 PM
-
I need to set up a 64-bit environment, but I can't find tinycore64.
Thanks B2
-
Install microcore64 plus Xlibs, Xprogs, Xvesa and wbar.
-
Xvesa doesn't run on 64bit.
-
I'm not sure what this means. I can download the listed files, but how are they installed?
Currently I qemu setup to boot:
qemu-system-x86_64 -M pc -hda /home/bwinfrey/qemu/cosd.disk -m 128 -cdrom /home/bwinfrey/Downloads/tinycore_3.3.iso -hdb /home/bwinfrey/qemu/swap.disk -net nic,vlan=1 -net user,vlan=1,hostname=emu -kernel /home/bwinfrey/Downloads/edit/boot/bzImage -initrd /home/bwinfrey/Downloads/edit/boot/microcore.gz
where bzImage and microcore.gz are the 64-bit versions.
Boots up fine and identifies as X86_64.
I want to use the hda image (already setup as ext4) as boot drive, and hdb image as swap.
-
I haveno 64bit machine to test on, and don't know how 64bit microcore was compiled, but this is how RedHat/Fedora handle mixed
archecture installations:
32 bit applications read libraries from /lib.
64 bit applications read libraries from /lib64.
This allows a 64 bit system to run both 64 and 32 bit applications with no library conflicts.
I did not know that 32bit Xvesa will not run with the 64bit kernel.
To answer bsquared's question:
The Xxxx.gz files are placed in the tce directory and are automatically loaded afrer boot.
-
Nothing to do with Xvesa's bitness, it's the bios calls it uses. Those are unavailable when on 64-bit.
Xorg's vesa doesn't call the bios, it uses its own emulator, which is why it works on 64.
-
Good, then bsquared should be able to copy Xlibs.gz and Xprogs.gz to his tce directory, load Xorg-7.5.tcz onboot, and have
a functioning X server with the 64 bit kernel.
Is this correct?
-
Yes, that should work. It's the lack of Xvesa why there's no tinycore64 iso.
-
Thanks for the help. What do you mean by the tce directory? I put them on the root of the cd image.
-
Please refer to the FAQs on tinycorelinux.com.
-
I am following the wiki "Adding a Desktop to MicroCore", but no success. Here is my setup:
booting microcore-64.iso
hda is created using dd on existing partiton out to hda.img (part image not disk image)
hdb is created using dd to create a file and running mkswap on it.
Xlibs.gz & Xprogs.gz are on hda in /tce.
qemu command:
qemu-system-x86_64 -M pc -hda hda.img -m 192 -cdrom microcore-64.iso -hdb swap.img -net nic,vlan=0 -net user,vlan=0,hostname=emu -boot d
boot: microcore tce=hda microcore showapps...
tc@box:~$cd `cat /opt/.tce_dir`
-sh: cd: can't cd to /tce
it looks as if no tce loading happens during boot and hda is not mounted.
Any ideas what is wrong other than my ignorance ;)
Thanks again.
-
(1) Can you be more specific about the 'dd' command used for the creation of 'hda.img'?
(2) Also what filesystem did you create on that disk image file?
(3) Could you show us the result of fdisk -l /dev/hda and blkid /dev/hda* from "inside" the VM?
Because I've just done a simplified version of your attempt (using 'qemu -hda hda.img -cdrom tinycore_3.4rc2.iso -boot d -m 48') and I had to boot once to be able to run something like sudo mkfs.ext3 /dev/hda and the second time around I can get the expected result of:
tc@box:~$ cd $( cat /opt/.tce_dir )
tc@box:/mnt/hda/tce$
And to just give you an idea of what I'm getting for (3), here is that output:
tc@box:~$ cat /proc/cmdline
initrd=/boot/tinycore.gz quiet BOOT_IMAGE=/boot/bzImage tce=hda
tc@box:~$ fdisk -l /dev/hda
Disk /dev/hda: 5 MB, 5242880 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/hda doesn't contain a valid partition table
tc@box:~$ blkid /dev/hda*
/dev/hda: UUID="74eff9c0-a95c-4aea-84ef-8ea97d5e7994" SEC_TYPE="ext2" TYPE="ext3"
-
> (1) Can you be more specific about the 'dd' command used for the creation of 'hda.img'?
I have a virtual disk - cosd.disk. I created an image of the first partition with dd.
to determine correct start position and size:
parted cosd.disk
...
(parted) unit
Unit? [compact]? B
(parted) print
Model: (file)
...
Number Start End Size Type File system Flags
1 1048576B 7976517631B 7975469056B primary ext4 boot
...
(parted) quit
create the image with the start/size information from above.
dd if=cosd.disk of=hda.img bs=512 skip={1048576/512} count={7975469056/4}
> (2) Also what filesystem did you create on that disk image file?
This is an image of a partition, not a disk. File system is ext4
> (3) Could you show us the result of fdisk -l /dev/hda and blkid /dev/hda* from "inside" the VM?
Disk reporting from within VM (same boot params as before).
tc@box:~$fdisk -l /dev/hda
Disk /dev/hda: 8387 MB, 8387559424 bytes
255 heads, 63 sectors/track, 1019 cyinders
Unite = cyinders of 16065 * 512 = 8225280 bytes
Disk /dev/hda doesn't contain a valid partition table
tc@box:~$blkid /dev/hda
/dev/hda: UUID="fb99a5e4-9fec-406c-a693-87ba14d7e3a3" TYPE="ext4"
-
Are you able to mount disk or partition in question from within VM?
If so, are you able to list /tce and contents?
-
Yes to both-kindof. yes it mounts, but /tce doesn't exist. it should be /mnt/hda/tce. so..
I mounted hda, recreated the tce directory just in case and ran tce-setup. It returned with /mnt/hda/tce.
I installed cifs-utils and copied the gz files from the host via samba.
I rebooted and got the same results.
-
< 3.4 won't add partitionless HD's to fstab, and I believe this prevents tce autodetection on those. Try 3.4rc2 or create a partition on the virtual hd.
-
I thought it may have something to do with the image. I dont see an explicit 3.4rc2 for 64-bit.
-
hda is not a valid partition.
-
do you mean to say that hda is not a valid partition as far as tce auto-mounting is concerned? therefore there is no need to check out rc2.
-
Your hda is an unpartitioned drive. hda1 would be a partition.
-
Hold on guys: Yes '/dev/hda' is an unpartitioned drive (which would not have worked with 'rebuildfstab' of TC 3.3), but since TC 3.4rc1 that limitation has been overcome.
I implicitly assumed that bsquared was aware of this, and have also therefore on purpose used TC 3.4rc2 in my quick test (see reply #11). (Just ignore the fact that I'm using TC instead of MC, since it does not make any difference for the issue at hand).
@bsquared: If you insist on using 64-bit (which for your current issue would not really be required) just download the seperate files of the kernel (http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release_candidates/distribution_files/bzImage) and the initrd (http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release_candidates/distribution_files/microcore64.gz) and use qemu-system-x86_64 -kernel bzImage -initrd microcore64.gz ... instead of qemu-system-x86_64 -cdrom microcore-64.iso -boot d ...
EDIT: To specify boot parameters with the '-kernel ...' style of using QEMU please add -append "tce=hda microcore showapps" to the command
-
@bsquared: Thanks for your details reply #12.
My observation is that the numbers don't add up: The partition 1 that you've tried to extract starts at block 1,048,576 / 512 = 2,048 (which should be used as the 'skip' parameter). It's size is 7,975,469,056 / 512 = 15,577,088 blocks (which should be used as the 'count' parameter). The size reported by 'parted' (i.e. 7,975,469,056 = 7606 MBytes), does not match with what 'fdisk' reports (i.e. 8,387,559,424 = 7999 MBytes).
I'd therefore suggest to check the file system (e.g. via fsck /dev/hda). You'll need an un-mounted file system for this, so you better boot with boot codes 'base norestore' to ensure that.
I guess you could make your life slightly easier if you'd use 'unit s' (for sectors, i.e. blocks) in 'parted'. That way the reported numbers can be used directly in a 'dd bs=512 ...' scenario.
-
Thanks all for you help. I went another direction to get 64-bit emulation with the image.