Hi, So I have been attempting to build xen from source for a bit longer than I care to admit. I''m trying very hard to stay within the realm of supported/non-experimental which seems to vastly limit my options. That is to say the 2.6.27 patch from novell is listed as unsupported/undeveloped/experimental and the paravirtualization stuff in 2.6.3x kernels is listed as experimental as well. This basically leaves the 2.6.18 option available to me. Trying to get it built has been a bit of a process, if you use the tarball that pulls down from kernel.org (instead of mercurial), there is a number of issues that made me finally move on to the mercurial sources (ketchup breaks due to a bad regexp, there are compile time errors in the kernel source [i.e. forgot to include limits.h], et cetera). The mercurial version compiles cleanly, but then I run into a run-time problem. On boot it informs me that I need to use bzImage v2.08 instead of v2.04. After some digging around, what it looks like to me is that xen at some point was brought up to use v2.08 of the boot protocol and this was never backported to the 2.6.18.8 kernel (v2.05 was released in 2.6.20). This of course won''t work (is there absolutely no one actually using the default and supported option?). So I elected to use the vmlinux/zImage version and I get the ''error: no multiboot header'' from grub (for both multiboot & linux directives). I get this for the kernel that pulls down from mercurial and the tarball on the website. My problems as best as I can tell appear to be a few things: - Grub has changed and I *think* this relates back to why I can''t seem to boot the vmlinux image - Xen 3.4.2 cannot boot a bzImage of the supported dom0 kernel So this leaves me with the question, how exactly am I supposed to use your product with? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com lists.xensource.com/xen-devel
On 29/12/2009 06:24, "Justin Ferguson" <jnferguson@gmail.com> wrote:> On boot it informs me that I need to use bzImage v2.08 instead of > v2.04. After some digging around, what it looks like to me is that xen > at some point was brought up to use v2.08 of the boot protocol and > this was never backported to the 2.6.18.8 kernel (v2.05 was released > in 2.6.20). This of course won''t work (is there absolutely no one > actually using the default and supported option?). So I elected to use > the vmlinux/zImage version and I get the ''error: no multiboot header'' > from grub (for both multiboot & linux directives). I get this for the > kernel that pulls down from mercurial and the tarball on the website.I think you are setting up the bootloader incorrectly. What bootloader are you using? If GRUB, you need a config entry like: title XEN root (hd0,1) kernel /boot/xen.gz module /boot/vmlinuz-xen <kernel params> module /boot/initrd-xen You get the idea. The main message here is that *Xen* is the kernel, not Linux dom0. Linux kernel is specified as the first module; initrd as the second module (if you have an initrd). You can most assuredly use a 2.6.18 bzImage for dom0 -- Xen knows what to do with it. Your problem in all cases is I think that you tried to boot dom0 kernel directly, without loading Xen as the kernel from grub''s p.o.v. This type of of question should go to the xen-users list, by the way. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com lists.xensource.com/xen-devel
On Tue, 2009-12-29 at 09:11 +0000, Keir Fraser wrote:> > You can most assuredly use a 2.6.18 bzImage for dom0 -- Xen knows what > to do with it.Unless someone backported the v2.08 bzImage format extensions (which I don''t think is the case) then you cannot boot a 2.6.18 bzImage under Xen, that support relies on newer fields in the header. IIRC those patches went into 2.6.27 upstream, although e.g. Debian backported them to their 2.6.26 kernel. For 2.6.18 I think you still need to use the old compressed-ELF style kernels. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com lists.xensource.com/xen-devel
>> You can most assuredly use a 2.6.18 bzImage for dom0 -- Xen knows what >> to do with it. > > Unless someone backported the v2.08 bzImage format extensions (which I > don''t think is the case) then you cannot boot a 2.6.18 bzImage under > Xen, that support relies on newer fields in the header. IIRC those > patches went into 2.6.27 upstream, although e.g. Debian backported them > to their 2.6.26 kernel. > > For 2.6.18 I think you still need to use the old compressed-ELF style > kernels.Which, may be a problem with my grub config-- but i dont think it is, I can''t seem to get grub 2 to boot the resultant vmlinux/zImage, it just likes to tell me its missing the magic number-- which I''m guessing, and my knowledge gets hazy here, is a result of it not being a multiboot compatible image? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com lists.xensource.com/xen-devel
On Tue, 2009-12-29 at 10:10 +0000, Justin Ferguson wrote:> >> You can most assuredly use a 2.6.18 bzImage for dom0 -- Xen knows what > >> to do with it. > > > > Unless someone backported the v2.08 bzImage format extensions (which I > > don''t think is the case) then you cannot boot a 2.6.18 bzImage under > > Xen, that support relies on newer fields in the header. IIRC those > > patches went into 2.6.27 upstream, although e.g. Debian backported them > > to their 2.6.26 kernel. > > > > For 2.6.18 I think you still need to use the old compressed-ELF style > > kernels. > > Which, may be a problem with my grub config-- but i dont think it is, > I can''t seem to get grub 2 to boot the resultant vmlinux/zImage, it > just likes to tell me its missing the magic number-- which I''m > guessing, and my knowledge gets hazy here, is a result of it not being > a multiboot compatible image?The kernel you use must be the toplevel vmlinux ELF file, optionally stripped and optionally gzip compressed. This is not the same as a zImage which is a format similar to to bzImage but not able to cope with such large images (it is effectively obsolete). I think there is a target in the 2.6.18-xen tree which will perform this strip and compress step for you but I don''t recall what it is, it might be the "vmlinuz" target although note that people often rename whatever image they have built to that name so if you find one lying around it isn''t necessarily in any particular format. A correct 2.6.18-xen kernel should respond to the file command like this: (I happened to have a 2.6.26-xen image hanging around, the output should be the same for 2.6.18-xen) $ file /boot/vmlinuz-2.6.26-2-xen-amd64 /boot/vmlinuz-2.6.26-2-xen-amd64: gzip compressed data, from Unix, last modified: Thu Aug 20 01:36:37 2009, max compression $ zcat /boot/vmlinuz-2.6.26-2-xen-amd64 | file - zcat /boot/vmlinuz-2.6.26-2-xen-amd64 | file - /dev/stdin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped 32 bit kernels will be similar. The grub examples Keir gave are correct, you just need to be careful about the kernel image you use. If you need to post again please include the exact grub config file you are using and the precise error messages rather than paraphrasing. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com lists.xensource.com/xen-devel
I apologize in advance as my terminology on the various linux kernel compression formats is not the best (up until today I thought bzImage was just a bzip''d copy of the elf image, and the documentation here uses a lot of conflicting terminology)-- I am not positive if it is zImage or what format it is (other than I know it is not bzImage), but: jf@theory:/boot$ file vmlinux ; zcat vmlinuz | file - vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped /dev/stdin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped (I changed both file names to make them easy to type with tab completion as ive been doing a lot of rebooting as of late)> The kernel you use must be the toplevel vmlinux ELF file, optionally > stripped and optionally gzip compressed. This is not the same as a > zImage which is a format similar to to bzImage but not able to cope with > such large images (it is effectively obsolete).When I attempt to boot either of these kernels from the command line, I get the (presumably grub due to the lack of verbosity) invalid magic error. Where I am unclear on grub is whether I am supposed to be using ''multiboot'' or ''linux'' as the operand (to replace ''kernel''), the bzimage i needed multiboot, but none of the images ive created have contained a (findable) multiboot header (per mbchk), That said I may be making things unnecessarily stupid on myself by using some new-fangled version of grub (that shipped with the distro). Regardless of whether I am doing something wrong with grub, one of the resulting images should boot, however all are returning the magic error.> I think there is a target in the 2.6.18-xen tree which will perform this > strip and compress step for you but I don''t recall what it is, it might > be the "vmlinuz" target although note that people often rename whatever > image they have built to that name so if you find one lying around it > isn''t necessarily in any particular format.Well a make kernels leaves you with the top level image necessary (or other ones in the arch directories). A full make world/make install installs a bzImage. The implication here of course is that the default image installed from a make install is the bzImage that cannot possibly work. (v2.04-v2.08 thing)> If you need to post again please include the exact grub config file you > are using and the precise error messages rather than paraphrasing.So, the grub.cfg I have at the moment contains the entry from the last make world/make install, since then I''ve attempted to boot the top level images on the command line as described. To satify you''re request, the relevant entry is as follows: menuentry "xen" { multiboot /boot/xen-3.4.gz dom0_mem=512M module /boot/vmlinuz-2.6.18-xen root=/dev/sda5 ro module /boot/initrd-2.6-xen.img } I''m not attempting to clutter the dev list with user list type things, but I''m fairly certain there is a bug here. justin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com lists.xensource.com/xen-devel
On Tue, 2009-12-29 at 12:29 +0000, Justin Ferguson wrote:> That said I may be making things unnecessarily stupid on myself by > using some new-fangled version of grub (that shipped with the distro).Have you tried using the distro supplied Xen and kernel packages?> > I think there is a target in the 2.6.18-xen tree which will perform this > > strip and compress step for you but I don''t recall what it is, it might > > be the "vmlinuz" target although note that people often rename whatever > > image they have built to that name so if you find one lying around it > > isn''t necessarily in any particular format. > > Well a make kernels leaves you with the top level image necessary (or > other ones in the arch directories). A full make world/make install > installs a bzImage. The implication here of course is that the default > image installed from a make install is the bzImage that cannot > possibly work. (v2.04-v2.08 thing)If you do "make world KERNELS=linux-2.6-xen" it will build a 2.6.18-xen kernel and do the correct thing by not using bzImage. I guess you are using the default which I think is equivalent to KERNELS=linux-2.6-pvops and assumes bzImage support is new enough, if you just drop in some other kernel than the one it would clone itself it may not work.> > If you need to post again please include the exact grub config file you > > are using and the precise error messages rather than paraphrasing. > > So, the grub.cfg I have at the moment contains the entry from the last > make world/make install, since then I''ve attempted to boot the top > level images on the command line as described. To satify you''re > request, the relevant entry is as follows: > > menuentry "xen" { > multiboot /boot/xen-3.4.gz dom0_mem=512M > module /boot/vmlinuz-2.6.18-xen root=/dev/sda5 ro > module /boot/initrd-2.6-xen.img > }IIRC grub2 (which is what you appear to be using) strips the image name itself, while grub1/legacy did not. I think you need a placeholder command line argument to work around this, perhaps a "." , e.g. "multiboot /boot/xen-3.4.gz . dom0_mem" and "module /boot/vmlinuz-... . root=etc..." I''ve not used grub2 myself though and I''m not sure if this relates the the magic error you refer too.> I''m not attempting to clutter the dev list with user list type things, > but I''m fairly certain there is a bug here.I''m pretty certain it is a configuration error, which might translate to a bug in the docs or something like that. You will likely find more people who have been through this on the users list. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com lists.xensource.com/xen-devel
> IIRC grub2 (which is what you appear to be using) strips the image name > itself, while grub1/legacy did not. I think you need a placeholder > command line argument to work around this, perhaps a "." , e.g. > "multiboot /boot/xen-3.4.gz . dom0_mem" and "module /boot/vmlinuz-... . > root=etc..." > > I''ve not used grub2 myself though and I''m not sure if this relates the > the magic error you refer too.grub2 is a first for me as well, and for anyone who might stumble upon this thread with this problem-- this was the fix. It must be an issue where the structure used doesn''t match the data and the magic member ends up pointing to the wrong spot (or something similar). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com lists.xensource.com/xen-devel