On Sat, 2004-10-23 at 09:31, Nuutti Kotivuori wrote:
> Brian Wolfe wrote:
> > But hey, each admin has their own magical formula. *grin*
>
> Exactly. What I have considered doing for a while is to make wrapper
> around make-kpkg and the kernel directory with a curses UI that would
> lessen confusion about what operations can be done next and what
> options need to be passed to all commands and all that. A bit like how
> debian-installer looks like.
Interesting... I wonder if that could be adapted to provide an interface
for xlb as well. If you write it, how much trouble would it be to have
it just parse a menu/action/dep config file to know what to present? Or
is there a package out there like this in existance already?
>
> > Where does make-kpkg stick the ekrnel and modules for unprived
> > domains? I'm assuming still in /boot and /lib/modules.
>
> Yes, /boot and /lib/modules.
>
> > I had a long discussion with Adam over the location of the kernel
> > and modules for "loaded" kernels such as the ones used for starting
> > domains via xm. We came to the conclusion that it made more sense to
> > use /usr/lib/kernels for UML and xenlinux kernels (other than
> > domain-0, which stays in /lib/modules and /boot). This way you can
> > simply nfs export the modules and kernel to the unprived domains
> > instead of having to load the darn package to every domain that
> > needs them.
>
> Well, it is a complex issue. For user-mode-linux, make-kpkg uses
> /usr/bin/linux-x.x.x and /usr/lib/uml/x.x.x I believe.
>
> I myself think about the matter a different way. I think the kernel is
> a part of the *guest* filesystem. And inside the guest,
> /lib/modules/x.x.x should be the kernel modules, /boot/config-x.x.x
> should have the kernel config, /boot/System.map-x.x.x should be the
> system map and the kernel binary should be found under /boot. And in
> the Debian world, these things should be installed inside the guest
> filesystem by a debian package. Special cases are honeypot guests and
> secure guests where they should not have access to the kernel binary
> or something.
>
> The fact that the kernel is started from the host side (or even run as
> a normal program on the host like in UML) is just an implementation
> detail - and to behave as much like a 'real' virtual machine, there
> should be a 'boot loader' which would dig the kernel binary from
> inside the guest filesystem and then boot that, just like Grub does on
> a native system.
>
> And specifically in Xen's case when the priviledged domain 0 kernel
> can also be booted as a guest kernel, I believe all the kernels and
> modules should belong in /boot and /lib/modules.
>
> But, like said, each admin has their own magical formula.
*nod* I can see your point about the bootloader issue. Maybe I can set a
pre-install debconf question that asks where the admin wants to stuff
em, standard location, or host server location (/usr/lib/xen or
/usr/lib/kernels or something)
I'm probably going to add post-config scripting to add the xen-br?
interfaces to /etc/network/interfaces and a new xen/scripts/network
script that uses that instead of the upstream version. This way other
debian stuff that messes with interface will know about the bridges. :)
>
> > What kind of 3rd part patches have you been using with xen so far?
>
> I've put in some netfilter patches.
I've been mixing in iscsi-target from sf.net, linux-iscsi from cisco, and a couple others.
My goal is to get xlb working enough that I can then use it to generate
unofficial kernel images that have options set as closely to the
official debian kernel-image packages as possible.
> > If I do that I inevitably run into a mess with 2.4.27 and skbuff as
> > well as IPSec issues in both 2.4.27 and 2.6.8. 8-P
> I use 2.6.8 and don't use IPSec. So perhaps that's why.
*nod* probably. I didn't hit it till I started trying to create the
above-mentioned debian style kernel-image tarballs. No debs yet, haven't
writen that part. May just make a call to make-kpkg to simplify since
it's a debian specific package method. End goal si to provide a set of
packages that can be loaded, answer a possible question or two, and
launch.
Need to figure out how to detect if grub has actually been loaded into
the boot sector at post-install.
>
> > If you are using the debs I'm producing of xen, you may want to try
> > using the kernel-patch-xen package instead of mkbuildtree for your
> > kernels since it avoids the issues I mentioned above with sparse
> > patching the deb source. The patch set I create seems to apply with
> > a minimal fuzzing to a pristine kernel source as well as the debian
> > kernel source.
>
> I wanted to first see if the regular mkbuildtree could be used to
> build - and yeah, I will probably use the kernel-patch-xen in the
> future. Before this I just didn't know if the patch was good or not ;)
*grin* I can understand the hesitation since I"m new at this. If you do
use it, please let me know if it glitches any for you. I fairly certain
that I've got the converter worked out finally. Another user reported
back that the 2.4.27 patch works now (was getting intermingled with
2.6.8.1). So the versions should be good. I haven't hit any patch
troubles since I fixed the converter.
>
> > Sorry for the spanish inquisition Nuutti. :)
>
> No problem, glad to give a different point of view.
*smiles and pulls the comfy chair forward* Let the inquisition begin,
that is if you don't mind. ;) I could use your opinions. They sound well
informed and thought out. Adam is darn good , but like most admins, he's
got some oddball ideas on how to do things at times (yeah, yeah, yeah,
pot, kettle, black, I know adam. *grin* no insult intended.)
>
> -- Naked
>
side note, I just had some of the debian packaging specifics related to
versions explained to me by Keybuk on irc.oftc.net #debian-devel. I've
been mucking the package versions even worse than I thought. sooo I
*think* I have the version stamps figured out finally. :)
xen_2.0-0.$(bk_patchlevel)-$(deb_version)
Once in stable mode, it'll become xen_2.0-$(deb_version)
Last question, should I stick to using xen-devel for debian related xen
threads, or should I move off into another list? I'm inclined to stay
here if the list mods think that it's apropriate. Don't wanna clutter
with debian specific topics too much. :)
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel