[syslinux] CPU usage while at syslinux boot prompt

[Gene Cumm]

On Mon, Nov 17, 2008 at 3:46 PM, Gene Cumm <gene.cumm at gmail.com> wrote:
> On Mon, Nov 17, 2008 at 3:05 PM, Dag Wieers <dag at wieers.com> wrote:
>> On Mon, 17 Nov 2008, H. Peter Anvin wrote:
>>
>>> Dag Wieers wrote:
>>>> I was wondering if this was known behaviour ? And if it is something that
>>>> we can fix ?
>>>
>>> I guess I might put a HLT in *as an option* (because people *will*
>>> complain that the serial port loses characters), but perhaps a better
>>> thing would be to not start the VM until you actually need it...
>>
>> One problem for us is that the connected ISO images cannot be ejected
>> (disconnected) like a physical system, otherwise they could reboot
>> directly into the newly installed system like we would prefer.
>>
>> That's a feature request for VMware...
>>
>
> For systems using slim height optical drives, they have no means to
> retract the drive tray back in to protect against dust like the half
> heights do.
>
> Can you remaster the ISO such that it times out to either localboot or
> chain load the local hard drive?  The timeout would allow you to
> manually boot into the installer (watching the VM via the console in
> the VIC) yet auto-boot to the local hard drive if you're not there.
>
> It's either that or put in a COMBOOT/COM32 module to detect whether or
> not the install has completed.  I know that the Windows installer
> discs attempt to detect if there might be an installed system and
> times out after 5-15 seconds to just booting the local hard drive.
>
> You might also be able to script the VM to change state from connected
> to disconnected.
>
> You might also have luck with a PXE system (again detecting if
> installed or having the PXE server deal different info).
>
> Also, Novell NetWare is just as bad as DOS until VMware Tools is
> installed (NOP versus HLT, I believe).
>

Unfortunately, it just dawned on me.  If these are VMs with new VMDKs,
preserve the boot order of HDD then CD.  This would allow the VM to
attempt the HDD but it will fail over to the CD and then boot, allow
you to run your installer, then reboot to the HDD.

If they don't have new VMDKs, you can fake it.  Create a new VMDK
(doesn't matter where).  Capture the MBR boot code to a file.  I'd use
a recovery-oriented Linux distro.  Now you legally have a backup of
the MBR boot code that you can install.

Another idea is that you set the boot order to HDD then CD but for the
boot that you need to boot off of the CD, manually select it (ESC for
boot menu, I believe).  If you have trouble getting the boot menu,
flag the VM to enter the BIOS configuration, then you can just exit
and reboot (not reset) the VM and get the boot menu.

-- 
"No one ever says, 'I can't read that ASCII E-mail you sent me.'"