Xen devel - Oct 2004 - Unofficial Xen 2.0 debian packages kinda broken

I''m not sure if this is the correct place to get the message through.

The unofficial Debian packages of Xen 2.0 found in:

  http://www.terrabox.com/debian/binary/

are more or less broken. They have versions such as:

  Version: 2.0_0.20041018_1.1401

Having underscores in versions is not really supported - and the
latest packages even lack the debian package version (even though the
Xen packages are not Debian native).

Perhaps a version such as 2.0+bk.20041018.1.1.401-1 would be more
suited - but even this carries the problem that a real 2.0-1 release
would be ''older'' than such a revision. But this is not such a
big
issue since the packages are not official and people can
''downgrade''
to the official packages when they come.

-- Naked



-------------------------------------------------------
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

I''ll correct the versioning with the next set. Got a bit tired when I
altered the version info. 8-P Maybe I can simply stick with 2.0-0.tagset
and save 2.0-1 for the official. :)

These packages will eventually (If Adam approves them) be sponsored as a
part of debian testing. It''s too late to make it into Sarge from what I
understand ( I could be wrong.)

Brian


On Thu, 2004-10-21 at 06:26, Nuutti Kotivuori wrote:
> I''m not sure if this is the correct place to get the message
through.
> 
> The unofficial Debian packages of Xen 2.0 found in:
> 
>   http://www.terrabox.com/debian/binary/
> 
> are more or less broken. They have versions such as:
> 
>   Version: 2.0_0.20041018_1.1401
> 
> Having underscores in versions is not really supported - and the
> latest packages even lack the debian package version (even though the
> Xen packages are not Debian native).
> 
> Perhaps a version such as 2.0+bk.20041018.1.1.401-1 would be more
> suited - but even this carries the problem that a real 2.0-1 release
> would be ''older'' than such a revision. But this is not
such a big
> issue since the packages are not official and people can
''downgrade''
> to the official packages when they come.
> 
> -- Naked
> 
> 
> 
> -------------------------------------------------------
> 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


-------------------------------------------------------
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

Dangit, I am getting tired tonight as well. 8-P

I forgot to mention that after today everyone can expect daily
(sometimes more often) debs as the xeno-unstable.bk tree is updated. I
just need to receive an email when a change is checked in to trigger the
update. Probably set a 15 minutes time delay just in case someone makes
a quickie update. ;)

Ian, any way to get notices via email to an address that I can then use
to trigger the deb creation?

On Thu, 2004-10-21 at 06:26, Nuutti Kotivuori wrote:
> I''m not sure if this is the correct place to get the message
through.
> 
> The unofficial Debian packages of Xen 2.0 found in:
> 
>   http://www.terrabox.com/debian/binary/
> 
> are more or less broken. They have versions such as:
> 
>   Version: 2.0_0.20041018_1.1401
> 
> Having underscores in versions is not really supported - and the
> latest packages even lack the debian package version (even though the
> Xen packages are not Debian native).
> 
> Perhaps a version such as 2.0+bk.20041018.1.1.401-1 would be more
> suited - but even this carries the problem that a real 2.0-1 release
> would be ''older'' than such a revision. But this is not
such a big
> issue since the packages are not official and people can
''downgrade''
> to the official packages when they come.
> 
> -- Naked
> 
> 
> 
> -------------------------------------------------------
> 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


-------------------------------------------------------
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

> I forgot to mention that after today everyone can expect daily
> (sometimes more often) debs as the xeno-unstable.bk tree is updated. I
> just need to receive an email when a change is checked in to trigger the
> update. Probably set a 15 minutes time delay just in case someone makes
> a quickie update. ;)
> 
> Ian, any way to get notices via email to an address that I can then use
> to trigger the deb creation?
Just sign up for the xen-changelog mailing list at
sourceforge. Rik does a pull once an hour an sends out the changelog.

Ian


-------------------------------------------------------
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

Brian Wolfe wrote:
> Maybe I can simply stick with 2.0-0.tagset and save 2.0-1 for the
> official. :)
Sounds fine by me - uncomplicated and works.
> These packages will eventually (If Adam approves them) be sponsored
> as a part of debian testing. It''s too late to make it into Sarge
> from what I understand ( I could be wrong.)
Very nice!

-- Naked



-------------------------------------------------------
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

Daaaang was my head messed up last night. 8-P This just proves the point
of "don''t hack when dead tired". *sigh*

  * fixed RULES target to point to /usr/bin/
  * fixed minor case of ARCH flags in make (aesthetic)
  * added help target to xlb
  * fixed out of order dependancy in xen_patch for extract_linux

I''m certain that many more bugs exist. So if youi use debian and are
brave enough to test my stuff out, I would greatly appreciate it!

Thanks!
Brian



On Thu, 2004-10-21 at 23:15, Brian Wolfe wrote:
> I''ll correct the versioning with the next set. Got a bit tired
when I
> altered the version info. 8-P Maybe I can simply stick with 2.0-0.tagset
> and save 2.0-1 for the official. :)
> 
> These packages will eventually (If Adam approves them) be sponsored as a
> part of debian testing. It''s too late to make it into Sarge from
what I
> understand ( I could be wrong.)
> 
> Brian
> 
> 
> On Thu, 2004-10-21 at 06:26, Nuutti Kotivuori wrote:
> > I''m not sure if this is the correct place to get the message
through.
> > 
> > The unofficial Debian packages of Xen 2.0 found in:
> > 
> >   http://www.terrabox.com/debian/binary/
> > 
> > are more or less broken. They have versions such as:
> > 
> >   Version: 2.0_0.20041018_1.1401
> > 
> > Having underscores in versions is not really supported - and the
> > latest packages even lack the debian package version (even though the
> > Xen packages are not Debian native).
> > 
> > Perhaps a version such as 2.0+bk.20041018.1.1.401-1 would be more
> > suited - but even this carries the problem that a real 2.0-1 release
> > would be ''older'' than such a revision. But this is
not such a big
> > issue since the packages are not official and people can
''downgrade''
> > to the official packages when they come.
> > 
> > -- Naked
> > 
> > 
> > 
> > -------------------------------------------------------
> > 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
> 
> 
> 
> -------------------------------------------------------
> 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


-------------------------------------------------------
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

I finished a BUNCH of min-changes last night and moved the bad-numbered
debs out of the main terrabox debian repo. So if anyone is pulling from
terrabox.com/debian, you will need to override the package version to
"downgrade" to the newer packages (that seems liek a rather strange
concept, but, eh, my bad on the versioning. ;) )

I''ve also altered the depends so that all of the packages depend on
that
releases specific version. No more mix-and-match of packages possible (I
think, so watch for a missing depends, tried to tie them all to xen or
libxc2.0).

XenLinux-Builder is also cleaned up a bit more and now has a couple new
targets. See /usr/share/doc/xenlinux-builder/README for more info on
help, pristine, and other targets.

Nuutti, if you did anythign special for your debianizing that beats
anythign i''ve done so far, I''d love to take a peek at your
ideas. :)
Some fo this has been hurting my brain (patch conversion for example).

Thanks!


On Fri, 2004-10-22 at 07:35, Nuutti Kotivuori wrote:
> Brian Wolfe wrote:
> > Maybe I can simply stick with 2.0-0.tagset and save 2.0-1 for the
> > official. :)
> 
> Sounds fine by me - uncomplicated and works.
> 
> > These packages will eventually (If Adam approves them) be sponsored
> > as a part of debian testing. It''s too late to make it into
Sarge
> > from what I understand ( I could be wrong.)
> 
> Very nice!
> 
> -- Naked
> 
> 
> 
> -------------------------------------------------------
> 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


-------------------------------------------------------
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

Brian Wolfe wrote:
> So if anyone is pulling from terrabox.com/debian, you will need to
> override the package version to "downgrade" to the newer packages
> (that seems liek a rather strange concept, but, eh, my bad on the
> versioning. ;) )
Yes, did that already, seemed to work fine now.
> XenLinux-Builder is also cleaned up a bit more and now has a couple
> new targets. See /usr/share/doc/xenlinux-builder/README for more
> info on help, pristine, and other targets.
>
> Nuutti, if you did anythign special for your debianizing that beats
> anythign i''ve done so far, I''d love to take a peek at
your ideas. :)
> Some fo this has been hurting my brain (patch conversion for
> example).
The idea of xenlinux-builder is kind of nice - and it is probably very
useful for some people.

