[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |