Xen devel - Mar 2006 - domUloader kernel command line arguments?

domUloader potentially makes my life a lot easier, but from experiments 
and looking at the code, it doesn''t seem like there is any way to pass 
kernel command line arguments with it. Am I just missing something?

Thanks,

John Byrne


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi John,

On Thu, Mar 09, 2006 at 06:29:57PM -0800, John Byrne
wrote:
> domUloader potentially makes my life a lot easier, but from experiments 
> and looking at the code, it doesn''t seem like there is any way to
pass
> kernel command line arguments with it. Am I just missing something?
No, it has been an oversight on the way domUloader was integrated
into xen. The XendBootloader assumes that the bootloader would
pass the kernel command line parameters back as (arg ...).
domUloader does not do that, as it does not use an external
configuration file where these would be specified.

Attached patch addresses this: If the bootloader does NOT return
anything as args, the values from the config file (ip, boot, extra)
will be filled in.

You need to apply this on top of the other domUloader patches.
Let me know if this addresses your problem.

Best,
-- 
Kurt Garloff, Head Architect Linux, Novell Inc.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Kurt Garloff wrote:
> 
> You need to apply this on top of the other domUloader patches.
> Let me know if this addresses your problem.
On a side note, WILL domUloader ever be integrated into Xen? I much 
prefer it over pygrub as it will read from a filesystem (vs partitions) 
and relies on the host FS support (so JFS/XFS are no problem).

I know there were some complaints to the implementation, but is work 
being done to make sure that domUloader does not die as a project?

Thanks,
Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Matt,

On Fri, Mar 10, 2006 at 09:20:21AM -0500, Matt Ayres
wrote:
> Kurt Garloff wrote:
> 
> >
> >You need to apply this on top of the other domUloader patches.
> >Let me know if this addresses your problem.
> 
> On a side note, WILL domUloader ever be integrated into Xen? 
Don''t know. I definitely would like to see it integrated.
I haven''t been able to follow the list too well the last weeks, so
I''m not aware of the latest discussion status on this.
> I much 
> prefer it over pygrub as it will read from a filesystem (vs partitions) 
> and relies on the host FS support (so JFS/XFS are no problem).
It should not come as a surprise that I like it as well :-)
> I know there were some complaints to the implementation, 
I''m aware of two complaints
(1) security concerns (you _mount_ the FS in dom0)
(2) the use of kpartx from multipath-tools which seems to be missing
    from some ancient distros

Anything else you are aware of?

