On Thu, Oct 16, 2014 at 5:52 PM, Johnny Hughes <johnny at centos.org> wrote: > On 10/16/2014 11:25 AM, George Dunlap wrote: >> On Fri, Oct 10, 2014 at 2:41 AM, Johnny Hughes <johnny at centos.org> wrote: >>> The new process for auto updates of grub upon kernel install is in the >>> xen4centos testing repo. >>> >>> In order to test these as updates to an existing system, you can do this: >>> >>> 1. download the test repo file: >>> >>> http://dev.centos.org/centos/6/xen-c6-RC1/xen-c6-RC1.repo >>> >>> 2. Put it in /etc/yum.repos.d/ >>> >>> 3. Issue this command: >>> >>> yum --disablerepo=Xen4CentOS upgrade xen\* centos-release-xen >>> >>> (that should install all the new files required to make the kernel >>> update work automatically) >>> >>> 4. Review the new file /etc/sysconfig/xen-kernel ... if there is any >>> other items you want on the 'kernel /xen.gz' line, you would edit the >>> file. For example, I like to add 'com1=115200,8n1 console=com1' to the >>> end of that line so I can use consoles in virsh. So I would change the >>> line: >> >> Hmm -- so I take it that /etc/sysconfig/xen-kernel is now a part of >> the xen package...? >> >> One issue with this is that during normal Xen development I often make >> an RPM directly from the upstream repo, so while I have the xen4centos >> kernel & libvirt installed, I don't have a xen4centos xen installed. >> >> The nice thing about the current script in centos-release-xen is that >> it works with non-x4c xen packages. >> >> Sorry I hadn't thought about that side-effect when you mentioned this >> before. :-/ >> >> Any thoughts? Would it be possible to have the script in >> centos-release-xen and check for the existence of /boot/xen.gz, for >> instance? > > I don't think that is a good idea .. people might have the xen.repo > installed so that they can get the kernel. But not xen installed (ie, > they are on a domU). They want the kernel and have centos-release-xen > installed .. BUT they don't want the grub mods as they want to boot a > normal kernel. I'm a bit confused. I suggested that the script only install xen if /boot/xen.gz exists. If they don't have the hypervisor package installed, then /boot/xen.gz won't exist, and so it should fall back to the default behavior. If they have the hypervisor package installed in the domU for some reason, then it will put /boot/xen.gz first unless they edit /etc/sysconfig/xen-kernel -- which is the same thing that would happen if they installed the hypervisor packages you have here, right? Hmm, maybe it wasn't clear that I was actually suggesting moving /etc/sysconfig/xen-kernel to centos-release-xen; I wasn't suggesting getting rid of it and just always loading the xen kernel if it exists. > The easier thing would be for you (as a one off installer situation) to > create your own /etc/sysconfig/xen-kernel manually if you want grub > updated. It only has 2 variables. That's not too hard. :-) But it does mean a bit of extra overhead for anyone installing a non-CentOS build of Xen (a local build, a snapshot of release candidate, &c). This solution was for C6 only, right -- C7 uses grub2, right? If it was going to be something CentOS would be using going forward we might be able to make the argument for including it in the upstream Xen install. But if it's just a patch to get C6 to work, I don't think upstream will be so keen. > I want to make it easy to get things right in the major use cases .. > which I think this solution does in the way it is split up. Right, so in your suggestion: - centos-release-xen installed, CentOS hypervisor installed: Automatically defaults to xen - centos-release-xen instlaled, CentOS hypervisor installed, xen-kernel edited: Whatever is configured - centos-release-xen installed, no hypervisor installed: Defaults to bare metal Linux - centos-release-xen installed, alternate Xen installed: Defaults to bare metal Linux (needs grub.conf editing every kernel update). Which means using the CentOS hypervisor packages are a little bit easier (since you don't need to remember to run grub-bootxen.sh on every kernel update); but it makes having an alternate Xen installed harder, because you need to actually edit menu.lst on every kernel update. In my suggestion (moving /etc/sysconfig/xen-kernel to centos-release-xen, checking to see if xen exists): - centos-release-xen installed, CentOS hypervisor installed: Automatically defaults to xen - centos-release-xen instlaled, CentOS hypervisor installed, xen-kernel edited: Whatever is configured - centos-release-xen installed, no hypervisor installed: Defaults to Linux - centos-release-xen installed, alternate Xen installed: Automatically defaults to Xen - centos-release-xen instlaled, alternate Xen installed, xen-kernel edited: Whatever is configured It seems to me my way keeps things just as sensible for when the CentOS hypervisor packages are installed, but makes things better in the case where an alternate Xen is installed (which is not uncommon, even for non-developers). Or am I missing something? -George