Author Topic: VMware Fusion + USB boot + FreeBSD 8  (Read 5334 times)

blue^

  • Newbie
  • *
  • Posts: 1
VMware Fusion + USB boot + FreeBSD 8
« on: September 17, 2010, 08:17:49 AM »
Hi,

First of all, thank you Elmar for this wonderful software!  :D

Ever since this afternoon I've been troubleshooting plpbt under VMware Fusion so that it can boot FreeBSD 8.0 off of a USB drive where the VM doesn't have any other hard drives configured.  (Yes Elmar, this is a potential reply to http://lists.freebsd.org/pipermail/freebsd-bugs/2008-February/028792.html if you remember.  :-p)

Problem: plpbt apparently does not increment the number of hard drives reported in the BIOS equipment list area (8-bit unsigned integer at the conventional memory location 0040h:0075h) by the number of drives it adds, and this confuses the FreeBSD boot loader.

Let's say there were originally M hard drives and plpbt adds N more drives (I believe N is typically just 1).  Before plpbt goes resident, BIOS drives >= 0x80 but < 0x80+M are the original drives; after plpbt kicks in, BIOS drives >= 0x80 but < 0x80+N are the drives under plpbt's control, and BIOS drives >= 0x80+N but < 0x80+N+M are the original drives.  Since the drive count at 0040h:0075h is still M, only the first M drives, not all N+M drives are considered by the FreeBSD boot loader.

Case 1: If the original VM had 3 hard drives, they would be 0x80, 0x81 and 0x82, and the drive count at 0040h:0075 would be 3. After plpbt adds one drive, the plpbt drive would be 0x80, and the original 3 hard drives would be 0x81, 0x82 and 0x83.  However, because plpbt does not increment the drive count from 3 to 4, the FreeBSD boot loader only considers drives 0x80 (plpbt drive), 0x81 (the 1st original) and 0x82 (the 2nd original); the 3rd original drive is no longer considered and cannot be accessed by the boot loader.  But this can be okay, as the boot loader typically needs to access only the drive 0x80.

Case 2 (worse): If the original VM had no hard drive at all, the drive count at 0040h:0075h would be 0.  After plpbt adds one drive at 0x80 but forgets to increment the drive count, the drive count would still be 0.  Because of this, the FreeBSD boot loader would not consider any hard drives at all, and of course, would not boot from the USB hard drive.

Could this be fixed in the next version of plpbt?

Cheers,
Eugene

P.S.  For those who are looking for a workaround, the obvious one is: Add at least one bootable hard drive to your system.  This includes a dummy virtual disk in VMware Fusion; its size doesn't matter and can be very small.  :)
« Last Edit: September 17, 2010, 08:35:07 AM by blue^ »

Elmar

  • Administrator
  • Hero Member
  • *****
  • Posts: 2491
  • a command shell is enough to do amazing things
Re: VMware Fusion + USB boot + FreeBSD 8
« Reply #1 on: September 17, 2010, 09:04:23 AM »
hi,

my boot manager updates the byte at 0040h:0075h in the bda since the first version. the problem with freebsd 7rc2 was another.

i quickly made some tests with vmware workstation (i dont have fusion) and a dos booted from usb and the attached drive value in the bda is always correct. i tested vm's with and without virtual internal hard disk.

currently i am downloading freebsd 8 and 8.1 to check this too.

best regards
elmar

Elmar

  • Administrator
  • Hero Member
  • *****
  • Posts: 2491
  • a command shell is enough to do amazing things
Re: VMware Fusion + USB boot + FreeBSD 8
« Reply #2 on: September 17, 2010, 13:09:10 PM »
oh nooo, i got the problem. i tested with the upcoming 5.0.11 release. and it works there, i tested with 5.0.10 and it doesn't work. i looked at the source and found no difference  :o the related source parts are completely equal in both versions! then a diff showed me the small but important difference. long time ago i made the update of the value optional in an IF UPDATEBIOSDATAAREAHARDDISKS EQ TRUE .... ENDIF directive. i think i did this because of debug purpose. however, it should be set to TRUE. I don't know why but in 5.0.10 its set to FALSE in the main asm program and so the the incremental part is not included. in the first test release of 5.0.11 i set it automatically to TRUE and so it works again with 5.0.11. shame on me!!!

best regards
elmar