I, however, do not wish to treat Xen builds in any way special from
the way I build my normal host kernels - or from the way I build
user-mode-linux kernels. That is, for me, the procedure is:

  - unpack kernel tarball to /usr/src/kernel-source-x.x.x
  - throw in patches (some debianized, some not)
  - run menuconfig (with appropriate arch if building um/xen kernels)
  - make-kpkg clean
  - make-kpkg kernel-image

And for xen specifically, I use mkbuildtree from the xen directory
first get the symlinks in for xen files to the kernel directory. A
patch would be much nicer, since I use ''quilt'' for patch
management on
the kernel tree. And the final line for me to build the xen kernel is:

  make-kpkg --arch=xen --subarch=xen0 --append-to-version=-shiro-1 --revision=1
kernel-image

So, no, I don''t have any magic tricks to do these things - but I
don''t
want to use a special builder for xen, um or anything else, if I don''t
build *all* my kernels with it.

-- Naked



-------------------------------------------------------
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

*nod* This is part of why I did it. make-kpkg is just now getting some
kind of xen arch support from what I understand, and aparantly it does
since you are using it :). But it''s specific to debian. I wanted to
make
xenlinux-builder to be distro-agnostic at it''s core and THEN use a few
distro specific tricks to assume compatibility. This way if an admin
needs to compile other OS kernels for xen, they use the same tool as you
said for xen kernels.:) Plus I dislike having to specify so many command
line options. I''d rather have a config file that the kernel builder
snakes the arch options etc from automagically. ;) But hey, each admin
has their own magical formula. *grin* 

Where does make-kpkg stick the ekrnel and modules for unprived domains?
I''m assuming still in /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.

Right now i''m playing with some ideas on how to best manage patchfiles.
I''m thinking of possibly using a configs/$(CONFIGFILE).patches control
file.

What kind of 3rd part patches have you been using with xen so far? How
have you managed to not hit the brokenness of running mkbuildtree
against the debianized kernel-source-x.x.x packages!? 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 also suspect a couple subtle issues when using the mkbuildtree on the
debian kernel-source-x.x.x packages. Haven''t botherd to track em since
they went away once I started converting things prior to patching.

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.

This is why I converted to a unified diff durign the debianizing of xen.
Specificly to FIX the areas where the xen sparse tree removes some
Debian patches to the kernel source. 8-P

Also, as a reminder to anyone else using the tb.c debian repo. Right now
the packages change pretty much daily. Once xen2.0 is official, the main
repo will become the stable packages. At that point I''ll start a new
repo at /debian-xen-unstable for continuing bleeding edge packages. :)

Sorry for the spanish inquisition Nuutti. :)

Brian

On Sat, 2004-10-23 at 08:49, Nuutti Kotivuori wrote:
> Brian Wolfe wrote:
> > So if anyone is pulling from terrabox.com/debian, you will need to
> > override the package version to "downgrade" to the newer
packages
> > (that seems liek a rather strange concept, but, eh, my bad on the
> > versioning. ;) )
> 
> Yes, did that already, seemed to work fine now.
> 
> > XenLinux-Builder is also cleaned up a bit more and now has a couple
> > new targets. See /usr/share/doc/xenlinux-builder/README for more
> > info on help, pristine, and other targets.
> >
> > Nuutti, if you did anythign special for your debianizing that beats
> > anythign i''ve done so far, I''d love to take a peek
at your ideas. :)
> > Some fo this has been hurting my brain (patch conversion for
> > example).
> 
> The idea of xenlinux-builder is kind of nice - and it is probably very
> useful for some people.
> 
> I, however, do not wish to treat Xen builds in any way special from
> the way I build my normal host kernels - or from the way I build
> user-mode-linux kernels. That is, for me, the procedure is:
> 
>   - unpack kernel tarball to /usr/src/kernel-source-x.x.x
>   - throw in patches (some debianized, some not)
>   - run menuconfig (with appropriate arch if building um/xen kernels)
>   - make-kpkg clean
>   - make-kpkg kernel-image
> 
> And for xen specifically, I use mkbuildtree from the xen directory
> first get the symlinks in for xen files to the kernel directory. A
> patch would be much nicer, since I use ''quilt'' for patch
management on
> the kernel tree. And the final line for me to build the xen kernel is:
> 
>   make-kpkg --arch=xen --subarch=xen0 --append-to-version=-shiro-1
--revision=1 kernel-image
> 
> So, no, I don''t have any magic tricks to do these things - but I
don''t
> want to use a special builder for xen, um or anything else, if I
don''t
> build *all* my kernels with it.
> 
> -- Naked
> 
> 
> 
> -------------------------------------------------------
> 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


