[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC/Patch: Support for other bootloaders



On Tue, 2005-03-22 at 14:42 +0000, Tim Deegan wrote:
> On Tue, Mar 22, 2005 at 09:18:52AM -0500, Michal Ostrowski wrote:
> > It is my opinion that it is preferable to have C code in place of
> > assembly code for such tasks.
> 
> Using the linux boot format will always be an unpleasant hack, and is
> only useful when multiboot loaders don't work (Xen + xenlinux + initrd
> is three files, and linux only deals with two files).  I'd rather keep
> this grimness separate from Xen.
> 
> As far as I can tell, the "right" answer to this problem is to port the
> relevant network driver to GrUB.
> 

I strongly disagree on this.  It's not a permanent solution because
there will always be devices out there you need to add support for.
Using the PXE firmware, which is increasingly common let's you break
away from requiring specific hardware support in the boot-loader.


> > PS:  mbootpack did not work on my system.  It printed:
> > 
> > mbootpack v0.1 (alpha)
> > 
> > and then nothing else happened.
> 
> Urgh.  Can you send me the command line you used to mbootpack?  It works
> fine for me from EXTLINUX, though I don't have a PXELINUX test rig at
> the moment, or a HS20 blade.

EXTLINUX should be sufficient for these tests.  I actually did most of
my development work on Bochs with SYSLINUX.

./mbootpack -c "xen console=com2 com2=19200,8n1 nosmp=1 noht=1"  \
-m "/u/kitchawa/tftpboot/mostrows/vmlinuz root=/dev/hda" \
-o /u/kitchawa/tftpboot/mostrows/ximg \
/homes/heater/mostrows/xen/xeno-unstable.bk/xen/xen



-- 
Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.