Initial support for ARM64
v3 cover Initial support for ARM64
The following adds support for testing on arm64 systems.
Since arm64 was only added in Debian Jessie this requires Wei's "Debian Jessie patches" as a base line, which are currently in osstest. This is therefore based on those, specifically 6e37f849f4b0.
The main development here is support for UEFI PXE booting, which is not particular to arm64, but is more prominent there. Hopefully this work would be useful for UEFI only x86 systems too.
Since last time I've adjust according to review comments and closed the UEFI boot order race!
N mg-*: Add mgi-common with fetch and fail helpers
N mg-*: Make package fetching common in new mgi-debian
M Introduce mg-pxe-loader-update
A Debian: Preseed a EFI system partition during host install
A ts-host-install: Split initrd out of @installcmdline
A ts-host-install: split the "di" from the "host" command line
M Refactor pxelinux configuration
M ts-host-install: Support UEFI PXE boot using grub.efi
Enable chain loading to local disk for UEFI PXE systems.
A Add arm64 build and test jobs
M ts-kernel-build: Additional kernel options for Mustang
N ts-kernel-build: Enable CONFIG_EFI_VARS
MA ts-host-install: Set dtbs in the non-special kernel case too.
N Debian: Do not add Debian to UEFI boot order on install
M standalone: Prefer ./local-config to $HOME/.xen-osstest/config
A Debian: grub2: Log full line range of menuentry and submenu entries
A Debian: grub2: Use GRUB_CMDLINE_LINUX_XEN_REPLACE(_DEFAULT)
A Collect xen.efi into xendist and install in appropriate place
A Debian: Ignore xen-syms entries in grub.cfg.
A Debian: Collect kernel command line from grub.cfg
M Debian: Arrange to be able to chainload a xen.efi from grub2
! Enable CONFIG_SPARSEMEM_VMEMMAP, arm64 seems to needs it (crashes).
A -- Acked
M -- Modified
N -- New
! -- please ignore the man behind the curtain.
Ian.
PATCH v3 1/22 mg-*: Add mgi-common with fetch and fail helpers
Taken from both mg-cpu-microcode-update and mg-debian-installer-update
---
v3: New patch
--- mg-cpu-microcode-update | 3 ++- mg-debian-installer-update | 8 +------- mgi-common | 26 ++++++++++++++++++++++++++ 3 files changed, 29 insertions(+), 8 deletions(-) create mode 100644 mgi-common
mg-cpu-microcode-update +2 -1
@@ -3,6 +3,7 @@ set -e . cri-getconfig +. mgi-common # iucode_tool is in /usr/sbin, see #788459. export PATH="/usr/local/sbin:$PATH:/sbin:/usr/sbin"
@@ -41,7 +42,7 @@ INTEL_TGZ='http://downloadmirror.intel.com/24661/eng/microcode-20150121.tgz' mkdir intel-ucode echo >&2 "Fetching Intel ucode" -curl -s $INTEL_TGZ > intel-ucode/microcode.tgz +fetch $INTEL_TGZ > intel-ucode/microcode.tgz tar -C intel-ucode -xaf intel-ucode/microcode.tgz microcode.dat
mg-debian-installer-update +1 -7
@@ -22,21 +22,15 @@ set -e . cri-getconfig +. mgi-common suite=$1 arch=$2 packages="$3" -fail () { echo >&2 "$0: $1"; exit 1; } - site=http://ftp.debian.org/debian/ sbase=$site/dists/$suite -fetch () { - # no-cache due to intercepting proxies messing things up. - curl -s -H 'Pragma: no-cache' $1 -} - case ${suite}_${arch} in lenny_armhf|squeeze_armhf|lenny_arm64|squeeze_arm64|wheezy_arm64) # No such thing.
mgi-common new file +26 -0
@@ -0,0 +1,26 @@ +# -*- bash -*- + +# Helpers for mg-* +# +# This is part of "osstest", an automated testing framework for Xen. +# Copyright (C) 2015 Citrix Inc. +# +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU Affero General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU Affero General Public License for more details. +# +# You should have received a copy of the GNU Affero General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +fail () { echo >&2 "$0: $1"; exit 1; } + +fetch () { + # no-cache due to intercepting proxies messing things up. + curl -s -H 'Pragma: no-cache' $1 +}
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 01/22] mg-*: Add mgi-common with fetch and fail helpers
Ian Campbell writes ("[PATCH OSSTEST v3 01/22] mg-*: Add mgi-common with fetch and fail helpers"):
Quoted 1 line
Taken from both mg-cpu-microcode-update and mg-debian-installer-update
PATCH v3 2/22 mg-*: Make package fetching common in new mgi-debian
In reply to Ian CampbellThis pattern appears several times in mg-debian-installer-update and I'm about to add another script which uses it.
The centralised version always does "sort -n -r | head -n" to pick out only the newest version, which only some of the open coded sites did.
Likewise the centralised version checks that $pkgfile is non-empty, unlike some of the open coded sites.
---
v3: New patch
--- mg-debian-installer-update | 34 +++++++++------------------------- mgi-debian | 38 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 47 insertions(+), 25 deletions(-) create mode 100644 mgi-debian
mg-debian-installer-update +9 -25
@@ -23,6 +23,7 @@ set -e . cri-getconfig . mgi-common +. mgi-debian suite=$1 arch=$2
@@ -59,8 +60,6 @@ case ${suite}_${arch} in ;; esac -pfile=$sbase/non-free/binary-$arch/Packages.gz - dstroot=`getconfig TftpPath`/`getconfig TftpDiBase`/ date=`date +%Y-%m-%d`-$suite dst=$arch/$date
@@ -85,16 +84,13 @@ if [ "x$dtbs" != "x" ] ; then gzip -9nf dtbs.tar fi +pfile=$sbase/non-free/binary-$arch/Packages.gz + fetch $pfile >Packages.gz for p in $packages; do - set +e echo >&2 "collecting $p" - pkgfile=`zcat Packages.gz | grep-dctrl -PX $p -nsFilename` - rc=$? - set -e - if [ $rc != 0 ]; then fail "package $p not found"; fi - fetch "$site/$pkgfile" >$p.deb + fetch_package "$site" Packages.gz -PX $p >$p.deb rm -rf x dpkg-deb -x $p.deb x cd x; pax -x sv4cpio -s '%lib%/lib%' -w -M norm lib >../cpio; cd ..
@@ -117,30 +113,18 @@ if [ x$bpok != x ]; then if [ x$need_initramfs = xy ]; then # Newer kernel often needs a newer initramfs-tools. Make that - # available + # is available echo >&2 "collecting backports initramfs-tools" - pkgfile=`zcat Packages.gz \ - | grep-dctrl -PX initramfs-tools -nsFilename \ - | sort -n -r | head -n1` - rc=$? - set -e - if [ $rc -ne 0 ] || [ x$pkgfile = x ]; then - fail "initramfs-tools package not found"; - fi - fetch "$site/$pkgfile" >initramfs-tools.deb + fetch_package $site Packages.gz -PX initramfs-tools \ + >initramfs-tools.deb fi set +e echo >&2 "collecting backports kernel" # Be careful to pickup the actual kernel package from the 'linux' # source and not a meta package from 'linux-latest' - pkgfile=`zcat Packages.gz | grep-dctrl -S linux \ - | grep-dctrl -Pe ^linux-image-.*-${bpok}$ -nsFilename \ - | sort -n -r | head -n1` - rc=$? - set -e - if [ $rc != 0 ]; then fail "backports kernel package not found"; fi - fetch "$site/$pkgfile" >backports.deb + fetch_package $site Packages.gz -Pe ^linux-image-.*-${bpok}$ \ + >backports.deb dpkg-deb -x backports.deb x cp x/boot/vmlinuz-* linux.backports # The full set of modules is pretty large and not that
mgi-debian new file +38 -0
@@ -0,0 +1,38 @@ +# -*- bash -*- + +# Helpers for mg-* dealing with Debian. +# +# This is part of "osstest", an automated testing framework for Xen. +# Copyright (C) 2015 Citrix Inc. +# +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU Affero General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU Affero General Public License for more details. +# +# You should have received a copy of the GNU Affero General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# Arguments: <Base URL> <Packages.gz> <grep-dctrl arguments> +# +# nb: -nsFilename argument to grep-dctrl is supplied here +fetch_package () { + local site=$1 ; shift 1 + local pgz=$1 ; shift 1 + + set +e + pkgfile=`zcat $pgz | grep-dctrl $@ -nsFilename | sort -n -r | head -n1` + rc=$? + set -e + + if [ $rc -ne 0 ] || [ x$pkgfile = x ]; then + fail "package matching $@ not found"; + fi + + fetch "$site/$pkgfile" +}
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 02/22] mg-*: Make package fetching common in new mgi-debian
Ian Campbell writes ("[PATCH OSSTEST v3 02/22] mg-*: Make package fetching common in new mgi-debian"):
Quoted 8 lines
This pattern appears several times in mg-debian-installer-update and I'm about to add another script which uses it.
The centralised version always does "sort -n -r | head -n" to pick out only the newest version, which only some of the open coded sites did.
Likewise the centralised version checks that $pkgfile is non-empty, unlike some of the open coded sites.
Although, another option would be to put this in mgi-common and call it "fetch_debian_package".
Ian.
Re: [PATCH OSSTEST v3 02/22] mg-*: Make package fetching common in new mgi-debian
Quoted 7 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v3 02/22] mg-*: Make package fetching common in new mgi-debian"):
Quoted 6 lines
This pattern appears several times in mg-debian-installer-update and I'm about to add another script which uses it.
The centralised version always does "sort -n -r | head -n" to pick out only the newest version, which only some of the open coded sites did.
Quoted 7 lines
Quoted 2 lines
Likewise the centralised version checks that $pkgfile is non-empty, unlike some of the open coded sites.
Acked-by Ian Jackson <[email protected]>Although, another option would be to put this in mgi-common and call it "
fetch_debian_package".
I'm happy either way, which would you prefer?
Ian.
Re: [PATCH OSSTEST v3 02/22] mg-*: Make package fetching common in new mgi-debian
Ian Campbell writes ("Re: [PATCH OSSTEST v3 02/22] mg-*: Make package fetching common in new mgi-debian"):
Quoted 1 line · Ian Jackson
...
Quoted 4 lines
Quoted 2 lines
Although, another option would be to put this in mgi-common and call it "
fetch_debian_package".I'm happy either way, which would you prefer?
I'd marginally prefer it all in mgi-common.
Ian.
PATCH v3 3/22 Introduce mg-pxe-loader-update
In reply to Ian CampbellThe story for PXE booting via UEFI (at least on arm64) is not so straightforward as with pxelinux on x86. There seems to no good bootloader to launch via UEFI+pxe, in fact all I could find was grub (syslinux, and by extension pxelinux.efi, is x86 only).
Add mg-pxe-loader-update modelled on mg-debian-installer-update which will download the necessary grub binaries and produce a grub image which can be used to pxe boot.
grub lacks the convenient ability to search for config file based on (substrings of) the MAC or IP address. So we arrange for the grub.cfg in TftpGrubBase to chain load another config file from TftpTmpDir/'$net_default_mac' where $net_default_mac is a grub variable which is substituted at boot time.
Actually using this requires that bootp/dhcp provide a next-file so UEFI knows what to boot (usually this would be pxelinux.0 which we can't use here). Locally we have configured this as $name/pxe.img, so we can use different loaders.
---
v3: Use mgi-common and mgi-debian
--- Osstest.pm | 3 ++ README | 4 ++- mg-pxe-loader-update | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++ production-config | 5 ++++ 4 files changed, 96 insertions(+), 1 deletion(-) create mode 100755 mg-pxe-loader-update
Osstest.pm +3 -0
@@ -200,6 +200,9 @@ sub readglobalconfig () { $c{TftpDiBase} ||= "$c{TftpPlayDir}debian-installer"; $c{TftpDiVersion} ||= 'current'; + $c{TftpGrubBase} ||= "$c{TftpPlayDir}grub"; + $c{TftpGrubVersion} ||= 'current'; + $c{WebspaceFile} ||= "$ENV{'HOME'}/public_html/"; $c{WebspaceUrl} ||= "http://$myfqdn/~$whoami/"; $c{WebspaceCommon} ||= 'osstest/';
README +3 -1
@@ -206,7 +206,9 @@ To run osstest in standalone mode: netcat chiark-utils-bin - - Optional: ipmitool + - Optional: + ipmitool -- for hosts which use IPMI for power control + grub-common -- for mg-pxe-loader-update - Write a config file ~/.xen-osstest/config
mg-pxe-loader-update new file +85 -0
85 lines not on this page · raw message
production-config +5 -0
@@ -82,12 +82,17 @@ TftpPxeTemplates %name%/pxelinux.cfg TftpPxeTemplatesReal pxelinux.cfg/%ipaddrhex% TftpPxeGroup osstest +# Update with ./mg-debian-installer-update(-all) TftpDiVersion 2015-06-23 # These should normally be the same. +# Update with ./mg-cpu-microcode-update MicrocodeUpdateAmd64 microcode.x86.2015-06-12.cpio MicrocodeUpdateI386 microcode.x86.2015-06-12.cpio +# Update with ./mg-pxe-loader-update +TftpGrubVersion XXXX-XX-XX + XenUsePath /usr/groups/xencore/systems/bin/xenuse XenUseUser osstest
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 03/22] Introduce mg-pxe-loader-update
Ian Campbell writes ("[PATCH OSSTEST v3 03/22] Introduce mg-pxe-loader-update"):
Quoted 8 lines
The story for PXE booting via UEFI (at least on arm64) is not so straightforward as with pxelinux on x86. There seems to no good bootloader to launch via UEFI+pxe, in fact all I could find was grub (syslinux, and by extension pxelinux.efi, is x86 only).
Add mg-pxe-loader-update modelled on mg-debian-installer-update which will download the necessary grub binaries and produce a grub image which can be used to pxe boot.
PATCH v3 4/22 Debian: Preseed a EFI system partition during host install
In reply to Ian CampbellAIUI the runes used will only result in an ESP if the system was booted via UEFI. IOW I don't think there should be any change for existing systems.
--- Osstest.pm | 1 + Osstest/Debian.pm | 6 ++++++ 2 files changed, 7 insertions(+)
Osstest.pm +1 -0
@@ -68,6 +68,7 @@ our %c = qw( TestHostKeypairPath id_rsa_osstest HostProp_GenEtherPrefixBase 5e:36:0e:f5 + HostDiskESP 300 HostDiskBoot 300 HostDiskRoot 10000 HostDiskSwap 2000
Osstest/Debian.pm +6 -0
@@ -987,6 +987,12 @@ d-i partman-basicmethods/method_only boolean false d-i partman-auto/expert_recipe string \\ boot-root :: \\ + $c{HostDiskESP} 60 $c{HostDiskESP} free \\ + \$iflabel{ gpt } \\ + reusemethod{ } \\ + method{ efi } \\ + format{ } \\ + . \\ $c{HostDiskBoot} 50 $c{HostDiskBoot} ext3 \\ \$primary{ } \$bootable{ } \\ method{ format } format{ } \\
Signature · 1 line
2.1.4
PATCH v3 5/22 ts-host-install: Split initrd out of @installcmdline
In reply to Ian CampbellOther bootloaders handle this with an explicit separate option rather than parsing it out of the command line as pxelinux does. Prepare for supporting these.
--- ts-host-install | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
ts-host-install +2 -4
@@ -265,9 +265,7 @@ END my $initrd= "$ho->{Tftp}{TmpDir}$ho->{Name}--initrd.gz"; system_checked("cat -- @initrds >$ho->{Tftp}{Path}$initrd"); - push @installcmdline, ("initrd=/$initrd", - "domain=$c{TestHostDomain}", - ); + push @installcmdline, "domain=$c{TestHostDomain}"; push @installcmdline, get_host_property($ho, "install-append $ho->{Suite}", ''), get_host_property($ho, "install-append $ho->{Suite} $r{arch}", '');
@@ -295,7 +293,7 @@ label overwrite menu label ^Overwrite menu default kernel $kernel - append $installcmdline + append initrd=/$initrd $installcmdline ipappend $ipappend $dtbs default overwrite
Signature · 1 line
2.1.4
PATCH v3 6/22 ts-host-install: split the "di" from the "host" command line
In reply to Ian Campbell(i.e. the bit before/after the -- marker). When abstracting over different bootloaders in a future patch this will be convenient since it allows the code to add to either.
--- ts-host-install | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-)
ts-host-install +11 -10
@@ -175,8 +175,8 @@ sub setup_pxeboot_firstboot($) { my $d_i= $ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.$c{TftpDiVersion}.'-'.$ho->{Suite}; - my @installcmdline= qw(vga=normal); - push @installcmdline, di_installcmdline_core($ho, $ps_url, %xopts); + my @dicmdline= qw(vga=normal); + push @dicmdline, di_installcmdline_core($ho, $ps_url, %xopts); my $src_initrd= "$d_i/initrd.gz"; my @initrds= "$ho->{Tftp}{Path}/$src_initrd";
@@ -265,26 +265,27 @@ END my $initrd= "$ho->{Tftp}{TmpDir}$ho->{Name}--initrd.gz"; system_checked("cat -- @initrds >$ho->{Tftp}{Path}$initrd"); - push @installcmdline, "domain=$c{TestHostDomain}"; - push @installcmdline, + push @dicmdline, "domain=$c{TestHostDomain}"; + push @dicmdline, get_host_property($ho, "install-append $ho->{Suite}", ''), get_host_property($ho, "install-append $ho->{Suite} $r{arch}", ''); my $console = get_host_native_linux_console($ho); - push @installcmdline, "console=$console" unless $console eq "NONE"; + push @dicmdline, "console=$console" unless $console eq "NONE"; - push @installcmdline, qw(--); + my @hocmdline; # See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 for # why this is repeated. - push @installcmdline, "console=$console" unless $console eq "NONE"; + push @hocmdline, "console=$console" unless $console eq "NONE"; - push @installcmdline, + push @hocmdline, get_host_property($ho, "linux-boot-append $ho->{Suite}", ''), get_host_property($ho, "linux-boot-append $ho->{Suite} $r{arch}", ''); - my $installcmdline= join ' ', @installcmdline; + my $dicmd= join ' ', @dicmdline; + my $hocmd= join ' ', @hocmdline; setup_pxeboot($ho, <<END); serial 0 $c{Baud}
@@ -293,7 +294,7 @@ label overwrite menu label ^Overwrite menu default kernel $kernel - append initrd=/$initrd $installcmdline + append initrd=/$initrd $dicmd -- $hocmd ipappend $ipappend $dtbs default overwrite
Signature · 1 line
2.1.4
PATCH v3 7/22 Refactor pxelinux configuration
In reply to Ian CampbellThe mechanism used to PXE boot can differ depending on the firmware type. Therefore refactor into Osstest::TestSupport and key off a new host property "firmware".
Currently supported is "bios" (the default) and "uboot", both of which use pxelinux.cfg style files.
The default for the firmware property is "bios", hence no change for any existing system (including those which use uboot, regardless of whether they are now configured with the firmware proprty or not)
As part of this "setup_pxeboot" becomes "setup_pxeboot_di" since it is somewhat d-i specific.
---
v3: reorder setup_${firmware}_pxeboot to setup_pxeboot_${firmware}
join $dicmd in setup_pxeboot instead of caller
--- Osstest/TestSupport.pm | 49 +++++++++++++++++++++++++++++++++++++++++++++---- ts-host-install | 23 ++++++----------------- 2 files changed, 51 insertions(+), 21 deletions(-)
Osstest/TestSupport.pm +45 -4
@@ -104,7 +104,7 @@ BEGIN { await_webspace_fetch_byleaf create_webfile file_link_contents get_timeout - setup_pxeboot setup_pxeboot_local host_pxefile + setup_pxeboot_di setup_pxeboot_local host_pxefile ether_prefix
@@ -2098,16 +2098,34 @@ sub host_pxefile ($;$) { (join ",", sort keys %v)." ?"; } -sub setup_pxeboot ($$) { +sub setup_pxelinux_bootcfg ($$) { my ($ho, $bootfile) = @_; my $f= host_pxefile($ho); file_link_contents("$ho->{Tftp}{Path}$ho->{Tftp}{PxeDir}$f", $bootfile, "$ho->{Name}-pxelinux.cfg"); } -sub setup_pxeboot_local ($) { +# Systems using BIOS are configured to use pxelinux +sub setup_pxeboot_di_bios ($$$$$;%) { + my ($ho,$kern,$initrd,$dicmd,$hocmd,%xopts) = @_; + my $dtbs = "fdtdir $xopts{dtbs}" if $xopts{dtbs}; + setup_pxelinux_bootcfg($ho, <<END); + serial 0 $c{Baud} +timeout 5 +label overwrite + menu label ^Overwrite + menu default + kernel $kern + append $dicmd initrd=$initrd -- $hocmd + ipappend $xopts{ipappend} + $dtbs +default overwrite +END +} + +sub setup_pxeboot_local_bios ($) { my ($ho) = @_; - setup_pxeboot($ho, <<END); + setup_pxelinux_bootcfg($ho, <<END); serial 0 $c{Baud} timeout 5 label local
@@ -2116,6 +2134,29 @@ default local END } +# uboot emulates pxelinux, so reuse BIOS stuff +sub setup_pxeboot_di_uboot ($$$$$;%) { return &setup_pxeboot_di_bios; } +sub setup_pxeboot_local_uboot ($) { return &setup_pxeboot_local_bios; } + +sub setup_pxeboot_local ($) { + my ($ho) = @_; + my $firmware = get_host_property($ho, "firmware", "bios"); + $firmware =~ s/-/_/g; + no strict qw(refs); + return &{"setup_pxeboot_local_${firmware}"}($ho); +} + +sub setup_pxeboot_di ($$$$$;%) { + my ($ho,$kern,$initrd,$dicmd,$hocmd,%xopts) = @_; + my $firmware = get_host_property($ho, "firmware", "bios"); + $firmware =~ s/-/_/g; + no strict qw(refs); + return &{"setup_pxeboot_di_${firmware}"}($ho,$kern,$initrd, + join(' ',@{$dicmd}), + join(' ',@{$hocmd}), + %xopts); +} + #---------- ISO images ---------- sub iso_create_genisoimage ($$$$;@) { my ($ho,$iso,$dir,$isotimeout,@xopts) = @_;
ts-host-install +6 -17
@@ -244,13 +244,14 @@ SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$ho->{Ether}", A END } - my $dtbs = ""; + my %xopts; + foreach my $kp (keys %{ $ho->{Flags} }) { # Backwards compatibility $kp = "need-kernel-deb-wheezy-backports" if $kp eq "need-kernel-deb-armmp"; $kp =~ s/need-kernel-deb-$ho->{Suite}-// or next; - $dtbs = "fdtdir /$d_i/$kp-dtbs" + $xopts{dtbs} = "/$d_i/$kp-dtbs" if -e "$ho->{Tftp}{Path}/$d_i/$kp-dtbs"; }
@@ -284,21 +285,9 @@ END get_host_property($ho, "linux-boot-append $ho->{Suite}", ''), get_host_property($ho, "linux-boot-append $ho->{Suite} $r{arch}", ''); - my $dicmd= join ' ', @dicmdline; - my $hocmd= join ' ', @hocmdline; - - setup_pxeboot($ho, <<END); -serial 0 $c{Baud} -timeout 5 -label overwrite - menu label ^Overwrite - menu default - kernel $kernel - append initrd=/$initrd $dicmd -- $hocmd - ipappend $ipappend - $dtbs -default overwrite -END + $xopts{ipappend} = $ipappend; + setup_pxeboot_di($ho, $kernel, "/$initrd", \@dicmdline, \@hocmdline, + %xopts); } install();
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 07/22] Refactor pxelinux configuration
Ian Campbell writes ("[PATCH OSSTEST v3 07/22] Refactor pxelinux configuration"):
Quoted 3 lines
The mechanism used to PXE boot can differ depending on the firmware type. Therefore refactor into
Osstest::TestSupportand key off a new host property "firmware".
PATCH v3 8/22 ts-host-install: Support UEFI PXE boot using grub.efi
In reply to Ian Campbell(Wrap DiBase entry in README too for consistency)
---
v3: Reindent README (fix DiBase too for consistency)
Adjust for reordering of setup_{firmware}_pxeboot to put
{firmware} at end
Rewrap setup_grub_efi_bootcfg
Adjust for setup_pxeboot -> setup_pxeboot_di
--- Osstest/TestSupport.pm | 37 ++++++++++++++++++++++++++++++++++++- README | 6 ++++-- 2 files changed, 40 insertions(+), 3 deletions(-)
Osstest/TestSupport.pm +36 -1
@@ -898,7 +898,7 @@ sub selecthost ($) { $ho->{Tftp} = { }; $ho->{Tftp}{$_} = $c{"Tftp${_}_${tftpscope}"} || $c{"Tftp${_}"} foreach qw(Path TmpDir PxeDir PxeGroup PxeTemplates PxeTemplatesReal - DiBase); + DiBase GrubBase); #----- finalise -----
@@ -2138,6 +2138,41 @@ END sub setup_pxeboot_di_uboot ($$$$$;%) { return &setup_pxeboot_di_bios; } sub setup_pxeboot_local_uboot ($) { return &setup_pxeboot_local_bios; } +sub setup_grub_efi_bootcfg ($$) { + my ($ho, $bootfile) = @_; + my $f = "grub.cfg-$ho->{Ether}"; + my $grub= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{GrubBase}.'/'. + $c{TftpGrubVersion}."/pxegrub-$r{arch}.efi"; + my $pxe=$ho->{Tftp}{Path}.'/'.$ho->{Name}.'/pxe.img'; + + logm("Copy $grub => $pxe"); + copy($grub, $pxe) or die "Copy $grub to $pxe failed: $!"; + + logm("grub_efi bootcfg into $f"); + file_link_contents("$ho->{Tftp}{Path}$ho->{Tftp}{TmpDir}$f", + $bootfile, "$ho->{Name}-pxegrub.cfg"); +} + +# UEFI systems PXE boot using grub.efi +sub setup_pxeboot_di_uefi ($$$$$;%) { + my ($ho,$kern,$initrd,$dicmd,$hocmd,%xopts) = @_; + setup_grub_efi_bootcfg($ho, <<END); +set default=0 +set timeout=5 +menuentry 'overwrite' { + linux $kern $dicmd -- $hocmd + initrd $initrd +} +END +} + +sub setup_pxeboot_local_uefi ($) { + my ($ho) = @_; + setup_grub_efi_bootcfg($ho, <<END); +echo Should do a local boot here, somehow +END +} + sub setup_pxeboot_local ($) { my ($ho) = @_; my $firmware = get_host_property($ho, "firmware", "bios");
README +4 -2
@@ -453,8 +453,10 @@ TftpFoo_<scope> and TftpFoo PxeTemplates See TftpPxeTemplates PxeTemplatesReal - DiBase The path under `Path' to the root of the debian installer - images. + DiBase The path under `Path' to the root of the debian + installer images. + GrubBase The path under `Path' to the root of the grub + EFI PXE images. For hosts in scope "default", TftpFoo_default (if set) takes precedence over TftpFoo. TftpFoo is used when the setting Foo is
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 08/22] ts-host-install: Support UEFI PXE boot using grub.efi
Ian Campbell writes ("[PATCH OSSTEST v3 08/22] ts-host-install: Support UEFI PXE boot using grub.efi"):
Quoted 1 line
(Wrap DiBase entry in README too for consistency)
...
Osstest/TestSupport.pm END · line 2174
Quoted 6 lines
Osstest/TestSupport.pm +6
-0+sub setup_pxeboot_local_uefi ($) { + my ($ho) = @_; + setup_grub_efi_bootcfg($ho, <<END); +echo Should do a local boot here, somehow +END +}
OK, I get the picture that EFI is strange, but surely there should be some comments or something about this ? Does this actually work like this ?
Ian.
PATCH v3 9/22 Enable chain loading to local disk for UEFI PXE systems.
In reply to Ian CampbellFirst arrange for bootloader to be installed to removable media path, by using a new in Jessie preseed option. Then use that to chainload a bootloader from the disk.
The removable media path is well known (part of the UEFI spec) which saves us having to worry about which OS is on the host (so long as the OS can be configured to populate the removable media path)
--- Osstest/Debian.pm | 2 ++ Osstest/TestSupport.pm | 18 +++++++++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-)
Osstest/Debian.pm +2 -0
@@ -757,6 +757,8 @@ d-i apt-setup/contrib boolean false d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, chiark-utils-bin, $extra_packages +d-i grub-installer/force-efi-extra-removable boolean true + $xopts{ExtraPreseed} END
Osstest/TestSupport.pm +17 -1
@@ -2168,8 +2168,24 @@ END sub setup_pxeboot_local_uefi ($) { my ($ho) = @_; + my %efi_archs = qw(amd64 X64 + arm32 ARM + arm64 AARCH64 + i386 IA32); + die "EFI arch" unless $efi_archs{ $r{arch} }; + my $efi = $efi_archs{ $r{arch} }; setup_grub_efi_bootcfg($ho, <<END); -echo Should do a local boot here, somehow +set default=0 +set timeout=5 +menuentry 'local' { + insmod chain + insmod part_gpt + insmod part_msdos + set root=(hd0,gpt1) + echo "Chainloading (\${root})/EFI/BOOT/BOOTAA64.EFI" + chainloader (\${root})/EFI/BOOT/BOOTAA64.EFI + boot +} END }
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 09/22] Enable chain loading to local disk for UEFI PXE systems.
Ian Campbell writes ("[PATCH OSSTEST v3 09/22] Enable chain loading to local disk for UEFI PXE systems."):
Quoted 7 lines
First arrange for bootloader to be installed to removable media path, by using a new in Jessie preseed option. Then use that to chainload a bootloader from the disk.
The removable media path is well known (part of the UEFI spec) which saves us having to worry about which OS is on the host (so long as the OS can be configured to populate the removable media path)
Ah here we are.
Quoted 1 line
-echo Should do a local boot here, somehow
If you change this print to a die instead, in the previous patch, you can put my ack on that one too.
Ian.
Re: [PATCH OSSTEST v3 09/22] Enable chain loading to local disk for UEFI PXE systems.
Quoted 9 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v3 09/22] Enable chain loading to local disk for UEFI PXE systems."):
Quoted 7 lines
First arrange for bootloader to be installed to removable media path, by using a new in Jessie preseed option. Then use that to chainload a bootloader from the disk.
The removable media path is well known (part of the UEFI spec) which saves us having to worry about which OS is on the host (so long as the OS can be configured to populate the removable media path)
Quoted 8 lines
Ah here we are.
Acked-by Ian Jackson <[email protected]>Quoted 1 line
-echo Should do a local boot here, somehow
If you change this print to a die instead, in the previous patch, you can put my ack on that one too.
I guess you mean to change the surrounding call to be die "that message" rather than to put die into the grub.cfg file (i.e. a strict s/echo/die/ on the line you quoted), so that is what I'll do.
Ian.
Re: [PATCH OSSTEST v3 09/22] Enable chain loading to local disk for UEFI PXE systems.
Ian Campbell writes ("Re: [PATCH OSSTEST v3 09/22] Enable chain loading to local disk for UEFI PXE systems."):
Quoted 7 lines · Ian Jackson
Quoted 2 lines
If you change this print to a die instead, in the previous patch, you can put my ack on that one too.
I guess you mean to change the surrounding call to be die "that message" rather than to put die into the grub.cfg file (i.e. a strict s/echo/die/ on the line you quoted), so that is what I'll do.
Yes, that is what I meant.
Thanks,
Ian.
PATCH v3 10/22 Add arm64 build and test jobs
In reply to Ian CampbellRunvars:
build-arm64 arch arm64 build-arm64 build_lvextend_max 50 build-arm64 enable_ovmf true build-arm64 enable_xend false build-arm64 enable_xsm false build-arm64 host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64 revision_ovmf build-arm64 revision_qemu build-arm64 revision_qemuu b2da824bc5ad35fb9f1e74a203d7be96a7b0345e build-arm64 revision_seabios build-arm64 revision_xen e13013dbf1d5997915548a3b5f1c39594d8c1d7b build-arm64 tree_ovmf build-arm64 tree_qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git build-arm64 tree_qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git build-arm64 tree_seabios build-arm64 tree_xen git://xenbits.xen.org/xen.git build-arm64-libvirt arch arm64 build-arm64-libvirt build_lvextend_max 50 build-arm64-libvirt buildjob build-arm64 build-arm64-libvirt host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64-libvirt revision_libvirt fd74e231751334b64af0934b680c5cc62f652453 build-arm64-libvirt tree_libvirt git://xenbits.xen.org/libvirt.git build-arm64-libvirt tree_xen git://xenbits.xen.org/xen.git build-arm64-pvops arch arm64 build-arm64-pvops build_lvextend_max 50 build-arm64-pvops host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64-pvops kconfig_override_y CONFIG_EXT4_FS build-arm64-pvops kconfighow xen-enable-xen-config build-arm64-pvops revision_linux ec18c9fc039971041d854e0d58551f1f1a32ff8f build-arm64-pvops revision_linuxfirmware c530a75c1e6a472b0eb9558310b518f0dfcd8860 build-arm64-pvops tree_linux git://xenbits.xen.org/linux-pvops.git build-arm64-pvops tree_linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git build-arm64-pvops treevcs_linux git build-arm64-xsm arch arm64 build-arm64-xsm build_lvextend_max 50 build-arm64-xsm enable_ovmf true build-arm64-xsm enable_xend false build-arm64-xsm enable_xsm true build-arm64-xsm host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64-xsm revision_ovmf build-arm64-xsm revision_qemu build-arm64-xsm revision_qemuu b2da824bc5ad35fb9f1e74a203d7be96a7b0345e build-arm64-xsm revision_seabios build-arm64-xsm revision_xen e13013dbf1d5997915548a3b5f1c39594d8c1d7b build-arm64-xsm tree_ovmf build-arm64-xsm tree_qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git build-arm64-xsm tree_qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git build-arm64-xsm tree_seabios build-arm64-xsm tree_xen git://xenbits.xen.org/xen.git test-arm64-arm64-libvirt all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-libvirt arch arm64 test-arm64-arm64-libvirt buildjob build-arm64 test-arm64-arm64-libvirt debian_arch arm64 test-arm64-arm64-libvirt debian_kernkind pvops test-arm64-arm64-libvirt enable_xsm false test-arm64-arm64-libvirt kernbuildjob build-arm64-pvops test-arm64-arm64-libvirt kernkind pvops test-arm64-arm64-libvirt libvirtbuildjob build-arm64-libvirt test-arm64-arm64-libvirt toolstack libvirt test-arm64-arm64-libvirt xenbuildjob build-arm64 test-arm64-arm64-libvirt-xsm all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-libvirt-xsm arch arm64 test-arm64-arm64-libvirt-xsm buildjob build-arm64-xsm test-arm64-arm64-libvirt-xsm debian_arch arm64 test-arm64-arm64-libvirt-xsm debian_kernkind pvops test-arm64-arm64-libvirt-xsm enable_xsm true test-arm64-arm64-libvirt-xsm kernbuildjob build-arm64-pvops test-arm64-arm64-libvirt-xsm kernkind pvops test-arm64-arm64-libvirt-xsm libvirtbuildjob build-arm64-libvirt test-arm64-arm64-libvirt-xsm toolstack libvirt test-arm64-arm64-libvirt-xsm xenbuildjob build-arm64-xsm test-arm64-arm64-xl all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl arch arm64 test-arm64-arm64-xl buildjob build-arm64 test-arm64-arm64-xl debian_arch arm64 test-arm64-arm64-xl debian_kernkind pvops test-arm64-arm64-xl enable_xsm false test-arm64-arm64-xl kernbuildjob build-arm64-pvops test-arm64-arm64-xl kernkind pvops test-arm64-arm64-xl toolstack xl test-arm64-arm64-xl xenbuildjob build-arm64 test-arm64-arm64-xl-credit2 all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl-credit2 arch arm64 test-arm64-arm64-xl-credit2 buildjob build-arm64 test-arm64-arm64-xl-credit2 debian_arch arm64 test-arm64-arm64-xl-credit2 debian_kernkind pvops test-arm64-arm64-xl-credit2 guests_vcpus 4 test-arm64-arm64-xl-credit2 kernbuildjob build-arm64-pvops test-arm64-arm64-xl-credit2 kernkind pvops test-arm64-arm64-xl-credit2 toolstack xl test-arm64-arm64-xl-credit2 xen_boot_append sched=credit2 test-arm64-arm64-xl-credit2 xenbuildjob build-arm64 test-arm64-arm64-xl-multivcpu all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl-multivcpu arch arm64 test-arm64-arm64-xl-multivcpu buildjob build-arm64 test-arm64-arm64-xl-multivcpu debian_arch arm64 test-arm64-arm64-xl-multivcpu debian_kernkind pvops test-arm64-arm64-xl-multivcpu guests_vcpus 4 test-arm64-arm64-xl-multivcpu kernbuildjob build-arm64-pvops test-arm64-arm64-xl-multivcpu kernkind pvops test-arm64-arm64-xl-multivcpu toolstack xl test-arm64-arm64-xl-multivcpu xenbuildjob build-arm64 test-arm64-arm64-xl-sedf all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl-sedf arch arm64 test-arm64-arm64-xl-sedf buildjob build-arm64 test-arm64-arm64-xl-sedf debian_arch arm64 test-arm64-arm64-xl-sedf debian_kernkind pvops test-arm64-arm64-xl-sedf guests_vcpus 4 test-arm64-arm64-xl-sedf kernbuildjob build-arm64-pvops test-arm64-arm64-xl-sedf kernkind pvops test-arm64-arm64-xl-sedf linux_boot_append loglevel=9 debug test-arm64-arm64-xl-sedf toolstack xl test-arm64-arm64-xl-sedf xen_boot_append sched=sedf loglvl=all test-arm64-arm64-xl-sedf xenbuildjob build-arm64 test-arm64-arm64-xl-sedf-pin all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl-sedf-pin arch arm64 test-arm64-arm64-xl-sedf-pin buildjob build-arm64 test-arm64-arm64-xl-sedf-pin debian_arch arm64 test-arm64-arm64-xl-sedf-pin debian_kernkind pvops test-arm64-arm64-xl-sedf-pin guests_vcpus 4 test-arm64-arm64-xl-sedf-pin kernbuildjob build-arm64-pvops test-arm64-arm64-xl-sedf-pin kernkind pvops test-arm64-arm64-xl-sedf-pin linux_boot_append loglevel=9 debug test-arm64-arm64-xl-sedf-pin toolstack xl test-arm64-arm64-xl-sedf-pin xen_boot_append sched=sedf loglvl=all dom0_vcpus_pin test-arm64-arm64-xl-sedf-pin xenbuildjob build-arm64 test-arm64-arm64-xl-xsm all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl-xsm arch arm64 test-arm64-arm64-xl-xsm buildjob build-arm64-xsm test-arm64-arm64-xl-xsm debian_arch arm64 test-arm64-arm64-xl-xsm debian_kernkind pvops test-arm64-arm64-xl-xsm enable_xsm true test-arm64-arm64-xl-xsm kernbuildjob build-arm64-pvops test-arm64-arm64-xl-xsm kernkind pvops test-arm64-arm64-xl-xsm toolstack xl test-arm64-arm64-xl-xsm xenbuildjob build-arm64-xsm
---
--- make-flight | 4 ++-- mfi-common | 23 ++++++++++++++++++----- ts-kernel-build | 1 + 3 files changed, 21 insertions(+), 7 deletions(-)
make-flight +2 -2
@@ -107,7 +107,7 @@ job_create_test_filter_callback () { test_matrix_branch_filter_callback () { case "$xenarch" in - armhf) + armhf|arm64) case "$branch" in linux-3.0) return 1;; linux-3.4) return 1;;
@@ -366,7 +366,7 @@ test_matrix_do_one () { do_credit2_tests # No further arm tests at the moment - if [ $dom0arch = armhf ]; then + if [ $dom0arch = armhf ] || [ $dom0arch = arm64 ]; then return fi
mfi-common +18 -5
@@ -67,12 +67,12 @@ create_build_jobs () { BUILD_RUNVARS+=" build_lvextend_max=$BUILD_LVEXTEND_MAX " fi - for arch in ${BUILD_ARCHES- i386 amd64 armhf }; do + for arch in ${BUILD_ARCHES- i386 amd64 armhf arm64 }; do if [ "x$arch" = xdisable ]; then continue; fi case "$arch" in - armhf) + armhf|arm64) case "$branch" in linux-3.0) continue;; linux-3.4) continue;;
@@ -247,7 +247,7 @@ create_build_jobs () { fi case "$arch" in - armhf) continue;; # don't do any other kernel builds + armhf|arm64) continue;; # don't do any other kernel builds esac if [ "x$REVISION_LINUX_OLD" != xdisable ]; then
@@ -319,13 +319,25 @@ test_matrix_iterate () { *) onetoolstack=xl ;; esac - for xenarch in ${TEST_ARCHES- i386 amd64 armhf } ; do + for xenarch in ${TEST_ARCHES- i386 amd64 armhf arm64 } ; do if [ "x$xenarch" = xdisable ]; then continue; fi test_matrix_branch_filter_callback || continue case "$xenarch" in + arm64) + # Arm64 from 4.5 onwards only + case "$xenbranch" in + xen-3.*-testing) continue;; + xen-4.0-testing) continue;; + xen-4.1-testing) continue;; + xen-4.2-testing) continue;; + xen-4.3-testing) continue;; + xen-4.4-testing) continue;; + *) ;; + esac + ;; armhf) # Arm from 4.3 onwards only case "$xenbranch" in
@@ -370,13 +382,14 @@ test_matrix_iterate () { *) echo >&2 "kernkind ? $kern"; exit 1 ;; esac - for dom0arch in i386 amd64 armhf; do + for dom0arch in i386 amd64 armhf arm64; do case ${xenarch}_${dom0arch} in amd64_amd64) ;; amd64_i386) ;; i386_i386) ;; armhf_armhf) ;; + arm64_arm64) ;; *) continue ;; esac
ts-kernel-build +1 -0
@@ -39,6 +39,7 @@ builddirsprops(); my $archparms = { 'armhf' => { DefConfig => 'multi_v7_defconfig', KernelImage => 'arch/arm/boot/zImage' }, + 'arm64' => { DefConfig => 'defconfig', KernelImage => 'arch/arm64/boot/Image' }, 'i386' => { DefConfig => 'defconfig', KernelImage => 'arch/x86/boot/bzImage' }, 'amd64' => { DefConfig => 'defconfig', KernelImage => 'arch/x86/boot/bzImage' } };
Signature · 1 line
2.1.4
PATCH v3 11/22 ts-kernel-build: Additional kernel options for Mustang
In reply to Ian Campbell---
Note: ARM testing currently uses a 3.16 based linux-arm-xen kernel (compared to 3.14 currently used as the default). In order to support Mustang something newer is needed, I've been testing 4.1 (next LTS kernel), 3.18 (the intervening LTS kernel) might be sufficient but I haven't tried it. We should plan to either update linux-arm-xen or the default kernel version at some point before we get Mustang h/w.
v3: Set CONFIG_NET_XGENE (was commented out before)
Remove setting of CONFIG_SPARSEMEM_VMEMMAP
--- ts-kernel-build | 7 +++++++ 1 file changed, 7 insertions(+)
ts-kernel-build +7 -0
@@ -542,6 +542,13 @@ setopt CONFIG_BLK_CPQ_CISS_DA m setopt CONFIG_FHANDLE y +# APM XGENE +setopt CONFIG_PHY_XGENE y +setopt CONFIG_NET_XGENE y +setopt CONFIG_AHCI_XGENE y +setopt CONFIG_POWER_RESET_XGENE y +setopt CONFIG_RTC_DRV_XGENE y + case ${XEN_TARGET_ARCH} in x86_32) setopt CONFIG_64BIT n ;; x86_64)
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 11/22] ts-kernel-build: Additional kernel options for Mustang
Ian Campbell writes ("[PATCH OSSTEST v3 11/22] ts-kernel-build: Additional kernel options for Mustang"):
Quoted 1 line
Signed-off-by Ian Campbell <[email protected]>
Re: [PATCH OSSTEST v3 11/22] ts-kernel-build: Additional kernel options for Mustang
In reply to Ian CampbellQuoted 6 lines · Ian Campbell
Note: ARM testing currently uses a 3.16 based linux-arm-xen kernel (compared to 3.14 currently used as the default). In order to support Mustang something newer is needed, I've been testing 4.1 (next LTS kernel), 3.18 (the intervening LTS kernel) might be sufficient but I haven't tried it. We should plan to either update linux-arm-xen or the default kernel version at some point before we get Mustang h/w.
FTR 3.18 seemed to work when I tried it again today, not sure what was up the last time (there has been a point release since though). Maybe I was confused by the sparsemem thing, which is now also understood.
Ian.
PATCH v3 12/22 ts-kernel-build: Enable CONFIG_EFI_VARS
In reply to Ian CampbellWhich makes efibootmgr work when running our kernel.
---
v3: New patch
--- ts-kernel-build | 3 +++ 1 file changed, 3 insertions(+)
ts-kernel-build +3 -0
@@ -542,6 +542,9 @@ setopt CONFIG_BLK_CPQ_CISS_DA m setopt CONFIG_FHANDLE y +# Needed for efibootmgr +setopt CONFIG_EFI_VARS y + # APM XGENE setopt CONFIG_PHY_XGENE y setopt CONFIG_NET_XGENE y
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 12/22] ts-kernel-build: Enable CONFIG_EFI_VARS
Ian Campbell writes ("[PATCH OSSTEST v3 12/22] ts-kernel-build: Enable CONFIG_EFI_VARS"):
Quoted 1 line
Which makes efibootmgr work when running our kernel.
PATCH v3 13/22 ts-host-install: Set dtbs in the non-special kernel case too.
In reply to Ian CampbellWhen DTB support was added for armhf it required a backports kernel for use with Wheezy and therefore DTBs were only collected for that special case. However as we move forward to newer kernels it should be possible to run using the proper kernel (e.g. Jessie should work for armhf). Therefore we will need the DTBs for those kernels too.
---
v3: Improved commit message
--- ts-host-install | 3 +++ 1 file changed, 3 insertions(+)
ts-host-install +3 -0
@@ -255,6 +255,9 @@ END if -e "$ho->{Tftp}{Path}/$d_i/$kp-dtbs"; } + $xopts{dtbs} = "/$d_i/dtbs" + if !$xopts{dtbs} && -e "$ho->{Tftp}{Path}/$d_i/dtbs"; + file_simple_write_contents("$initrd_overlay.cpio", sub { contents_make_cpio($_[0], 'newc', "$initrd_overlay.d"); });
Signature · 1 line
2.1.4
PATCH v3 14/22 Debian: Do not add Debian to UEFI boot order on install
In reply to Ian CampbellBy default Debian inserts itself before any existing entries, including the PXE one, meaning we otherwise cannot remotely regroove the box.
Add a hook to /usr/lib/base-installer.d/ which installs a diversion of /usr/sbin/grub-install and installs a wrapper which adds the --no-nvram argument which prevents grub-install from adding the boot entries.
---
v3: New patch replacing "Debian: Fixup UEFI boot order during install"
--- Osstest/Debian.pm | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
Osstest/Debian.pm +25 -0
@@ -1018,6 +1018,31 @@ END preseed_microcode($ho,$sfx); + if (get_host_property($ho, "firmware") eq "uefi" && + $ho->{Suite} =~ m/jessie/) { + # Prevent grub-install from making a new Debian boot entry, so + # we always reboot from PXE. Debian bug #789798 proposes a + # properly preseedable solution to this. + preseed_hook_installscript($ho, $sfx, + '/usr/lib/base-installer.d/', + 'osstest-disable-grub-nvram', <<'END'); +#!/bin/sh +set -ex + +logger -t osstest-disable-grub-nvram "Adding our grub-install wrapper" + +t=/usr/sbin/grub-install + +in-target dpkg-divert --divert $t.osstest --rename --add $t + +cat >/target/$t <<EOF +#!/bin/sh +exec $t.osstest --no-nvram \$@ +EOF +chmod +x /target/$t +END + } + $preseed_file .= preseed_hook_cmds(); if ($ho->{Flags}{'no-di-kernel'}) {
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 14/22] Debian: Do not add Debian to UEFI boot order on install
Ian Campbell writes ("[PATCH OSSTEST v3 14/22] Debian: Do not add Debian to UEFI boot order on install"):
Quoted 3 lines
By default Debian inserts itself before any existing entries, including the PXE one, meaning we otherwise cannot remotely regroove the box.
Right.
Osstest/Debian.pm END · line 1022
Quoted 2 lines
Osstest/Debian.pm +2
-0+ if (get_host_property($ho, "firmware") eq "uefi" && + $ho->{Suite} =~ m/jessie/) {
I think you mean
+ if (get_host_property($ho, "firmware") eq "uefi")
+ die unless $ho->{Suite} =~ m/jessie/;
or this will expose us to broken boxes beyond jessie.
The rest looks plausible (although a bit unpleasant).
Ian.
Re: [PATCH OSSTEST v3 14/22] Debian: Do not add Debian to UEFI boot order on install
Quoted 12 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v3 14/22] Debian: Do not add Debian to UEFI boot order on install"):
Quoted 3 lines
By default Debian inserts itself before any existing entries, including the PXE one, meaning we otherwise cannot remotely regroove the box.
Right.
Osstest/Debian.pm END · line 1022
Quoted 2 lines
Osstest/Debian.pm +2
-0+ if (get_host_property($ho, "firmware") eq "uefi" && + $ho->{Suite} =~ m/jessie/) {I think you mean
Quoted 4 lines
+ if (
get_host_property($ho, "firmware")eq "uefi")
+ die unless $ho->{Suite} =~ m/jessie/;or this will expose us to broken boxes beyond jessie.
Ah yes, that's a good idea indeed.
Quoted 1 line
The rest looks plausible (although a bit unpleasant).
Indeed, hopefully it will be easier in Stretch...
PATCH v3 15/22 standalone: Prefer ./local-config to $HOME/.xen-osstest/config
In reply to Ian CampbellOSSTEST_CONFIG still trumps both.
---
v3: local-config not standalone.config
--- standalone | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
standalone +7 -1
@@ -68,7 +68,13 @@ TEMP=$(getopt -o c:f:h:rRs --long config:,flight:,host:,reuse,noreuse,reinstall, eval set -- "$TEMP" -config=${OSSTEST_CONFIG-$HOME/.xen-osstest/config} +if [ -n "${OSSTEST_CONFIG}" ]; then + config=${OSSTEST_CONFIG} +elif [ -f local-config ]; then + config=local-config +else + config=$HOME/.xen-osstest/config +fi flight="standalone" host= reuse=1 # Don't blow away machines by default
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 15/22] standalone: Prefer ./local-config to $HOME/.xen-osstest/config
Ian Campbell writes ("[PATCH OSSTEST v3 15/22] standalone: Prefer ./local-config to $HOME/.xen-osstest/config"):
Quoted 1 line
OSSTEST_CONFIGstill trumps both.
PATCH v3 16/22 Debian: grub2: Log full line range of menuentry and submenu entries
In reply to Ian CampbellIs useful when debugging.
--- Osstest/Debian.pm | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
Osstest/Debian.pm +4 -5
@@ -412,8 +412,7 @@ sub setupboot_grub2 ($$$$) { if (m/^\s*\}\s*$/) { die unless $entry || $submenu; if (!defined $entry && defined $submenu) { - logm("Met end of a submenu starting from ". - "$submenu->{StartLine}. ". + logm("Met end of a submenu $submenu->{StartLine}..$.. ". "Our want kern is $want_kernver"); $submenu=undef; pop @offsets;
@@ -426,14 +425,14 @@ sub setupboot_grub2 ($$$$) { ? qw(Title Hv KernDom0 KernVer) : qw(Title Hv KernOnly KernVer)); if (@missing) { - logm("(skipping entry at $entry->{StartLine};". + logm("(skipping entry at $entry->{StartLine}..$.;". " no @missing)"); } elsif (defined $want_kernver && $entry->{KernVer} ne $want_kernver) { - logm("(skipping entry at $entry->{StartLine};". + logm("(skipping entry at $entry->{StartLine}..$.;". " kernel $entry->{KernVer}, not $want_kernver)"); } elsif ($want_xsm && !defined $entry->{Xenpolicy}) { - logm("(skipping entry at $entry->{StartLine};". + logm("(skipping entry at $entry->{StartLine}..$.;". " XSM policy file not present)"); } else { # yes!
Signature · 1 line
2.1.4
PATCH v3 17/22 Debian: grub2: Use GRUB_CMDLINE_LINUX_XEN_REPLACE(_DEFAULT)
In reply to Ian CampbellThis overrides GRUB_CMDLINE_LINUX(_DEFAULT) which we were previously editing but only for the Xen entries, meaning that we don't switch to console=hvc0 for the native cases (i.e. don't break them).
We do however want to edit GRUB_CMDLINE_LINUX(_DEFAULT) to remove "quiet" if present, since it is useful to people, especially those using standalone mode as a provisioning tool, wanting to e.g. compare a boot under Xen with the native case.
This has been supported since Wheezy but in any case we supply our own 20_linux_xen grub generator based on Wheezy which supports this.
--- Osstest/Debian.pm | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
Osstest/Debian.pm +12 -3
@@ -507,7 +507,7 @@ sub setupboot_grub2 ($$$$) { $v =~ s/^\s*([\'\"])(.*)\1\s*$/$2/; $k{$k}= $v; } - next if m/^GRUB_CMDLINE_(?:XEN|LINUX).*\=|^GRUB_DEFAULT.*\=/; + next if m/^GRUB_CMDLINE_(?:XEN|LINUX(?:_XEN_REPLACE)?(?:_DEFAULT)?).*\=|^GRUB_DEFAULT.*\=/; print ::EO; } print ::EO <<END or die $!;
@@ -521,11 +521,20 @@ GRUB_CMDLINE_XEN="$xenhopt" END foreach my $k (qw(GRUB_CMDLINE_LINUX GRUB_CMDLINE_LINUX_DEFAULT)) { my $v= $k{$k}; + + # Tailor native case $v =~ s/\bquiet\b//; + print ::EO "$k=\"$v\"\n" or die $!; + + # Xen overrides $v =~ s/\b(?:console|xencons)=[0-9A-Za-z,]+//; $v .= " $xenkopt" if $k eq 'GRUB_CMDLINE_LINUX'; - print ::EO "$k=\"$v\"\n" or die $!; - } + # Ensure variable isn't zero length, or 20_linux_xen will ignore it. + $v .= " "; + my $rk = $k; + $rk =~ s/LINUX/LINUX_XEN_REPLACE/; + print ::EO "$rk=\"$v\"\n" or die $!; + } }); };
Signature · 1 line
2.1.4
PATCH v3 18/22 Collect xen.efi into xendist and install in appropriate place
In reply to Ian CampbellPreviously these binaries would have been included in the regular ("tools") dist file, whereas they really belong in the xen one.
Install into /boot/efi/EFI/osstest ready for use when chainloading.
Note that /boot/efi is (or should be) a VFAT filesystem. So a bit of care is needed WRT symlinks etc. This is also what prevents us from just including /boot/efi/EFI/osstest/xen.efi in the dist tarball since untarring over a VFAT needs a little care WRT the case of directories etc.
--- ts-xen-build | 7 +++++++ ts-xen-install | 7 +++++++ 2 files changed, 14 insertions(+)
ts-xen-build +7 -0
@@ -172,6 +172,13 @@ sub divide () { mv \$mvfiles xeninstall/boot/. fi fi + if test -d install/usr/lib64/efi/; then + if test -f install/usr/lib64/efi/xen.efi; then + mkdir -p xeninstall/usr/lib64/efi + mvfiles=`find install/usr/lib64/efi -name 'xen[a-z]*' -prune -o -name 'xen*' -print` + mv \$mvfiles xeninstall/usr/lib64/efi/. + fi + fi END }
ts-xen-install +7 -0
@@ -77,6 +77,13 @@ sub extract () { target_extract_jobdistpath($ho, $part, "path_${part}dist", $r{"${part}buildjob"}, \%distpath); } + if (target_file_exists($ho, "/usr/lib64/efi/xen.efi")) { + target_cmd_root($ho,<<END); + mkdir -p /boot/efi/EFI/osstest + # /boot/efi is VFAT, so dereference the symlink + cp -vL /usr/lib64/efi/xen.efi /boot/efi/EFI/osstest +END + } target_cmd_root($ho, '/sbin/ldconfig'); }
Signature · 1 line
2.1.4
PATCH v3 19/22 Debian: Ignore xen-syms entries in grub.cfg.
In reply to Ian CampbellThese can't (in general?) actually be booted.
--- Osstest/Debian.pm | 3 +++ 1 file changed, 3 insertions(+)
Osstest/Debian.pm +3 -0
@@ -427,6 +427,9 @@ sub setupboot_grub2 ($$$$) { if (@missing) { logm("(skipping entry at $entry->{StartLine}..$.;". " no @missing)"); + } elsif ($entry->{Hv} =~ m/xen-syms/) { + logm("(skipping entry at $entry->{StartLine}..$.;". + " is xen-syms)"); } elsif (defined $want_kernver && $entry->{KernVer} ne $want_kernver) { logm("(skipping entry at $entry->{StartLine}..$.;".
Signature · 1 line
2.1.4
PATCH v3 20/22 Debian: Collect kernel command line from grub.cfg
In reply to Ian CampbellI'm going to want it in a subsequent patch
--- Osstest/Debian.pm | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
Osstest/Debian.pm +4 -2
@@ -460,15 +460,17 @@ sub setupboot_grub2 ($$$$) { die unless $entry; $entry->{Hv}= $1; } - if (m/^\s*multiboot\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))/) { + if (m/^\s*multiboot\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) { die unless $entry; $entry->{KernOnly}= $1; $entry->{KernVer}= $2; + $entry->{KernOpts}= $3; } - if (m/^\s*module\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))/) { + if (m/^\s*module\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) { die unless $entry; $entry->{KernDom0}= $1; $entry->{KernVer}= $2; + $entry->{KernOpts}= $3; } if (m/^\s*module\s*(?:\/boot)?\/(initrd\S+)/) { $entry->{Initrd}= $1;
Signature · 1 line
2.1.4
PATCH v3 21/22 Debian: Arrange to be able to chainload a xen.efi from grub2
In reply to Ian CampbellXen cannot (currently) be booted directly via the usual multiboot path on EFI systems of any arch. Instead it is necessary to either launch xen.efi direct from the UEFI shell or to chainload it from grub. In both cases the Xen command line as well as what would normally be the multiboot modules (kernel+command line, XSM policy, initrd) must be configured in a Xen configuration file.
By patching overlay/etc/grub.d/20_linux_xen that if a suitable xen.efi is found in the EFI System Partition (as arrange by a previous patch) a suitable entry is created in grub.cfg as well.
When parsing the grub.cfg look for such an entry into addition to the regular/multiboot one and when necessary write the configuration file based on the regular entry and return the chainload one such that it gets booted.
This is currently enabled only for Jessie ARM64 systems.
Note that the 20_linux_xen change here is a bit specific to us and not really generic enough to go upstream IMHO, hence I haven't.
---
v3: Rewrap and reindent to avoid long lines
--- Osstest/Debian.pm | 77 +++++++++++++++++++++++++++++++++++++++-- overlay/etc/grub.d/20_linux_xen | 21 +++++++++++ 2 files changed, 96 insertions(+), 2 deletions(-)
Osstest/Debian.pm +75 -2
@@ -400,12 +400,18 @@ sub setupboot_grub2 ($$$$) { my $rmenu= '/boot/grub/grub.cfg'; my $kernkey= (defined $xenhopt ? 'KernDom0' : 'KernOnly'); - + + # Grub2 on Jessie/arm* doesn't do multiboot, so we must chainload. + my $need_uefi_chainload = + get_host_property($ho, "firmware") eq "uefi" && + $ho->{Suite} =~ m/jessie/ && $r{arch} =~ m/^arm/; + my $parsemenu= sub { my $f= bl_getmenu_open($ho, $rmenu, "$stash/$ho->{Name}--grub.cfg.1"); my @offsets = (0); my $entry; + my $chainentry; my $submenu; while (<$f>) { next if m/^\s*\#/ || !m/\S/;
@@ -424,7 +430,13 @@ sub setupboot_grub2 ($$$$) { (defined $xenhopt ? qw(Title Hv KernDom0 KernVer) : qw(Title Hv KernOnly KernVer)); - if (@missing) { + if ($need_uefi_chainload && $entry->{Chainload}) { + # Needs to be before check of @missing, since a + # chained entry doesn't have anything useful in it + logm("Found chainload entry at $entry->{StartLine}..$."); + die "already got one" if $chainentry; + $chainentry = $entry; + } elsif (@missing) { logm("(skipping entry at $entry->{StartLine}..$.;". " no @missing)"); } elsif ($entry->{Hv} =~ m/xen-syms/) {
@@ -456,9 +468,15 @@ sub setupboot_grub2 ($$$$) { $submenu={ StartLine =>$., MenuEntryPath => join ">", @offsets }; push @offsets,(0); } + if (m/^\s*chainloader\s*\/EFI\/osstest\/xen.efi/) { + die unless $entry; + $entry->{Hv}= $1; + $entry->{Chainload} = 1; + } if (m/^\s*multiboot\s*(?:\/boot)?\/(xen\S+)/) { die unless $entry; $entry->{Hv}= $1; + $entry->{Chainload} = 0; } if (m/^\s*multiboot\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) { die unless $entry;
@@ -490,13 +508,68 @@ sub setupboot_grub2 ($$$$) { die unless $entry->{Hv}; } + if ($need_uefi_chainload) { + die 'chainload entry not found' unless $chainentry; + + # Propagate relevant fields of the main entry over to the + # chain entry for use of subsequent code. + foreach (qw(KernVer KernDom0 KernOnly KernOpts + Initrd Xenpolicy)) { + next unless $entry->{$_}; + die if $chainentry->{$_}; + $chainentry->{$_} = $entry->{$_}; + } + + $entry = $chainentry; + } + return $entry; }; $bl->{UpdateConfig}= sub { my ( $ho ) = @_; + + target_editfile_root($ho, '/etc/default/grub', sub { + while (<::EI>) { + next if m/^export GRUB_ENABLE_XEN_UEFI_CHAINLOAD\=/; + print ::EO; + } + print ::EO "export GRUB_ENABLE_XEN_UEFI_CHAINLOAD=\"osstest\"\n" + if $need_uefi_chainload; + }); + target_cmd_root($ho, "update-grub"); + + if ($need_uefi_chainload) { + my $entry= $parsemenu->(); + my $xencfg = <<END; +[global] +default=osstest + +[osstest] +options=$xenhopt +kernel=vmlinuz $entry->{KernOpts} +END + $xencfg .= "ramdisk=initrd.gz\n" if $entry->{Initrd}; + $xencfg .= "xsm=xenpolicy\n" if $entry->{Xenpolicy}; + + target_putfilecontents_root_stash($ho,30,$xencfg, + "/boot/efi/EFI/osstest/xen.cfg"); + + # /boot/efi should be a mounted EFI system partition, and + # /boot/efi/EFI/osstest/xen.efi should already exist. Hence no mkdir + # here. + target_cmd_root($ho, + <<END.($entry->{Initrd}?<<END:"").($entry->{Xenpolicy}?<<END:"")); +set -ex +cp -vL /boot/$entry->{KernDom0} /boot/efi/EFI/osstest/vmlinuz #/ +END +cp -vL /boot/$entry->{Initrd} /boot/efi/EFI/osstest/initrd.gz #/ +END +cp -vL /boot/$entry->{Xenpolicy} /boot/efi/EFI/osstest/xenpolicy #/ +END + } }; $bl->{GetBootKern}= sub { return $parsemenu->()->{$kernkey}; };
overlay/etc/grub.d/20_linux_xen +21 -0
@@ -142,6 +142,27 @@ EOF } EOF } +chain_xen_entry () { + vendor="$1" + if [ ! -f /boot/efi/EFI/$vendor/xen.efi ] ; then + return + fi + title=$(gettext_quoted "Chainload $vendor Xen") + xmessage="$(gettext_printf "Chainloading $vendor Xen ...")" + printf "menuentry '${title}' ${CLASS} {\n" + prepare_grub_to_access_device \ + `${grub_probe} --target=device /boot/efi/EFI/$vendor/xen.efi` \ + | grub_add_tab + cat <<EOF + echo '$xmessage' + chainloader /EFI/$vendor/xen.efi +} +EOF +} + +for i in ${GRUB_ENABLE_XEN_UEFI_CHAINLOAD} ; do + chain_xen_entry $i +done linux_list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* /boot/kernel-*; do if grub_file_is_not_garbage "$i"; then
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2
Ian Campbell writes ("[PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2"):
Quoted 2 lines
Note that the 20_linux_xen change here is a bit specific to us and not really generic enough to go upstream IMHO, hence I haven't.
So if we accept this patch, we are committing to always having 20_linux_xen (and perhaps updating it to cope with new versions of grub). Originally having this file in osstest was intended as a stopgap, pending inclusion of a suitable file upstream.
Is there some upstream-friendly way of achieving the same thing ?
I'm not really sure what is specific to us' (or what us' here means
- osstest, or Xen on arm64, or ...?)
Thanks,
Ian.
Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2
Quoted 8 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2"):
Quoted 2 lines
Note that the 20_linux_xen change here is a bit specific to us and not really generic enough to go upstream IMHO, hence I haven't.
So if we accept this patch, we are committing to always having 20_linux_xen (and perhaps updating it to cope with new versions of grub). Originally having this file in osstest was intended as a stopgap, pending inclusion of a suitable file upstream.
I originally considered writing NN_osstest_uefi, but it looked like it was going to involve copying a fair bit of boilerplate from 20_linux_xen.
However, I've changed the approach I was using since then and now I suspect there wouldn't actually be much duplication. So unless you think otherwise I'll try that for next time around.
Quoted 1 line
Is there some upstream-friendly way of achieving the same thing ?
Not AFAIK. I could try upstreaming this but given that a) the user still needs to manually copy things to the ESP and create a suitable xen.cfg and b) people are working on a better way which will just work with the existing non-UEFI grub.cfg file entries, I'm not sure how much point there is.
Quoted 2 lines
I'm not really sure what is
specific to us' (or whatus' here means
- osstest, or Xen on arm64, or ...?)
All the paths are basically specific to us, just the general shape of the entry is more generically applicable.
http://wiki.xen.org/wiki/Xen_EFI already documents how to do things FWIW.
Ian.
Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2
Ian Campbell writes ("Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2"):
Quoted 8 lines · Ian Jackson
Quoted 1 line
Is there some upstream-friendly way of achieving the same thing ?
Not AFAIK. I could try upstreaming this but given that a) the user still needs to manually copy things to the ESP and create a suitable xen.cfg and b) people are working on a better way which will just work with the existing non-UEFI grub.cfg file entries, I'm not sure how much point there is.
I think "people are working on a better way" is what I was looking for. When that change comes along, we can remove 20_linux_xen ?
Quoted 5 lines
Quoted 2 lines
I'm not really sure what is
specific to us' (or whatus' here means
- osstest, or Xen on arm64, or ...?)All the paths are basically specific to us, just the general shape of the entry is more generically applicable.
`us' = osstest ? Xen ?
Ian.
Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2
Quoted 4 lines · Ian Jackson
Ian Campbell writes ("Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2"):
Quoted 3 lines · Ian Jackson
Quoted 1 line
Is there some upstream-friendly way of achieving the same thing ?
Quoted 8 lines
Quoted 5 lines
Not AFAIK. I could try upstreaming this but given that a) the user still needs to manually copy things to the ESP and create a suitable xen.cfg and b) people are working on a better way which will just work with the existing non-UEFI grub.cfg file entries, I'm not sure how much point there is.
I think "people are working on a better way" is what I was looking for. When that change comes along, we can remove 20_linux_xen ?
OK.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
I'm not really sure what is
specific to us' (or whatus' here means
- osstest, or Xen on arm64, or ...?)All the paths are basically specific to us, just the general shape of the entry is more generically applicable.
`us' = osstest ? Xen ?
Mostly osstest.
Quoted 2 lines
Ian.
Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2
Ian Campbell writes ("Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2"):
Quoted 5 lines · Ian Jackson
Quoted 2 lines
I think "people are working on a better way" is what I was looking for. When that change comes along, we can remove 20_linux_xen ?
OK.
By OK' do you mean yes' ?
Ian.
Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2
Quoted 8 lines · Ian Jackson
Ian Campbell writes ("Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2"):
Quoted 5 lines · Ian Jackson
Quoted 2 lines
I think "people are working on a better way" is what I was looking for. When that change comes along, we can remove 20_linux_xen ?
OK.
By
OK' do you meanyes' ?
I did, yes.
I'm still considering to split this stuff out anyway, but I'll talk to you f2f about that...
Ian.
Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2
In reply to Ian JacksonQuoted 4 lines · Ian Jackson
Ian Campbell writes ("Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2"):
Quoted 3 lines · Ian Jackson
Quoted 1 line
Is there some upstream-friendly way of achieving the same thing ?
Quoted 8 lines
Quoted 5 lines
Not AFAIK. I could try upstreaming this but given that a) the user still needs to manually copy things to the ESP and create a suitable xen.cfg and b) people are working on a better way which will just work with the existing non-UEFI grub.cfg file entries, I'm not sure how much point there is.
I think "people are working on a better way" is what I was looking for. When that change comes along, we can remove 20_linux_xen ?
Not sure if he speaks of Daniel and me doing things in that arena?
There is one outstanding patch for 20_linux_xen that adds the proper 'multiboot2' for the Xen?
Quoted 15 lines
Quoted 6 lines
Quoted 3 lines
I'm not really sure what is
specific to us' (or whatus' here means
- osstest, or Xen on arm64, or ...?)All the paths are basically specific to us, just the general shape of the entry is more generically applicable.
`us' = osstest ? Xen ?
Ian.
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2
Quoted 11 lines · Konrad Rzeszutek Wilk
Quoted 10 lines · Ian Jackson
Ian Campbell writes ("Re: [PATCH OSSTEST v3 21/22] Debian: Arrange to be able to chainload a xen.efi from grub2"):
Quoted 8 lines · Ian Jackson
Quoted 1 line
Is there some upstream-friendly way of achieving the same thing ?
Not AFAIK. I could try upstreaming this but given that a) the user still needs to manually copy things to the ESP and create a suitable xen.cfg and b) people are working on a better way which will just work with the existing non-UEFI grub.cfg file entries, I'm not sure how much point there is.
Quoted 4 lines
Quoted 2 lines
I think "people are working on a better way" is what I was looking for. When that change comes along, we can remove 20_linux_xen ?
Not sure if he speaks of Daniel and me doing things in that arena?
Yes, plus Fu Wei from Linaro's work on multiboot_xen for arm64.
Quoted 2 lines
There is one outstanding patch for 20_linux_xen that adds the proper 'multiboot2' for the Xen?
My assumption was that once these things landed that just running "update-grub" would result in a working grub.cfg config, which I would assume would need something in upstream grub's 20_linux_xen at least for the x86 case, yes.
Ian.
PATCH v3 22/22 Enable CONFIG_SPARSEMEM_VMEMMAP, arm64 seems to needs it (crashes).
In reply to Ian CampbellTODO: Find out why!
This is just a placeholder/reminder, do not apply.
--- ts-kernel-build | 3 +++ 1 file changed, 3 insertions(+)
ts-kernel-build +3 -0
@@ -552,6 +552,9 @@ setopt CONFIG_AHCI_XGENE y setopt CONFIG_POWER_RESET_XGENE y setopt CONFIG_RTC_DRV_XGENE y +#arm64 crashes without -- determine why +setopt CONFIG_SPARSEMEM_VMEMMAP y + case ${XEN_TARGET_ARCH} in x86_32) setopt CONFIG_64BIT n ;; x86_64)
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v3 22/22] Enable CONFIG_SPARSEMEM_VMEMMAP, arm64 seems to needs it (crashes).
Quoted 3 lines · Ian Campbell
TODO: Find out why!
This is just a placeholder/reminder, do not apply.
This turned out to be a known upstream issue (thanks to Mark Rutland for the tip) which has just been fixed for 4.2 and tagged for stable backport.
Ian.
Quoted 18 lines
--- ts-kernel-build | 3 +++ 1 file changed, 3 insertions(+)ts-kernel-build +3
-0@@ -552,6 +552,9 @@ setopt CONFIG_AHCI_XGENE y setopt CONFIG_POWER_RESET_XGENE y setopt CONFIG_RTC_DRV_XGENE y +#arm64 crashes without -- determine why +setopt CONFIG_SPARSEMEM_VMEMMAP y + case ${XEN_TARGET_ARCH} in x86_32) setopt CONFIG_64BIT n ;; x86_64)