-------------------------------------------------------
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

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.
> 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.
> What kind of 3rd part patches have you been using with xen so far? 
I''ve put in some netfilter patches.
> 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.
> 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 ;)
> Sorry for the spanish inquisition Nuutti. :)
No problem, glad to give a different point of view.

-- Naked


-------------------------------------------------------
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

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

Brian Wolfe wrote:
> On Sat, 2004-10-23 at 09:31, Nuutti Kotivuori wrote:
>>  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?
Well, making the tool is not high on my to-do list, so no need to
consider these matters yet too thoroughly.

Apparently somebody else has thought about something similar as I
stumbled upon this in the experimental debian archive:

Package: sourcerer-kernel-builder
Description: automatically build new custom kernels on source upgrades
 Sourcerer-kernel-builder tracks changes in the kernel-source,
 kernel-patch and kernel-modules packages and rebuilds kernel-images
 with a custom configuration whenever packages relevant to it change.
 Sourcerer-kernel-builder also provides a frontend to manage those
 custom configuration alowing users to choose what patches and modules
 they want included.
 ...
> 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.
Standard Xen kernel images would be really nice, yes.
> 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)
Um. Can you have two dashes in package versions? I thought there was
only one dash and it was to separate the debian version from the
upstream version.

If you wish to have the bk_patchlevel in the upstream version part and
still get the upgrade nicely, I think one needs to do the ugly ugly
format used by several packges.

1.999+2.0.bk.1.1092-1

But like said, these aren''t the official packages yet, so versioning
doesn''t really matter - 2.0-1 should be the first official package and
that matters.

-- Naked



-------------------------------------------------------
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

On Sun, 2004-10-24 at 19:07, Nuutti Kotivuori wrote:
> Brian Wolfe wrote:
> > On Sat, 2004-10-23 at 09:31, Nuutti Kotivuori wrote:
> >>  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?
> 
> Well, making the tool is not high on my to-do list, so no need to
> consider these matters yet too thoroughly.
> 
> Apparently somebody else has thought about something similar as I
> stumbled upon this in the experimental debian archive:
> 
> Package: sourcerer-kernel-builder
> Description: automatically build new custom kernels on source upgrades
>  Sourcerer-kernel-builder tracks changes in the kernel-source,
>  kernel-patch and kernel-modules packages and rebuilds kernel-images
>  with a custom configuration whenever packages relevant to it change.
>  Sourcerer-kernel-builder also provides a frontend to manage those
>  custom configuration alowing users to choose what patches and modules
>  they want included.
>  ...
> 
Nift. Though i''m aiming xlb as more of a platform-agnostic tool with
some nifts for specific distros. 
> > 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.
> 
> Standard Xen kernel images would be really nice, yes.
> 
> > 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)
> 
> Um. Can you have two dashes in package versions? I thought there was
> only one dash and it was to separate the debian version from the
> upstream version.
You can have a dash in the upstream IF and only if you have a debian
version appended with the dash.
> 
> If you wish to have the bk_patchlevel in the upstream version part and
> still get the upgrade nicely, I think one needs to do the ugly ugly
> format used by several packges.
> 
> 1.999+2.0.bk.1.1092-1
> 
> But like said, these aren''t the official packages yet, so
versioning
> doesn''t really matter - 2.0-1 should be the first official package
and
> that matters.
*nod* I''m goign to go with the above mentioned plan unless someone
throws a snit fit. :) It''ll work, and it''ll let people know
exactly what
bk revision it is since there isn''t any other versioning besides 1.2,
2.0, unstable.....

When 2.0 is official, I''ll stick with the versions and just create a
new
debian/ repo for them.
> 
> -- Naked
> 
> 
> 
> -------------------------------------------------------
> 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


-------------------------------------------------------
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

On Sat, 23 Oct 2004, Nuutti Kotivuori wrote:
> 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.
Do you really want to allow your virtualized users to be able to change the
kernel?


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader''s Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Sat, 23 Oct 2004, Brian Wolfe wrote:
> *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)
Er, bad.  If you have install-time placement of files, then dpkg -S
doesn''t
work right.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader''s Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Adam Heath wrote:
> On Sat, 23 Oct 2004, Brian Wolfe wrote:
>
>> *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)
>
> Er, bad.  If you have install-time placement of files, then dpkg -S
> doesn''t work right.
I understood this completely differently - I thought this pre-install
debconf question to be for the xen linux builder package. But now that
I think about it more, that would be silly, since it could just as
well be put as a question while building the kernel.

