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

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