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

Re: [Xen-users] Kernel Headers for Xen Kernel

  • To: Marcus Brown <marcusbrutus@xxxxxxxxxxxxxxxx>, Olaf Grewe <olaf@xxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
  • From: Yvette Chanco <yentlsoup@xxxxxxxxx>
  • Date: Sat, 6 Aug 2005 04:44:07 -0500
  • Delivery-date: Sat, 06 Aug 2005 09:42:32 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UAKpb2aQ6v7nPi/XsLExZM/IYfkhdhzp3+xWCodnEdnjD/ShKbeVr/TGfxDb+mloSBeTcG5hcrmDLG/IdL0uRFuEjf5wDNXsyuHgdxZbwTbfeFyeaAim2nKpYew99yjfef90ETNxV5EPs7w2dZHL83sPXySJwonUTK6je68GCJE=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

> > I´m using stable, mainly because a while ago a post came round that
> > hiding PCI devices from dom0 isn´t working at the moment.
> >
> I'm using sid with xen-testing on my dom0 atm.
> Hiding seems to works well.
> # uptime
>  22:32:00 up 5 days,  7:28,  1 user,  load average: 0.00, 0.00, 0.00
> LOL ... OK, it's not doing much by the looks of it! :)
> kernel          /xen-2.0-testing.gz dom0_mem=131072 root=/dev/hda3 ro
> console=tty0 physdev_dom0_hide=(00:07.2)
> module          /vmlinuz- root=/dev/hda3 ro console=tty0
> My development server has a similar setup but uses modules and an initrd,
> with root on LVM.

>From what I recall, it is the unstable tree that doesn't support
hiding pci devices - anything in 2.0 (testing or stable) does
(somebody please correct me if I'm wrong).

> > When you start using make-kpkg, maybe the following observations might
> > help: Installing the kernel-package that make-kpkg generated failed to
> > update grub´s menu.lst. The kernel is also named such that it won´t be
> > recognized by grub-update. As I don´t have physical access to the
> > machine I´m using, I haven´t tried the new kernel yet. However I used
> > it to boot a domU and that worked just fine.
> >
> I've noticed some strange Debian-related naming conventions for kernels
> and initrds when using make-kpkg ... I'll keep an eye on it next time I do a 
> batch.
> > Again, thanks for looking into it, I´d be interested to see how your
> > make-kpkg experience turns out.
> >     Olaf
> >
> I'm about to upgrade the server (long story), so I'll have a chance to
> do this soon. I hope to be able to make kernel packages on my workstation 
> and copy them to the server for intstall.
> I'll post results.

1) I often use make-kpkg to create new debian/xen kernels
- sorry, I'm being a bit lazy with my forum posts today and just
giving links). Although I was curious about the issues with the
kernel_headers target, they appear to have been worked out. My only
comment is that these days it's not usually make-kpkg that's the
issue, it's getting the config right...

2) As far as I can tell with my experiences (and I'm probably wrong)...
 *update-grub does rely on very specific naming conventions. If you
use then xen kernel patches to build xen kernels (with make-kpkg), if
prepends "xen-linux" which results in those kernels being ignored by
 *Even if the xen kernels weren't ignored, update-grub (in debian
sarge) does not currently support all the needed options to boot a xen
 * I created a quick, temporary (and no doubt horrible) modified
version of update-grub which "seems to work." It deals with
"xen-linux" prepended kernels, and also with the xen binary install
(the symlinks are a bit of a problem for update-grub). Anyhow, feel
free to use it - the modified script is called update-grub-xen - the
most recent version should be here:


...but if you want to have it run every time you install a new kernel,
you'll need to edit the hooks in /etc/kernel-img.conf.


Xen-users mailing list



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