-- Naked




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader''s Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Adam Heath wrote:
> Do you really want to allow your virtualized users to be able to
> change the kernel?
Yes. In some cases.

There are cases where strict separation is not an issue, where
granting priviledges does not really matter.

And even where strict separation is an issue, with Xen there shouldn''t
be any problem, should there?

I mean, with UML obviously if the kernel is compromised, it can access
everything the binary can on the host - and needs to be restricted
there somehow. And if compromising the kernel shouldn''t be possible,
it gives quite a bit of restrictions on the guest side - like no
modules allowed and so.

But with Xen, the separation is on a lower layer, and there should be
no problem allowing custom built kernels with custom patches or binary
modules or whatnot.

But in any case, it is simply a choice there.

-- Naked




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader''s Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> There are cases where strict separation is not an issue, where
> granting priviledges does not really matter.
>
> And even where strict separation is an issue, with Xen there
shouldn''t
> be any problem, should there?
No problem, it''s perfectly safe in Xen for users to run whatever they
please
as a kernel.  If it tries to access things it shouldn''t, the accesses
will
safely fail.  All security is enforced by Xen.

It''d be rather nice to have a Xen "bootloader" allowing users
to choose a
kernel they''d compiled without help from a sysadmin.  This is not
technically
difficult, so it''s just a question of someone putting the time in.

HTH,
Mark


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader''s Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

As an ISP, letting the users choose their kernel is a config issue, not
a boot time issue to me. I''d rather have a customer controlpanel that
lets them choose what base config their server runs. If they want to be
able to choose, they can select, shutdown and restart their kernel from
a control panel instead of within the virtual server. It''d be cleaner
this way I think.


