Re: Xenial/grub2: Changes for Xen

[Ian Campbell]

On Tue, 2015-12-01 at 09:49 +0100, Stefan Bader wrote:
> On 30.11.2015 18:22, Mathieu Trudel-Lapierre wrote:
> > On Mon, Nov 30, 2015 at 10:01 AM, Stefan Bader  > com
> > > wrote:
> > [...]
> > 
> > Currently I do a /etc/grub.d/xen.cfg which, apart from adding a
> > nicely separated
> > place for Xen specific grub options (which I think is worth
> > keeping), adds an
> > override string to boot into Xen by default. A better way for that
> > long term
> > seems to be to simply change the order of the generator script
> > (/etc/grub.d/20_linux_xen). This only generates a real section if
> > there is a Xen
> > hypervisor installed and doing that a user likely also wants that
> > to become the
> > default. So the question is whether it sounds reasonable to rename
> > 20_linux_xen
> > into something like 09_xen?
> > 
> > 
> > I'm not opposed to that, but it's worth checking with the Debian GRUB
> > maintainers too, since we usually try to keep grub in sync.
> 
> Fair point. I added Colin and Ian. Actually Ian may remember some of the 
> details
> about multiboot that I forgot. And maybe it makes sense to reach out to
> pkg-xen-devel and if a similar list exists for grub2 to that as well.

I've long thought that reordering 10_linux and 20_linux_xen would make
sense as an upstream fix even, I just never got around to doing anything
about it (IIRC).

> > The the other thing probably needs more change than only grub: For a 
> > while now
> > xen-hypervisor ships a version that is normally used from grub (using 
> > multiboot)
> > and an EFI executable. The normal version cannot be used on UEFI 
> > systems because
> > multiboot protocol has some shortcomings and there is no way to 
> > transfer control
> > in a way to allow to get the memory layout (as one example).
> > Currently 20_linux_xen generates two grub entries, one for xen-*.gz and 
> > one for
> > xen-*.efi. The latter plainly is wrong and has only gone unnoticed 
> > because the
> > former is selected by default. But I would propose the following change:
> > 
> > 
> > We most likely don't want to use the .efi image at all, if we want to 
> > maintain
> > the behavior of simply booting via grub for both methods. One use of the 
> > .efi
> > image is probably because you can more easily enforce the signature on that 
> > EFI
> > binary, but it doesn't seem to me like something we'd go out of our way to 
> > sign
> > anyway.
> 
> I agree. Its also simpler to find the choice between Xen and normal boot 
> there.
> So I, too, would prefer any solution that keeps grub as the integration point.

You currently can't boot xen.efi via grub in the normal way, you have to
chainload and provide (somehow) a xen.cfg per http://xenbits.xen.org/docs/u
nstable/misc/efi.html otherwise all sorts of things fail. I think most
people just register xen.efi with the firmware rather than laundering via
grub, although with chainloading I think both are supposed to work equally
well.

Daniel Kiper from Oracle is working with upstream grub2 and Xen to make
"normal" booting work properly, by defining a multiboot handover mechanism
for EFI apps (I've not been keeping up with the specifics).

Probably all of this is best discussed on either pkg-grub-devel and/or the
upstream xen/grub devel lists.

Ian.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: arm64 Debian/Ubuntu port image available

[Ian Campbell]

On Wed, 2013-02-27 at 13:37 +, Wookey wrote:
 I had to choose between getting this working in vaguely finite time
 and keeping both Debian and Ubuntu bootstraps in sync, so unstable
 just got stuck at the 'toolchain bootstrap needed' stage.

That's quite reasonable

 Is raring useful to you or do you need sid? Once the toolchain is done it
 shouldn't be _too_ much work to get Debian uptodate although there
 will be a _lot_ of patched packages. 

Raring is fine, just reached for Debian out of habit etc.

To be honest I'm probably getting a little bit ahead of myself anyway --
I'm working on aarch64 guest support for Xen at the minute and your mail
prompted me to wonder how hard it would be to build the Xen tools for
arm64 in a multiarch environment, to some extent the toolchain is the
least of my worries ;-).

Ian.
-- 
Ian Campbell

A witty saying proves nothing, but saying something pointless gets
people's attention.


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: arm64 Debian/Ubuntu port image available

[Ian Campbell]

On Wed, 2013-02-27 at 02:10 +, Wookey wrote:
 
 Setting up an arm64 build environment is very simple. Use sbuild-createchroot 
 or mk-sbuild
 and point at the bootstrap repo, with a bit of config and some updated tools 
 packages from
 the repo (amd64 only supplied). Details are given on
 https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap 

I think these are missing a dpkg --add-architecture arm64 at some
point before apt-get update / install crossbuild-essential-arm64 ?

I tried to adjust those instructions to something similar for Sid + the
debian-bootstrap repo but there were unmet dependencies of
crossbuild-essential-arm64 (libc, pkgbinarymangler), but I get the
impression that is to be expected at this stage?

Ian.
-- 
Ian Campbell

Alea iacta est.
[The die is cast]
-- Gaius Julius Caesar


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel