Bug#903821: [Pkg-xen-devel] Bug#903821: linux-image-4.9.0-7-amd64: Can not boot 4.9.0_7_amd64 with Xen

[John Keates]

I’ll pile on top of this: domUs crash with the kernel as well, with a GPF. 
Looks like any Xen + 4.9.0-7 = Crash, regardless of it being a domU or dom0.

John

> On 15 Jul 2018, at 21:55, Sebastien KOECHLIN  wrote:
> 
> Package: src:linux
> Followup-For: Bug #903821
> 
> When booting with the new kernel, I got the following Dom0 crash:
> 
> Loading Xen 4.8-amd64 ...
> Loading Linux 4.9.0-7-amd64 ...
> Loading initial ramdisk ...
> (XEN) Xen version 4.8.4-pre (Debian 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9) 
> (ijack...@chiark.greenend.org.uk) (gcc (Debian 6.3.0-18+deb9u1) 6.3.0 
> 20170516) debug=n  Fri Jun 22 15:50:19 UTC 2018
> (XEN) Bootloader: GRUB 2.02~beta3-5
> (XEN) Command line: placeholder dom0_mem=4096M,max:4096M com2=57600,8n1 
> console=com2,vga
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: none; EDID transfer time: 2 seconds
> (XEN)  EDID info not retrieved because no DDC retrieval method detected
> (XEN) Disc information:
> (XEN)  Found 4 MBR signatures
> (XEN)  Found 4 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)   - 000a (usable)
> (XEN)  0010 - 7faa (usable)
> (XEN)  7faa - 7fab6000 (reserved)
> (XEN)  7fab6000 - 7fad5c00 (ACPI data)
> (XEN)  7fad5c00 - 8000 (reserved)
> (XEN)  e000 - f000 (reserved)
> (XEN)  fe00 - 0001 (reserved)
> (XEN)  0001 - 00068000 (usable)
> (XEN) ACPI: RSDP 000F23D0, 0024 (r2 DELL  )
> (XEN) ACPI: XSDT 000F245C, 00AC (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: FACP 7FAD34F8, 00F4 (r3 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: DSDT 7FAB6000, 3E0D (r1 DELL   PE_SC3  1 INTL 20050624)
> (XEN) ACPI: FACS 7FAD5C00, 0040
> (XEN) ACPI: APIC 7FAD3078, 008A (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: SPCR 7FAD3104, 0050 (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: HPET 7FAD3158, 0038 (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: MCFG 7FAD3194, 003C (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: WD__ 7FAD31D4, 0134 (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: SLIC 7FAD330C, 0024 (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: ERST 7FABBB88, 0210 (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: HEST 7FABBD98, 027C (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: BERT 7FABBA08, 0030 (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: EINJ 7FABBA38, 0150 (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: TCPA 7FAD3490, 0064 (r1 DELL   PE_SC3  1 DELL1)
> (XEN) ACPI: SSDT 7FAB9E0D, 0454 (r1 DELL   PE_SC3 11 INTL 20050624)
> (XEN) ACPI: SSDT 7FABA4B3, 0454 (r1 DELL   PE_SC3 11 INTL 20050624)
> (XEN) ACPI: SSDT 7FABAB59, 0454 (r1 DELL   PE_SC3 11 INTL 20050624)
> (XEN) ACPI: SSDT 7FABB1FF, 0454 (r1 DELL   PE_SC3 11 INTL 20050624)
> (XEN) ACPI: SSDT 7FABB8A5, 0162 (r1 DELL   PE_SC3 10 INTL 20050624)
> (XEN) System RAM: 24570MB (25159936kB)
> (XEN) Domain heap initialised
> (XEN) IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23
> (XEN) IOAPIC[1]: apic_id 5, version 32, address 0xfec1, GSI 256-279
> (XEN) IOAPIC[2]: apic_id 6, version 32, address 0xfec1, GSI 64-87
> (XEN) Enabling APIC mode:  Flat.  Using 3 I/O APICs
> (XEN) Failed to get Error Log Address Range.
> (XEN) xstate: size: 0x240 and states: 0x3
> (XEN) Unrecognised CPU model 0x17 - assuming vulnerable to LazyFPU
> (XEN) Speculative mitigation facilities:
> (XEN)   Hardware features:
> (XEN)   Compiled-in support: INDIRECT_THUNK
> (XEN)   Xen settings: BTI-Thunk RETP(XEN) Allocated console ring of 16 KiB.
> (XEN) VMX: Supported advanced features:
> (XEN)  - APIC MMIO access virtualisation
> (XEN)  - APIC TPR shadow
> (XEN)  - Virtual NMI
> (XEN)  - MSR direct-access bitmap
> (XEN) HVM: ASIDs disabled.
> (XEN) HVM: VMX enabled
> (XEN) HVM: Hardware Assisted Paging (HAP) not detected
> (XEN) Brought up 4 CPUs
> (XEN) Dom0 has maximum 856 PIRQs
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN)  Xen  kernel: 64-bit, lsb, compat32
> (XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x1f66000
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN)  Dom0 alloc.:   00066a00->00066c00 (1035540 pages to be 
> allocated)
> (XEN)  Init. ramdisk: 00067ed14000->00067e7e
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN)  Loaded kernel: 8100->81f66000
> (XEN)  Init. ramdisk: ->
> (XEN)  Phys-Mach map: 0080->00800080
> (XEN)  Start info:81f66000->81f664b4
> (XEN)  Page tables:   81f67000->81f7a000
> (XEN)  Boot stack:81f7a000->81f7b000
> (XEN)  TOTAL: 8000->8200
> (XEN)  ENTRY ADDRESS: 81d3d180
> (XEN) Dom0 has 

Bug#858962: [Pkg-xen-devel] Bug#858962: enabling OVMF - 4.10+

[John Keates]

Excellent! Good to see you got the serial console working as well. 
There are a bunch of extra options like allowing custom nvram per-vm (normally 
it’s just one read-only nvram for all instances),
but those aren’t important right now, basic EFI domu booting is pretty fair to 
get in Debian first.

John

> On 1 Mar 2018, at 00:14, Hans van Kranenburg <h...@knorrie.org> wrote:
> 
> Hey,
> 
> On 02/28/2018 12:59 AM, John Keates wrote:
>> 
>> [...]
>> 
>> 1. Install Xen with OVMF support
>> 2. Install OVMF (which basically just gets you the binary file, package is 
>> called ovmf)
>> 3. Get an EFI-bootable image, the Debian Netinstall image will probably do 
>> fine
>> 3. Create a domU config like this:
>> 
>> name = 'uefi-domu-thingy'
>> bios = "ovmf"
>> builder = 'hvm'
>> memory = '512'
>> vcpus = 1
>> 
>> Then sudo xl create 
>> 
>> This should start the domu, and since there is no disk, just get to the UEFI 
>> shell and idle around and not do much else. You can connect to it over VNC, 
>> but I’m sure it can be started in UEFI text mode too so you get UEFI access 
>> via the serial console.
> 
> Ok, as promised, I tried.
> 
> For Xen 4.10, I ended up with:
> 
> name = 'uefi-domu-thingy'
> bios = "ovmf"
> type = 'hvm'
> memory = '512'
> vcpus = 1
> vnc=1
> vnclisten='0.0.0.0'
> serial='pty'
> 
> I installed the qemu packages that Mark Pryor already rebuilt as test
> (which use libxen 4.10).
> 
> When doing xen create -c on that, I get a serial console to it:
> 
> UEFI Interactive Shell v2.2
> EDK II
> UEFI v2.70 (EDK II, 0x0001)
> Mapping table
> BLK0: Alias(s):
>  PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
> BLK1: Alias(s):
>  PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
> Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
> Shell>
> 
> A vnc connection also shows an ugly screen which a copy of the output.
> 
> Step 2: Use a disk
> 
> I simply added...
> disk = ['file:/yolo/ovmf/debian-9.3.0-amd64-netinst.iso,xvda']
> 
> and now the serial console shows a purple blinking cursor, and the vnc
> connection shows a graphical Debian GNU/Linux UEFI Installer menu.
> 
> Great success!
> 
> Hans

Bug#858962: [Pkg-xen-devel] Bug#858962: enabling OVMF - 4.10+

[John Keates]

HI Hans,

We probably should update the mailing list anyway since not everybody will be 
on GitLab anyway. Here is how you can test it:

1. Install Xen with OVMF support
2. Install OVMF (which basically just gets you the binary file, package is 
called ovmf)
3. Get an EFI-bootable image, the Debian Netinstall image will probably do fine
3. Create a domU config like this:

name = 'uefi-domu-thingy'
bios = "ovmf"
builder = 'hvm'
memory = '512'
vcpus = 1

Then sudo xl create 

This should start the domu, and since there is no disk, just get to the UEFI 
shell and idle around and not do much else. You can connect to it over VNC, but 
I’m sure it can be started in UEFI text mode too so you get UEFI access via the 
serial console.

If you want to test booting an OS, a simple way is starting debian. Grabbing 
the netinstall image works, add a disk stanza and there you go:

disk = ['file:/tmp/debian-9.3.0-amd64-netinst.iso,xvda’]

If you want to control the virtual frame buffer VNC setup:

vfb = ["type=vnc, vnclisten=0.0.0.0, vncpasswd=1337-haxx0r"]

If you also want to have some networking fun, you could add a virtual interface 
as normal:

vif = [ 'mac=00:16:3e:12:34:56, bridge=testlan0, script=vif-openvswitch, 
type=vif’]

By the way, if OVMF isn’t enabled or the ovmf.fd file doesn’t exist in the 
expected or configured path, it will error out.

- John

> On 28 Feb 2018, at 00:18, Hans van Kranenburg  wrote:
> 
> Hi John,
> 
> I don't think this will ever hit 4.8 in stable, but I want to have this
> in the new 4.10+ packages for unstable because you've been waiting long
> enough now.
> 
> Thanks for sending the Merge Request about this. Now the change will go
> in under your name. :)
> 
> I don't think that a discussion in gitlab on some commit that got
> rebased later is the best way, so let's continue here.
> 
> I know --enable-ovmf builds ok, now I need instructions to test this. I
> suspect you're on 4.8 and unless you have a spare test system already
> you might not want to be running random experimental test builds for
> 4.10. It also needs rebuilt qemu packages against xen 4.10.
> 
> So, what is the minimal set of things I can do to make sure the
> resulting build does something sensible? I have to be honest I'm not a
> qemu user myself, so I might not be totally familiar with all steps.
> 
> I see https://wiki.xenproject.org/wiki/OVMF which has an example, which
> also mentions use of a live CD.
> 
> Can you point me so something I can provide as a disk, and tell me if
> this is the right path to a minimal test to check that everything is
> working right?
> 
> Thanks,
> Hans
> 
> ___
> Pkg-xen-devel mailing list
> pkg-xen-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel

Bug#870001: openvswitch-switch: switch takes a very long time to start or fails without upstream's SYSTEMCTL_SKIP_REDIRECT=yes

[John Keates]

Package: openvswitch-switch
Version: 2.6.2~pre+git20161223-3
Severity: important

Dear Maintainer,

I setup openvswitch-switch with a small number of switches that have one 
physical interface each. Upon boot, they get configured extremely slow, taking 
over half an hour to get basic networking up.

On IRC and the upstream repository, I found out that systemd now needs 
SYSTEMCTL_SKIP_REDIRECT=yes on newer systems, on top of the existing 
_SYSTEMCTL_SKIP_REDIRECT=yes. This is added in the upstream version, but not in 
the current versions in Stretch, Buster or Sid.

Adding this makes the system configure the switches and interfaces in about 2 
seconds and everything works perfectly fine. Reportbug attached the 
modification as well, but since it is already known upstream this should be old 
news.

Regards,
John

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/40 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openvswitch-switch depends on:
ii  kmod   23-2
ii  libatomic1 6.3.0-18
ii  libc6  2.24-11+deb9u1
ii  libpython2.7-stdlib [python-argparse]  2.7.13-2
ii  netbase5.4
ii  openvswitch-common 2.6.2~pre+git20161223-3
ii  procps 2:3.3.12-3
ii  python 2.7.13-2
ii  uuid-runtime   2.29.2-1

openvswitch-switch recommends no packages.

openvswitch-switch suggests no packages.

-- Configuration Files:
/etc/init.d/openvswitch-switch changed:
(test -x /usr/sbin/ovs-vswitchd && test -x /usr/sbin/ovsdb-server) || exit 0
_SYSTEMCTL_SKIP_REDIRECT=yes
SYSTEMCTL_SKIP_REDIRECT=yes
. /usr/share/openvswitch/scripts/ovs-lib
test -e /etc/default/openvswitch-switch && . /etc/default/openvswitch-switch
network_interfaces () {
INTERFACES="/etc/network/interfaces"
[ -e "${INTERFACES}" ] || return
bridges=`ifquery --allow ovs --list`
[ -n "${bridges}" ] && $1 --allow=ovs ${bridges}
}
load_kmod () {
ovs_ctl load-kmod || exit $?
}
start () {
if ovs_ctl load-kmod; then
:
else
echo "Module has probably not been built for this kernel."
if ! test -d /usr/share/doc/openvswitch-datapath-source; then
echo "Install the openvswitch-datapath-source package, then read"
else
echo "For instructions, read"
fi
echo "/usr/share/doc/openvswitch-datapath-source/README.Debian"
if test X"$OVS_MISSING_KMOD_OK" = Xyes; then
# We're being invoked by the package postinst.  Do not
# fail package installation just because the kernel module
# is not available.
exit 0
fi
fi
set ovs_ctl ${1-start} --system-id=random
if test X"$FORCE_COREFILES" != X; then
set "$@" --force-corefiles="$FORCE_COREFILES"
fi
set "$@" $OVS_CTL_OPTS
"$@" || exit $?
if [ "$2" = "start" ] && [ "$READ_INTERFACES" != "no" ]; then
network_interfaces ifup
fi
}
stop () {
[ "$READ_INTERFACES" != "no" ] && network_interfaces ifdown
ovs_ctl stop
}
restart () {
# OVS_FORCE_RELOAD_KMOD can be set by package postinst script.
if [ "$1" = "--save-flows=yes" ] || \
[ "${OVS_FORCE_RELOAD_KMOD}" = "no" ]; then
start restart
elif [ "${OVS_FORCE_RELOAD_KMOD}" = "yes" ]; then
depmod -a
if [ -e /sys/module/openvswitch ]; then
LOADED_SRCVERSION=`cat /sys/module/openvswitch/srcversion \
   2>/dev/null`
LOADED_VERSION=`cat /sys/module/openvswitch/version \
2>/dev/null`
fi
SRCVERSION=`modinfo -F srcversion openvswitch 2>/dev/null`
VERSION=`modinfo -F version openvswitch 2>/dev/null`
ovs_ctl_log "Package upgrading:\n"\
"Loaded version: ${LOADED_VERSION} ${LOADED_SRCVERSION}.\n"\
"Version on disk: ${VERSION} ${SRCVERSION}."
# If the kernel module was previously loaded and it is different than
# the kernel module on disk, then do a 'force-reload-kmod'.
if [ -n "${LOADED_SRCVERSION}" ] && [ -n "${SRCVERSION}" ] && \
[ "${SRCVERSION}" != "${LOADED_SRCVERSION}" ]; then
start force-reload-kmod
else
start restart
fi
else
READ_INTERFACES="no" stop
READ_INTERFACES="no" start
fi
}
case $1 in
start)
start
;;
stop | force-stop)
stop
;;
reload | force-reload)
# The OVS daemons keep up-to-date.
;;
restart)
shift
restart "$@"
;;
status)
  

Bug#863198: [Pkg-xen-devel] Bug#863198: Xen compiling with XSM on

[John Keates]

Have you tried building the package instead? I find that ‘make install’ often 
doesn’t do what you expect when a project is engineered to work as a package.

Try the following:

- run apt-get source and apt-get build-sep as you did
- Edit rules.real in the debian directory, you can add configure settings in 
there as well
- run debuild  or dpkg-buildpackage -us -uc to get .deb packages with your 
changes

you then end up with ‘normal’ debian packages you can install using dpkg -i.

John

> On 23 May 2017, at 12:32, Hervé Moris  wrote:
> 
> Package: xen
> 
> Version: 4.8.1
> OS : Debian Jessie 8.8 (stable), testing repository enabled in sources.list 
> to download xen-4.8.1
> 
> 
> I'm trying to install xen with XSM Flask module on.
> Following, the instructions I did :
> 
> apt-get build-dep xen
> apt-get source xen
> cd xen-4.8.1
> vim.tiny Configure.mk (and added XSM_ENABLE ?=y and FLASK_ENABLE ?=y)
> make clean
> ./configure --enable-xen --enable-tools --enable-xsm
> make
> make install
> update grub
> reboot
> After the reboot, debian with hypervisor starts but I'm unable to launch xl 
> command and xenstore-ls gives no answer. 
> Am I missing something ?
> 
> Regards,
> 
> Hervé
> 
> uname -a : Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 
> GNU/Linux
> ___
> Pkg-xen-devel mailing list
> pkg-xen-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel

Bug#858962: [Pkg-xen-devel] Bug#858962: Request: enable OVMF at build time in 4.8 as it does not require non-free anymore

[John Keates]

>> I'm not sure how to create a .patch file for this, but since it's one line 
>> with very clear results, I hope it's sufficient.
> 
> Indeed.
> 
> However: I do not intend to make this change at this stage of the
> stretch release freeze.

I suppose that makes sense since in a freeze you wouldn’t want ‘new’ features 
added.

> If you (or someone else) gets preapproval from the release team, then
> I would be prepared to do.  But I think such approval would probably
> be refused for good reasons.  If someone wants to make such an
> approval request, please let me know and I may be able to help
> pre-review it etc. - on the condition that this isn't taken as
> endorsement :-).
> 
> Thanks,
> Ian.

I really think this should be enabled, it’s side-effects are nil by default as 
far as I know, and it’s been in there for a long time, but simply not enabled.
Enabling this will allow virtualisation of operating systems that don’t support 
BIOS-style machine firmware in HVM mode. On top of that, it allows
virtualising Apple’s macOS since that requires EFI. Legally, that requires 
Debian to be installed in Apple hardware, which happens to be what I’m doing, 
so that’s fine too.

Some Windows variants will only boot on EFI enabled machines too, so there is a 
need for OVMF there as well. Currently, some people resort to using KVM since 
it works there,
but I’d rather see it working with Xen. Same goes for some ARM setups where you 
can’t boot HVM machines without EFI.

Where would I go to make a request for approval from the release team?

Thanks,
John


> On 29 Mar 2017, at 12:51, Ian Jackson <ian.jack...@eu.citrix.com> wrote:
> 
> Control: tags -1 patch
> 
> John Keates writes ("Bug#858962: Request: enable OVMF at build time in 4.8 as 
> it does not require non-free anymore"):
>> Package: src:xen
>> Version: 4.8.1~pre.2017.01.23-1
>> Severity: wishlist
> 
> Hi.  Thanks for the report.
> 
>> Currently, OVMF is not enabled, probably because it used to require
>> OVMF at compile time which would make for a hard dependency on
>> non-free code. Since this is no longer the case, you could make it a
>> run-time option by enabling OVMF for this package, and when a user
>> would want to actually use it, they would only need to add a OVMF
>> binary to a preset path themselves (i.e. by installing the non-free
>> ovmf package).
> 
> I looked into this OVMF nonfreeness and it seems to be fixed:
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815618
> 
>> Around line 74 the compile-time options for Xen are listed, and enabling 
>> OVMF is as simple as adding one line:
>> 
>>   --enable-ovmf --with-system-ovmf=/usr/share/ovmf/OVMF.fd
>> 
>> The path specified does not need to exist at compile time. In this
>> case I chose to use the path where the OVMF package installs the
>> binary firmware file so it can be automatically used.
> 
> Thanks for this testing.
> 
> I think that, given that UEFI is becoming quite common, it might be
> worth adding a dependency of some kind to the Debian Xen packages, as
> well as simply enabling ovmf support.  But that's probably not a
> blocker for fixing this.
> 
>> I'm not sure how to create a .patch file for this, but since it's one line 
>> with very clear results, I hope it's sufficient.
> 
> Indeed.
> 
> However: I do not intend to make this change at this stage of the
> stretch release freeze.
> 
> If you (or someone else) gets preapproval from the release team, then
> I would be prepared to do.  But I think such approval would probably
> be refused for good reasons.  If someone wants to make such an
> approval request, please let me know and I may be able to help
> pre-review it etc. - on the condition that this isn't taken as
> endorsement :-).
> 
> Thanks,
> Ian.
> 
> ___
> Pkg-xen-devel mailing list
> pkg-xen-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel

Bug#858962: Request: enable OVMF at build time in 4.8 as it does not require non-free anymore

[John Keates]

Package: src:xen
Version: 4.8.1~pre.2017.01.23-1
Severity: wishlist

Dear Maintainer,

In Xen 4.8 it is possible to enable OVMF without the need for any OVMF code or 
binary to be on the system.
Currently, OVMF is not enabled, probably because it used to require OVMF at 
compile time which would
make for a hard dependency on non-free code. Since this is no longer the case, 
you could make it a run-time
option by enabling OVMF for this package, and when a user would want to 
actually use it, they would only need
to add a OVMF binary to a preset path themselves (i.e. by installing the 
non-free ovmf package).

I tested this on a strech machine, by getting the sources using apt-get source 
and editing debian/rules.real.
Around line 74 the compile-time options for Xen are listed, and enabling OVMF 
is as simple as adding one line:

--enable-ovmf --with-system-ovmf=/usr/share/ovmf/OVMF.fd

The path specified does not need to exist at compile time. In this case I chose 
to use the path where the OVMF package
installs the binary firmware file so it can be automatically used.

I'm not sure how to create a .patch file for this, but since it's one line with 
very clear results, I hope it's sufficient.

Regards,
John Keates

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (650, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

xen-hypervisor-4.8-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.8-amd64 recommends:
ii  xen-utils-4.8  4.8.1~pre.2017.01.23-1

xen-hypervisor-4.8-amd64 suggests no packages.

-- Configuration Files:
/etc/default/grub.d/xen.cfg changed [not included]

-- no debconf information

Bug#852069: [Pkg-xen-devel] Bug#852069: DomU guests with pygrub as bootloader do not start after, upgrade from Xen 4.1 (wheezy) to Xen 4.4 (jessie)

[John Keates]

On 23 Jan 2017, at 16:14, Ian Jackson  wrote:
> 
> Michael Bilow writes ("Bug#852069: DomU guests with pygrub as bootloader do 
> not start after, upgrade from Xen 4.1 (wheezy) to Xen 4.4 (jessie)"):
>> Under Xen 4.1 in Debian 7 (wheezy), the following works when included in a
>> DomU configuration in "/etc/xen/cfg/" --
>> 
>>  bootloader   = '/usr/lib/xen-default/bin/pygrub'
>> 
>> After upgrading to Xen 4.4 as part of an upgrade to Debian 8 (jessie), the
>> DomU silently fails to start. Examination of the log files shows that the
>> cause is that the old path for "bootloader" no longer exists. Correcting the
>> DomU configuration manually to the new path works --
>> 
>>  bootloader   = '/usr/lib/xen-4.4/bin/pygrub'
>> 
>> I would assume that creating a symlink would work also, and perhaps the
>> package installer should do it (in "/usr/lib", "ln -s xen-4.4 xen-default").
> 
> Thanks for the report.
> 
> Nowadays the right way to configure this is to say just
> 
>  bootloader = "pygrub"
> 
> This will work with the packages I have prepared for Debian stretch
> (aka testing).  But TBH I'm not sure that will work with the packages
> in jessie.
> 
> Can you try that and let me know if it works ?
> 
> Thanks,
> Ian.
> 
> ___
> Pkg-xen-devel mailing list
> pkg-xen-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel

That works on Jessie as well using 4.4.1-9+deb8u7.

John

Bug#778990: gdm3 login crashes when logging in to gnome-shell

[John Keates]

Package: gdm3
Version: 3.14.1-3
Severity: normal

Dear Maintainer,


I upgraded my system from Wheezy to Jessie a few months ago, but as of a few 
weeks I cannot
log in to gnome-shell from gdm3 anymore. Changing the session to Gnome on 
Wayland does log 
me in to a Wayland session, but the normal Gnome login causes a segfault:

pool[3144]: segfault at 198 ip 7fc31a3c24a4 sp 7fc315857d58 error 4 in 
libc-2.19.so[7fc31a346000+19f000]

The strange thing is that sometimes it's in libc, and sometimes it's in 
freetype.
I tried logging in into a fresh account, but that doesn't change anything. A 
fresh install on
a separate disk does not have the problem.

Curiously, going to tty1 and running startx gets me a gnome-shell just fine.
Gnome-session, however does not work from a tty to start a gnome session.

I have asked around on IRC, but after plenty of digging nothing has come up, 
and segfaults point to a code or linking error. Aside from the segfault I
don't get anything useful in the logs to point me to the origin of this bug.

If this was reported earlier on, I could not find it in the current bug list,
and if this is a configuration error, I'm sorry for reporting a bug, however,
a configuration error should ofcourse not lead to constant segfaults, which
would be a bug by itself.

Thanks.

-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.37-3+b1
ii  adduser   3.113+nmu3
ii  dconf-cli 0.22.0-1
ii  dconf-gsettings-backend   0.22.0-1
ii  debconf [debconf-2.0] 1.5.55
ii  gir1.2-gdm3   3.14.1-3
ii  gnome-session [x-session-manager] 3.14.0-2
ii  gnome-session-bin 3.14.0-2
ii  gnome-settings-daemon 3.14.2-2
ii  gnome-shell   3.14.2-3+b1
ii  gnome-terminal [x-terminal-emulator]  3.14.1-1
ii  gsettings-desktop-schemas 3.14.1-1
ii  libaccountsservice0   0.6.37-3+b1
ii  libaudit1 1:2.4-1+b1
ii  libc6 2.19-13
ii  libcanberra-gtk3-00.30-2.1
ii  libcanberra0  0.30-2.1
ii  libgdk-pixbuf2.0-02.31.1-2+b1
ii  libgdm1   3.14.1-3
ii  libglib2.0-0  2.42.1-1
ii  libglib2.0-bin2.42.1-1
ii  libgtk-3-03.14.5-1
ii  libpam-modules1.1.8-3.1
ii  libpam-runtime1.1.8-3.1
ii  libpam-systemd215-11
ii  libpam0g  1.1.8-3.1
ii  librsvg2-common   2.40.5-1
ii  libselinux1   2.3-2
ii  libsystemd0   215-11
ii  libwrap0  7.6.q-25
ii  libx11-6  2:1.6.2-3
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.1-1+b1
ii  libxrandr22:1.4.2-1+b1
ii  lsb-base  4.1+Debian13+nmu1
ii  metacity [x-window-manager]   1:3.14.3-1
ii  mutter [x-window-manager] 3.14.2-1
ii  policykit-1   0.105-8
ii  ucf   3.0030
ii  x11-common1:7.7+7
ii  x11-xserver-utils 7.7+3+b1
ii  xterm [x-terminal-emulator]   312-1

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.14.0-1
ii  desktop-base   8.0.2
ii  gnome-icon-theme   3.12.0-1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  x11-xkb-utils  7.7+1
ii  xserver-xephyr 2:1.16.4-1
ii  xserver-xorg   1:7.7+7
ii  zenity 3.14.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.14.0-3
ii  libpam-gnome-keyring  3.14.0-1+b1

-- Configuration Files:
/etc/gdm3/Init/Default [Errno 2] No such file or directory: 
u'/etc/gdm3/Init/Default'
/etc/gdm3/PostLogin/Default.sample [Errno 2] No such file or directory: 
u'/etc/gdm3/PostLogin/Default.sample'
/etc/gdm3/PostSession/Default [Errno 2] No such file or directory: 
u'/etc/gdm3/PostSession/Default'
/etc/gdm3/PreSession/Default [Errno 2] No such file or directory: 
u'/etc/gdm3/PreSession/Default'
/etc/gdm3/Xsession [Errno 2] No such file or directory: u'/etc/gdm3/Xsession'
/etc/gdm3/daemon.conf [Errno 2] No such file or directory: 
u'/etc/gdm3/daemon.conf'

-- debconf 

Bug#703586: [Pkg-xen-devel] Bug#703586: Bug#703586: Xen fails to boot Linux dom0 under UEFI

[John Keates]

On Wed, 10 Sep 2014 20:22:54 +0100 Ian Campbell i...@hellion.org.uk wrote:
 On Sun, 2014-09-07 at 13:42 +0200, John Keates wrote:
  1. Rebuild the debian package with a small change
  
  Do your usual apt-sourcing and build-depping, but add the pep target to 
  debian/rules:
  
  (I put it right underneath include debian/rules.defs)
  
  DEB_CONFIGURE_EXTRA_FLAGS  += --enable-targets=x86_64-pep
 
 This isn't actually necessary, the Xen build will automatically produce
 xen.efi if the tools are new enough and contain the necessary support.
 --enable-targets=x86_64-pep is actually something which needs to be
 passed to the *binutils* configure, and this is done on Debian.
 
  then do your usual binary run to produce the files needed.
  You’ll find xen.efi in 
  ./debian/build/build-hypervisor_amd64_amd64/xen/xen.efi
 
 It turns out that the Debian build is already building xen.efi today, it
 just isn't putting it in the package!
 
 I think it would be sensible to pickup this binary for inclusion, either
 in the existing xen-hypervisor package or into a new EFI package.
 

Ah, okay, I didn’t notice that. In that case, including xen.efi should even be 
easier. Pretty much one additional line for the package maintainer right?

  2. Allow UEFI to find your xen.efi
  
  UEFI uses your ESP to launch the efi binaries, so that’s where it needs to 
  go.
  Simply put (not symlink) xen.efi in /boot/efi/EFI/debian/
 
 This should be taken care of by packaging it in the right place, I
 think, or possibly by the postinst moving it there.
 

Yes indeed. And since the installation of Xen on an EFI platform can be 
detected fairly easily, this also shouldn’t take more than 4 of 5 lines for 
postinst.

  3. Configure dom0 booting
 
 This and the rest would need a bit more infrastructure putting into
 place to do automagically, which I don't see happening for Jessie given
 the looming freeze, but at least by packaging the xen.efi binary we can
 simplify things for people who want to set this stuff up themselves.
 
 Hopefully for Jessie+1 grub will be able to launch xen.efi itself, and
 most of this will go away.
 
 Ian.
 

Well, there is one more thing: If kernel 3.17 manages to get in before the 
kernel freeze, full-fledged Xen-EFI support will be baked into the kernel by 
default!
3.17 has been patched to provider hypercall support for Xen to get the efivars 
facility (and pretty much anything and everything else EFI) working for Dom0.

Now, I’ve seen some messages on the mailing list where three people actually 
want to freeze the kernel on 3.16, but since 3.17 is on RC4 already and due to 
be 
released really soon (like, in 4 to 5 weeks) with a bit of luck 3.17 might be 
decided upon instead of 3.16. Besides Xen EFI support, it brings a ton of 
really important updates as well that are beneficial for everyone.

Ideally we get the following:

- fix for including xen.efi in the package
- patch for postinst that detects the EFI ESP and copies xen.efi over there and 
adds an efibootmgr entry
- maybe a simple management script that generates xen.cfg and allows the user 
to set Xen as the first boot option?
- kernel 3.17 so after booting into dom0 EFI is still accessible and the 
efibootmgr still works

But having xen.efi in the package would be a ton of help already. Who do I 
stalk to make that happen?

John

 
 





smime.p7s
Description: S/MIME cryptographic signature

Bug#703586: [Pkg-xen-devel] Bug#703586: Xen fails to boot Linux dom0 under UEFI

[John Keates]

I’ll explain what’s happening first, and list the steps after that.

First: pep is short for the Xen target x86_64-pep. It’s a target you can enable 
when configuring Xen to create an EFI binary.

What is happening with Xen on UEFI via Grub is that it doesn’t give the kernel 
any info on the ACPI root pointer.
Basically, this means that Linux won’t be able to do ACPI, and therefore a ton 
of hardware functionality is lost.
The reason why this used to happen was the fact that Xen got a e-801 map from 
Grub for some reason.
Not sure if that exact issue is still the source of this current issue, but Xen 
via Grub on EFI simply doesn’t work.

But when you use Xen on UEFI via the EFI binary (xen.efi) it works just fine, 
the kernel gets to know about RSDP so it can do it’s ACPI stuff.

Loading xen.efi can be done in different ways. The fastest way is to let 
efibootmgr know about it and booting it directly.
Alternatively, you can simply test it by manually loading it from the UEFI 
shell, and as a third option, you can EFI chain load it from Grub.
The chain loading pretty much means that grubx64.efi loads xen.efi just as you 
would from the shell or the bootmgr.

There is one small catch: Xen on native EFI doesn’t give you a normal efivars 
system in dom0.
This has to be fixed on a lower level in either Linux or Xen. From what I’ve 
found out so far, the efivars are passed in a different way to Linux,
but Linux doesn’t know about it and therefore cannot use it. This is the only 
downside to the whole thing. However, if you only want to boot using the EFI 
boot menu, this is not really a problem: you can still choose to boot xen.efi 
or grubx64.efi and when you boot grub and a non-Xen entry, you can use efivars 
(and efibootmgr) all you want.

Steps:

1. Rebuild the debian package with a small change

Do your usual apt-sourcing and build-depping, but add the pep target to 
debian/rules:

(I put it right underneath include debian/rules.defs)

DEB_CONFIGURE_EXTRA_FLAGS  += --enable-targets=x86_64-pep

then do your usual binary run to produce the files needed.
You’ll find xen.efi in ./debian/build/build-hypervisor_amd64_amd64/xen/xen.efi

2. Allow UEFI to find your xen.efi

UEFI uses your ESP to launch the efi binaries, so that’s where it needs to go.
Simply put (not symlink) xen.efi in /boot/efi/EFI/debian/

3. Configure dom0 booting

In order for Xen to boot your dom0, you’ll have to do two things:

- Get the kernel and initrd on the ESP as well
- Configure Xen to load a specific kernel and initrd

The kernel and initrd are easy, just copy them from /boot/ to 
/boot/efi/EFI/debian/
I used my most current kernel and initrd.

Xen.efi configuration is easy as well, since you only need to create a short 
ini-style cfg file.
This configuration file needs to be on your ESP as well, with the kernel, 
initrd and xen.efi files.
All in the same directory!

Xen.cfg is fairly straightforward, I’ll just put mine here:

[global]
default=debian8

[debian8]
options=console=vga,com1 com1=115200 loglvl=all noreboot
kernel=vmlinuz-3.14-2-amd64 ignore_loglevel  root=/dev/mapper/clava-root ro 
quiet #earlyprintk=xen
ramdisk=initrd.img-3.14-2-amd64

And that’s it! Xen.efi now boots super-fast, dom0 gets booted really fast as 
well, everything is working!

Now, instead of messing around in the UEFI setup ROM to create a boot entry, 
you might as well do it from your non-xen system while it’s still booted.
Simply add an entry with efibootmgr:

sudo efibootmgr -c -g -d /dev/sda -p 1 -w -L Xen EFI Loader -l 
'\EFI\debian\xen.efi'

Where /dev/sda is the disk with the partition containing your ESP and -p 1 is 
set to the partition number for that ESP partition (in my cast it’s partition 
1).

You can make the Xen entry the default or just manually boot it whenever you 
want.
Buy the way, if you run a grub-update right now, it’ll find your efibootmgr 
entry and add it to the list for chainloading.

The end.


Well, almost, because those manual steps are pretty easy to incorporate in the 
related packages.

First: xen-4.4.0 simply needs to enable the target x86_64-pep by default. 
Without it no Xen EFI.

Second: The package that creates the grub.d xen_linux snippet might be extended 
to move xen.efi, vmlinuz, initrd and a xen.cfg to the ESP

Kernel commandline options can be taken from /proc/cmdline and/or grub’s 
/etc/default/grub and added to the xen.cfg automatically.
The efibootmgr entry can be added automatically as well.

I don’t have a patch handy right here, I use a hackish bash script for now to 
produce the desired results for any servers I set up that have UEFI without CSM 
but need to run Xen. A patch would be pretty neat of course. I don’t really 
know how to make official patches for debian packages, but if nobody wants to 
do it, I can give it a go, manuals and tutorials everywhere anyway.

John

On 07 Sep 2014, at 08:12, Ian Campbell i...@hellion.org.uk wrote:

 On Sun, 2014-09-07 at 00:02 +0200, John Keates wrote:
 How do I

Bug#703586: [Pkg-xen-devel] Bug#703586: Xen fails to boot Linux dom0 under UEFI

[John Keates]

As an addition to anyone having issues with booting but only getting 1 CPU and 
a ton of devices that misbehave,
check to see if you have an RSDP in Xen and Linux.

You should have both (I use xl and not xm):

sudo xl dmesg | grep RSDP
(XEN) ACPI: RSDP DDA4A000, 0024 (r2 SUPERM)

and

sudo dmesg | grep RSDP
[0.00] ACPI: RSDP 000f0010 24 (v02 SUPERM)

I’m running this on a Supermicro X10SL7-F to be a bit more precise.

If you can’t boot at all, it probably means some essential parts of your system 
will only with with ACPI.
For example, your GPU might not be found without ACPI. (I don’t really know if 
that is true, just thinking out loud)
Another reason why booting might not work is if you have the older e-801 issue.

Both are solved with running Xen without Grub, straight on UEFI.

John

On Sun, 7 Sep 2014 13:42:46 +0200 John Keates j...@keates.nl wrote:
 Iíll explain whatís happening first, and list the steps after that.
 
 First: pep is short for the Xen target x86_64-pep. Itís a target you can 
 enable when configuring Xen to create an EFI binary.
 
 What is happening with Xen on UEFI via Grub is that it doesnít give the 
 kernel any info on the ACPI root pointer.
 Basically, this means that Linux wonít be able to do ACPI, and therefore a 
 ton of hardware functionality is lost.
 The reason why this used to happen was the fact that Xen got a e-801 map from 
 Grub for some reason.
 Not sure if that exact issue is still the source of this current issue, but 
 Xen via Grub on EFI simply doesnít work.
 
 But when you use Xen on UEFI via the EFI binary (xen.efi) it works just fine, 
 the kernel gets to know about RSDP so it can do itís ACPI stuff.
 
 Loading xen.efi can be done in different ways. The fastest way is to let 
 efibootmgr know about it and booting it directly.
 Alternatively, you can simply test it by manually loading it from the UEFI 
 shell, and as a third option, you can EFI chain load it from Grub.
 The chain loading pretty much means that grubx64.efi loads xen.efi just as 
 you would from the shell or the bootmgr.
 
 There is one small catch: Xen on native EFI doesnít give you a normal efivars 
 system in dom0.
 This has to be fixed on a lower level in either Linux or Xen. From what Iíve 
 found out so far, the efivars are passed in a different way to Linux,
 but Linux doesnít know about it and therefore cannot use it. This is the only 
 downside to the whole thing. However, if you only want to boot using the EFI 
 boot menu, this is not really a problem: you can still choose to boot xen.efi 
 or grubx64.efi and when you boot grub and a non-Xen entry, you can use 
 efivars (and efibootmgr) all you want.
 
 Steps:
 
 1. Rebuild the debian package with a small change
 
 Do your usual apt-sourcing and build-depping, but add the pep target to 
 debian/rules:
 
 (I put it right underneath include debian/rules.defs)
 
 DEB_CONFIGURE_EXTRA_FLAGS  += --enable-targets=x86_64-pep
 
 then do your usual binary run to produce the files needed.
 Youíll find xen.efi in ./debian/build/build-hypervisor_amd64_amd64/xen/xen.efi
 
 2. Allow UEFI to find your xen.efi
 
 UEFI uses your ESP to launch the efi binaries, so thatís where it needs to go.
 Simply put (not symlink) xen.efi in /boot/efi/EFI/debian/
 
 3. Configure dom0 booting
 
 In order for Xen to boot your dom0, youíll have to do two things:
 
 - Get the kernel and initrd on the ESP as well
 - Configure Xen to load a specific kernel and initrd
 
 The kernel and initrd are easy, just copy them from /boot/ to 
 /boot/efi/EFI/debian/
 I used my most current kernel and initrd.
 
 Xen.efi configuration is easy as well, since you only need to create a short 
 ini-style cfg file.
 This configuration file needs to be on your ESP as well, with the kernel, 
 initrd and xen.efi files.
 All in the same directory!
 
 Xen.cfg is fairly straightforward, Iíll just put mine here:
 
 [global]
 default=debian8
 
 [debian8]
 options=console=vga,com1 com1=115200 loglvl=all noreboot
 kernel=vmlinuz-3.14-2-amd64 ignore_loglevel  root=/dev/mapper/clava-root ro 
 quiet #earlyprintk=xen
 ramdisk=initrd.img-3.14-2-amd64


Met vriendelijke groet,

John Keates
Keates Creative Technology
06 52 633 813



smime.p7s
Description: S/MIME cryptographic signature

Bug#703586: Slight mistake in version difference

[John Keates]

I’m so sorry for mailing in a bunch of times, I now see that this is for a 
different version.
The UEFI bug is still valid, but the fix is only for Jessie (Xen 4.4+). Earlier 
Xen versions have no official EFI patches or support.
Sorry! I should probably find the bug report for Jessie + Xen 4.4 where the 
default setup with EFI and Xen is still broken…
It also requires a relatively new kernel (I’m using 3.14)…

Please disregard what I have added before, unless this ticket is valid for the 
testing release as well.

John

smime.p7s
Description: S/MIME cryptographic signature

Bug#703586: Xen fails to boot Linux dom0 under UEFI

[John Keates]

How do I assist with getting this in for Jessie?

I have this working in a fairly easy setup, it basically only requires the pep 
target to be on for debian’s Xen package,
and a tiny bit of infrastructure to get xen.efi, vmlinuz, an initrd and a 
xen.cfg on to the ESP partition and letting the efibootmgr know about it.

I already have a oneliner to do this manually, but it isn’t that hard to 
automate, unless that tiny bit of infrastructure regarding the kernel bits and 
efi boot is creating a ripple touching many other packages, or if there are 
rules I am not aware of that make this really hard to make conform to those 
rules.

John

smime.p7s
Description: S/MIME cryptographic signature