On Sat, 2004-10-30 at 07:16, Mark A. Williamson wrote:
> > There are cases where strict separation is not an issue, where
> > granting priviledges does not really matter.
> >
> > And even where strict separation is an issue, with Xen there
shouldn''t
> > be any problem, should there?
> 
> No problem, it''s perfectly safe in Xen for users to run whatever
they please
> as a kernel.  If it tries to access things it shouldn''t, the
accesses will
> safely fail.  All security is enforced by Xen.
> 
> It''d be rather nice to have a Xen "bootloader" allowing
users to choose a
> kernel they''d compiled without help from a sysadmin.  This is not
technically
> difficult, so it''s just a question of someone putting the time in.
> 
> HTH,
> Mark
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader''s Choice Award Winner for best database on
Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 1455
> 61 1093465360.M941750P9751V000000000000000AI3D732F26_1.mail1,S=2823
> 62 1093532573.M6981P24707V000000000000000AI3D7329E9_1.mail1,S=7780
> 63 1093537777.M236817P25913V000000000000000AI3D7330C7_1.mail1,S=12110
> 64 1093596173.M906411P6001V000000000000000AI3D7332FA_1.mail1,S=4127
> 65 1093623583.M329099P12640V000000000000000AI3D73347E_1.mail1,S=5540
> 66 1093631310.M82220P14313V000000000000000AI3D7334E8_1.mail1,S=1107
> 67 1093657998.M456283P21749V000000000000000AI3D733246_1.mail1,S=2018
> 68 1093748411.M468384P7067V000000000000000AI3D7339C9_1.mail1,S=4742
> 69 1093830423.M779709P20588V000000000000000AI3D733784_1.mail1,S=1525
> 70 1093878032.M684880P29637V000000000000000AI3D733DC0_1.mail1,S=27709
> 71 1095185186.M234030P3077V000000000000000AI3D709BA5_1.mail1,S=11820
> 72 1095185200.M237423P3117V000000000000000AI3D70A42B_1.mail1,S=12966
> 73 1095185200.M603516P3126V000000000000000AI3D70A59E_1.mail1,S=8403
> 74 1095185220.M13614P3150V000000000000000AI3D70A9E0_1.mail1,S=3815
> 75 1095185890.M136284P3598V000000000000000AI3D732D84_1.mail1,S=2210
> 78 1095186181.M25017P3741V000000000000000AI3D732DCC_1.mail1,S=1426
> 81 1095186574.M763593P3827V000000000000000AI3D732E1A_1.mail1,S=3373
> 82 1095186665.M487030P3855V000000000000000AI3D732E91_1.mail1,S=1930
> 83 1095186746.M144651P3905V000000000000000AI3D732F53_1.mail1,S=3709
> 84 1095186827.M63386P3925V000000000000000AI3D732EB3_1.mail1,S=5992457
> 85 1095186860.M843558P3952V000000000000000AI3D732F58_1.mail1,S=3446
> 97 1095193369.M173781P5273V000000000000000AI3D733966_1.mail1,S=928
> 98 1095193544.M853621P5314V000000000000000AI3D7339CB_1.mail1,S=3447
> 99 1095194114.M46100P5416V000000000000000AI3D733B7D_1.mail1,S=3455
> 100 1095194144.M643473P5435V000000000000000AI3D733B7E_1.mail1,S=3446
> 101 1095194144.M683452P5438V000000000000000AI3D733B7F_1.mail1,S=3448
> 103 1095197196.M663551P5912V000000000000000AI3D733E1C_1.mail1,S=1668
> 145 1095229506.M36033P11360V000000000000000AI3D733F5B_1.mail1,S=2078
> 146 1095229778.M893546P11389V000000000000000AI3D733F5D_1.mail1,S=1049
> 167 1095256692.M603397P14925V000000000000000AI3D73403F_1.mail1,S=2604
> 187 1095279578.M36235P18187V000000000000000AI3D734126_1.mail1,S=10248
> 193 1095288706.M565899P19587V000000000000000AI3D73418E_1.mail1,S=11651
> 196 1095291566.M733567P20006V000000000000000AI3D7341B4_1.mail1,S=5929
> 197 1095291768.M443516P20028V000000000000000AI3D7341B0_1.mail1,S=4047
> 204 1095300739.M563552P21668V000000000000000AI3D7341FE_1.mail1,S=1515
> 218 1095333799.M753369P25816V000000000000000AI3D73430B_1.mail1,S=1044
> 227 1095350135.M852132P31861V000000000000000AI3D734430_1.mail1,S=1693
> 228 1095351357.M633286P718V000000000000000AI3D7344CB_1.mail1,S=11852
> 262 1095436642.M313646P12473V000000000000000AI3D734822_1.mail1,S=7273
> 267 1095441936.M833921P13641V000000000000000AI3D734876_1.mail1,S=3081
> 274 1095452360.M233637P19025V000000000000000AI3D7348C1_1.mail1,S=1658
> 275 1095453523.M57385P19708V000000000000000AI3D7348EE_1.mail1,S=1809
> 276 1095453810.M563213P19876V000000000000000AI3D734903_1.mail1,S=20547
> 277 1095454414.M724540P20430V000000000000000AI3D73490E_1.mail1,S=2961
> 281 1095457065.M493500P22274V000000000000000AI3D734917_1.mail1,S=8841
> 288 1095462122.M864912P25728V000000000000000AI3D73496B_1.mail1,S=995
> 290 1095465813.M549933P28396V000000000000000AI3D7349B0_1.mail1,S=3069
> 291 1095473881.M283196P1159V000000000000000AI3D734A00_1.mail1,S=9224
> 292 1095476185.M394475P2913V000000000000000AI3D734A0C_1.mail1,S=15786
> 293 1095478031.M489687P3771V000000000000000AI3D734A17_1.mail1,S=3265
> 294 1095479812.M772637P4571V000000000000000AI3D734A1C_1.mail1,S=2507
> 295 1095480899.M483590P5228V000000000000000AI3D734A28_1.mail1,S=3744
> 296 1095487663.M895839P9399V000000000000000AI3D734A5E_1.mail1,S=3740
> 297 1095489522.M693086P10418V000000000000000AI3D734A75_1.mail1,S=1532
> 298 1095492184.M713278P11651V000000000000000AI3D734A8E_1.mail1,S=13355
> 299 1095496025.M796646P13638V000000000000000AI3D734AA7_1.mail1,S=9656
> 300 1095502482.M693554P17135V000000000000000AI3D734AD9_1.mail1,S=11296
> 301 1095507874.M703250P20689V000000000000000AI3D734AFB_1.mail1,S=4563
> 302 1095507990.M83224P20789V000000000000000AI3D734ADA_1.m


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader''s Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel