[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-misc
Subject:    Re: qemu and USB drives (SOLVED)
From:       Vijay Sankar <vsankar () foretell ! ca>
Date:       2012-01-29 22:11:29
Message-ID: 20120129161129.76813tiactk8fimp () server1 ! foretell ! ca
[Download RAW message or body]

Quoting Stuart Henderson <stu@spacehopper.org>:

> On 2012-01-28, Vijay Sankar <vsankar@foretell.ca> wrote:
>> Hi,
>>
>> Sorry for the long message. I am not able to figure out a good
>> solution for the following:
>>
>> Right now, what I do to test ports etc., is download install51.iso,
>> run it within qemu, and then do the work. To test the port on a
>> different server (which is on a different network), I end up burning a
>> new CD or use PXE boot within my LAN when that is possible, so that
>> the latest version is on a USB stick. However, I would like to have
>> -current or -beta on a USB drive without having to burn a CD or use
>> PXE boot.
>>
>> Is it possible to install OpenBSD on a USB drive from within qemu and
>> then use that USB drive to boot a laptop?
>
> I don't know about doing this with qemu, but you can fdisk/disklabel,
> mount, untar sets, create fstab, and run installboot(8) manually from
> a running OS..
>
>

Thank you very much for the five clues you gave me here. It is  
perfect! As you very politely hinted, I was using the wrong tool for  
what I was trying to achieve.

Also, for the archives, many people sent me suggestions in private  
messages. I replied to them and thanked them in private but would like  
to thank them again through the list as well. I tried each of their  
suggestions and this is what I noticed. Jotting it down for the  
archives just in case it saves time for anyone.

SUGGESTIONS FROM LIST AND THE RESULTS

1) TRY WITH A DIFFERENT USB STICK: I purchased a 2GB and another 8GB  
USB stick and retried the installation. On the new 2GB drive as well  
as the 8GB drive, installation from qemu worked but I could not reboot  
using the drive on a laptop. disklabel continued to give me wrong  
information as mentioned in my initial message.

2) WIPE OUT "SECURITY" STUFF ON THE USB DISK: I did an fdisk and  
disklabel on the 2GB drive. As soon as I did that, qemu installation  
worked without any problems and I was able to take the drive and boot  
a laptop with it. I now see the following from the host as well as the  
guest.

disklabel sd6
# /dev/rsd6c:
type: ESDI
disk: ESDI/IDE disk
label: QEMU HARDDISK
duid: 9fa6e404f695e65d
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 64
sectors/cylinder: 4032
cylinders: 999
total sectors: 4028416
boundstart: 63
boundend: 3999744
drivedata: 0

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
   a:          3869377               63  4.2BSD   2048 16384    1
   b:           130281          3869440    swap
   c:          4028416                0  unused


3) TRY RAW AND BLOCK MODES: I was able to install using /dev/sd6c as  
well as /dev/rsd6c with the 2GB drives once it was partitioned  
properly. The install script did not partition the 2GB drive into many  
chunks -- it kept a and b that I had configured with fdisk.

4) TRY RAW AND BLOCK MODES: With the new 8GB drive, I was able to  
install as mentioned earlier. It would not boot on a laptop but would  
boot when used with qemu. But once I did an fdisk -i, wiped out what  
was there and created the partitions, installation worked with  
/dev/rsd6c as well as /dev/sd6c and I can boot from within qemu as a  
guest VM or on a laptop. Interestingly, all I did was create a 7.2GB  
sd6a and sd6b as swap but the installation program did create all the  
different partitions (unlike the 2GB disk).

Here is the disklabel from the qemu host:

disklabel sd6
# /dev/rsd6c:
type: ESDI
disk: ESDI/IDE disk
label: QEMU HARDDISK
duid: 56f7b68cb1c83aea
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 15520
total sectors: 15644912
boundstart: 64
boundend: 15631245
drivedata: 0

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
   a:           211392               64  4.2BSD   2048 16384    1
   b:           211395           211456    swap
   c:         15644912                0  unused
   d:           321792           422880  4.2BSD   2048 16384    1
   e:           287456           744672  4.2BSD   2048 16384    1
   f:          1890752          1032128  4.2BSD   2048 16384    1
   g:          1077088          2922880  4.2BSD   2048 16384    1
   h:          4289408          3999968  4.2BSD   2048 16384    1
   i:          2116160          8289376  4.2BSD   2048 16384    1
   j:          2700416         10405536  4.2BSD   2048 16384    1
   k:          2525152         13105952  4.2BSD   2048 16384    1


5) USE DUID: That has been my practice since it became available. Use  
of duid helped me here as well since I did not have to change  
/etc/fstab.

6) USE VIRTUALBOX: I tried with VirtualBox on my iMac and it worked  
well once the disk was partitioned properly. I don't use the iMac much  
since I discovered how awesome xxxterm is, So I did not spend a lot of  
time with VirtualBox, if it is helpful to do any additional tests,  
please let me know and I can do that.

7) STUART's SUGGESTION: This is perfect for me since I don't have to  
use anything other that the base OS. Installation with this approach  
is a 6 minute operation instead of a 18 minute chore!!

I will now go back to watching Planet 51 :)

Thanks again,

Vijay

Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsankar@foretell.ca

Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsankar@foretell.ca

---------------------------------------------
This message was sent using ForeTell-POST 4.9

[prev in list] [next in list] [prev in thread] [next in thread]