(1) is a feature and it''s the reason why we probably will have pygrub
    coexist with domUloader :-(
(2) we could help, by using fdisk -l and losetup rather than kpartx
    if the latter is missing; though fdisk -l would limit the supported
    partition tables to DOS ones.
> but is work 
> being done to make sure that domUloader does not die as a project?
Well, domUloader is shipped and used by Novell.
I guess I should set up a project page somewhere in case we can''t
get it included in Xen.

Regards,
-- 
Kurt Garloff, Head Architect Linux, Novell Inc.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On Fri, Mar 10, 2006 at  8:25 AM, in message
<20060310152554.GK5766@tpkurt.garloff.de>, Kurt Garloff
<garloff@suse.de> wrote: 
> (2) we could help, by using fdisk -l and losetup rather than kpartx
>     if the latter is missing; though fdisk -l would limit the
supported
>     partition tables to DOS ones.
BTW:  lomount in the xen tree is working pretty well for me now; it
automates those two steps.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Kurt Garloff wrote:
> 
>> but is work 
>> being done to make sure that domUloader does not die as a project?
> 
> Well, domUloader is shipped and used by Novell.
> I guess I should set up a project page somewhere in case we can''t
> get it included in Xen.
> 
That is all I needed to hear.  Thanks.

In the case pygrub is the one and only boot loader then that means it 
must supersede domUloader in features.

Thanks!
Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > I know there were some complaints to the implementation,
> 
> I''m aware of two complaints
> (1) security concerns (you _mount_ the FS in dom0)
This is certainly a fair concern. I''d wager most linux filesystem code
can quite easily be subverted by a maliciously crafted on-disk bit
pattern.
> (2) the use of kpartx from multipath-tools which seems to be missing
>     from some ancient distros
Not so ancient... I''ve never managed to make kpartx work on anything
other than a SuSE distro.
> Anything else you are aware of?
> 
> (1) is a feature and it''s the reason why we probably will have
pygrub
>     coexist with domUloader :-(
> (2) we could help, by using fdisk -l and losetup rather than kpartx
>     if the latter is missing; though fdisk -l would limit the 
> supported
>     partition tables to DOS ones.
I''m not a fan of pygrub as that requires very new versions of the
filesystem libraries (to support "open2" and hence patition table
offsets).

Perhaps we should be considering having both in tree? I''ve somewhat
lost
track of where we are in the discussion as regards to support for Sun''s
UFS. Could someone please generate a summary?

Thanks,
Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Mar 10, 2006 at 11:41:40PM -0000, Ian Pratt wrote:
> I''m not a fan of pygrub as that requires very new versions of the
> filesystem libraries (to support "open2" and hence patition table
> offsets).
> 
> Perhaps we should be considering having both in tree? I''ve
somewhat lost
> track of where we are in the discussion as regards to support for
Sun''s
> UFS. Could someone please generate a summary?
I sent a proposal regarding the configuration format for bootloaders.
Jeremy had some issues that centered around:

o he didn''t like the format I suggested. I proposed one closer to that
  currently provided, but haven''t had a response to that yet

o he believes that the current "supply a Python module" interface to
  file systems is OK and that all domu''s are expected to provide GPLed
  sources (not necessarily a huge problem for us but I do worry about
  other situations in the future).

o he pointed out that for Fedora/RHEL, the current solution is
  sufficient.

o he appeared to be against the notion of enabling other boot loaders
  beyond the current (limited) interface

Apologies if I''ve mis-represented anything here; Jeremy''s
posts are not
available in the mail archives.

There was general agreement that a solution that defers all
configuration to the domu such as grub xen support was the best
long-term option. I do not think that this affects the current
discussion, however.

I believe the biggest issue that needs to be resolved is where the
filesystem-reading code belongs. I''ve been advocating that the relevant
dom0 systems provide a ''readfs'' binary that defer to
particular
implementations for each file system. This would help take the
maintenance burden off the Xen project itself, and centralise all FS
handling in one sensible place. (In particular, such a project could
easily ship with its own ext2fs library so the open2 support issue goes
away for now). So far this idea does not seem popular, but I''ve not
received any details as to why. I believe that an opaque interface
provided by a command line binary is safer in the mid/long-term than
requiring a Python module to be delivered, mainly due to the fact that
Python is still changing incompatibly, and the stability of the internal
pygrub API is under doubt (Jeremy has mentioned he wants to make changes
already).

My changes should also work well with Kurt''s loader which Novell are
using. As a by-product it resolves some of the problems with the
bootloader interface that domUloader has.

I hope I''ve not missed anything important here; corrections are
welcome.

regards,
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Ian,

On Fri, Mar 10, 2006 at 11:41:40PM -0000, Ian Pratt
wrote:
> > > I know there were some complaints to the implementation,
> > 
> > I''m aware of two complaints
> > (1) security concerns (you _mount_ the FS in dom0)
> 
> This is certainly a fair concern. I''d wager most linux filesystem
code
> can quite easily be subverted by a maliciously crafted on-disk bit
> pattern.
You underestimate the quality of Linux FS. Keep in mind that these would
all be vulnerabilities that you''d be able to exploit by inserting CDs
or USB sticks as a normal user.
That said, it would certainly be good to audit the FS code and I would
expect that the kernel FS implementations are not prefect in that area,
especially not the less commonly used ones. FS metadata could have been
considered trusted prior to the invention of removable media. 
> > (2) the use of kpartx from multipath-tools which seems to be missing
> >     from some ancient distros
> 
> Not so ancient... I''ve never managed to make kpartx work on
anything
> other than a SuSE distro.
Strange.
Should I try to provide multipath-tools RPMs/DEBs for other distros?
> > (1) is a feature and it''s the reason why we probably will
have pygrub
> >     coexist with domUloader :-(
> > (2) we could help, by using fdisk -l and losetup rather than kpartx
> >     if the latter is missing; though fdisk -l would limit the
supported
> >     partition tables to DOS ones.
> 
> I''m not a fan of pygrub as that requires very new versions of the
> filesystem libraries (to support "open2" and hence patition table
> offsets).
> 
> Perhaps we should be considering having both in tree? I''ve
somewhat lost
> track of where we are in the discussion as regards to support for
Sun''s
> UFS. Could someone please generate a summary?
I you want an fdisk -l losetup / lomount fallback for domUloader to make
it usable by more people, that would be something I could work on.

Best,
-- 
Kurt Garloff, Head Architect Linux, Novell Inc.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel